Hi all,
As some of you know, I have started university about a month ago. Due to
the amount of time I have to spend on university tasks these days, I can
no longer fulfil all my project obligations. Therefore, I'm looking for
new maintainers in the following areas:
* RosBE-Unix
* My Web tools (especially Testman and the rest of the regression
testing system, but also GetBuilds/People Map/Subsystem integration)
* Release Engineering (unless Ziliang can fully takeover my position)
Provided that I find time, I'll introduce the new maintainers into these
tasks as good as possible.
I try to stay available for infrastructure and foundation tasks, but my
time for these will definitely be limited as well.
Best regards,
Colin
Debug log from testing cmake soundchip in KSStudio.
http://www.reactos.org/paste/index.php/9568/
Btw i'm getting crash in cmuda.sys on two different PCs (though i didn't
notiv=ce if chips are the same)
To get your attention, Johannes ;)
Am 16.11.2011 22:17, schrieb tfaber(a)svn.reactos.org:
> Author: tfaber
> Date: Wed Nov 16 21:17:38 2011
> New Revision: 54401
>
> URL: http://svn.reactos.org/svn/reactos?rev=54401&view=rev
> Log:
> [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474)
> [NDK] - Remove meaningless const attribute from pointer rvalues to make Coverity's life easier
> -#define SharedUserData ((KUSER_SHARED_DATA *CONST)USER_SHARED_DATA)
> +#define SharedUserData ((KUSER_SHARED_DATA *)USER_SHARED_DATA)
It is like this (with the const) in wdm.h
#define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA)
maybe its supposed to express that "SharedUserData" is a constant and
not a variable... although that doesn't make much sense
>The Total Commander comboboxes for the left and right drive list
>are Unicode. However, Total Commander calls
>SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
>to add items as ANSI text. This seems to work, but it's adding some
>extra text at the end.
If I understand correctly, Total Commander is calling SendMessage, which in
this case is translated to SendMessageW (as the comboboxes are Unicode).
So TC is calling SendMessageW to append an ANSI string to a Combobox.
Let's give a look to SendMessageW implementation thanks to Doxygen:
http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88…
02161 Result = NtUserMessageCall( Wnd,
02162 KMMsg.message,
02163 KMMsg.wParam,
02164 KMMsg.lParam,
02165 (ULONG_PTR)&Result,
02166 FNID_SENDMESSAGE,
02167 FALSE);
Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall.
But in this case the BOOL ANSI should be TRUE as the string is really ANSI.
So since this moment we are treating TC call ( SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); )
in the same way as we would be treating SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext);
This seems a bug for me.
Feel free to correct me, but seems that SendMessageW is able to set both kind
of strings ANSI and UNICODE in Windows, while we are forcing to our
SendMessageW implementation to treat them as UNICODE always.
Am I wrong?
This could be a big potential issue as this could affect to all the SendmessageW calls.
This is all just a guess, so please feed me with your knowledge.
Thanks a lot!
Hi all,
Looking at
https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev, we
have scored the 810th place in the tough competition and just won 1000
EUR for the foundation! :-)
Even if we lost our position in the top of the list, comparable German
Open-Source foundations like KDE e.V. or Free Software Foundation Europe
are both out of the game.
I'd like to use this opportunity to thank every voter for the great
support towards the project! Over 8000 votes in four weeks really shows
that we still have a huge fan base.
Best regards,
Colin
I'm getting questions, if it's "just formatting and no code changes",
why author names are removed for good and not readded in the new file?
WBR,
Aleksey Bragin.
On 07.11.2011 3:01, ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Sun Nov 6 23:01:04 2011
> New Revision: 54323
>
> URL: http://svn.reactos.org/svn/reactos?rev=54323&view=rev
> Log:
> [KERNEL32]: Move the "curdir.c" APIs into path.c as well, as they are Path APIs. No code changes (just formatting and moving to DPRINTs).
> Removed: trunk/reactos/dll/win32/kernel32/client/file/curdir.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/…
> ==============================================================================
> --- trunk/reactos/dll/win32/kernel32/client/file/curdir.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/kernel32/client/file/curdir.c (removed)
> @@ -1,388 +1,0 @@
> -/* $Id$
> - *
> - * COPYRIGHT: See COPYING in the top level directory
> - * PROJECT: ReactOS system libraries
> - * FILE: lib/kernel32/file/curdir.c
> - * PURPOSE: Current directory functions
> - * PROGRAMMER: Eric Kohl
> - * Filip Navara
> - * Steven Edwards
> - * Thomas Weidenmueller
> - * Gunnar Andre' Dalsnes
> - * UPDATE HISTORY:
> - * Created 30/09/98
> - */
>
Hi!
What I have run across in regards of ReactOS send message subsystem,
ros is not packing before co_MsqSendMessage and unpacking after
co_IntCallWindowProc! Instead packing before co_IntCallWindowProc with
send message. Does that not raise any questions?
co_IntSendMessageWithCallBack seems to do it almost right, but
IntCallWndProc/Ret should be called when calling the client via
co_IntCallWindowProc and should pack before the call to MsqWakeQueue
and then unpack after the call to co_IntCallWindowProc. Confused?
Basing this on IntCallLowLevelEvent and co_IntCallLowLevelHook when
the lParam is used to save information that could get lost in a stack
switch or release.
Setting up the pattern; Pack before co_MsqSendMessage or related
friends and Unpack after calling co_IntCallWindowProc to client. Have
co_MsqDispatchOneSentMessage call something other than
co_IntSendMessage so the Packed data can be handled correctly when
calling to the client via co_IntCallWindowProc.
I'm sure Michael Martin has brought this up to me on many occasions.
Let's see where this goes!
Thanks,
James
Hi,
the Linux build slave will be relocated (changing data center & country)
starting tomorrow. It will, obviously, be offline during the meantime.
So, you will not have any Linux builds nor KVM tests.
We will do our best to get it back online as soon as possible.
Regards,
The ReactOS Sysadmins.
Hello all,
Here are the minutes from the last ReactOS meeting on the 27th of October
2011:
20:20 Aleksey Bragin called the meeting to order
- Aleksey Bragin shared a video interview about ReactOS at
http://alenapopova.ru/egov/react-os-kraudsorsing-pri-sozdanii-operacionnoj-…
- Aleksey Bragin stated the meeting agenda as being:
1. Website revamp status
2. CMake adoption
3. Release status
1. Website Revamp
-----------------
- Amine Khaldi started on the Website revamp status and stated that
unfortunately nothing has progressed since the last meeting because of
aross, superdog and nisky being extremely busy.
- He also stated that Aleksey has yet to commit the bridges needed and
that the actual milestone is the theme (ie design/layout that matches
the current website), after which devs will need to investigate phpbb
issue.
- Aleksey Bragin added that almost the only thing left is the theme
and with it progress could be made fast to the website engine and have
a test run with real data.
- He also stated that all details could be provided to anyone
motivated enough with HTML/CSS.
- Matthias Kupfer said he could support HTML/CSS around Christmas, but
not earlier.
- Aleksey Bragin asked Maciej Bialas if he could assist in theming.
- Maciej Bialas said he could, and added that he tried to create a
simple theme first resembling the current one, and that aross said he
could have done better by using some Drupal modules Maciej was not
aware of.
- Aleksey Bragin stated that a simple theme would suffice for now and
a better one can always be done later.
- Ziliang Guo asked about user and forum transfer status.
- Aleksey Bragin replied that the forum is phpbb and therefore easily
transferable
- Ziliang Guo asked about the reason for sticking with phpbb.
- Amine Khaldi and Aleksey Bragin stated that it was for the sake of
easier migration (ie migrate one thing at a time not everything at
once)
- Maciej Bialas stated that one downside to this was tedious
integration with phpbb.
- Aleksey Bragin pointed out that playground.reactos.org (with its
intact database) will be what the new main site looks like when the
switch is made.
- Ziliang Guo said he can start trying to add content the coming weekend.
- Amine Khaldi asked Ziliang Guo to keep everything minimalistic.
- Aleksey Bragin moved the meeting on to the CMake adoption topic on the agenda.
2. CMake adoption
--------------------
- Aleksey Bragin took this chance to welcome Alex Ionescu back to the
ReactOS project.
- Amine Khaldi stated that Alex Ionescu stumbled upon a way to
separate debug info from binaries, in a pdb similar way, using
objcopy. He also mentioned that Alex helped by fixing two bugs in
windmc and windres.
- He went on to say that Alex suggested that we go back to using
dwarf-2, only this time with pdb style debug, and with an improved,
out of the kernel, symbols handling. He mentioned that Thomas Faber
was kind enough to sketch a batch script that takes a debug log and
translates the addresses inside it.
- Amine Khaldi further stated that with the script + the CMake changes
to take account of windres and objcopy, we'll be able to reduce the
iso size, reduce the memory footprint, reduce the disk space needed to
compile, use windres alone and get rid of handling symbols in the
kernel (something "no other OS does" as Alex describes it).
- He then explained that, on the RosBE level, this will only require
updating binutils (gcc will stay at 4.4.3) with the patched windres
and windmc, and it will also require the translating script to be part
of RosBE.
A discussion ensued about testing the new RosBE and the following
conclusions where reached:
- Have a new Build Environment Release Candidate (2.0) which is an
update to binutils (ld, windres, windmc, addr2line... etc) until the
next meeting.
- Keep the 4.4.3 version of gcc until the next meeting.
- Alex Ionescu suggested having the new RosBE ready by the time of the
next release. He also noted that this does not mean the new BE will be
released along with the next version of ReactOS, but that it must be
ready by then.
- Cameron Gutman then brought up the issue of switching to gcc 4.6,
but it was decided to keep gcc 4.4.3 until after the next release.
- Thomas Faber then suggested an outlined step by step plan:
1) Update BE
2) Release new version of ReactOS (0.3.14)
3) Get rid of wrc
4) Get rid of rbuild
5) Switch to dwarf
6) Adopt new compiler (gcc 4.6)
After some deliberating it was agreed upon that Thomas Faber's
proposed course of action is the best way to go, and his proposal was
accepted.
- Amine Khaldi then moved the meeting to the next topic
3. Release status
--------------------
- Cameron Gutman inquired about the progress on the heap regression issue.
- Thomas Faber stated that although he himself hasn't made much
progress because he is very busy during the week, Jerome has been
tracking it down pretty well and that it is apparently caused by
resource loading.
- Amine Khaldi took this chance too thank everyone for the awesome
bugfixing phase, and stated that a lot of bugs has been fixed and a
lot of regression has been addressed. He also went on to thank
testers, and outlined the importance they have, and stated that he
hopes this will be the mentality of the ReactOS project team, as
thanks to it ReactOS is improving a lot.
- He went on to say that as far as the remaining blockers are
concerned, more team work on fixing them is needed, as this has proved
very effective in the past. He also added that Jim Tabor did a good
one man job on the jre issue, but that the other issues could use some
teaming up.
- Aleksey Bragin further added to this that ReactOS is on the way to
possibly one of the best releases, and that after years have passed
everyone is working towards the same goal, which, he added, is
fantastic.
- Cameron Gutman agreed that ReactOS is indeed very stable now,
especially in kernel mode.
- Olaf Siejka went on to sum up that entering the release stage would
require at the very least fixing mshtml bug and fixing ldr
regressions.
- Aleksey Bragin agreed with Olaf Siejka on that point.
- Kamil Hornicek inquired about the official stance about hackfixing
certain bugs.
- Aleksey Bragin and Amine Khaldi both explained that while hackfixing
should be avoided, there are some bugs which cannot be resolved in a
timely fashion. But hackfixing these should clearly be reflected in
the commit message and comments in the code.
- Amine Khaldi went on to ask for a more visible teaming up, for
example on IRC and through bug reports, and to also request marking
bugs as assigned when devs take them. He mentioned that since the
release blockers remained unassigned for a while, it was difficult at
times to keep track of who is working on what.
- Cameron Gutman inquired if anybody objects to modifying the default
color depth from 16-bit to 32-bit.
- Olaf Siejka raised some concerns about this as it will affect QEMU
since it does not support 32bpp.
- Cameron Cutman further inquired about the possibility of falling
back more gracefully as far as color depth is concerned when a video
card does not support a certain resolution (right now it falls back
directly to 8bpp). He went further to ask Timo Kreuzer if this is
standard windows behavior.
- Timo Kreuzer said he would need to investigate this issue.
- Aleksey Bragin formally ended the meeting, thanking everyone for
their time and information.
Minutes by Claudiu Mihail.
