I tested some of GreatLord's regressions and I can see how Aleksey would
get angry about all the fixes he has to do to GreatLord's code, but
GreatLord has fixed a whole lot more than he has broken and Fireball
chasing around 'if (Foo == FALSE)' and changing it to 'if (!Foo)' seems
pointless. We've got plenty of code formatted as 'if (Foo == FALSE)' in
the kernel that works great. Aleksey is making more work for himself by
making needless changes to GreatLord's code. All that is needed is
someone with commit access that is willing to correct GreatLord's
comments. I don't have a problem with finding a regression of GL's here
or there. Sure he should test his code before committing but as far as
breakages, but his code usually correct and all coders create breakages
one time or another.
Hi,
I did some research and found something very interesting. I kept
thinking about the last DCE commit (34289). I had a guess and modified
the user32 test for wine. The results are very clear. Apparently
windows does not care for which dc is returned if it is Cached or a
bug since hWnd is the same. When DCX_NORESETATTRS is set when calling
GetDCEx; "Does not reset the attributes of this DC to the default
attributes when this DC is released." We do this correctly in
ReleaseDC. So the next GetDCEx should keep the original DC data for
the next set of tests. Wine test is completely incorrect. So all of
our DCE attributes code is good to go. Windows did not pass the
modified "Same hDC" check and we still fail the "ROP" check. See the
windows results at the end of this message.
////////
Changes to user32/tests/dce.c:
ReleaseDC( hwnd_cache, hdc );
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE | DCX_NORESETATTRS );
<------ DCX_NORESETATTRS
rop = GetROP2( hdc );
ok( rop == def_rop || rop == R2_WHITE, "wrong ROP2 %d after
release\n", rop );
ReleaseDC( hwnd_cache, hdc );
+ old_hdc = hdc;
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE );
rop = GetROP2( hdc );
+ ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
ok( rop == def_rop, "wrong ROP2 %d after release\n", rop );
ReleaseDC( hwnd_cache, hdc );
/* test own DC */
////////
////////
Results from XP:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Z:\>e:
E:\>user32_crosstest dce
dce.c:79: Test failed: didn't get same DC F5010866/FC0107E0
dce: 77 tests executed (0 marked as todo, 1 failure), 0 skipped.
E:\>
/////////
I also agree.
About the last point, in Ged's mail, I'm afraid to say I've real
difficulties to code with such build time. I'm obliged to work on outdated
revisons, and on partial builds. That's really insane.
P. Schweitzer
--------------------------------------------------
From: "gedmurphy" <gedmurphy(a)gmail.com>
Sent: Wednesday, July 02, 2008 5:49 PM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
> I completely agree, this needs to be clamped down on. Do we really need 78
> different keyboard layouts at this point?
> It's fine for the people with mega fast systems and time on their hands,
> but
> most people don't fall into this category.
>
> I now try to avoid building as much as possible and I suspect more people
> will be following suit if the build time continues to increase.
>
> Ged
>
>
Once again I agree, and I'd like to add my 2 cents, perhaps it will help.
We need two solutions right now. A short term one, and a long term one.
The short one, purposed by Ged seems, IMO, to be a nice alternative before
more important work, and seems to be quite easy to realize.
The long one could be a work on rbuild (and makefile) with the hierarchy
purposed by Ged. And instead of typing make bootcd, we would have to type
make bootcd X where X would be the additionnal components with hierarchy.
P. Schweitzer
--------------------------------------------------
From: "gedmurphy" <gedmurphy(a)gmail.com>
Sent: Thursday, July 03, 2008 9:19 AM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
> I'm certainly not asking him to stop. But I do think we need a rethink of
> our tree structure.
> The rosapps thing has never been ideal either, so moving stuff into there
> isn't a good solution.
>
> Perhaps we need a hierarchy of components listed for importance. Let's say
> the list ranges from 1 to 10. 1 being core components required to boot the
> OS, 2 being additional components to get to the GUI, etc, with 10 being
> things like these keyboard dlls I used as an earlier example.
>
> However, such a solution isn't a 5 minute job so we do need a quick fix in
> the meantime. Maybe something similar to how rosapps works, with an
> addition
> to the /modules rbuild file?
>
> Ged.
>
> -----Original Message-----
> From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
> Behalf Of Aleksey Bragin
> Sent: 02 July 2008 22:34
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
>
> Asking Dmitry to abstain from work would be considered "a hack", not
> "a proper solution".
>
> WBR,
> Aleksey.
>
> On Jul 3, 2008, at 12:45 AM, Heis Spiter wrote:
>
>> I also agree.
>> About the last point, in Ged's mail, I'm afraid to say I've real
>> difficulties to code with such build time. I'm obliged to work on
>> outdated
>> revisons, and on partial builds. That's really insane.
>>
>> P. Schweitzer
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi,
Something else: there are two FORCEINLINE functions in
ntoskrnl/include/internal/ntoskrnl.h, DefaultSetInfoBufferCheck() and
DefaultQueryInfoBufferCheck(), but they cannot be inlined because of SEH
(i.e. setjmp/longjmp).
Timo Kreuzer wrote:
> What about wrapping the _SEH_TRY part in a local inline function? In my
> tests this successfully prevented the variables from being optimized away.
> At least under normal optimisation settings.
>> I now try to avoid building as much as possible and I suspect more people
>> will be following suit if the build time continues to increase.
>
> We could develop a lean target that only builds the bare apps and
> libraries required.
That's one of the things I experimented with while working on my C# rbuild
implementation http://www.marcpiulachs.com/reactos/designer.html . My
intention is to end up adding that kind of Platform Builder like feature to
our C++ implementation
Regards,
/Marc
Um...
KiDeliverApc already sets KernelApcPending = FALSE; Now you're setting
it twice...please revert.
On 1-Jul-08, at 3:08 AM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Tue Jul 1 05:08:14 2008
> New Revision: 34230
>
> URL: http://svn.reactos.org/svn/reactos?rev=34230&view=rev
> Log:
> - Fix a problem with normal and special APCs being inserted in the
> wrong order, spotted by Jury Sidorov. Now Borland Turbo Debugger
> should be able to debug applications, also it can fix hangs in other
> applications.
> - When delivering kernel APC, set the pending flag to false (by
> analogy with delivering user APC and clearing its pending flag).
> See issue #3426 for more details.
>
> Modified:
> trunk/reactos/ntoskrnl/ke/apc.c (contents, props changed)
>
> Modified: trunk/reactos/ntoskrnl/ke/apc.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/apc.c?rev=3423…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/ntoskrnl/ke/apc.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/apc.c [iso-8859-1] Tue Jul 1 05:08:14
> 2008
> @@ -145,8 +145,8 @@
> /* Get the APC */
> QueuedApc = CONTAINING_RECORD(NextEntry, KAPC,
> ApcListEntry);
>
> - /* Is this a Normal APC? If so, break */
> - if (QueuedApc->NormalRoutine) break;
> + /* Is this a No-Normal APC? If so, break */
> + if (!QueuedApc->NormalRoutine) break;
>
> /* Move to the next APC in the Queue */
> NextEntry = NextEntry->Blink;
> @@ -320,6 +320,9 @@
> break;
> }
>
> + /* It's not pending anymore */
> + Thread->ApcState.KernelApcPending = FALSE;
> +
> /* Get the next Entry */
> ApcListEntry = Thread->ApcState.ApcListHead[KernelMode].Flink;
> Apc = CONTAINING_RECORD(ApcListEntry, KAPC, ApcListEntry);
>
> Propchange: trunk/reactos/ntoskrnl/ke/apc.c
> ------------------------------------------------------------------------------
> --- svn:needs-lock (original)
> +++ svn:needs-lock (removed)
> @@ -1,1 +1,0 @@
> -*
>
Best regards,
Alex Ionescu