Re: [ros-dev] [ros-diffs] [fireball] 40368: - Compile UniATA with stdcall default calling convention instead of cdecl.
Please don't do this. -MRTD has NOTHING to do with stdcall and has been broken since gcc 2.9.5 Best regards, Alex Ionescu On Sun, Apr 5, 2009 at 7:46 AM, wrote: > Author: fireball > Date: Sun Apr 5 15:46:53 2009 > New Revision: 40368 > > URL: http://svn.reactos.org/svn/reactos?rev=40368&view=rev > Log: > - Compile UniATA with stdcall default calling convention instead of cdecl. > > Modified: >trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild > > Modified: trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild?rev=40368&r1=40367&r2=40368&view=diff > > == > --- trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild [iso-8859-1] > (original) > +++ trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild [iso-8859-1] Sun > Apr 5 15:46:53 2009 > @@ -4,6 +4,7 @@ > >. >inc > + -mrtd > >ntoskrnl >hal > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : Year 2038 problem
Again, since Ged wasn't clear: This is NT. NT does not use Unix time. Best regards, Alex Ionescu On Sat, Apr 11, 2009 at 6:52 PM, Sylvain Petreolle wrote: > I also noticed a funny thing browsing the year 2038 website : > http://www.2038bug.com/demo.html shows the first negative date given by a > negative int32 number. > > -2147483648, Fri Dec 13 20:45:52 1901 > > Kind regards, > Sylvain Petreolle > > > De : Ged > À : ReactOS Development List > Envoyé le : Dimanche, 12 Avril 2009, 1h19mn 26s > Objet : Re: [ros-dev] Year 2038 problem > > This is NT, not unix (thankfully) > > > > From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On > Behalf Of Javier Agustìn Fernàndez Arroyo > Sent: 12 April 2009 00:02 > To: ReactOS Development List > Subject: [ros-dev] Year 2038 problem > > > > Hi all, > i hope you have already taken into account this: > > http://en.wikipedia.org/wiki/Year_2038_problem > > Regards, > Javier > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : Year 2038 problem
Just to make the point clear: It will overflow on January 1st, 584942. Best regards, Alex Ionescu On Sat, Apr 11, 2009 at 10:08 PM, Alex Ionescu wrote: > Windows NT time is specified as the number of 100 nanosecond intervals > since January 1, 1601 > > Best regards, > Alex Ionescu > > > > On Sat, Apr 11, 2009 at 8:13 PM, King InuYasha wrote: >> Then what DOES NT use to calculate time? >> On Sat, Apr 11, 2009 at 9:34 PM, Alex Ionescu wrote: >>> >>> Again, since Ged wasn't clear: This is NT. NT does not use Unix time. >>> >>> Best regards, >>> Alex Ionescu >>> >>> >>> >>> On Sat, Apr 11, 2009 at 6:52 PM, Sylvain Petreolle >>> wrote: >>> > I also noticed a funny thing browsing the year 2038 website : >>> > http://www.2038bug.com/demo.html shows the first negative date given by >>> > a >>> > negative int32 number. >>> > >>> > -2147483648, Fri Dec 13 20:45:52 1901 >>> > >>> > Kind regards, >>> > Sylvain Petreolle >>> > >>> > >>> > De : Ged >>> > À : ReactOS Development List >>> > Envoyé le : Dimanche, 12 Avril 2009, 1h19mn 26s >>> > Objet : Re: [ros-dev] Year 2038 problem >>> > >>> > This is NT, not unix (thankfully) >>> > >>> > >>> > >>> > From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] >>> > On >>> > Behalf Of Javier Agustìn Fernàndez Arroyo >>> > Sent: 12 April 2009 00:02 >>> > To: ReactOS Development List >>> > Subject: [ros-dev] Year 2038 problem >>> > >>> > >>> > >>> > Hi all, >>> > i hope you have already taken into account this: >>> > >>> > http://en.wikipedia.org/wiki/Year_2038_problem >>> > >>> > Regards, >>> > Javier >>> > >>> > ___ >>> > Ros-dev mailing list >>> > Ros-dev@reactos.org >>> > http://www.reactos.org/mailman/listinfo/ros-dev >>> > >>> > >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : Year 2038 problem
Windows NT time is specified as the number of 100 nanosecond intervals since January 1, 1601 Best regards, Alex Ionescu On Sat, Apr 11, 2009 at 8:13 PM, King InuYasha wrote: > Then what DOES NT use to calculate time? > On Sat, Apr 11, 2009 at 9:34 PM, Alex Ionescu wrote: >> >> Again, since Ged wasn't clear: This is NT. NT does not use Unix time. >> >> Best regards, >> Alex Ionescu >> >> >> >> On Sat, Apr 11, 2009 at 6:52 PM, Sylvain Petreolle >> wrote: >> > I also noticed a funny thing browsing the year 2038 website : >> > http://www.2038bug.com/demo.html shows the first negative date given by >> > a >> > negative int32 number. >> > >> > -2147483648, Fri Dec 13 20:45:52 1901 >> > >> > Kind regards, >> > Sylvain Petreolle >> > >> > >> > De : Ged >> > À : ReactOS Development List >> > Envoyé le : Dimanche, 12 Avril 2009, 1h19mn 26s >> > Objet : Re: [ros-dev] Year 2038 problem >> > >> > This is NT, not unix (thankfully) >> > >> > >> > >> > From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] >> > On >> > Behalf Of Javier Agustìn Fernàndez Arroyo >> > Sent: 12 April 2009 00:02 >> > To: ReactOS Development List >> > Subject: [ros-dev] Year 2038 problem >> > >> > >> > >> > Hi all, >> > i hope you have already taken into account this: >> > >> > http://en.wikipedia.org/wiki/Year_2038_problem >> > >> > Regards, >> > Javier >> > >> > ___ >> > Ros-dev mailing list >> > Ros-dev@reactos.org >> > http://www.reactos.org/mailman/listinfo/ros-dev >> > >> > >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Using git for all ros source as main revision control
Bazaar is a toy, I'm surprised you've "never heard" of anyone using hg... Also, see http://bitbucket.org/ Best regards, Alex Ionescu On Sun, Apr 12, 2009 at 10:38 AM, Michael B. Trausch wrote: > On Sun, 12 Apr 2009 01:13:47 -0500 > Zachary Gorden > wrote: > >> This was discussed amongst the developers. A fair portion objected, >> and rather strongly at that. I happen to be one of them. Its >> "performance" is oversold and its support for Windows remains a >> problem point. And with the new branching features in SVN, the one >> advantage git does hold that's worth anything to us may well be >> disappearing. > > Have you guys taken a look at Bazaar? > > Granted moving to it (or any other DVCS) would likely require that the > repository be split so that reactos, rosapps, etc., are all in their > own shared repositories, but I think that this is better than pulling > everything all at once anyway. You can pull subsets with Subversion, > but it's still a pain to mirror that way. > > The big players ATM in DVCS are git and Bazaar, though. (And hg, > mentioned elsewhere in this thread, is also written in Python and so it > is just as portable as Bazaar is, though I don't know of terribly many > projects using it). If you switched to bzr, you'd get the nice > advantage of making it easy for Launchpad to mirror the repositories, > and making it easier for people who already use Launchpad and bzr for > hosting to contribute. Just a thought. > > --- Mike > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [janderwald] 40823: - Use a spinlock with list functions over interlocked list functions - Use a bitmap for storing reference count of the mappings as mapping are complete as
RtlBitmap?
Best regards,
Alex Ionescu
On Thu, May 7, 2009 at 12:58 AM, wrote:
> Author: janderwald
> Date: Thu May 7 02:58:57 2009
> New Revision: 40823
>
> URL: http://svn.reactos.org/svn/reactos?rev=40823&view=rev
> Log:
> - Use a spinlock with list functions over interlocked list functions
> - Use a bitmap for storing reference count of the mappings as mapping are
> complete async and not very likely in determined order
>
> Modified:
>trunk/reactos/drivers/wdm/audio/backpln/portcls/irpstream.c
>trunk/reactos/drivers/wdm/audio/backpln/portcls/pin_wavepci.c
>
> Modified: trunk/reactos/drivers/wdm/audio/backpln/portcls/irpstream.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/backpln/portcls/irpstream.c?rev=40823&r1=40822&r2=40823&view=diff
>
> ==
> --- trunk/reactos/drivers/wdm/audio/backpln/portcls/irpstream.c
> [iso-8859-1] (original)
> +++ trunk/reactos/drivers/wdm/audio/backpln/portcls/irpstream.c
> [iso-8859-1] Thu May 7 02:58:57 2009
> @@ -14,6 +14,7 @@
> KSSTREAM_HEADER *Header;
> PIRP Irp;
>
> +ULONG References;
> ULONG NumTags;
> PVOID * Tag;
> }IRP_MAPPING, *PIRP_MAPPING;
> @@ -141,6 +142,7 @@
> IN PIRP Irp)
> {
> PIRP_MAPPING Mapping;
> +ULONG Index;
> IIrpQueueImpl * This = (IIrpQueueImpl*)iface;
>
> Mapping = AllocateItem(NonPagedPool, sizeof(IRP_MAPPING),
> TAG_PORTCLASS);
> @@ -166,7 +168,6 @@
> {
> Mapping->NumTags++;
> }
> -ASSERT(Mapping->NumTags < 32);
> }
> }
> else
> @@ -181,12 +182,18 @@
> FreeItem(Mapping, TAG_PORTCLASS);
> return STATUS_UNSUCCESSFUL;
> }
> +ASSERT(Mapping->NumTags < 32);
> +for(Index = 0; Index < Mapping->NumTags; Index++);
> +Mapping->References |= (1 << Index);
>
> This->NumDataAvailable += Mapping->Header->DataUsed;
>
> -DPRINT("IIrpQueue_fnAddMapping NumMappings %u SizeOfMapping %lu
> NumDataAvailable %lu Mapping %p NumTags %u FrameSize %u\n",
> This->NumMappings, Mapping->Header->DataUsed, This->NumDataAvailable,
> Mapping, Mapping->NumTags, This->MaxFrameSize);
> -
> -ExInterlockedInsertTailList(&This->ListHead, &Mapping->Entry,
> &This->Lock);
> +DPRINT("IIrpQueue_fnAddMapping NumMappings %u SizeOfMapping %lu
> NumDataAvailable %lu Mapping %p NumTags %u References %x FrameSize %u\n",
> This->NumMappings, Mapping->Header->DataUsed, This->NumDataAvailable,
> Mapping, Mapping->NumTags, Mapping->References, This->MaxFrameSize);
> +
> +KeAcquireSpinLockAtDpcLevel(&This->Lock);
> +InsertTailList(&This->ListHead, &Mapping->Entry);
> +KeReleaseSpinLockFromDpcLevel(&This->Lock);
> +
> (void)InterlockedIncrement((volatile long*)&This->NumMappings);
>
> if (Irp)
> @@ -253,7 +260,10 @@
> {
> This->CurrentOffset = 0;
>
> -(void)ExInterlockedRemoveHeadList(&This->ListHead, &This->Lock);
> +KeAcquireSpinLockAtDpcLevel(&This->Lock);
> +RemoveHeadList(&This->ListHead);
> +KeReleaseSpinLockFromDpcLevel(&This->Lock);
> +
> InterlockedDecrement(&This->NumMappings);
> FreeMappingRoutine(CurMapping);
> }
> @@ -339,7 +349,7 @@
>
> /* calculate the offset */
> if (Index)
> -Offset = (Index + 1) * This->MaxFrameSize;
> +Offset = Index * This->MaxFrameSize;
> else
> Offset = 0;
>
> @@ -416,6 +426,7 @@
> KeReleaseSpinLockFromDpcLevel(&This->Lock);
> This->OutOfMapping = TRUE;
> This->StartStream = FALSE;
> +DPRINT("No Mapping available\n");
> return STATUS_UNSUCCESSFUL;
> }
>
> @@ -425,9 +436,9 @@
> IN IIrpQueue *iface,
> IN PVOID Tag)
> {
> -PIRP_MAPPING CurMapping;
> +PIRP_MAPPING CurMapping = NULL;
> PLIST_ENTRY CurEntry;
> -ULONG Index;
> +ULONG Index = 0;
> ULONG Found;
> IIrpQueueImpl * This = (IIrpQueueImpl*)iface;
>
> @@ -440,40 +451,48 @@
> return STATUS_UNSUCCESSFUL;
> }
>
> -CurMapping = CONTAINING_RECORD(CurEntry, IRP_MAPPING, Entry);
> Found = FALSE;
> -
> -for(Index = 0; Index < CurMapping->NumTags; Index++)
> -{
> -if (CurMapping->Tag[Index] == Tag)
> +MapIndex = 0;
> +while (CurEntry != &This->ListHead)
> +{
> +Cur
Re: [ros-dev] Stubbing Block w TEB
Looks like the CSRSS bug in Windows
-- by setting this to NULL, something is probably trying to dereference it
and crashes.
What is the original value? Probably some bogus uninitialized variable that
happens to be valid memory...
Best regards,
Alex Ionescu
On Tue, May 12, 2009 at 7:03 AM, James Tabor wrote:
> This should work! It's just writing zero into a place holder in TEB
> but it throws a exception and kills boot!
>
>
> Index: win32k/ntuser/misc.c
> ===
> --- win32k/ntuser/misc.c(revision 40892)
> +++ win32k/ntuser/misc.c(working copy)
> @@ -550,6 +550,7 @@
> //ci->pClientThreadInfo = &ti->ClientThreadInfo; // FIXME!
> ci->pClientThreadInfo = NULL;
> ci->ppi = ti->ppi;
> +ci->pDeskInfo = NULL;
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] I want to develop the kernel of ReactOS, how do i join????
I don't know what kind of crack you guys (except Ged and Aleksey) are on. Also, sorry for sounding arrogant, but what the hell do some random ML subscribers and project testers have to do in responding to an official request? Who are you to give this guy advice and give your opinions on wether or not you "think" that he should or should not commit. The rules (and again, since people seem to forget this, they ARE rules, and they ARE documented) prohibit development of any ReactOS code if you've seen MS source. That includes "advice" and "documentation". The only exceptions are things like the WRK, where a student has signed an agreement with MS to view only a specific part of the OS kernel. That student can then commit code to say, shell32, or the font viewer, or even win32k.sys. However, someone who has ILLEGALLY commited IP theft, and, additionally, seen a source code base that encompasses the ENTIRE NT tree (winnt source leaks even have the CRT and boot loader in there, and the linker, nothing is safe!) needs to stay as far away from this project as possible. Best regards, Alex Ionescu On Sun, May 17, 2009 at 2:35 PM, Daniel Reimer < daniel.rei...@stud-mail.uni-wuerzburg.de> wrote: > Gabriel ilardi wrote: > > Ged +1 > > Mike +1 > > > > Absolutely agreed. > > > > > > From: gedmur...@gmail.com > > To: ros-dev@reactos.org > > Date: Sun, 17 May 2009 12:38:57 +0100 > > Subject: Re: [ros-dev] I want to develop the kernel of ReactOS, how do > > i join > > > > I agree with Mike’s stance on this. > > > > Access to any MS source means no access to reactos. > > > > I think this point needs to be discussed and cemented as no one really > > seems to know what the official stance on this topic is anymore. > > > > Ged. > > > > *From:* ros-dev-boun...@reactos.org > > [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *Michael Martin > > *Sent:* 16 May 2009 23:10 > > *To:* ros-dev@reactos.org > > *Subject:* Re: [ros-dev] I want to develop the kernel of ReactOS, how > > do i join > > > > This is treading on thin ice. > > In my opinion, anyone having admitted to having accessed MS source > > code should not be allowed to write code for ReactOS and should never > > get commit access. > > Working on something not related to the source someone has seen, > > should still be a no go. > > As this will still increase the perception out there that ROS is tainted. > > And from my experienced of life in general, perception = reality, > > whether its true or not. > > > > Mike > > > > > > > > Date: Sat, 16 May 2009 12:09:00 -0500 > > From: drakekaizer...@gmail.com > > To: ros-dev@reactos.org > > Subject: Re: [ros-dev] I want to develop the kernel of ReactOS, how do > > i join > > > > He'd need to demonstrate that whatever he developed, the reason for > > what his code does can be tracked to available documentation, not the > > leaked source code. > > > > > > > > Hotmail® has a new way to see what's up with your friends. Check it > > out. > > < > http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 > > > > > > > > > > Chiamate gratis da PC a PC? Provale da Messenger! > > <http://messenger.it/videoconversazioni.aspx> > > > > > > ___ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > I just rephrased what I was told to the time of the audit. So don't > blame me ;-) > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 40961: - Initialize IoCountOperations variable to FALSE by default. Spotted by Dmitry Chapyshev & winetests.
Um, there's a serious compiler/linker/loader bug if that value is not
already FALSE by default.
Best regards,
Alex Ionescu
On Sun, May 17, 2009 at 6:46 PM, wrote:
> Author: fireball
> Date: Sun May 17 20:46:58 2009
> New Revision: 40961
>
> URL: http://svn.reactos.org/svn/reactos?rev=40961&view=rev
> Log:
> - Initialize IoCountOperations variable to FALSE by default. Spotted by
> Dmitry Chapyshev & winetests.
>
> Modified:
>trunk/reactos/ntoskrnl/io/iomgr/iomgr.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/iomgr.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/iomgr.c?rev=40961&r1=40960&r2=40961&view=diff
>
> ==
> --- trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] Sun May 17
> 20:46:58 2009
> @@ -31,7 +31,7 @@
> POBJECT_TYPE IoFileObjectType = NULL;
> extern POBJECT_TYPE IoControllerObjectType;
> extern UNICODE_STRING NtSystemRoot;
> -BOOLEAN IoCountOperations;
> +BOOLEAN IoCountOperations = FALSE;
> ULONG IoReadOperationCount = 0;
> LARGE_INTEGER IoReadTransferCount = {{0, 0}};
> ULONG IoWriteOperationCount = 0;
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 40963: MmGrowKernelStack: Don't assert, but fail, when the kernel stack can't grow any more. Fixes a crash with recursive user calls. See issue #4060 for more deta
The code SHOULD assert.
This is a hack.
Best regards,
Alex Ionescu
On Sun, May 17, 2009 at 11:51 PM, wrote:
> Author: tkreuzer
> Date: Mon May 18 01:51:31 2009
> New Revision: 40963
>
> URL: http://svn.reactos.org/svn/reactos?rev=40963&view=rev
> Log:
> MmGrowKernelStack: Don't assert, but fail, when the kernel stack can't grow
> any more. Fixes a crash with recursive user calls.
> See issue #4060 for more details.
>
> Modified:
>trunk/reactos/ntoskrnl/mm/procsup.c
>
> Modified: trunk/reactos/ntoskrnl/mm/procsup.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/procsup.c?rev=40963&r1=40962&r2=40963&view=diff
>
> ==
> --- trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] Mon May 18 01:51:31
> 2009
> @@ -259,8 +259,11 @@
> PETHREAD Thread = PsGetCurrentThread();
>
> /* Make sure we have reserved space for our grow */
> -ASSERT(((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit)
> <=
> - (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE));
> +if (((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) >
> + (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE))
> +{
> +return STATUS_NO_MEMORY;
> +}
>
> /*
> * We'll give you three more pages.
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] I want to develop the kernel of ReactOS, how do i join????
You should care because >50% of ReactOS code comes from Wine :) Best regards, Alex Ionescu On Sun, May 17, 2009 at 10:57 PM, Ged wrote: > James Tabor wrote: > > > Question should be, Where is the full discloser of the wine audit? > > Who cares? > Let's concentrate on our own project instead of trying to reignite old > arguments manifested by a small minority. > I left school a long time ago, let's leave the petty name calling there. > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 41042: - Formatting fix. No code change
That's unfair, I don't think every other dev checks with anyone that might have pending patches. This is life. Best regards, Alex Ionescu On Fri, May 22, 2009 at 10:12 PM, Aleksey Bragin wrote: > I hope you asked James and Timo, who may have uncommitted patches to > this file (which would fail to apply now). > > > WBR, > Aleksey Bragin. > > On May 22, 2009, at 4:50 PM, dchapys...@svn.reactos.org wrote: > >> Author: dchapyshev >> Date: Fri May 22 16:50:31 2009 >> New Revision: 41042 >> >> URL: http://svn.reactos.org/svn/reactos?rev=41042&view=rev >> Log: >> - Formatting fix. No code change >> >> Modified: >> trunk/reactos/subsystems/win32/win32k/ntuser/hook.c >> > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 41090: - MajorFunction has IRP_MJ_MAXIMUM_FUNCTION positions - Sorry for so many commits on the same function
May I ask, why not use simple C for this?: DriverBlock->DriverObject->MajorFunction = MajorFunctions; Or if that doesn't work, use a casting trick... Best regards, Alex Ionescu On Sun, May 24, 2009 at 2:49 AM, wrote: > Author: cgutman > Date: Sun May 24 04:49:02 2009 > New Revision: 41090 > > URL: http://svn.reactos.org/svn/reactos?rev=41090&view=rev > Log: > - MajorFunction has IRP_MJ_MAXIMUM_FUNCTION positions > - Sorry for so many commits on the same function > > Modified: > trunk/reactos/drivers/network/ndis/ndis/miniport.c > > Modified: trunk/reactos/drivers/network/ndis/ndis/miniport.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/miniport.c?rev=41090&r1=41089&r2=41090&view=diff > == > --- trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] Sun May > 24 04:49:02 2009 > @@ -2788,7 +2788,7 @@ > return NDIS_STATUS_RESOURCES; > } > > - for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++) > + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) > DriverBlock->DriverObject->MajorFunction[i] = MajorFunctions[i]; > > DriverBlock->DriverObject->MajorFunction[IRP_MJ_PNP] = NdisIDispatchPnp; > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cwittich] 41093: sync RegQueryValueExA, RegQueryValueA, RegQueryValueW and RegSetValueExA to wine patch by Giannis Adamopoulos See issue #452
Lol, Ged...this is Wine, remember?
It works like this:
Ntoskrnl calls user32, which calls kernel32, which calls ntdll, which
then calls msi.
Msi's A function then calls ntoskrnl's W function, which calls back
into gdi32's A function (after converting all the parameters).
Best regards,
Alex Ionescu
On Sun, May 24, 2009 at 3:35 PM, Ged wrote:
> Is this really right?
> I haven't checked the call chain in Windows, but 'A' functions generally call
> their 'W' counterpart to do the work.
>
> Ged.
>
> -Original Message-
> From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On
> Behalf Of cwitt...@svn.reactos.org
> Sent: 24 May 2009 09:45
> To: ros-di...@reactos.org
> Subject: [ros-diffs] [cwittich] 41093: sync RegQueryValueExA, RegQueryValueA,
> RegQueryValueW and RegSetValueExA to wine patch by Giannis Adamopoulos
> See issue #4528 for more details.
>
> Author: cwittich
> Date: Sun May 24 12:45:05 2009
> New Revision: 41093
>
> URL: http://svn.reactos.org/svn/reactos?rev=41093&view=rev
> Log:
> sync RegQueryValueExA, RegQueryValueA, RegQueryValueW and RegSetValueExA to
> wine
> patch by Giannis Adamopoulos
> See issue #4528 for more details.
>
> Modified:
> trunk/reactos/dll/win32/advapi32/reg/reg.c
>
> Modified: trunk/reactos/dll/win32/advapi32/reg/reg.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/reg/reg.c?rev=41093&r1=41092&r2=41093&view=diff
> ==
> --- trunk/reactos/dll/win32/advapi32/reg/reg.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/advapi32/reg/reg.c [iso-8859-1] Sun May 24
> 12:45:05 2009
> @@ -3964,110 +3964,96 @@
> *
> * @implemented
> */
> -LONG WINAPI
> -RegQueryValueExA(HKEY hKey,
> - LPCSTR lpValueName,
> - LPDWORD lpReserved,
> - LPDWORD lpType,
> - LPBYTE lpData,
> - LPDWORD lpcbData)
> -{
> - UNICODE_STRING ValueName;
> - UNICODE_STRING ValueData;
> - ANSI_STRING AnsiString;
> - LONG ErrorCode;
> - DWORD Length;
> - DWORD Type;
> -
> - TRACE("hKey 0x%X lpValueName %s lpData 0x%X lpcbData %d\n",
> - hKey, lpValueName, lpData, lpcbData ? *lpcbData : 0);
> -
> - if (lpData != NULL && lpcbData == NULL)
> - {
> - return ERROR_INVALID_PARAMETER;
> - }
> -
> - if (lpData)
> - {
> - ValueData.Length = 0;
> - ValueData.MaximumLength = (*lpcbData + 1) * sizeof(WCHAR);
> - ValueData.Buffer = RtlAllocateHeap(ProcessHeap,
> - 0,
> - ValueData.MaximumLength);
> - if (!ValueData.Buffer)
> - {
> - return ERROR_OUTOFMEMORY;
> - }
> - }
> - else
> - {
> - ValueData.Buffer = NULL;
> - ValueData.Length = 0;
> - ValueData.MaximumLength = 0;
> -
> - if (lpcbData)
> - *lpcbData = 0;
> - }
> -
> - RtlCreateUnicodeStringFromAsciiz(&ValueName,
> - (LPSTR)lpValueName);
> -
> - Length = (lpcbData == NULL) ? 0 : *lpcbData * sizeof(WCHAR);
> - ErrorCode = RegQueryValueExW(hKey,
> - ValueName.Buffer,
> - lpReserved,
> - &Type,
> - (lpData == NULL) ? NULL :
> (LPBYTE)ValueData.Buffer,
> - &Length);
> - TRACE("ErrorCode %lu\n", ErrorCode);
> - RtlFreeUnicodeString(&ValueName);
> -
> - if (ErrorCode == ERROR_SUCCESS ||
> - ErrorCode == ERROR_MORE_DATA)
> - {
> - if (lpType != NULL)
> - {
> - *lpType = Type;
> - }
> -
> - if ((Type == REG_SZ) || (Type == REG_MULTI_SZ) || (Type ==
> REG_EXPAND_SZ))
> - {
> - if (ErrorCode == ERROR_SUCCESS && ValueData.Buffer != NULL)
> +LSTATUS WINAPI RegQueryValueExA( HKEY hkey, LPCSTR name, LPDWORD reserved,
> LPDWORD type,
> + LPBYTE data, LPDWORD count )
> +{
> + NTSTATUS status;
> + ANSI_STRING nameA;
> + DWORD total_size, datalen = 0;
> + char buffer[256], *buf_ptr = buffer;
> + KEY_VALUE_PARTIAL_INFORMATION *info = (KEY_VALUE_PARTIAL_INFORMATION
> *)buffer;
> + static const int info_size = offsetof( KEY_VALUE_PARTIAL_INFORMATION,
> Data );
> +
> + TRACE("(%p,%s,%p,%p,%p,%p=%d)\n",
Re: [ros-dev] [ros-diffs] [cwittich] 41093: sync RegQueryValueExA, RegQueryValueA, RegQueryValueW and RegSetValueExA to wine patch by Giannis Adamopoulos See issue #452
FYI, Local* or Base functions are typically always W.
Best regards,
Alex Ionescu
On Sun, May 24, 2009 at 6:13 PM, Ged wrote:
> And somewhere in the middle of that there's an RPC call picked up by the
> linux host which calls a bash script to do the work.
>
>
> I was initially worried about scenarios which may brake apps, for example an
> app hooks RegQueryValueEx and expects to pick up all calls to
> RegQueryValue(Ex|A|W) (stupid, but possible). I think it's important to keep
> the call chains as close to Windows as possible.
> Anyway, I've just checked the call chain and it seems both ansi and Unicode
> functions call a LocalBase* function to do the work, so this isn't so much
> of an issue.
>
> I still disagree with this change though as we're doubling up on the code to
> do the same operation, meaning we now have 2 failure points instead of 1.
> This is one of the main reasons for getting A functions to call their W
> counterpart. If it's broken, you only have 1 code path to fix.
>
> Ged.
>
> -Original Message-
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of Alex Ionescu
> Sent: 24 May 2009 15:19
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [cwittich] 41093: sync RegQueryValueExA,
> RegQueryValueA, RegQueryValueW and RegSetValueExA to wine patch by Giannis
> Adamopoulos See issue #4528 for more
> details.
>
> Lol, Ged...this is Wine, remember?
>
> It works like this:
>
> Ntoskrnl calls user32, which calls kernel32, which calls ntdll, which
> then calls msi.
>
> Msi's A function then calls ntoskrnl's W function, which calls back
> into gdi32's A function (after converting all the parameters).
>
> Best regards,
> Alex Ionescu
>
>
>
> On Sun, May 24, 2009 at 3:35 PM, Ged wrote:
>> Is this really right?
>> I haven't checked the call chain in Windows, but 'A' functions generally
> call their 'W' counterpart to do the work.
>>
>> Ged.
>>
>> -Original Message-
>> From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org]
> On Behalf Of cwitt...@svn.reactos.org
>> Sent: 24 May 2009 09:45
>> To: ros-di...@reactos.org
>> Subject: [ros-diffs] [cwittich] 41093: sync RegQueryValueExA,
> RegQueryValueA, RegQueryValueW and RegSetValueExA to wine patch by Giannis
> Adamopoulos See issue #4528 for more
> details.
>>
>> Author: cwittich
>> Date: Sun May 24 12:45:05 2009
>> New Revision: 41093
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=41093&view=rev
>> Log:
>> sync RegQueryValueExA, RegQueryValueA, RegQueryValueW and RegSetValueExA
> to wine
>> patch by Giannis Adamopoulos
>> See issue #4528 for more details.
>>
>> Modified:
>> trunk/reactos/dll/win32/advapi32/reg/reg.c
>>
>> Modified: trunk/reactos/dll/win32/advapi32/reg/reg.c
>> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/reg/reg.
> c?rev=41093&r1=41092&r2=41093&view=diff
>>
>
> ==
>> --- trunk/reactos/dll/win32/advapi32/reg/reg.c [iso-8859-1] (original)
>> +++ trunk/reactos/dll/win32/advapi32/reg/reg.c [iso-8859-1] Sun May 24
> 12:45:05 2009
>> @@ -3964,110 +3964,96 @@
>> *
>> * @implemented
>> */
>> -LONG WINAPI
>> -RegQueryValueExA(HKEY hKey,
>> - LPCSTR lpValueName,
>> - LPDWORD lpReserved,
>> - LPDWORD lpType,
>> - LPBYTE lpData,
>> - LPDWORD lpcbData)
>> -{
>> - UNICODE_STRING ValueName;
>> - UNICODE_STRING ValueData;
>> - ANSI_STRING AnsiString;
>> - LONG ErrorCode;
>> - DWORD Length;
>> - DWORD Type;
>> -
>> - TRACE("hKey 0x%X lpValueName %s lpData 0x%X lpcbData %d\n",
>> - hKey, lpValueName, lpData, lpcbData ? *lpcbData : 0);
>> -
>> - if (lpData != NULL && lpcbData == NULL)
>> - {
>> - return ERROR_INVALID_PARAMETER;
>> - }
>> -
>> - if (lpData)
>> - {
>> - ValueData.Length = 0;
>> - ValueData.MaximumLength = (*lpcbData + 1) * sizeof(WCHAR);
>> - ValueData.Buffer = RtlAllocateHeap(ProcessHeap,
>> - 0,
>> - ValueData.MaximumLength);
>> - if (!ValueData.Buffer)
>> - {
>> - return ERROR_OUTOFMEMORY;
>> - }
Re: [ros-dev] [ros-diffs] [tkreuzer] 41106: MmGrowKernelStack: go back to the ASSERT and add a fixed check
Sorry for not replying to e-mails about this -- I was on vacation on a cruise.
When I'm back to Montreal I'll write a driver to test if this is
correct or not -- but definitely this is better.
Best regards,
Alex Ionescu
On Mon, May 25, 2009 at 1:17 AM, wrote:
> Author: tkreuzer
> Date: Mon May 25 03:17:48 2009
> New Revision: 41106
>
> URL: http://svn.reactos.org/svn/reactos?rev=41106&view=rev
> Log:
> MmGrowKernelStack: go back to the ASSERT and add a fixed check
>
> Modified:
> trunk/reactos/ntoskrnl/mm/procsup.c
>
> Modified: trunk/reactos/ntoskrnl/mm/procsup.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/procsup.c?rev=41106&r1=41105&r2=41106&view=diff
> ==
> --- trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] Mon May 25 03:17:48 2009
> @@ -258,11 +258,15 @@
> {
> PETHREAD Thread = PsGetCurrentThread();
>
> - /* Make sure we have reserved space for our grow */
> - if (((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) >
> - (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE))
> - {
> - return STATUS_NO_MEMORY;
> + /* Make sure the stack did not overflow */
> + ASSERT(((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) <=
> + (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE));
> +
> + /* Check if we have reserved space for our grow */
> + if ((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit +
> + KERNEL_STACK_SIZE > KERNEL_LARGE_STACK_SIZE)
> + {
> + return STATUS_STACK_OVERFLOW;
> }
>
> /*
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Wineconf 2009
if I show up will there be a crucifix built for me? On 30-May-09, at 2:00 PM, Steven Edwards wrote: > Hi, > I just wanted to let everyone know that Wineconf 2009 is going to be > held in Holland on Nov 6-8th. I am of course planning on attending and > Fireball said that he might as well. If any ReactOS developers are > interested in going and don't have the resources, speak up and perhaps > some of the users and advocates that follow ReactOS development would > be willing to contribute $5 or $10 to the Foundation on your behalf. > > Information (what little there is currently) is here: > http://wiki.winehq.org/WineConf2009 > > The ReactOS foundation Donation page is here > http://www.reactos.org/en/foundation_donate.html > > Also while there has been some heated exchanges with Wine and ReactOS > developers in the past, we do get quite a lot in terms of code from > them so if your interested in helping them out, you can donate to the > Wine Development Fund, which will help pay for Wine developers to > attend. The donation link is on the main page of Winehq.org > > Thanks > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 41213: - Export and hackplement NdisSetTimerEx - Implementation is #ifed out currently but I may enable it later - Hopefully somebody can think of a better way to d
There's nothing ugly about this -- this is exactly what the field is for.
Best regards,
Alex Ionescu
On Sat, May 30, 2009 at 4:07 PM, wrote:
> Author: cgutman
> Date: Sun May 31 03:07:13 2009
> New Revision: 41213
>
> URL: http://svn.reactos.org/svn/reactos?rev=41213&view=rev
> Log:
> - Export and hackplement NdisSetTimerEx
> - Implementation is #ifed out currently but I may enable it later
> - Hopefully somebody can think of a better way to do it than the current code
>
> Modified:
> trunk/reactos/drivers/network/ndis/ndis.def
> trunk/reactos/drivers/network/ndis/ndis/time.c
>
> Modified: trunk/reactos/drivers/network/ndis/ndis.def
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis.def?rev=41213&r1=41212&r2=41213&view=diff
> ==
> --- trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] Sun May 31
> 03:07:13 2009
> @@ -257,6 +257,7 @@
> ndissetpacketpoolprotoco...@8
> ;NdisSetProtocolFilter ?
> ndissetti...@8
> +ndissettime...@12
> ndissetupdmatrans...@24
> ndissystemprocessorco...@0
> ndisterminatewrap...@8
>
> Modified: trunk/reactos/drivers/network/ndis/ndis/time.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/time.c?rev=41213&r1=41212&r2=41213&view=diff
> ==
> --- trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] Sun May 31
> 03:07:13 2009
> @@ -243,5 +243,26 @@
> KeSetTimer (&Timer->Timer, Timeout, &Timer->Dpc);
> }
>
> +VOID
> +EXPORT
> +NdisSetTimerEx(
> + IN PNDIS_TIMER Timer,
> + IN UINT MillisecondsToDelay,
> + IN PVOID FunctionContext)
> +{
> +#if 0
> + /* FIXME: I'm not sure how to this in a nice way
> + * We can't store the function context anywhere in NDIS_TIMER
> + * so I'm forced to do this
> + */
> +
> + Timer->Dpc.DeferredContext = FunctionContext;
> +
> + NdisSetTimer(Timer, MillisecondsToDelay);
> +#else
> + UNIMPLEMENTED
> +#endif
> +}
> +
> /* EOF */
>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [mjmartin] 41269: - IopCreateDriver: Change MajorFunction routines back to internal function IopInvalidDeviceRequest for ones that were set to NULL in the Drivers DriverEntry
I must say that I protest to all the recent I/O changes, and in my
opinion, they are all wrong and badly researched, and have hacked what
was once good code.
Best regards,
Alex Ionescu
On Wed, Jun 3, 2009 at 2:48 AM, wrote:
> Author: mjmartin
> Date: Wed Jun 3 13:48:33 2009
> New Revision: 41269
>
> URL: http://svn.reactos.org/svn/reactos?rev=41269&view=rev
> Log:
> - IopCreateDriver: Change MajorFunction routines back to internal function
> IopInvalidDeviceRequest for ones that were set to NULL in the Drivers
> DriverEntry. Windows does it and so shall we.
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/driver.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/driver.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/driver.c?rev=41269&r1=41268&r2=41269&view=diff
> ==
> --- trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] Wed Jun 3 13:48:33
> 2009
> @@ -1302,7 +1302,7 @@
> RtlZeroMemory(DriverObject, ObjectSize);
> DriverObject->Type = IO_TYPE_DRIVER;
> DriverObject->Size = sizeof(DRIVER_OBJECT);
> - DriverObject->Flags = DRVO_BUILTIN_DRIVER;
> + DriverObject->Flags = DRVO_LEGACY_DRIVER;//DRVO_BUILTIN_DRIVER;
> DriverObject->DriverExtension = (PDRIVER_EXTENSION)(DriverObject + 1);
> DriverObject->DriverExtension->DriverObject = DriverObject;
> DriverObject->DriverInit = InitializationFunction;
> @@ -1398,6 +1398,14 @@
> {
> /* Returns to caller the object */
> *pDriverObject = DriverObject;
> + }
> +
> + /* Loop all Major Functions */
> + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
> + {
> + /* Set each function that was set to NULL to internal routine */
> + if (!DriverObject->MajorFunction[i])
> + DriverObject->MajorFunction[i] = IopInvalidDeviceRequest;
> }
>
> /* Return the Status */
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 41557: #define inline to __inline for Visual C++ when compiling C sources
Why not fix the code instead? I hate these kinds of hacks. GCC understands __inline and static, so just make the code not use STATIC and inline. On 22-Jun-09, at 1:03 PM, hyper...@svn.reactos.org wrote: > Author: hyperion > Date: Tue Jun 23 00:03:20 2009 > New Revision: 41557 > > URL: http://svn.reactos.org/svn/reactos?rev=41557&view=rev > Log: > #define inline to __inline for Visual C++ when compiling C sources > > Modified: >trunk/reactos/ReactOS-generic.rbuild > > Modified: trunk/reactos/ReactOS-generic.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ReactOS-generic.rbuild?rev=41557&r1=41556&r2=41557&view=diff > = > = > = > = > = > = > = > = > == > --- trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] (original) > +++ trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] Tue Jun 23 > 00:03:20 2009 > @@ -132,6 +132,7 @@ > > > > + __inline > /Zl > /Zi > /W1 > Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cwittich] 41599: stub NtSetThreadExecutionState needed by PowerPoint Viewer 2003
Statics? Win32 flags? Hungarian notation?
What is this -- Wine?
Please revert this shit.
Best regards,
Alex Ionescu
On Wed, Jun 24, 2009 at 12:53 PM, wrote:
> Author: cwittich
> Date: Wed Jun 24 23:53:54 2009
> New Revision: 41599
>
> URL: http://svn.reactos.org/svn/reactos?rev=41599&view=rev
> Log:
> stub NtSetThreadExecutionState needed by PowerPoint Viewer 2003
>
> Modified:
> trunk/reactos/ntoskrnl/po/power.c
>
> Modified: trunk/reactos/ntoskrnl/po/power.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/po/power.c?rev=41599&r1=41598&r2=41599&view=diff
> ==
> --- trunk/reactos/ntoskrnl/po/power.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/po/power.c [iso-8859-1] Wed Jun 24 23:53:54 2009
> @@ -588,6 +588,16 @@
> NtSetThreadExecutionState(IN EXECUTION_STATE esFlags,
> OUT EXECUTION_STATE *PreviousFlags)
> {
> - UNIMPLEMENTED;
> - return STATUS_NOT_IMPLEMENTED;
> -}
> + static EXECUTION_STATE current =
> + ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED | ES_USER_PRESENT;
> + EXECUTION_STATE old = current;
> +
> + UNIMPLEMENTED;
> +
> + if (!(current & ES_CONTINUOUS) || (esFlags & ES_CONTINUOUS))
> + current = esFlags;
> +
> + *PreviousFlags = old;
> +
> + return STATUS_SUCCESS;
> +}
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 41610: Remove a hack from NtAccessCheck(). Bug #4169.
Oh, I see. All these white spaces were hacks.
Thanks for mixing in 500 whitespace and formatting changes with 5
lines of code changes. It makes it really clear!
Has the kernel become a no-man's land of garbage? I'm thinking of
removing my name from the sources if this keeps up.
Best regards,
Alex Ionescu
On Thu, Jun 25, 2009 at 6:29 AM, wrote:
> Author: dgorbachev
> Date: Thu Jun 25 17:29:58 2009
> New Revision: 41610
>
> URL: http://svn.reactos.org/svn/reactos?rev=41610&view=rev
> Log:
> Remove a hack from NtAccessCheck(). Bug #4169.
>
> Modified:
> trunk/reactos/ntoskrnl/se/semgr.c
>
> Modified: trunk/reactos/ntoskrnl/se/semgr.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=41610&r1=41609&r2=41610&view=diff
> ==
> --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Thu Jun 25 17:29:58 2009
> @@ -49,7 +49,7 @@
> SepExports.SeSystemEnvironmentPrivilege = SeSystemEnvironmentPrivilege;
> SepExports.SeChangeNotifyPrivilege = SeChangeNotifyPrivilege;
> SepExports.SeRemoteShutdownPrivilege = SeRemoteShutdownPrivilege;
> -
> +
> SepExports.SeNullSid = SeNullSid;
> SepExports.SeWorldSid = SeWorldSid;
> SepExports.SeLocalSid = SeLocalSid;
> @@ -72,11 +72,11 @@
> SepExports.SeAuthenticatedUsersSid = SeAuthenticatedUsersSid;
> SepExports.SeRestrictedSid = SeRestrictedSid;
> SepExports.SeAnonymousLogonSid = SeAnonymousLogonSid;
> -
> +
> SepExports.SeUndockPrivilege = SeUndockPrivilege;
> SepExports.SeSyncAgentPrivilege = SeSyncAgentPrivilege;
> SepExports.SeEnableDelegationPrivilege = SeEnableDelegationPrivilege;
> -
> +
> SeExports = &SepExports;
> return TRUE;
> }
> @@ -92,18 +92,18 @@
> if (!SepInitSDs()) return FALSE;
> SepInitPrivileges();
> if (!SepInitExports()) return FALSE;
> -
> +
> /* Initialize the subject context lock */
> ExInitializeResource(&SepSubjectContextLock);
> -
> +
> /* Initialize token objects */
> SepInitializeTokenImplementation();
> -
> +
> /* Clear impersonation info for the idle thread */
> PsGetCurrentThread()->ImpersonationInfo = NULL;
> PspClearCrossThreadFlag(PsGetCurrentThread(),
> CT_ACTIVE_IMPERSONATION_INFO_BIT);
> -
> +
> /* Initialize the boot token */
> ObInitializeFastReference(&PsGetCurrentProcess()->Token, NULL);
> ObInitializeFastReference(&PsGetCurrentProcess()->Token,
> @@ -117,7 +117,7 @@
> {
> NTSTATUS Status;
> PAGED_CODE();
> -
> +
> /* Insert the system token into the tree */
> Status = ObInsertObject((PVOID)(PsGetCurrentProcess()->Token.Value &
> ~MAX_FAST_REFS),
> @@ -127,7 +127,7 @@
> NULL,
> NULL);
> ASSERT(NT_SUCCESS(Status));
> -
> +
> /* FIXME: TODO \\ Security directory */
> return TRUE;
> }
> @@ -140,17 +140,17 @@
> switch (ExpInitializationPhase)
> {
> case 0:
> -
> +
> /* Do Phase 0 */
> return SepInitializationPhase0();
> -
> +
> case 1:
> -
> +
> /* Do Phase 1 */
> return SepInitializationPhase1();
> -
> +
> default:
> -
> +
> /* Don't know any other phase! Bugcheck! */
> KeBugCheckEx(UNEXPECTED_INITIALIZATION_CALL,
> 0,
> @@ -170,7 +170,7 @@
> HANDLE DirectoryHandle;
> HANDLE EventHandle;
> NTSTATUS Status;
> -
> +
> /* Create '\Security' directory */
> RtlInitUnicodeString(&Name,
> L"\\Security");
> @@ -187,7 +187,7 @@
> DPRINT1("Failed to create 'Security' directory!\n");
> return FALSE;
> }
> -
> +
> /* Create 'LSA_AUTHENTICATION_INITALIZED' event */
> RtlInitUnicodeString(&Name,
> L"\\LSA_AUTHENTICATION_INITALIZED");
> @@ -207,12 +207,12 @@
> NtClose(DirectoryHandle);
> return FALSE;
> }
> -
> +
> ZwClose(EventHandle);
> ZwClose(DirectoryHandle);
> -
> +
> /* FIXME: Create SRM port and listener thread */
> -
> +
> return TRUE;
> }
>
> @@ -228,16 +228,16 @@
> IN PGENERIC_MAPPING GenericMapping)
> {
> PAGED_CODE();
> -
> +
> /* Select the operation type */
Re: [ros-dev] r41685 crashes early at boot in my real hardware (P-i @ 200 MHz)
You could just read his log and see that the P1 issue in the newsletter has nothing to do with the issue he's experiencing Best regards, Alex Ionescu On Mon, Jun 29, 2009 at 10:36 AM, Zachary Gorden wrote: > I refer you to http://www.reactos.org/en/newsletter_61.html#sec1 near the > end of that section for an explanation of why it failed on your PI system. > > 2009/6/29 Javier Agustìn Fernàndez Arroyo > >> Hi all, >> >> As talked with Aleksey i would want to let you knwo that revision r41685 >> is broken, in my real hardware, at least. >> This is the log i get, im sorry to say i cannot give you more details >> (backtraces, disasm´s, and so, since even kb does not work after the crash. >> >> (ntoskrnl/kd/kdio.c:221) ReactOS 0.4-SVN (Build 20090629-r41685) >> (ntoskrnl/kd/kdio.c:222) Command Line: NOGUIBOOT DEBUGPORT=COM1 >> NOGUIBOOT DEBUGPORT=COM1 >> (ntoskrnl/kd/kdio.c:223) ARC Paths: multi(0)disk(0)cdrom(159) \ >> multi(0)disk(0)cdrom(159) \reactos\ >> Used memory 327284Kb >> (ntoskrnl/mm/mminit.c:224)Start End Type >> (ntoskrnl/mm/mminit.c:225) 0x8000 - 0x8080 Undefined region >> (ntoskrnl/mm/mminit.c:228) 0x8080 - 0x80E0 FreeLDR Kernel >> mapping region >> (ntoskrnl/mm/mminit.c:231) 0x80E0 - 0x80FE PFN Database >> region >> (ntoskrnl/mm/mminit.c:238) 0x80FE - 0x873E Non paged pool >> region >> (ntoskrnl/mm/mminit.c:241) 0x873E - 0x8D7E Paged pool region >> (ARM³::INIT:340) System PTE count has been tuned to 22000 (90112000 >> bytes) >> (ARM³::INIT:445) NP Pool has been tuned to: 10584064 bytes and 130072576 >> bytes >> (ARM³::INIT:490) System PTE VA starts at: F300 >> (ARM³::INIT:491) NP Expansion VA begins at: F89EC000 and ends at: >> FFBE >> (ARM³::INIT:507) PFN DB VA begins at: B000 and ends at: B01E >> (ARM³::INIT:510) PFN DB PA PFN begins at: 1000 >> (ARM³::INIT:511) NP VA begins at: B01E and ends at: B0BF8000 >> (ARM³::INIT:514) NP PA PFN begins at: 11e0 >> (ARM³::SYSPTE:341) System PTE space for 1 starting at: C03E27B4 and >> ending at: C03FEF78 >> Assertion '(MmNumberOfSystemPtes - OldCount) <= 1000' failed at >> ARM³::INIT line 652 >> Entered debugger on embedded INT3 at 0x0008:0x808bfcf6. >> kdb:> >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 41788: "Fix" MDL PROBE FAILED! bug #4663.
I'm confused... I've looked through the code, and I don't get what the "Break" does here. Does the ExRaiseStatus somehow end up handled in this path again? That means there's a serious SEH2 bug. On 6-Jul-09, at 11:28 AM, dgorbac...@svn.reactos.org wrote: > Author: dgorbachev > Date: Mon Jul 6 22:28:11 2009 > New Revision: 41788 > > URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev > Log: > "Fix" MDL PROBE FAILED! bug #4663. > > Modified: >trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c?rev=41788&r1=41787&r2=41788&view=diff > = > = > = > = > = > = > = > = > == > --- trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] Mon Jul 6 > 22:28:11 2009 > @@ -679,6 +679,7 @@ > // Oops :( > // > ProbeStatus = _SEH2_GetExceptionCode(); > +_SEH2_YIELD(break); > } > _SEH2_END; > > Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 41788: "Fix" MDL PROBE FAILED! bug #4663.
Yes, why is there not a bug report for this on BugZilla, and why are the developers screaming murder against the portable group when they've uncovered a major PSEH fault? Reverting their commit, while, yes, 'unbreaking' trunk (and only only on the test server anyway), would've caused this issue to go unnoticed and perhaps cause headaches later on (without the DPRINT there this would've been hard to catch). On 7-Jul-09, at 5:48 AM, Aleksey Bragin wrote: > If it would be said so (in a commit message, in a bug report), it > wouldn't provide so big frustration among developers. Otherwise we'll > end up communicating in C code rather than in human readable > language :) > > WBR, > Aleksey. > > > On Jul 7, 2009, at 11:52 AM, Dmitry Gorbachev wrote: > >> Yes, it's a bug in PSEH2, unnoticed. More testcases are needed in >> psehtest. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 41863: stop building ntdll as a win32dll so we can fucking stop auto-importing mingw_common and kernel32 into it... it's supposed to be built as a /SUBSYSTE
Seems to me that something is broken with rbuild if "Please build me a windows subsystem DLL" gets translated into.. "Please build me a windows subsystem DLL and go ahead and import mingw while you're at it, and let's import chk_stk too, which means you'll probably also want kernel32". Unless "type" is supposed to be used like TARGET_TYPE in WDK Build, which means "please be helpful and import extra shit behind my back" in which case, yes, probably "subsystem" would be useful to have. Just my 2 cents... I'll let the ninjas do the knocking. On 11-Jul-09, at 4:49 AM, KJK::Hyperion wrote: > ros-arm-brin...@svn.reactos.org wrote: >> stop building ntdll as a win32dll so we can fucking stop auto- >> importing mingw_common and kernel32 into it... > > if you need any rbuild features or fixes, just ask me > >> it's supposed to be built as a /SUBSYSTEM:WINDOWS dll > > not even that, it's a DLL built with a subsystem of CONSOLE! (no idea > why, what the hell, Microsoft?) which rbuild can't currently express > in > any way but . Do you need a "subsystem" attribute for > modules, maybe? Knock the table once for "no", twice for "yes" > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Very nice.
You can create physical apartuses (aparatii?) that demonstrate the existence of pseudo-forces, so they do "exist". The term "pseudo" doesn't mean "non-existent". Hell, go up a building and drop a heavy object in a perfect straight line. It'll land a bit east because of circular motion forces that are "pseudo". On 15-Jul-09, at 5:22 PM, Alex wrote: > Hello Timo, > > Thursday, July 16, 2009, 4:09:30 AM, you wrote: > >> [01:12]care2debug: Physicus: do you have a physics degree? I >> wonder >> how one can make such blunders who is not in the 7th grade :) > > Oops, that didn't sound very well, I agree, even if it was not meant > as a serious remark (see the smile). Heat of the discussion, I > suppose. > > For that I apologize. > > But I still don't think banning was an appropriate solution. You could > ignore me, you could tell me to STFU, anything. > >> The ban was to make you think about your behaviour. Please learn the >> stuff (there is a centrifugal force, it is only existant in the >> rotating >> reference system and not in an inertial system and it's a pseudo- >> force, >> but that doesn't make it non-existant, learn about what a force is at >> all) and learn to be less of a smartass. Your ban has already been >> removed > > I see that you agree that this is a pseudo-force. But since this list > is not related to physics I will not continue this discussion here. > > -- > Best regards, > Alex mailto:care2de...@gmail.com > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. " people will eat you alive anyway so it doesn't really matter"
What are you guys trying to do, btw? Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for multiple reasons I can discuss if this is what you're attempting to do). Or... get Wine's GUI running to see what graphic improvements appear, and what graphics are still fucked in the same way, so you can remove that part from the equation (meaning the problem is the driver or kernel or some other DLL). <--- I hope so Best regards, Alex Ionescu On Fri, Jul 17, 2009 at 6:12 PM, James Tabor wrote: > Hi, > > 2009/7/17 Timo Kreuzer : > > Yeah it looks promising. I love it. I will join in now, too. Let us all > work > > on this great idea to get it ready for the next release. > > It will finally make our crappy win32k absolete. And it will fix the > kernel! > > ;-P > > > > > I wasn't thinking like that, our code is not going away,,, for a > different set of reasons. The argument was setup years ago, the answer > is coming closer .. ... .. .. ... . We have the tools now, so~... > .. . .. .. .. > James > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. " people will eat you alive anyway so it doesn't really matter"
This is such an awesome russian response :) "Let me finish the political upheveal first, "restructure" the parliament, rebuild the economy and then my vision will become clear". Best regards, Alex Ionescu On Sat, Jul 18, 2009 at 12:16 PM, Aleksey Bragin wrote: > Don't jump into fast conclusions :-) > > I will explain thoroughly and in all details what's being done. Just let me > commit the remaining of my stuff first. > > > WBR, > Aleksey Bragin. > > > On Jul 18, 2009, at 6:34 PM, Timo Kreuzer wrote: > > Hi, > > I still don't get it. What do you want to research here? How wine works? Or > how windows works? Or how to create a monstrous chimera from reactos and > wine? > > I wonder what people would say, if I created a branch called arsentxx, > cleaned out ntoskrnl and imported LUK... ;-P > > Well, my current opinion is that this is simply a lot of wasted time and > will most likely end up like nwin32 (which was a much better idea) and most > other branches being left alone and bitrotting. > > Anyway, this is just my opinion, based on what I have seen and guesses, as > long as noone states the real goal of this. And of cause everyone is free to > spend his free time with whatever he likes :-) > > Regards, > Timo > > PS: That world domination thing won't work this way. I tried that myself. > You need more robots! > > James Tabor schrieb: > > Hi! > > On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu > wrote: > > > What are you guys trying to do, btw? > Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for > multiple reasons I can discuss if this is what you're attempting to do). > > > I don't think wine can draw w/o X so answer is no~ Wine uses those > X->Z(,,,) to driver calls and it would include winex11.drv as a > minimal to be added and adapted to call our driver code so~ for sure > this is a No. ie. [wine, user] create a window, it calls the driver > and that is winex11.drv so a call to X is performed there. > > I've added X to our code base to support math needed for drawing, I > guess those could be adapted as well? The math is sound, but as an > extra layer of code, is not what I wanted to do. But Win32k does have > that kind of math for drawing so We can simplify it, rewrite it > and so on~ a side note. > > > > Or... get Wine's GUI running to see what graphic improvements appear, and > what graphics are still fucked in the same way, so you can remove that part > from the equation (meaning the problem is the driver or kernel or some other > DLL). <--- I hope so > Best regards, > Alex Ionescu > > > > More I think about it, if it does compile, it will not work, ntoskrnl > needs win32k so how to overcome this? Need to rewrite the kernel? That > is a no. Win32k process and threading issues and kernel callbacks so, > more, no. Someone could do the same with Xp or W7U, rewrite win32k to > support wine, write the callbacks make it interface as it should, > basically making win32k into win32kX11 Graphic driver issues,,, so > the assumed response is no, why do all that when you can use the same > time writing it the right way. or Keep win32k, rewrite wine server and > winex11.drv to support NtGdi/NtUser calls.. Basically ending up > where you started off since over 80% of our win32k is wine code from > the start. Adapted modified and simplified to interface with drivers > and kernel. > > Look at it as a research project. We will answer these questions soon > James > > PS newbies, > FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that > have direct contact with kernel space. > * Split in two parts one "win32k" kernel space and the other user > space counter parts and uses data packets "known as shared data" > outside the API to transfer data from kernel space to user space and > back from user space to kernel space. > ___ > Ros-dev mailing > listros-...@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify SwitchToThread and QueueUserWorkItem - Remove unneeded InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT structure - Other sm
I have no idea why typecasting would make it "crash" on another architecture... On 21-Jul-09, at 4:02 AM, Ged wrote: > Dmitry do you have a reply for this? > I worry that you're simply copying Windows internals without > thinking about > it. > > I agree with Thomas on this, if we can do something better then we > should. > There's no reason to do everything in exactly the same manner just > to for > the sake of copying. In fact, I would actually advise we do things > slightly > differently whenever possible. > > Ged. > > > -Original Message- > From: ros-dev-boun...@reactos.org [mailto:ros-dev- > boun...@reactos.org] On > Behalf Of Thomas Bluemel > Sent: 17 July 2009 22:53 > To: ReactOS Development List > Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify > SwitchToThread and QueueUserWorkItem - Remove unneeded > InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT > structure - Other small changes > > Just because Wine and Windows do it that way doesn't make it any more > correct or portable. > > RtlQueueWorkItem expects a function of this type: > typedef VOID (NTAPI *WORKERCALLBACKFUNC)(IN PVOID Context); > > The supplied function is of this type: > typedef ULONG (NTAPI *PTHREAD_START_ROUTINE)(PVOID Parameter); > > This doesn't crash on x86 and "works" because the return value is > simply > ignored, but it's definitely not portable and MAY crash on another > architecture where it does make a difference. I don't know if it > would > matter on ARM/PPC/... but the old code at least implemented it > correctly/portable. It's not really an issue but IMO a bad hack. > Typecasting a function pointer to a function with a different > signature > is hardly ever good practice. > > - Thomas > > Dmitry Chapyshev wrote: >> On Fri, 17 Jul 2009 23:03:18 +0400, Thomas Bluemel > > > >> wrote: >> >>> This explains why we are using a trampoline function and not just >>> typecast there... Is there a reason you changed this? >>> >>> - Thomas >>> >>> dchapys...@svn.reactos.org wrote: >>>> -/* NOTE: Don't use Function directly since the callback >>>> signature >>>> - differs. This might cause problems on certain >>>> platforms... */ >>>> -Status = RtlQueueWorkItem(InternalWorkItemTrampoline, >>>> - WorkItemContext, >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >> Wine and Windows do so. Why we should do in another way? Other >> reasons are > >> necessary? >> > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify SwitchToThread and QueueUserWorkItem - Remove unneeded InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT structure - Other sm
That doesn't make any sense. All architectures have an ABI that defines which registers are used for return values, and so the compiler will NEVER (under ANY circumstances) assume that the return register should somehow be "usable", especially for an external function pointer! Furthermore, this is typecasting from a ULONG to a VOID, isn't it? So the "real" function will never return anything in the first place, making this a non-issue. I challenge you to provide a test case/example on any architecture where this could possibly happen. It can't. Best regards, Alex Ionescu On Tue, Jul 21, 2009 at 1:11 PM, Thomas Bluemel wrote: > On an architecture where function return values e.g. modify a register > that would otherwise be preserved? Or that have a different return > method depending on whether data needs to be returned? It's like > typecasting a function to one with a different calling method, except > that it may work fine for *most* but not all architectures. It's still > bad code... > > Thomas > Alex Ionescu wrote: > > I have no idea why typecasting would make it "crash" on another > > architecture... > > > > On 21-Jul-09, at 4:02 AM, Ged wrote: > > > >> Dmitry do you have a reply for this? > >> I worry that you're simply copying Windows internals without > >> thinking about > >> it. > >> > >> I agree with Thomas on this, if we can do something better then we > >> should. > >> There's no reason to do everything in exactly the same manner just > >> to for > >> the sake of copying. In fact, I would actually advise we do things > >> slightly > >> differently whenever possible. > >> > >> Ged. > >> > >> > >> -Original Message- > >> From: ros-dev-boun...@reactos.org [mailto:ros-dev- > >> boun...@reactos.org] On > >> Behalf Of Thomas Bluemel > >> Sent: 17 July 2009 22:53 > >> To: ReactOS Development List > >> Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify > >> SwitchToThread and QueueUserWorkItem - Remove unneeded > >> InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT > >> structure - Other small changes > >> > >> Just because Wine and Windows do it that way doesn't make it any more > >> correct or portable. > >> > >> RtlQueueWorkItem expects a function of this type: > >> typedef VOID (NTAPI *WORKERCALLBACKFUNC)(IN PVOID Context); > >> > >> The supplied function is of this type: > >> typedef ULONG (NTAPI *PTHREAD_START_ROUTINE)(PVOID Parameter); > >> > >> This doesn't crash on x86 and "works" because the return value is > >> simply > >> ignored, but it's definitely not portable and MAY crash on another > >> architecture where it does make a difference. I don't know if it > >> would > >> matter on ARM/PPC/... but the old code at least implemented it > >> correctly/portable. It's not really an issue but IMO a bad hack. > >> Typecasting a function pointer to a function with a different > >> signature > >> is hardly ever good practice. > >> > >> - Thomas > >> > >> Dmitry Chapyshev wrote: > >>> On Fri, 17 Jul 2009 23:03:18 +0400, Thomas Bluemel < > tho...@reactsoft.com > >>> wrote: > >>> > >>>> This explains why we are using a trampoline function and not just > >>>> typecast there... Is there a reason you changed this? > >>>> > >>>> - Thomas > >>>> > >>>> dchapys...@svn.reactos.org wrote: > >>>>> -/* NOTE: Don't use Function directly since the callback > >>>>> signature > >>>>> - differs. This might cause problems on certain > >>>>> platforms... */ > >>>>> -Status = RtlQueueWorkItem(InternalWorkItemTrampoline, > >>>>> - WorkItemContext, > >>>> ___ > >>>> Ros-dev mailing list > >>>> Ros-dev@reactos.org > >>>> http://www.reactos.org/mailman/listinfo/ros-dev > >>> > >>> > >>> Wine and Windows do so. Why we should do in another way? Other > >>> reasons are > >>> necessary? > >>> > >> ___ > >> Ros-dev mailing list > >> Ros-dev@reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > >> > >> ___ > >> Ros-dev mailing list > >> Ros-dev@reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > Best regards, > > Alex Ionescu > > > > ___ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] FullFAT replacement for Fastfat.sys
I'm still at a loss as to why you are all ignoring the free, open source, FastFAT driver in the Microsoft WDK. On 29-Jul-09, at 10:56 AM, Gabriel ilardi wrote: Hi James, Welcome to the team! ReactOS kernel aims to be compatible with W2k3's, meanwhile Win32 subsystem aims atm Vista. You'll come across missing stuff, just search for UNIMPLEMENTED throughout the code. Encoded started a page with missing functionality here:http://www.reactos.org/wiki/Missing_ReactOS_Functionality Hope you have fun with ReactOS as much as we do... Gabriel ilardi. > Date: Wed, 29 Jul 2009 13:59:42 +0200 > From: ja...@worm.me.uk > To: ros-dev@reactos.org > Subject: [ros-dev] FullFAT replacement for Fastfat.sys > > Hi Everyone, > > I just thought I'd introduce myself. I am the author of a new FAT > implementation that was really designed for embedded systems. As such > it provides very good performance. (See www.fullfat-fs.co.uk). > > Fireball contacted me a few days ago to discuss the current > development of FullFAT, and since I have agreed to implement an IFS > driver based on FullFAT with a view to replacing the current > fastfat.sys implementation. During the conversation we also discussed > implementing a special journaling extension to FullFAT via the windows > driver. > > I hope to start work on this project in the next few weeks, and > further to this I would also like to help in some other areas of > ReactOS. I shall be taking a closer look at the ReactOS code over the > coming weeks, and will probably post some questions about various > aspects. I have just bought the Windows Internals, fifth edition > co-authored by Alex Ionescu, hopefully this will provide me with a > good overview of the Windows architecture etc. > > For complete Windows XP compatibility, just how much of the > implementation is currently missing from ReactOS? > > Nice to meet you all, and I hope to provide some good contributions to > ReactOS in the near future. > > James > > -- > James Walmsley > > ja...@worm.me.uk > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! _______ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] FullFAT replacement for Fastfat.sys
I didn't say you should copy/paste the driver. But by all means, using it as a reference and writing an identically functioning driver is 100% legal. Hence I don't get the point of having "Experts" in FAT come and write an independent driver, or use some other non-Windows driver as reference/source. In fact, legally, I move that if ReactOS were to strip out 70% of the FastFAT code (totally likely, since the driver is legitimately bloated for things ReactOS doesn't even need to worry about yet), you could add the other 30% *as is*. I believe this work was already started by one of Aleksey's russian guys, but seems to have been dropped... On 29-Jul-09, at 4:47 PM, Steven Edwards wrote: > On Wed, Jul 29, 2009 at 5:00 PM, Alex Ionescu > wrote: >> I'm still at a loss as to why you are all ignoring the free, open >> source, >> FastFAT driver in the Microsoft WDK. > > Speaking just for myself, its not clear to me what in the aggregate of > the WDK is actually 'free' and which is just there for reference > purposes. I mean it could be perfectly fine and dandy for us to use > it, but without the ablity to do proper due diligence, it does not > seem to be worth it. Given the history of the fat patent mess, this > should seem perfectly clear. > > Until Microsoft has the desire to clearly lay out for us what is safe > to use in an open source project and what is not, I don't see why its > worth the risk. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > _______ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
What you guys need is some way to convince the ARM Ninjas that rewriting the memory manager won't make the ARM port easier -- but that rewriting win32k/gdi32/user32 will! Best regards, Alex Ionescu On Thu, Jul 30, 2009 at 1:32 PM, Samuel serapion wrote: > I love you. > > > On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer wrote: > >> King InuYasha schrieb: >> > Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the >> > implementation that some people are saying is "right" is more in line >> with >> > the NT4-WinXP. >> You obviously have no clue what you're talking about. >> arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 >> architecture. >> Also Vista/Win7 architecture is following XP/2003 architecture much more >> than NT3. >> >> > In the strictest sense of the definition, both arwinss and >> > the current default implementation styles are "correct." Both >> > implementations work and allow Windows NT drivers to work with it, so >> that's >> > not the problem. It also adds in RDP-esque support through X, which is >> > pretty cool too. >> > I guess some of these people don't like Wine code. The problem with that >> is >> > that without Wine code, ReactOS would probably take ten times as long to >> > actually get to a usable state. >> That's just bs. >> The win32 subsystem has a bunch of bugs yes, but don't expect them to go >> away by using more wine code. >> >> > Using Wine code for win32k seems to cross >> > some sort of line for them. I heard some of them saying the Wine code >> for >> > win32k is "ugly." >> When you talk about "them" and "these people" you talk about us, don't >> you? It's win32k devs you talk about, right? If you can do the coding >> for us, ... >> >> > What does ugliness have to do with it? Being able to share >> > more with Wine saves a lot of hard work from ReactOS devs. They can >> focus >> > more on bringing the NT kernel up to scratch, rather than spending more >> time >> > with the Win32k code. >> And this is exactly what is *not* happening. Aleksey currentlty spends >> his time with this win32k rewrite instead of something useful, like >> fixing the kernel or fixing the real win32k or fixing fat or usb or >> porting reactos to mips. >> >> > They could even work on adding in other subsystems, if >> > they wanted to. >> > >> Yes everyone is free to code what he likes, it just won't lead us >> anywhere. >> >> Sorry for sounding rude, but I just hate when people with no >> understanding about the topic are spreading misinformation. >> >> Thanks, >> Timo >> >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 42305: Add a hack in KiSystemStartupReal function until Better Times.
Please apply this hack in ke/freeldr.c Best regards, Alex Ionescu On Sat, Aug 1, 2009 at 3:55 AM, Dmitry Gorbachev wrote: > > otherwise you're breaking ntldr boot style, I suppose. > > No, the new hack is applied only if the old is present. > > > Should I or would you? > > Why to change that old style, if it is going to be replaced by the > new? There are probably more important things to do. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 42305: Add a hack in KiSystemStartupReal function until Better Times.
ke/freeldr.c was designed for sh*t. It really means, translated sh/itfile.c and I was actually hoping to commit it that way. The other files are designed to be 100% compatible and as much as possible identical to 2003 SP1, so please remove that hack from there. You can put anything you want in sh/itfile.c (oops, I mean ke/freeldr.c), including GRUB code, Wine code and Linux_kernel_functions all day long. Best regards, Alex Ionescu On Sat, Aug 1, 2009 at 2:27 PM, Dmitry Gorbachev wrote: > > Please apply this hack in ke/freeldr.c > > Should I apply same sh*t to different file? :) I believe that now > everything is 'right' there, nothing to change. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 42305: Add a hack in KiSystemStartupReal function until Better Times.
ASCII porn of RMS is also okay. Best regards, Alex Ionescu On Sat, Aug 1, 2009 at 3:26 PM, Alex Ionescu wrote: > ke/freeldr.c was designed for sh*t. It really means, translated sh/itfile.c > and I was actually hoping to commit it that way. > The other files are designed to be 100% compatible and as much as possible > identical to 2003 SP1, so please remove that hack from there. > > You can put anything you want in sh/itfile.c (oops, I mean ke/freeldr.c), > including GRUB code, Wine code and Linux_kernel_functions all day long. > > Best regards, > Alex Ionescu > > > > On Sat, Aug 1, 2009 at 2:27 PM, Dmitry Gorbachev > wrote: > >> > Please apply this hack in ke/freeldr.c >> >> Should I apply same sh*t to different file? :) I believe that now >> everything is 'right' there, nothing to change. >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 42305: Add a hack in KiSystemStartupReal function until Better Times.
Thanks dad, baby Bragin and Ionescu love you. Best regards, Alex Ionescu On Sat, Aug 1, 2009 at 5:15 PM, Dmitry Gorbachev wrote: > > The other files are designed to be 100% compatible and as much as > possible > > identical to 2003 SP1, so please remove that hack from there. > > All right, I will change it "because I want to stop the crying of a > baby." :) This small modification receives more attention then it > deserves. One fine day, these hacks will be removed, anyway. > > Alex Ionescu wrote: > > ASCII porn of RMS is also okay. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42333: - Handle case when RosGdiSetDeviceClipping is being called without rects at all (with a respective DPRINT1). - Use combined clipping object everywhere to en
A similar question would apply to the ninjas' "issue #" that crept up once or twice... Best regards, Alex Ionescu On Sun, Aug 2, 2009 at 3:26 PM, Steven Edwards wrote: > On Sun, Aug 2, 2009 at 6:32 AM, wrote: > > - Use combined clipping object everywhere to ensure drawing happens only > in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox > and other apps which would corrupt memory if trying to blit to area outside > of DC. > > I keep seeing these comments, 'see arwinss nr. #'. Where do I go to > look this up? > > Thanks > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
The version that GCC 4.4 and CL 15 will generate would be way more optimized than this unportable/slower assembly code. This isn't 1994 anymore. You can't beat the compiler anymore. Best regards, Alex Ionescu On Sun, Aug 2, 2009 at 3:31 PM, wrote: > Author: tkreuzer > Date: Mon Aug 3 00:31:29 2009 > New Revision: 42353 > > URL: http://svn.reactos.org/svn/reactos?rev=42353&view=rev > Log: > asm version of DIB_32BPP_ColorFill: > - Add frame pointer > - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned > - Optimize the loop > - Add comments > > Modified: >trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > > Modified: > trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s?rev=42353&r1=42352&r2=42353&view=diff > > == > --- trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > [iso-8859-1] Mon Aug 3 00:31:29 2009 > @@ -4,78 +4,62 @@ > * FILE:subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.c > * PURPOSE: ASM optimised 32bpp ColorFill > * PROGRAMMERS: Magnus Olsen > + * Timo Kreuzer (timo.kreu...@rectos.org) > */ > > - .globl _DIB_32BPP_ColorFill > - .intel_syntax noprefix > +.intel_syntax noprefix > > - .def _DIB_32BPP_ColorFill; > - .scl 2; > - .type32; > - .endef > - > - _DIB_32BPP_ColorFill: > -sub esp, 24 > -mov ecx, [esp+32] > -mov [esp+8], ebx > -mov ebx, [esp+28] > -mov [esp+20], ebp > -mov ebp, [esp+36] > -mov [esp+12], esi > -mov [esp+16], edi > -mov edi, [ecx] > -mov esi, [ecx+8] > -mov edx, [ebx+36] > -sub esi, edi > -mov edi, [ecx+4] > -mov eax, edi > -imuleax, edx > -add eax, [ebx+32] > -mov ebx, [ecx] > -lea eax, [eax+ebx*4] > -mov [esp+4], eax > -mov eax, [ecx+12] > -cmp eax, edi > -jbe end > -sub eax, edi > -mov [esp], eax > -lea esi, [esi+0] > +/* > + * BOOLEAN > + * _cdecl > + * DIB_32BPP_ColorFill(SURFOBJ* pso, RECTL* prcl, ULONG iColor); > +*/ > > - for_loop: > -mov eax, ebp > -cld > -mov ebx, esi > -mov edi, [esp+4] > -testedi, 3 > -jnz algin_draw > -mov ecx, esi > -rep stosd > -add [esp+4], edx > -dec dword ptr [esp] > -jnz for_loop > - end: > -mov ebx, [esp+8] > -mov eax, 1 > -mov esi, [esp+12] > -mov edi, [esp+16] > -mov ebp, [esp+20] > -add esp, 24 > -ret > +.globl _DIB_32BPP_ColorFill > +_DIB_32BPP_ColorFill: > +pushebp > +mov ebp, esp > +pushebx > +pushesi > +pushedi > +sub esp, 4/* Space for lDelta */ > > - algin_draw: > -stosd > -dec ebx > -mov ecx, ebx > -rol eax, 16 > -stosd > -add [esp+4], edx > -dec dword ptr [esp] > -jnz for_loop > +mov edx, [ebp+12] /* edx = prcl */ > +mov ecx, [ebp+8] /* ecx = pso */ > > -mov ebx, [esp+8] > -mov eax, 1 > -mov esi, [esp+12] > -
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
Just got back to San Francisco... I will take you up on the challenge. Your ass is grass, and I'm the lawnmower. Best regards, Alex Ionescu On Mon, Aug 3, 2009 at 11:15 AM, Timo Kreuzer wrote: > yeah ;-) > > Dmitry Gorbachev wrote: > > Bug? > > > > > >> ULONG lDelta, cx, cy; > >> > >> if (cx <= 0) > >> return TRUE; > >> > > > > ___ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
I won. I actually had to spend the better part of the hour convincing GCC *not* to optimize, just to make things fair. You see, because one of the #1 reasons why inline ASM loses vs C, is that gcc understood the structure of my code -- it realized that I was calling the function with static parameters, and integrated them into the function itself. I tried calling the function twice -- gcc actually inlined the function twice, with static parameters twice! I finally settled on calling it with arguments from the command line, which are always changing. But this proves one of the first points -- gcc will be able to analyze the form of your program, and make minute optimizations that are *impossible* to do in ASM. For example, it could decide "all functions calling this function will store parameter 3 in ECX" and this will optimize the overall speed of the entire program, not only the function, plus save stack space. This is only an example of the many hidden optimizations it could decide to do. Depending on how many times/how this function is called, gcc could've done any number of register allocation and tree/loop optimizations based on the code. Once I fooled gcc into generating "stupid" code, the output was very similar, but more optimized than yours -- partly because ebp was clobbered. In case you're wondering, yes, gcc inlined the rep stosd. However, it chose rep stosb instead, because I did not give it a guarantee of alignment (that would be a simple __attribute__). More importantly however, once I selected -mtune=core2, gcc destroyed you. It made uglier (less compact) code, but didn't use any push/pops at all, and moved data directly into the stack. It also used some more exotic checks and operands, because it KNEW that this would be faster on the Core 2 I was testing on. When I used -mtune=486, or -mtune=k6, I once again got very different looking programs. Because gcc knew what was best for each chip. You don't, and even if you did, you'd have to write 50 versions of your assembly code. I also built it for x64 and ARM, and got fast code for those platforms too -- your assembly code requires someone to port it. Additionally, gcc also aligned the code, and certain parts of the loop, to best suit the cache settings of the platform, and where the code was actually located in the binary. Finally, on certain platforms, gcc chose to call memset instead, and provided a highly optimized memset implementation which even used SSE 4.1 if required (if it determined it would be fastest for this set of inputs). Again, your rep movsd, while fast on 486, is slow as molasses on newer Core processors (or even the P3), because it gets micro-coded and has to do a lot of pre-setup work. I don't know if you were trying to bait me -- I respect you and I'm pretty sure you knew these facts, so I'm surprised about this "challenge". Best regards, Alex Ionescu On Mon, Aug 3, 2009 at 7:05 PM, WaxDragon wrote: > Your kung-fu is the best, Alex. > > On Aug 3, 2009 7:22 PM, "Alex Ionescu" wrote: > > Just got back to San Francisco... I will take you up on the challenge. > Your ass is grass, and I'm the lawnmower. > Best regards, > Alex Ionescu > > On Mon, Aug 3, 2009 at 11:15 AM, Timo Kreuzer wrote: > >> yeah ;-) > > Dmitr... > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
The optimizer will do this for you if you write out the actual C code
of what you're trying to achieve (a loop setting dwords to zero).
Another option (in NT) is to use RtlFillMemoryUlong.
So yes, my second version just does it in C, and that's how GCC is
able to perform the best possible zeroing (the kernel itself will use
XMMI btw)
Best regards,
Alex Ionescu
On Mon, Aug 3, 2009 at 8:37 PM, Alexander Potashev wrote:
> Hey, relax, guys!
>
>
> Btw, 'memset' can only fill a chunk of memory with identical bytes,
> thus it can't fill an array of DWORDs.
>
> 2009/8/3 Timo Kreuzer :
>> That would be a few lines, wouldn't it?
>> Ok, let me do the work for you.
>> And now compile and show me how the loop would be optimized anywhere near
>> the asm code.
>> Or can you do better?
>>
>> BOOLEAN
>> DIB_32BPP_ColorFill(SURFOBJ* pso, RECTL* prcl, ULONG iColor);
>> {
>> ULONG lDelta, cx, cy;
>> ULONG pulLine;
>>
>> lDelta = pso->lDelta;
>> pulLine= (PULONG)((PCHAR)pso->pvScan0 + prcl->top * lDelta + prcl->left
>> * 4);
>>
>> cx = prcl->right - prcl->left;
>> if (cx <= 0)
>> return TRUE;
>>
>> cy = prcl->bottom - prcl->top;
>> if (cy <= 0)
>> return TRUE;
>>
>> do
>> {
>> memset(pulLine, iColor, cx);
>> pulLine += lDelta / 4;
>> cy--;
>> } while (cy > 0);
>>
>> return TRUE;
>> }
>>
>>
>> Aleksey Bragin schrieb:
>>
>> "in a few lines" - and what if about using the same algorithm you used in
>> this assembly, but without pretending to be compiler?
>>
>>
>> WBR,
>> Aleksey.
>>
>> On Aug 3, 2009, at 7:31 AM, Timo Kreuzer wrote:
>>
>> I hereby challenge you to provide portable C code, that - compiled with gcc
>> - is faster than this assembly code.
>> Should be done in a few lines.
>>
>> I bet my ass on it: You will fail! No matter what optimization you choose.
>> You would also fail with msvc or Intel compiler.
>>
>> Regards,
>> Timo
>>
>> Alex Ionescu wrote:
>>
>> The version that GCC 4.4 and CL 15 will generate would be way more optimized
>> than this unportable/slower assembly code.
>> This isn't 1994 anymore. You can't beat the compiler anymore.
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>> On Sun, Aug 2, 2009 at 3:31 PM, wrote:
>>
>>
>> Author: tkreuzer
>> Date: Mon Aug 3 00:31:29 2009
>> New Revision: 42353
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=42353&view=rev
>> Log:
>> asm version of DIB_32BPP_ColorFill:
>> - Add frame pointer
>> - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned
>> - Optimize the loop
>> - Add comments
>>
>> Modified:
>> trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s
>>
>> Modified:
>> trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s?rev=42353&r1=42352&r2=42353&view=diff
>>
>> ==
>> --- trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s
>> [iso-8859-1] (original)
>> +++ trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s
>> [iso-8859-1] Mon Aug 3 00:31:29 2009
>> @@ -4,78 +4,62 @@
>> * FILE: subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.c
>> * PURPOSE: ASM optimised 32bpp ColorFill
>> * PROGRAMMERS: Magnus Olsen
>> + * Timo Kreuzer (timo.kreu...@rectos.org)
>> */
>>
>> - .globl _DIB_32BPP_ColorFill
>> - .intel_syntax noprefix
>> +.intel_syntax noprefix
>>
>> - .def _DIB_32BPP_ColorFill;
>> - .scl 2;
>> - .type 32;
>> - .endef
>> -
>> - _DIB_32BPP_ColorFill:
>> - sub esp, 24
>> - mov ecx, [esp+32]
>> - mov [esp+8], ebx
>> - mov ebx, [esp+28]
>> - mov [esp+20], ebp
>> - mov ebp, [esp+36]
>> - mov [esp+12], esi
>> - mov [esp+16], edi
>> - mov edi, [ecx]
>> -
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
I will provide some code and timings but I love how you ignored my
main points:
1) The optimizations of the code *around* the function (ie: the
callers), which Michael also pointed out, cannot be done in ASM.
2) The fact if you try this code on a Core 2, Pentium 4, Pentium 1 and
Nehalem you will get totally different results with your ASM code,
while the compilers will generate the best possible code.
3) The fact that someone will now have to write optimized versions for
each other architecture
4) The fact that if the loop is what you're truly worried about, you
can optimize it by hand with __builtinia32_rep_movsd (and MSVC has a
similar intrinsic), and still keep the rest of the function portable C.
Also, gcc does support profiling, another fact you don't seem to know.
However, with linker optimizations, you do not need a profiler, the
linker will do the static analysis.
Also, to everyone sayings things like "I was able to save a ", I hope you understand that smaller != faster.
On 4-Aug-09, at 10:13 AM, Timo Kreuzer wrote:
> Michael Steil wrote:
>>
>> I wonder, has either of you, Alex or Timo actually *benchmarked* the
>> code on some sort of native i386 CPU before you argue whether it
>> should be a stosb or a stosd? If not, writing assembly would be a
>> clear case of "premature optimization".
>>
> I did. on Athlon X2 64, I called the function a bunch ot times, with a
> 100x100 rect, measuring time with rdtsc the results were quite
> random,
> but roughly
> asm: ~580
> gcc 4.2 -march=k8 -fexpensive-optimizations -O3: ~1800
> WDK: /GL /Oi /Ot /O2 : ~2600
> MSVC 2008 express: /GL /Oi /Ot /O2 ~1800
>
> using a 50x50 rect shifts the advantage slightly in direction of the
> asm
> implementations.
>
> I added volatile to the pointer to prevent the loop to be optimized
> away.
> using memset was a bit slower than a normal loop.
> This is what msvc produced with the above settings
>
> _DIB_32BPP_ColorFill:
>push ebx
>mov ebx, [eax+8]
>subebx, [eax]
>testebx, ebx
>jg short label1
>xoral, al
>pop ebx
>retn
>
> label1:
>mov ecx, [eax+4]
>push esi
>mov esi, [eax+0Ch]
>sub esi, ecx
>test esi, esi
>jg short label2
>pop esi
>xor al, al
>pop ebx
>retn
>
> label2:
>mov eax, [edx+4]
>imul ecx, eax
>add ecx, [edx]
>cdq
>and edx, 3
>add eax, edx
>sar eax, 2
>add eax, eax
>push edi
>mov edi, ecx
>add eax, eax
>jmp short label3
>
> align 10h
> label3:
>mov ecx, edi
>mov edx, ebx
>
> label4:
>mov dword ptr [ecx], 3039h
>add ecx, 4
>sub edx, 1
>jnzshort label4
>
>dec esi
>add edi, eax
>test esi, esi
>jg short label3
>
>pop edi
>pop esi
>mov al, 1
>pop ebx
>retn
>
>
>
> I though myself I did something wrong. For me no compiler was able to
> generate code as fast as the asm code.
> I don't know how Alex managed to get better optimizations, maybe he
> knows a secret ninja /Oxxx switch, or maybe express and wdk version
> both
> suck at optimizing or maybe I'm just too supid... ;-)
>
>
>> See above: If all you want to optimize is the loop, then have C code
>> with asm("rep movsd") in it, or fix the static inline memcpy() to be
>> more efficient (if it isn't efficient in the first place).
>>
> I tried __stosd() which actually resulted in a faster function. with
> ~610 gcc was aslmost as fast as the asm implementation, msvc actually
> won with 590. But that was using not pure portable code. It's the best
> solution, it seems, although it will probably still be slower unless
> we
> set our optimization to max.
>
> Btw, I already thought about rewriting our dib code some time ago.
> Using
> inline functions instead of a code generator. The idea is to make it
> fully portable, optimizable though inline asm functions where useful
> and
> easier to maintain then the current stuff. It's on my list...
>
> Timo
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
On 4-Aug-09, at 12:36 PM, Timo Kreuzer wrote:
Alex Ionescu wrote:
I will provide some code and timings but I love how you ignored my
main points:
And you ignored my main points:
1) The optimization "around" the function is not important, as the
function is not called that often, the loop is much more important.
If the function is not called often, then you using ASM as an
optimization is what we call "premature optimization".
You should spend your time profiling the codebase and identifying real
bottlenecks.
2) It doesn't matter if the function performs differently on
different machines as long as it's always faster than the portable
code.
Which is an assumption you're making. My point is that it won't be.
3) Noone is forced to write optimized versions, we have a C version
for all other architectures..
So now we have a huge performance delta (if it were to exist) between
different architectures, as well as two code bases (and possibly more,
as people write more ASM versions), and eventually there are 10
versions of the same function, with different bugs.
Great!
(Please don't write code in a real company's product, kthx).
4) I'm not worried about the loop, the loop is fine the way I wrote
it ;-)
I don't get it? You just claimed the loop is "90%", and that yours is
better because it's in ASM and uses REP MOVSD. So take the C version,
and make an inline REP MOVSD instead of a memset, and you know have
your exact code, but written in C.
I just claimed that you couldn't provide a faster C version. Faster
in terms of real life usage. And I'm yet waiting for you to prove me
wrong.
1) The optimizations of the code *around* the function (ie: the
callers), which Michael also pointed out, cannot be done in ASM.
2) The fact if you try this code on a Core 2, Pentium 4, Pentium 1
and
Nehalem you will get totally different results with your ASM code,
while the compilers will generate the best possible code.
3) The fact that someone will now have to write optimized versions
for
each other architecture
4) The fact that if the loop is what you're truly worried about, you
can optimize it by hand with __builtinia32_rep_movsd (and MSVC has a
similar intrinsic), and still keep the rest of the function
portable C.
Also, gcc does support profiling, another fact you don't seem to
know.
However, with linker optimizations, you do not need a profiler, the
linker will do the static analysis.
Also, to everyone sayings things like "I was able to save a ", I hope you understand that smaller != faster.
On 4-Aug-09, at 10:13 AM, Timo Kreuzer wrote:
Michael Steil wrote:
I wonder, has either of you, Alex or Timo actually *benchmarked*
the
code on some sort of native i386 CPU before you argue whether it
should be a stosb or a stosd? If not, writing assembly would be a
clear case of "premature optimization".
I did. on Athlon X2 64, I called the function a bunch ot times,
with a
100x100 rect, measuring time with rdtsc the results were quite
random,
but roughly
asm: ~580
gcc 4.2 -march=k8 -fexpensive-optimizations -O3: ~1800
WDK: /GL /Oi /Ot /O2 : ~2600
MSVC 2008 express: /GL /Oi /Ot /O2 ~1800
using a 50x50 rect shifts the advantage slightly in direction of the
asm
implementations.
I added volatile to the pointer to prevent the loop to be optimized
away.
using memset was a bit slower than a normal loop.
This is what msvc produced with the above settings
_DIB_32BPP_ColorFill:
push ebx
mov ebx, [eax+8]
subebx, [eax]
testebx, ebx
jg short label1
xoral, al
pop ebx
retn
label1:
mov ecx, [eax+4]
push esi
mov esi, [eax+0Ch]
sub esi, ecx
test esi, esi
jg short label2
pop esi
xor al, al
pop ebx
retn
label2:
mov eax, [edx+4]
imul ecx, eax
add ecx, [edx]
cdq
and edx, 3
add eax, edx
sar eax, 2
add eax, eax
push edi
mov edi, ecx
add eax, eax
jmp short label3
align 10h
label3:
mov ecx, edi
mov edx, ebx
label4:
mov dword ptr [ecx], 3039h
add ecx, 4
sub edx, 1
jnzshort label4
dec esi
add edi, eax
test esi, esi
jg short label3
pop edi
pop esi
mov al, 1
pop ebx
retn
I though myself I did something wrong. For me no compiler was able
to
generate code as fast as the asm code.
I don't know how Alex managed to get better optimizations, maybe he
knows a secret ninja /Oxxx switch, or maybe express and wdk version
both
suck at optimizing or maybe I'm just too supid... ;-)
See above: If all you want to optimize is the loop, then have C
code
with asm("rep movsd") in it, or fix the static inline memcpy() to
be
more efficient (if it isn't efficient in the first place).
I tried __stosd() which actually resulted in a faster fu
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
Note to everyone else: I just spent some time to do the calculations and have data proving C code can be faster -- I will post tonight from home. Now to get to your argument, Jose.. Best regards, Alex Ionescu On Tue, Aug 4, 2009 at 2:19 PM, Jose Catena wrote: > With all respect Alex, although I agree with you in the core, that this does > not deserve the disadvantages of asm for a tiny performance difference if > any (portability, readability, etc), I don't agree with many your arguments. Also keep in mind Timo admitted "This code is not called often", making ASM optimization useless. > > --> > 1) The optimizations of the code *around* the function (ie: the > callers), which Michael also pointed out, cannot be done in ASM. > > <-- > Yes, it can. I could always outperform or match a C compiler at that, and > did many times (I'm the author of an original PC BIOS, performance > libraries, mission critical systems, etc). > I very often used regs for calling params, local storage through SP instead > of BP, good use and reuse of registers, etc. An optimizing compiler will do this too. > In fact, the loop the compiler generated was identical to the asm source > except for the two instructions the compiler added (that serve for no > purpose, it is a msvc issue). Really? Here's sample code from my faster C version: .text:004013E0 lea eax, [esi+eax*4] .text:004013E3 lea esi, ds:0[edi*4] .text:004013EA lea eax, [ebp+eax+0] .text:004013EE db 66h .text:004013EE nop 99% percent of people on this list (and you, probably) will tell me "this is a GCC issue" or that this is "useless code". Guess what, I compiled with mtune=core2 and this code sequence is specifically generated before the loop. Timo, and I admit not even myself, would think of adding this kind of code. But once I asked some experts what this does, I understood why it's there. To quote Michael "if you think the compiler is generating useless code, try to find out what the code is doing." In most cases, your thinking that it is "wrong" or "useless" is probably wrong itself. As a challenge, can you tell me the point of this code? Why is it written this way? If I build for 486 (which is what ALL OF YOU SEEM TO BE STUCK ON!!!), I get code that looks like Timo's. > It is actually in the calling overhead and local initialization and storage > where I could easily beat the compiler, since it complies with rules that I > can safely break. That doesn't make any sense. You are AGREEING with me. My point is that a compiler will break normal calling rules while the assembly code will have to respect at least some rules, because you won't know apriori all your callers (you might in a BIOS, but not in a giant code like win32k). The compiler on the other hand, DOES know all the callers, and will hapilly clober registers, change the calling convention, etc. Please re-read Michael's email. > Furthermore, in most cases a compiler won't change calling convention unless > the source specifies it Completely not true. Compilers will do this. This is not 1994 anymore. , and in any case the register based calling used by > compilers is way restricted compared with what can be done in asm which can > always use more efficient methods (more extensive and intelligent register > allocation). Again, simply NOT true. Today's compilers will be able to do things like "All callers of foo must have param 8 in ECX", and will write the code that way, not to save/restore ECX, and to use it as a parameter. You CANNOT do this in assembly unless you have a very small number of callers that you know nobody else will touch. As soon as someone else adds a caller, YOU have to do all the work to make ECX work that way. You seem to have a very 1990ies understanding of how compilers work (respecting calling conventions, save/restoring registers, not touching ebp, etc). Probably because you worked on BIOSes, which yes, in that time, worked that way. Please read a bit into the technologies such as LLVM or microsoft's link time code generator. > In any case, the most important optimizations are equally done in C and > assembly when the programmer knows how to write optimum code and does not > have to comply with a prototype. Again, NO. Unless you control all your callsites and are willing to update the code each single time a cal site gets added, the compiler WILL beat you. LLVM and LTCG can even go 2-3 call sites away, such that callers of foo which call bar which call baz have some sort of stack frame or register content that will make barbaz faster. > For example passing arguments as a pointer > to an struct is always more efficient. > It actually depen
Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments
Also, rep movsd will be slower on small counts. On most processors,
less than 8 iterations will be faster with a move than with a rep.
This has changed lately:
http://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/51402/reply/34703/
With blocks larger than 512 bytes, SSE/FPU code will always be faster.
On 4-Aug-09, at 9:50 PM, Michael Steil wrote:
> On 4 Aug 2009, at 17:37, Jose Catena wrote:
>>> but how would you want to optimize "rep stosd" anyway?
>>
>> No way. That's what I said, possibly with the exception of using a
>> 64 bit
>> equivalent if we could assume that the CPU is 64 bit capable.
>> But Alex knows better, he's is calling me an ignorant. He says that
>>
>> L1: Mov [edi], eax
>> Add edi, 4
>> Dec ecx
>> Jnz L1
>>
>> Is faster than
>>
>> rep stosd
>>
>> Both things do exactly the same thing, the later much smaller AND
>> FASTER in
>> any CPU from the 386 to the i7.
>
> I have done some tests on all generations of Intel CPUs since Yonah,
> and in all cases, rep stosd was faster than any loop I could craft or
> GCC would generate from my C code.
>
> But this does *not* mean that
> * rep stosd is by definition faster than a scalar loop
> * rep stosd is by definition faster than any kind of loop.
>
> Look at the test program at the end of this email. It compares rep
> stosd with a hand-crafted loop written with SSE instructions and SSE
> registers (parts borrowed from XNU).
>
> On all tested machines, the SSE version is significantly faster (for
> big loops):
>
> Yonah: Genuine Intel(R) CPU T2500 @ 2.00GHz
> SSE is 3.34x faster than stosl
>
> Merom: Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
> SSE is 4.86x faster than stosl
>
> Penryn: Intel(R) Xeon(R) CPU5150 @ 2.66GHz
> SSE is 4.94x faster than stosl
>
> Nehalem: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz
> SSE is 4.62x faster than stosl
>
> So one should not assume that it's a good idea to always just use rep
> stosd. Use memset(), and have an optimized implementation of memset()
> somewhere else. One that can be inlined, and checks the size and
> branches to the optimal implementation: Like XNU does it, for example:
>
> http://fxr.watson.org/fxr/source/osfmk/i386/commpage/?v=xnu-1228
>
> Michael
>
>
> #include
> #include
> #include
>
> #define MIN(a,b) ((a)<(b)? (a):(b))
>
> #define DATASIZE (1024*1024)
> #define TIMES 1
>
> static inline long long
> rdtsc64(void)
> {
> long long ret;
> __asm__ volatile("lfence; rdtsc; lfence" : "=A" (ret));
> return ret;
> }
>
> static inline void
> sse(int *p) {
> int c_new;
> char *p_new;
> asm volatile (
> "1: \n"
> "movdqa %%xmm0,(%%edi,%%ecx) \n"
> "movdqa %%xmm0,16(%%edi,%%ecx) \n"
> "movdqa %%xmm0,32(%%edi,%%ecx) \n"
> "movdqa %%xmm0,48(%%edi,%%ecx) \n"
> "subl$64,%%ecx \n"
> "jns 1b \n"
> : "=D"(p_new), "=c"(c_new)
> : "D"(p), "c"(DATASIZE/sizeof(int))
> );
> }
>
> static inline void
> stos(int *p) {
> int c_new;
> char *p_new;
> asm volatile (
> "rep stosl"
> : "=D"(p_new), "=c"(c_new)
> : "D"(p), "c"(DATASIZE/sizeof(int)), "a"(1)
> );
> }
>
> int
> main() {
> void *data = malloc(DATASIZE);
> long long t1, t2, t3, m1, m2;
> int i;
>
> t1 = rdtsc64();
>
> for (i = 0; i < TIMES; i++)
> sse(data);
>
> t2 = rdtsc64();
>
> for (i = 0; i < TIMES; i++)
> stos(data);
>
> t3 = rdtsc64();
>
> m1 = t2 - t1;
> m2 = t3 - t2;
>
> if (m1>m2)
> printf("stosl is %.2fx faster than SSE\n", (float)m1/m2);
> else
> printf("SSE is %.2fx faster than stosl\n", (float)m2/m1);
>
> return 0;
> }
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 42400: - Partial rewrite of recursive mutex code - Makes the recursive mutex faster and smaller - Fixes several unprotected accesses to recursive mutex
t++;
> -ExReleaseFastMutex( &RecMutex->Mutex );
> -} else {
> -KeAcquireSpinLockAtDpcLevel( &RecMutex->SpinLock );
> -RecMutex->OldIrql = DISPATCH_LEVEL;
> -RecMutex->Locked = TRUE;
> -RecMutex->Writer = ToWrite;
> -RecMutex->CurrentThread = CurrentThread;
> -RecMutex->LockCount++;
> +while( RecMutex->LockCount != 0 ) {
> + ExReleaseFastMutex( &RecMutex->Mutex );
> + Status = KeWaitForSingleObject( &RecMutex->StateLockedEvent,
> + UserRequest,
> + KernelMode,
> + FALSE,
> + NULL );
> + ExAcquireFastMutex( &RecMutex->Mutex );
> }
> -
> -return TRUE;
> +RecMutex->CurrentThread = CurrentThread;
> +RecMutex->LockCount++;
> +ExReleaseFastMutex( &RecMutex->Mutex );
> }
>
> VOID RecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ) {
> +ASSERT(RecMutex);
> +
> +ExAcquireFastMutex( &RecMutex->Mutex );
>
> ASSERT(RecMutex->LockCount > 0);
> RecMutex->LockCount--;
>
> if( !RecMutex->LockCount ) {
> -RecMutex->CurrentThread = NULL;
> -if( RecMutex->OldIrql <= APC_LEVEL ) {
> -ExAcquireFastMutex( &RecMutex->Mutex );
> -RecMutex->Locked = FALSE;
> -RecMutex->Writer = FALSE;
> -ExReleaseFastMutex( &RecMutex->Mutex );
> -} else {
> -RecMutex->Locked = FALSE;
> -RecMutex->Writer = FALSE;
> -KeReleaseSpinLockFromDpcLevel( &RecMutex->SpinLock );
> -}
> -
> KePulseEvent( &RecMutex->StateLockedEvent,
> IO_NETWORK_INCREMENT,
> FALSE );
> }
> +
> +ExReleaseFastMutex( &RecMutex->Mutex );
> }
>
>
> Modified: trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h?rev=42400&r1=42399&r2=42400&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h
> [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h
> [iso-8859-1] Wed Aug 5 01:51:39 2009
> @@ -10,20 +10,12 @@
> PVOID CurrentThread;
> /* Notification event which signals that another thread can take
> over */
> KEVENT StateLockedEvent;
> -/* IRQL from spin lock */
> -KIRQL OldIrql;
> -/* Is Locked */
> -BOOLEAN Locked;
> -/* Is reader or writer phase */
> -BOOLEAN Writer;
> -/* Spin lock needed for */
> -KSPIN_LOCK SpinLock;
> } RECURSIVE_MUTEX, *PRECURSIVE_MUTEX;
>
> extern VOID RecursiveMutexInit( PRECURSIVE_MUTEX RecMutex );
> -extern SIZE_T RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex,
> BOOLEAN ToRead );
> +extern VOID RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex );
> extern VOID RecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex );
>
> -#define ASSERT_LOCKED(x) ASSERT((x)->Locked)
> +#define ASSERT_LOCKED(x)
>
> #endif/*_ROSRTL_RECMUTEX_H*/
>
> Modified: trunk/reactos/drivers/network/tcpip/tcpip/lock.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/tcpip/lock.c?rev=42400&r1=42399&r2=42400&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- trunk/reactos/drivers/network/tcpip/tcpip/lock.c [iso-8859-1]
> (original)
> +++ trunk/reactos/drivers/network/tcpip/tcpip/lock.c [iso-8859-1]
> Wed Aug 5 01:51:39 2009
> @@ -48,11 +48,9 @@
> RecursiveMutexInit( RecMutex );
> }
>
> -UINT TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, BOOLEAN
> ToWrite ) {
> -UINT Ret;
> +VOID TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, BOOLEAN
> ToWrite ) {
> //TI_DbgPrint(DEBUG_LOCK,("Locking\n"));
> -Ret = RecursiveMutexEnter( RecMutex, ToWrite );
> -return Ret;
> +RecursiveMutexEnter( RecMutex );
> }
>
> VOID TcpipRecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ) {
>
>
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 42530: modified base/setup/vmwinst/vmwinst.c modified base/setup/vmwinst/vmwinst.rbuild Implement VMWare detection for Visual C++ as well For cleaner code, use SEH
Awe, Thomas's "Fuck Alex" code is gone... On 8-Aug-09, at 11:03 AM, hyper...@svn.reactos.org wrote: > For cleaner code, use SEH instead of VEH, even if it means losing > this pearl of ReactOS wisdom: > > /* Setup a vectored exception handler to protect the > detection. Don't use SEH > here so we notice the next time someone removes support for > vectored > exception handling from ros... */ Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 42596: Implement EngFileIoControl and EngFileWrite
And since when is static used in ReactOS kernel code?
Best regards,
Alex Ionescu
On Mon, Aug 10, 2009 at 10:51 AM, Hervé Poussineau wrote:
> tkreu...@svn.reactos.org a écrit :
> > Author: tkreuzer
> > Date: Mon Aug 10 17:09:14 2009
> > New Revision: 42596
> >
> > +static
> > +DWORD
> > +EngpFileIoRequest(
> > + PFILE_OBJECT pFileObject,
> > + ULONG ulMajorFunction,
> > + LPVOID lpBuffer,
> > + DWORD nBufferSize,
> > + ULONGLONG ullStartOffset,
> > + OUT LPDWORD lpInformation)
> > +{
>
> [...]
>
> > + return STATUS_INVALID_PARAMETER;
>
> [...]
>
> > + return FALSE;
>
> [...]
>
> > + return NT_SUCCESS(Status);
> > +}
>
> I don't really understand what is supposed to return EngpFileIoRequest?
> A DWORD, a BOOLEAN, or a NTSTATUS?
>
>
> Hervé
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Some upcoming changes
Can we please 7zip logs instead of deleting them? Should give you massive improvements (especially since A) it's text B) it contains highly-repeatable file/function names). Thanks! Best regards, Alex Ionescu On Sat, Aug 15, 2009 at 7:17 PM, Colin Finck wrote: > Hello all, > > I just wanted to announce some upcoming changes. Comments are appreciated. > > > Official removal of i486 support > - > The Mingw-w64 project held an internal meeting today. One of the decisions > was to remove support for architectures older than i586 from their code. > As we already use some of their runtime code and loosely planned to switch > to a mingw-w64 x86/x64 multilib toolchain once that is released and stable > (which should be the case in gcc 4.5.x), we will be affected by this change, > too. > > Of course, the Mingw-w64 code would just add another problem to the pot of > i486 incompatibilities. > For example, some of our assembly code makes use of the CMPXCHG8B > instruction (introduced in the Pentium). > > Though I don't know anybody, who tried a recent ReactOS build on an i486 > machine, I also never found a statement about the official removal of i486 > support. > So as long as nobody objects, let's officially declare i486 support > abandoned now. > > > ISO cleaning on iso.reactos.org > > As we were right before running out of space on the ISO storage server (in > fact, that would have happened when Aleksey was on his planned holiday trip > :D), I've installed a script to clean old ISOs automatically now. > The script will remove bootcd-dbg ISOs older than 2 years and all other ISOs > older than half a year. This should free enough space while keeping enough > important ISOs for tracking down old regressions. > > > Testman log cleaning > - > Another service that takes more space than you might think is Testman. Logs > for ~1300 revisions currently take around 2 GB. > My plan would be to delete logs (not the actual test result numbers) older > than half a year to keep the used space for them on an almost constant > level. If nobody objects, such a script will be installed in the upcoming > days. > > > Best regards, > > Colin > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Some upcoming changes
How about archiving the older logs in a format that may be a one-time CPU expense, but never have to worry about uncompressing? Ie: I don't want really old logs accessible through the UI, but just available by developer request. Best regards, Alex Ionescu On Mon, Aug 17, 2009 at 2:36 AM, Colin Finck wrote: > Alex Ionescu wrote: >> Can we please 7zip logs instead of deleting them? > > As the logs are not simple text files, but stored in a database for showing > them together with other test information (see e.g. > http://backend.reactos.org/testman/detail.php?id=341420), I've used MySQL's > COMPRESS/UNCOMPRESS instead of 7-Zip now. > In my opinion, the higher memory requirements and system load of 7-Zip also > don't outweigh the compression ratio for text files, which shouldn't be that > much better compared to a zlib-based algorithm (as it's used by > COMPRESS/UNCOMPRESS). Keep in mind that everybody shall still be able to > easily access these logs over the web interface, so they have to be > uncompressed on-the-fly. > > But all in all, using compression here was a good idea, we're down to 190 MB > now. :-) > > Though I'm still not in favor of keeping logs of ancient revisions forever. > It's okay if we extend the limit to 2-3 years, but does anybody really need > even older logs? > > Best regards, > > Colin > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] GCC 4.4
Please see http://www.reactos.org/wiki/Moving_to_GCC_4.4 Thank you! Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
Hi Dmitry, Does that mean you have patches to fix all the warnings (and errors) in the log? Or have you just hacked the .rbuild files to ignore them? ;-) What about C++ support, how did you solve that? Happy to hear the test results are similar, however. Best regards, Alex Ionescu On Mon, Aug 24, 2009 at 11:00 AM, Dmitry Gorbachev wrote: > Hi, > > I use GCC 4.4 for ReactOS for a long time, and have not yet found any > major issues. Test results are similar to those from the server. > Looking into GCC 4.5 (has two regressions) and LLVM-GCC (one major bug > and some lesser). > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
Hi, I'd be curious about how you solved these issues: modules\rostests\dxtest\ddraw\testlist.cpp:29: error: deprecated conversion from string constant to 'CHAR*' base\shell\explorer\shell\pane.cpp:58: error: deprecated conversion from string constant to 'WCHAR*' modules\rosapps\applications\devutils\gdb2\gdb2.cpp:97: error: deprecated conversion from string constant to 'char*' modules\rostests\dxtest\ddraw\/debug.cpp:8: error: deprecated conversion from string constant to 'CHAR*' modules\rostests\dxtest\ddraw\/Surface/caps_tests.h:8: error: deprecated conversion from string constant to 'char*' And especially: modules\rostests\winetests\kernel32\thread.c:22:1: warning: "_WIN32_WINNT" redefined (and similar) And also the linker errors regarding unwind functions in C++, and the lack of a libgcc? How were you able to build ntoskrnl when the function to make the stack executable imports from VirtualProtect? Thanks! Best regards, Alex Ionescu On Mon, Aug 24, 2009 at 1:43 PM, Dmitry Gorbachev wrote: >> Does that mean you have patches to fix all the warnings (and errors) >> in the log? > > There are no errors. No need to fix all warnings at once. Though > ReactOS is compiling with -Werror, there are (commented out) options > in ReactOS-generic.rbuild, which demote some errors to warnings again, > so they will not be forgotten. > >> Or have you just hacked the .rbuild files to ignore them? ;-) > > I unhacked them. ;-) > >> What about C++ support, how did you solve that? > > I have not noticed any problems with C++. > >> Happy to hear the test results are similar, however. > > Everything is just fine! :-) > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
On 25-Aug-09, at 2:18 AM, Dmitry Gorbachev wrote: > Hi! > >> I'd be curious about how you solved these issues: >> >> error: deprecated conversion from string constant to 'CHAR*' > > As it is not a real error, I turned it into a warning again with > "-Wno-error=write-strings" in ReactOS-generic.rbuild. Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example. Perhaps you don't understand the issue: in C, declaring a string "const" means it will never be modified. Most linkers will place the string in .rdata, consequently. Writing to such a string is both dangerous, because you're breaking a contract, and will also generate a page fault, since you're trying to write to a read-only section (.rdata). > >> And especially: >> >> modules\rostests\winetests\kernel32\thread.c:22:1: warning: >> "_WIN32_WINNT" redefined > > GCC from RosBE also emits warnings like "_WIN32_IE" redefined, it does > not make impossible to use it. It is still a very big error to redefine the target version. > >> And also the linker errors regarding unwind functions in C++ > > Maybe your GCC is configured differently? What "gcc -v" says? > >> and the lack of a libgcc? > > How it can be?! > >> How were you able to build ntoskrnl when the function to >> make the stack executable imports from VirtualProtect? > > At first, patched GCC. But when Daniel said he failed to build GCC, I > replaced __enable_execute_stack() in libgcc instead. See bug #4810. So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode. > > Cheers, > Dmitry > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
Hi, On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote: >> Overwriting constant strings is a very real error and should be >> fixed. >> Code like this would crash in Windows, for example. > > These warnings do not mean overwriting, simply passing a string > constant to a function which takes char *; a potential, not > necessarily a real error. It is allowed in C, not in C++. So they still deserve fixing :) > > Of course, it would be good to check all warnings, some can be bugs. > Not all useful warnings are included in -Wall. It may be worth to > activate more. > > But warnings should not deter from adoption of GCC 4.4. I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today. > >> So as I said, ReactOS need an in-tree version of libgcc with proper >> support for __enable_execute_stack for kernel-mode. > > It is not needed in user-mode, too. Nested functions are only used by > PSEH2, and it works well without __enable_execute_stack() Sure, but that's not the only reason why an in-tree libgcc is a good idea. Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 42829: - svchost: #ifdef _MSC_VER doesn't mean "using Microsoft's headers" anymore - ddraw, imm32, msxml3, oleaut32, riched20: Include typeof.h for typeof emulati
"If (!x & 1)" is the most horrible way to write this. To most people
it means "NOT X AND 1", what you want is NOT(X AND 1).
Best regards,
Alex Ionescu
On Fri, Sep 11, 2009 at 7:31 PM, Jose Catena wrote:
> To check odd / even we should always use:
>
>
>
> // if odd
>
> If (x & 1)
>
> // if even
>
> If (!x & 1)
>
>
>
> % is very slow.
>
>
>
> Jose Catena
>
> DIGIWAVES S.L.
>
>
>
>
>
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of Wladimir A. Jimenez B.
> Sent: Friday, 11 September, 2009 16:56
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 42829: - svchost: #ifdef
> _MSC_VER doesn't mean "using Microsoft's headers" anymore - ddraw, imm32,
> msxml3, oleaut32, riched20: Include typeof.h for typeof emulation when
> compiling under MSVC and remove from React
>
>
>
> Filip:
>
>
>
>
>
> *NetworkAddressLength = (UINT)((j+1)/2);
>
>
>
> Do not equal to
>
>
>
>> + if ((j % 2) == 0) // if even
>> + {
>> + *NetworkAddressLength = (UINT)(j/2);
>> + }
>> + else
>> + {
>> + *NetworkAddressLength = (UINT)((j/2)+1);
>> + }
>
>
>
>
>
>
>
>
>
>
>
> 2009/8/23 Filip Navara
>
> On Fri, Aug 21, 2009 at 5:57 PM, wrote:
>> --- trunk/reactos/drivers/network/ndis/ndis/config.c [iso-8859-1]
>> (original)
>> +++ trunk/reactos/drivers/network/ndis/ndis/config.c [iso-8859-1] Fri Aug
>> 21 17:57:26 2009
>> @@ -705,7 +705,14 @@
>>
>> while (j < str.Length && str.Buffer[j] != '\0') j++;
>>
>> - *NetworkAddressLength = (UINT)((j/2)+0.5);
>> + if ((j % 2) == 0)
>> + {
>> + *NetworkAddressLength = (UINT)(j/2);
>> + }
>> + else
>> + {
>> + *NetworkAddressLength = (UINT)((j/2)+1);
>> + }
>
> Why not use *NetworkAddressLength = (UINT)((j+1)/2); unconditionally?
>
>>
>> if ((*NetworkAddressLength) == 0)
>> {
>>
>
> F.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> --
>
> Wladimir A. Jiménez B.
> http://www.kasbeel.cl
> Linux User # 444661
> Ubuntu User # 19201
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
So? What's the status on this? It's almost been a month. Best regards, Alex Ionescu On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer wrote: > Alex Ionescu wrote: >> Hi, >> >> On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote: >> >> >>>> Overwriting constant strings is a very real error and should be >>>> fixed. >>>> Code like this would crash in Windows, for example. >>>> >>> These warnings do not mean overwriting, simply passing a string >>> constant to a function which takes char *; a potential, not >>> necessarily a real error. It is allowed in C, not in C++. >>> >> So they still deserve fixing :) >> >> >>> Of course, it would be good to check all warnings, some can be bugs. >>> Not all useful warnings are included in -Wall. It may be worth to >>> activate more. >>> >>> But warnings should not deter from adoption of GCC 4.4. >>> >> I agree, but switching compilers is a great time to fix some warnings. >> It would take less then a day to fix the ones present today. >> >> >>> >>>> So as I said, ReactOS need an in-tree version of libgcc with proper >>>> support for __enable_execute_stack for kernel-mode. >>>> >>> It is not needed in user-mode, too. Nested functions are only used by >>> PSEH2, and it works well without __enable_execute_stack() >>> >> Sure, but that's not the only reason why an in-tree libgcc is a good >> idea. >> >> Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it >> could become part of RosBE -- they have not been able to figure out >> how to build the compiler, hence my idea to use the MinGW binaries. >> >> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> Best regards, >> Alex Ionescu >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > Maybe he can just look at our wiki: > http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so > that it works ;-) > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
So in other words, in a month minus 3 days: * The release engineer has expressed a desire (to do something that has already been attempted for 7 months and counting) and * A couple of developers (Stefan, mainly) have, at least, fixed a couple dozen warnings (thank you!) So: * No Libgcc has been imported into the tree yet (to solve some of the linker errors) as KJK has suggested he will do * No additional attempts/efforts (expressing a desire/want does not count as effort) have been made to recompile Mingw32-gcc-4.4 as Dmitry does. * Two months after Aleksey promised me that "he will write something about this", I still don't see any e-mail regarding GCC 4.4 (ie: I was bullshitted to). I think more effort needs to be put into this, honestly. Daniel, on the log: 1) Could you please separate trunk vs rosapps/rostests errors? 2) "In file included from modules\rosapps\applications\net\ncftp\sio\SClose.c:1: modules\rosapps\applications\net\ncftp\sio\/syshdrs.h:36:1: warning: "strncasecmp" redefined" is spamming half the log -- the actual error is only one (and pretty easy to fix, but that's another story), so I suggest you remove the 50 duplicate entries. 3) There used to be errors related to PSEH2 and executable stack -- have those been fixed or...? Thank you. Best regards, Alex Ionescu On Sun, Sep 13, 2009 at 3:21 PM, Daniel Reimer wrote: > Alex Ionescu wrote: >> So? What's the status on this? It's almost been a month. >> >> Best regards, >> Alex Ionescu >> >> >> >> On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer >> wrote: >> >>> Alex Ionescu wrote: >>> >>>> Hi, >>>> >>>> On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote: >>>> >>>> >>>> >>>>>> Overwriting constant strings is a very real error and should be >>>>>> fixed. >>>>>> Code like this would crash in Windows, for example. >>>>>> >>>>>> >>>>> These warnings do not mean overwriting, simply passing a string >>>>> constant to a function which takes char *; a potential, not >>>>> necessarily a real error. It is allowed in C, not in C++. >>>>> >>>>> >>>> So they still deserve fixing :) >>>> >>>> >>>> >>>>> Of course, it would be good to check all warnings, some can be bugs. >>>>> Not all useful warnings are included in -Wall. It may be worth to >>>>> activate more. >>>>> >>>>> But warnings should not deter from adoption of GCC 4.4. >>>>> >>>>> >>>> I agree, but switching compilers is a great time to fix some warnings. >>>> It would take less then a day to fix the ones present today. >>>> >>>> >>>> >>>>> >>>>>> So as I said, ReactOS need an in-tree version of libgcc with proper >>>>>> support for __enable_execute_stack for kernel-mode. >>>>>> >>>>>> >>>>> It is not needed in user-mode, too. Nested functions are only used by >>>>> PSEH2, and it works well without __enable_execute_stack() >>>>> >>>>> >>>> Sure, but that's not the only reason why an in-tree libgcc is a good >>>> idea. >>>> >>>> Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it >>>> could become part of RosBE -- they have not been able to figure out >>>> how to build the compiler, hence my idea to use the MinGW binaries. >>>> >>>> >>>> >>>>> ___ >>>>> Ros-dev mailing list >>>>> Ros-dev@reactos.org >>>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>>> >>>>> >>>> Best regards, >>>> Alex Ionescu >>>> >>>> >>>> ___ >>>> Ros-dev mailing list >>>> Ros-dev@reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>>> >>>> >>> Maybe he can just look at our wiki: >>> http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so >>> that it works ;-) >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > - Colin wants to build a GCC with more optimal settings than the > official one when he got some > spare time. > - I added a new log three days ago which shows the linking errors too. > - Some devs started to fix warnings and errors we get. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GCC 4.4
Finally. I apologize if I sounded rude but as you can see, asskicking works. Best regards, Alex Ionescu On Tue, Sep 15, 2009 at 10:18 AM, Daniel Reimer wrote: > Hi, plase modify this one: > http://www.reactos.org/wiki/Compiling_GCC_From_Windows so that we can > build it too and understand what you did. > > Thx, you rock! :-D > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hpoussin] 43145: Revert r43141 to try to fix ReactOS boot style...
Fuck.
Best regards,
Alex Ionescu
On Fri, Sep 25, 2009 at 11:10 AM, wrote:
> Author: hpoussin
> Date: Fri Sep 25 17:10:28 2009
> New Revision: 43145
>
> URL: http://svn.reactos.org/svn/reactos?rev=43145&view=rev
> Log:
> Revert r43141 to try to fix ReactOS boot style...
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/arcname.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/arcname.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/arcname.c?rev=43145&r1=43144&r2=43145&view=diff
> ==
> --- trunk/reactos/ntoskrnl/io/iomgr/arcname.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/arcname.c [iso-8859-1] Fri Sep 25
> 17:10:28 2009
> @@ -19,6 +19,107 @@
> PCHAR IoLoaderArcBootDeviceName;
>
> /* FUNCTIONS
> */
> +
> +BOOLEAN
> +INIT_FUNCTION
> +NTAPI
> +IopApplyRosCdromArcHack(IN ULONG i)
> +{
> + ULONG DeviceNumber = -1;
> + OBJECT_ATTRIBUTES ObjectAttributes;
> + ANSI_STRING InstallName;
> + UNICODE_STRING DeviceName;
> + CHAR Buffer[128], RosSysPath[16];
> + FILE_BASIC_INFORMATION FileInfo;
> + NTSTATUS Status;
> + PCHAR p, q;
> + PCONFIGURATION_INFORMATION ConfigInfo = IoGetConfigurationInformation();
> + extern BOOLEAN InitIsWinPEMode, ExpInTextModeSetup;
> +
> + /* Change this if you want ROS to boot properly from another directory */
> + sprintf(RosSysPath, "%s", "reactos");
> +
> + /* Only ARC Name left - Build full ARC Name */
> + p = strstr(KeLoaderBlock->ArcBootDeviceName, "cdrom");
> + if (p)
> + {
> + /* Build installer name */
> + sprintf(Buffer, "\\Device\\CdRom%lu\\%s\\ntoskrnl.exe", i,
> RosSysPath);
> + RtlInitAnsiString(&InstallName, Buffer);
> + Status = RtlAnsiStringToUnicodeString(&DeviceName, &InstallName,
> TRUE);
> + if (!NT_SUCCESS(Status)) return FALSE;
> +
> + /* Try to find the installer */
> + InitializeObjectAttributes(&ObjectAttributes,
> + &DeviceName,
> + 0,
> + NULL,
> + NULL);
> + Status = ZwQueryAttributesFile(&ObjectAttributes, &FileInfo);
> +
> + /* Free the string */
> + RtlFreeUnicodeString(&DeviceName);
> +
> + /* Check if we found the file */
> + if (NT_SUCCESS(Status))
> + {
> + /* We did, save the device number */
> + DeviceNumber = i;
> + }
> + else
> + {
> + /* Build live CD kernel name */
> + sprintf(Buffer,
> + "\\Device\\CdRom%lu\\%s\\system32\\ntoskrnl.exe",
> + i, RosSysPath);
> + RtlInitAnsiString(&InstallName, Buffer);
> + Status = RtlAnsiStringToUnicodeString(&DeviceName,
> + &InstallName,
> + TRUE);
> + if (!NT_SUCCESS(Status)) return FALSE;
> +
> + /* Try to find it */
> + InitializeObjectAttributes(&ObjectAttributes,
> + &DeviceName,
> + 0,
> + NULL,
> + NULL);
> + Status = ZwQueryAttributesFile(&ObjectAttributes, &FileInfo);
> + if (NT_SUCCESS(Status)) DeviceNumber = i;
> +
> + /* Free the string */
> + RtlFreeUnicodeString(&DeviceName);
> + }
> +
> + if (!InitIsWinPEMode)
> + {
> + /* Build the name */
> + sprintf(p, "cdrom(%lu)", DeviceNumber);
> +
> + /* Adjust original command line */
> + q = strchr(p, ')');
> + if (q)
> + {
> + q++;
> + strcpy(Buffer, q);
> + sprintf(p, "cdrom(%lu)", DeviceNumber);
> + strcat(p, Buffer);
> + }
> + }
> + }
> +
> + /* OK, how many disks are there? */
> + DeviceNumber += ConfigInfo->DiskCount;
> +
> + /* Return whether this is the CD or not */
> + if ((InitIsWinPEMode) || (ExpInTextModeSetup))
> + {
> + return TRUE;
> + }
> +
> + /* Failed */
> + return FALSE;
> +}
>
&g
Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3 friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this is compatible with both compilers)
No.
0x.
Best regards,
Alex Ionescu
On Sat, Sep 26, 2009 at 9:41 AM, wrote:
> Author: sginsberg
> Date: Sat Sep 26 15:41:57 2009
> New Revision: 43167
>
> URL: http://svn.reactos.org/svn/reactos?rev=43167&view=rev
> Log:
> - HAL: Make /W3 friendly
> - Everywhere else: Use casts instead of -1U to fix C4146 (this is compatible
> with both compilers)
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/debug.c
> trunk/reactos/dll/cpl/console/colors.c
> trunk/reactos/dll/cpl/console/layout.c
> trunk/reactos/dll/cpl/main/mouse.c
> trunk/reactos/dll/win32/kernel32/debug/debugger.c
> trunk/reactos/dll/win32/kernel32/file/file.c
> trunk/reactos/dll/win32/opengl32/opengl32.c
> trunk/reactos/hal/halx86/generic/dma.c
> trunk/reactos/hal/halx86/generic/pci.c
> trunk/reactos/hal/halx86/include/ioapic.h
> trunk/reactos/hal/halx86/mp/apic.c
> trunk/reactos/hal/halx86/mp/ioapic.c
> trunk/reactos/hal/halx86/mp/mpconfig.c
> trunk/reactos/lib/cmlib/hivedata.h
> trunk/reactos/lib/rtl/debug.c
> trunk/reactos/ntoskrnl/ex/init.c
> trunk/reactos/ntoskrnl/ps/psmgr.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/debug.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/debug.c?rev=43167&r1=43166&r2=43167&view=diff
> ==
> --- trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] Sat Sep 26
> 15:41:57 2009
> @@ -311,7 +311,7 @@
> Length = _vsnprintf(Buffer, 512, Format, ap);
>
> /* Check if we went past the buffer */
> - if (Length == -1U)
> + if (Length == (ULONG)-1)
> {
> /* Terminate it if we went over-board */
> Buffer[sizeof(Buffer) - 1] = '\n';
>
> Modified: trunk/reactos/dll/cpl/console/colors.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/console/colors.c?rev=43167&r1=43166&r2=43167&view=diff
> ==
> --- trunk/reactos/dll/cpl/console/colors.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/cpl/console/colors.c [iso-8859-1] Sat Sep 26 15:41:57
> 2009
> @@ -116,7 +116,7 @@
> break;
> }
>
> - if (red == -1U)
> + if (red == (DWORD)-1)
> {
> red = SendMessage(GetDlgItem(hwndDlg,
> IDC_UPDOWN_COLOR_RED), UDM_GETPOS, 0, 0);
> if (HIWORD(red))
> @@ -127,7 +127,7 @@
> red = LOBYTE(red);
> }
>
> - if (green == -1U)
> + if (green == (DWORD)-1)
> {
> green = SendMessage(GetDlgItem(hwndDlg,
> IDC_UPDOWN_COLOR_GREEN), UDM_GETPOS, 0, 0);
> if (HIWORD(green))
> @@ -138,7 +138,7 @@
> green = LOBYTE(green);
> }
>
> - if (blue == -1U)
> + if (blue == (DWORD)-1)
> {
> blue = SendMessage(GetDlgItem(hwndDlg,
> IDC_UPDOWN_COLOR_BLUE), UDM_GETPOS, 0, 0);
> if (HIWORD(blue))
>
> Modified: trunk/reactos/dll/cpl/console/layout.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/console/layout.c?rev=43167&r1=43166&r2=43167&view=diff
> ==
> --- trunk/reactos/dll/cpl/console/layout.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/cpl/console/layout.c [iso-8859-1] Sat Sep 26 15:41:57
> 2009
> @@ -160,7 +160,7 @@
> SendMessage(GetDlgItem(hwndDlg,
> IDC_UPDOWN_WINDOW_POS_LEFT), UDM_SETRANGE, 0, (LPARAM)MAKELONG(xres, 0));
> SendMessage(GetDlgItem(hwndDlg,
> IDC_UPDOWN_WINDOW_POS_TOP), UDM_SETRANGE, 0, (LPARAM)MAKELONG(yres, 0));
>
> - if (pConInfo->WindowPosition != -1U)
> + if (pConInfo->WindowPosition != (DWORD)-1)
> {
> SetDlgItemInt(hwndDlg,
> IDC_EDIT_WINDOW_POS_LEFT, LOWORD(pConInfo->WindowPosition), FALSE);
> SetDlgItemInt(hwndDlg,
> IDC_EDIT_WINDOW_POS_TOP, HIWORD(pConInfo->WindowPosition), FALSE);
>
> Modified: trunk/reactos/dll/cpl/main/mouse.c
> URL:
> h
Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3 friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this is compatible with both compilers)
1) Ask yourself why the compiler is emitting a warning when you use -1
2) Ask yourself how you are "fixing" this -- forcibly casting the type
to silence the compiler. In other words, you are doing this:
int foo(int* ptrToNumber);
...
{
int number = 5;
foo((int*)number); // Hmm, compiler warns I need an int*... let me
typecast, it seems to fix the warning.
}
3) Ask yourself what ULONG means
4) And then ask yourself what -1 means
If you still don't get it, go read a book on C.
Best regards,
Alex Ionescu
On Sat, Sep 26, 2009 at 11:50 AM, Stefan Ginsberg
wrote:
> What is wrong with -1?
>
>> Date: Sat, 26 Sep 2009 10:27:14 -0400
>> From: ion...@videotron.ca
>> To: ros-dev@reactos.org
>> CC: ros-di...@reactos.org
>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3
>> friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this is
>> compatible with both compilers)
>>
>> No.
>>
>> 0x.
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>>
>> On Sat, Sep 26, 2009 at 9:41 AM, wrote:
>> > Author: sginsberg
>> > Date: Sat Sep 26 15:41:57 2009
>> > New Revision: 43167
>> >
>> > URL: http://svn.reactos.org/svn/reactos?rev=43167&view=rev
>> > Log:
>> > - HAL: Make /W3 friendly
>> > - Everywhere else: Use casts instead of -1U to fix C4146 (this is
>> > compatible with both compilers)
>> >
>> > Modified:
>> > trunk/reactos/boot/freeldr/freeldr/debug.c
>> > trunk/reactos/dll/cpl/console/colors.c
>> > trunk/reactos/dll/cpl/console/layout.c
>> > trunk/reactos/dll/cpl/main/mouse.c
>> > trunk/reactos/dll/win32/kernel32/debug/debugger.c
>> > trunk/reactos/dll/win32/kernel32/file/file.c
>> > trunk/reactos/dll/win32/opengl32/opengl32.c
>> > trunk/reactos/hal/halx86/generic/dma.c
>> > trunk/reactos/hal/halx86/generic/pci.c
>> > trunk/reactos/hal/halx86/include/ioapic.h
>> > trunk/reactos/hal/halx86/mp/apic.c
>> > trunk/reactos/hal/halx86/mp/ioapic.c
>> > trunk/reactos/hal/halx86/mp/mpconfig.c
>> > trunk/reactos/lib/cmlib/hivedata.h
>> > trunk/reactos/lib/rtl/debug.c
>> > trunk/reactos/ntoskrnl/ex/init.c
>> > trunk/reactos/ntoskrnl/ps/psmgr.c
>> >
>> > Modified: trunk/reactos/boot/freeldr/freeldr/debug.c
>> > URL:
>> > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/debug.c?rev=43167&r1=43166&r2=43167&view=diff
>> >
>> > ==
>> > --- trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] (original)
>> > +++ trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] Sat Sep 26
>> > 15:41:57 2009
>> > @@ -311,7 +311,7 @@
>> > Length = _vsnprintf(Buffer, 512, Format, ap);
>> >
>> > /* Check if we went past the buffer */
>> > - if (Length == -1U)
>> > + if (Length == (ULONG)-1)
>> > {
>> > /* Terminate it if we went over-board */
>> > Buffer[sizeof(Buffer) - 1] = '\n';
>> >
>> > Modified: trunk/reactos/dll/cpl/console/colors.c
>> > URL:
>> > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/console/colors.c?rev=43167&r1=43166&r2=43167&view=diff
>> >
>> > ==
>> > --- trunk/reactos/dll/cpl/console/colors.c [iso-8859-1] (original)
>> > +++ trunk/reactos/dll/cpl/console/colors.c [iso-8859-1] Sat Sep 26
>> > 15:41:57 2009
>> > @@ -116,7 +116,7 @@
>> > break;
>> > }
>> >
>> > - if (red == -1U)
>> > + if (red == (DWORD)-1)
>> > {
>> > red = SendMessage(GetDlgItem(hwndDlg,
>> > IDC_UPDOWN_COLOR_RED), UDM_GETPOS, 0, 0);
>> > if (HIWORD(red))
>> > @@ -127,7 +127,7 @@
>> > red = LOBYTE(red);
>> > }
>> >
>> > - if (green == -1U)
>> > + if (green == (DWORD)-1)
>> > {
>> > green = SendMessage(GetDlgItem(hwndDlg,
>> > IDC_UPDOWN_COLOR_GREEN), UDM_GETPOS, 0, 0);
>>
Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3 friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this is compatible with both compilers)
1) Nope. Please paste the language of the warning. I believe it is
"expecting unsigned int type, given int type".
2) Nope. It tells the compiler "I have no idea what this warning
means, please ignore it"
3) Good! Now tell us, what type is -1?
4) Yes, setting an "UNSIGNED VALUE" to "-1" is nonstandard C.
You have one more chance to figure out why... I asked a CS student in
a bar last night the same question, and he figured it out immediately,
so it's not a Millennium Problem.
To Timo's comment -- yes, it won't work for 64-bit values, in which
case you use 0x...
Or if you want "portability", you can use ~0.
Best regards,
Alex Ionescu
On Sat, Sep 26, 2009 at 2:39 PM, Stefan Ginsberg
wrote:
> 1) I believe that is to warn about a possible mistake where you really want
> -1 and not 0x.
> 2) It tells the compiler "shut the hell up, I know what I am doing, thank
> you" because the usage is correct in those places.
> 3) unsigned long
> 4) Setting an unsigned value to -1 appears to be a generic way to set a
> variable, be it 16, 32 or 64 bits wide, to its highest value/all bits set.
> Is this nonstandard C?
>
>> Date: Sat, 26 Sep 2009 14:06:40 -0400
>> From: ion...@videotron.ca
>> To: ros-dev@reactos.org
>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3
>> friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this is
>> compatible with both compilers)
>>
>> 1) Ask yourself why the compiler is emitting a warning when you use -1
>> 2) Ask yourself how you are "fixing" this -- forcibly casting the type
>> to silence the compiler. In other words, you are doing this:
>>
>> int foo(int* ptrToNumber);
>> ...
>> {
>> int number = 5;
>> foo((int*)number); // Hmm, compiler warns I need an int*... let me
>> typecast, it seems to fix the warning.
>> }
>> 3) Ask yourself what ULONG means
>> 4) And then ask yourself what -1 means
>>
>> If you still don't get it, go read a book on C.
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>>
>> On Sat, Sep 26, 2009 at 11:50 AM, Stefan Ginsberg
>> wrote:
>> > What is wrong with -1?
>> >
>> >> Date: Sat, 26 Sep 2009 10:27:14 -0400
>> >> From: ion...@videotron.ca
>> >> To: ros-dev@reactos.org
>> >> CC: ros-di...@reactos.org
>> >> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43167: - HAL: Make /W3
>> >> friendly - Everywhere else: Use casts instead of -1U to fix C4146 (this
>> >> is
>> >> compatible with both compilers)
>> >>
>> >> No.
>> >>
>> >> 0x.
>> >>
>> >> Best regards,
>> >> Alex Ionescu
>> >>
>> >>
>> >>
>> >> On Sat, Sep 26, 2009 at 9:41 AM, wrote:
>> >> > Author: sginsberg
>> >> > Date: Sat Sep 26 15:41:57 2009
>> >> > New Revision: 43167
>> >> >
>> >> > URL: http://svn.reactos.org/svn/reactos?rev=43167&view=rev
>> >> > Log:
>> >> > - HAL: Make /W3 friendly
>> >> > - Everywhere else: Use casts instead of -1U to fix C4146 (this is
>> >> > compatible with both compilers)
>> >> >
>> >> > Modified:
>> >> > trunk/reactos/boot/freeldr/freeldr/debug.c
>> >> > trunk/reactos/dll/cpl/console/colors.c
>> >> > trunk/reactos/dll/cpl/console/layout.c
>> >> > trunk/reactos/dll/cpl/main/mouse.c
>> >> > trunk/reactos/dll/win32/kernel32/debug/debugger.c
>> >> > trunk/reactos/dll/win32/kernel32/file/file.c
>> >> > trunk/reactos/dll/win32/opengl32/opengl32.c
>> >> > trunk/reactos/hal/halx86/generic/dma.c
>> >> > trunk/reactos/hal/halx86/generic/pci.c
>> >> > trunk/reactos/hal/halx86/include/ioapic.h
>> >> > trunk/reactos/hal/halx86/mp/apic.c
>> >> > trunk/reactos/hal/halx86/mp/ioapic.c
>> >> > trunk/reactos/hal/halx86/mp/mpconfig.c
>> >> > trunk/reactos/lib/cmlib/hivedata.h
>> >> > trunk/reactos/lib/rtl/debug.c
>> >> > trunk/reactos/ntoskrnl/ex/init.c
>> >> > trunk/reactos/ntoskrnl/ps/psmgr.c
>> >> >
>> >> > Modified: trunk/reactos/boot/freeldr/freeldr/debug.c
>> >> > URL:
>> >> >
>> >> > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/deb
Re: [ros-dev] [ros-diffs] [sginsberg] 43241: - KeBugCheckEx expects BugCheckParameter2 to point to an array when the bug code is FATAL_UNHANDLED_HARD_ERROR -- properly stub out ExpSystemErrorHandler s
And the reason you couldn't pass Parameters?
Best regards,
Alex Ionescu
On Wed, Sep 30, 2009 at 2:31 PM, wrote:
> Author: sginsberg
> Date: Wed Sep 30 20:31:26 2009
> New Revision: 43241
>
> URL: http://svn.reactos.org/svn/reactos?rev=43241&view=rev
> Log:
> - KeBugCheckEx expects BugCheckParameter2 to point to an array when the bug
> code is FATAL_UNHANDLED_HARD_ERROR -- properly stub out ExpSystemErrorHandler
> so we don't crash in KeBugCheckEx.
>
> Modified:
> trunk/reactos/ntoskrnl/ex/harderr.c
>
> Modified: trunk/reactos/ntoskrnl/ex/harderr.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/harderr.c?rev=43241&r1=43240&r2=43241&view=diff
> ==
> --- trunk/reactos/ntoskrnl/ex/harderr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ex/harderr.c [iso-8859-1] Wed Sep 30 20:31:26 2009
> @@ -58,10 +58,12 @@
> IN PULONG_PTR Parameters,
> IN BOOLEAN Shutdown)
> {
> + ULONG_PTR Dummy[4] = {0, 0, 0, 0};
> +
> /* FIXME: STUB */
> KeBugCheckEx(FATAL_UNHANDLED_HARD_ERROR,
> ErrorStatus,
> - 0,
> + (ULONG_PTR)Dummy,
> 0,
> 0);
> return STATUS_SUCCESS;
>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 43265: - Replace some x86 assembly in drivers with portable breakpoint support.
Portbability is ALWAYS needed, except I guess to people like who you
insist on using assembly even when it's been proven to be unreliable,
unportable and inefficient. How is the PPC build or ARM build supposed
to work with your component?
And why the fuck can't you be bothered to use "__break()"??? It's
inlined -- producing exactly the same int 3 code as you were using on
x86, would've saved you to have to re-define DbgBreakPoint, and
would've been portable from day one.
Best regards,
Alex Ionescu
On Sat, Oct 3, 2009 at 6:03 PM, Timo Kreuzer wrote:
>
> It was intentionally that I used an inlined break point in bmfd & ftfd.
> Portability is not yet needed. Please revert.
>
>
> sginsb...@svn.reactos.org wrote:
>> Author: sginsberg
>> Date: Sat Oct 3 16:15:46 2009
>> New Revision: 43265
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=43265&view=rev
>> Log:
>> - Replace some x86 assembly in drivers with portable breakpoint support.
>>
>> Modified:
>> trunk/reactos/drivers/network/ndis/ndis/miniport.c
>> trunk/reactos/drivers/video/font/bmfd/bmfd.h
>> trunk/reactos/drivers/video/font/bmfd/font.c
>> trunk/reactos/drivers/video/font/bmfd/glyph.c
>> trunk/reactos/drivers/video/font/ftfd/enable.c
>> trunk/reactos/drivers/video/font/ftfd/font.c
>> trunk/reactos/drivers/video/font/ftfd/ftfd.h
>>
>> Modified: trunk/reactos/drivers/network/ndis/ndis/miniport.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/miniport.c?rev=43265&r1=43264&r2=43265&view=diff
>> ==
>> --- trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1]
>> (original)
>> +++ trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] Sat Oct
>> 3 16:15:46 2009
>> @@ -1472,7 +1472,7 @@
>> *NdisWrapperHandle = NULL;
>>
>> #if BREAK_ON_MINIPORT_INIT
>> - __asm__ ("int $3\n");
>> + DbgBreakPoint();
>> #endif
>>
>> Miniport = ExAllocatePool(NonPagedPool, sizeof(NDIS_M_DRIVER_BLOCK));
>>
>> Modified: trunk/reactos/drivers/video/font/bmfd/bmfd.h
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/font/bmfd/bmfd.h?rev=43265&r1=43264&r2=43265&view=diff
>> ==
>> --- trunk/reactos/drivers/video/font/bmfd/bmfd.h [iso-8859-1] (original)
>> +++ trunk/reactos/drivers/video/font/bmfd/bmfd.h [iso-8859-1] Sat Oct 3
>> 16:15:46 2009
>> @@ -263,17 +263,6 @@
>> ULONG
>> DbgPrint(IN PCHAR Format, IN ...);
>>
>> -FORCEINLINE
>> -VOID
>> -DbgBreakPoint(VOID)
>> -{
>> -#ifdef __GNUC__
>> - asm volatile ("int $3");
>> -#else
>> - __asm int 3;
>> -#endif
>> -}
>> -
>> DHPDEV
>> APIENTRY
>> BmfdEnablePDEV(
>>
>> Modified: trunk/reactos/drivers/video/font/bmfd/font.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/font/bmfd/font.c?rev=43265&r1=43264&r2=43265&view=diff
>> ==
>> --- trunk/reactos/drivers/video/font/bmfd/font.c [iso-8859-1] (original)
>> +++ trunk/reactos/drivers/video/font/bmfd/font.c [iso-8859-1] Sat Oct 3
>> 16:15:46 2009
>> @@ -247,7 +247,7 @@
>> ULONG cjView;
>>
>> DbgPrint("BmfdLoadFontFile()\n");
>> - DbgBreakPoint();
>> + EngDebugBreak();
>>
>> /* Check parameters */
>> if (cFiles != 1)
>> @@ -323,7 +323,7 @@
>> PBMFD_FILE pfile = (PBMFD_FILE)iFile;
>>
>> DbgPrint("BmfdQueryFontFile()\n");
>> -// DbgBreakPoint();
>> +// EngDebugBreak();
>>
>> switch (ulMode)
>> {
>> @@ -397,7 +397,7 @@
>> HGLYPH * phglyphs;
>>
>> DbgPrint("DrvQueryFontTree(iMode=%ld)\n", iMode);
>> -// DbgBreakPoint();
>> +// EngDebugBreak();
>>
>> /* Check parameters, we only support QFT_GLYPHSET */
>> if (!iFace || iFace > pfile->cNumFaces || iMode != QFT_GLYPHSET)
>> @@ -522,7 +522,7 @@
>> PANOSE panose = {0};
>>
>> DbgPrint("BmfdQueryFont()\n");
>> -// DbgBreakPoint();
>> +// EngDebugBreak();
>>
>> /* Validate parameters */
>> if (iFace > pfile->cNumFaces || !pid)
>>
>> Modified: trunk/reactos/drivers/video
Re: [ros-dev] [ros-diffs] [sginsberg] 43265: - Replace some x86 assembly in drivers with portable breakpoint support.
He did :) Thanks Timo, and sorry for the typo, it's __debugbreak, as you committed. Best regards, Alex Ionescu On Sun, Oct 4, 2009 at 5:48 PM, KJK::Hyperion wrote: > Timo Kreuzer wrote: >> Stop whining, smartass. > > Please do as the smartass says > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 43331: Fix logging to a file. In spite of limitations, it remains the only way to obtain desired logs for some people.
This code has multiple synchronization issues, such as spinning on a
test-for-spin-lock, which is non-atomic... might as well get rid of
the spinlock.
Also, you should probably be using a worker thread instead of
consuming system resources for a dedicated thread and mucking with
priorities.
Best regards,
Alex Ionescu
On Wed, Oct 7, 2009 at 3:57 PM, wrote:
> Author: dgorbachev
> Date: Wed Oct 7 21:57:40 2009
> New Revision: 43331
>
> URL: http://svn.reactos.org/svn/reactos?rev=43331&view=rev
> Log:
> Fix logging to a file.
>
> In spite of limitations, it remains the only way to obtain desired logs for
> some people.
>
> Modified:
> trunk/reactos/ntoskrnl/kd/kdio.c
>
> Modified: trunk/reactos/ntoskrnl/kd/kdio.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=43331&r1=43330&r2=43331&view=diff
> ==
> --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Wed Oct 7 21:57:40 2009
> @@ -14,16 +14,17 @@
>
> /* GLOBALS
> ***/
>
> -#define BufferSize 32*1024
> -
> -HANDLE KdbLogFileHandle;
> -BOOLEAN KdpLogInitialized;
> -CHAR DebugBuffer[BufferSize];
> -ULONG CurrentPosition;
> -WORK_QUEUE_ITEM KdpDebugLogQueue;
> +#define KdpBufferSize (1024 * 512)
> +BOOLEAN KdpLoggingEnabled = FALSE;
> +PCHAR KdpDebugBuffer = NULL;
> +volatile ULONG KdpCurrentPosition = 0;
> +volatile ULONG KdpFreeBytes = 0;
> +KSPIN_LOCK KdpDebugLogSpinLock;
> +KEVENT KdpLoggerThreadEvent;
> +HANDLE KdpLogFileHandle;
> +
> KSPIN_LOCK KdpSerialSpinLock;
> -BOOLEAN ItemQueued;
> -KD_PORT_INFORMATION SerialPortInfo = {DEFAULT_DEBUG_PORT,
> DEFAULT_DEBUG_BAUD_RATE, 0};
> +KD_PORT_INFORMATION SerialPortInfo = { DEFAULT_DEBUG_PORT,
> DEFAULT_DEBUG_BAUD_RATE, 0 };
>
> /* Current Port in use. FIXME: Do we support more then one? */
> ULONG KdpPort;
> @@ -32,56 +33,103 @@
>
> VOID
> NTAPI
> -KdpPrintToLogInternal(PVOID Context)
> -{
> +KdpLoggerThread(PVOID Context)
> +{
> + ULONG beg, end, num;
> IO_STATUS_BLOCK Iosb;
>
> - /* Write to the Debug Log */
> - NtWriteFile(KdbLogFileHandle,
> - NULL,
> - NULL,
> - NULL,
> - &Iosb,
> - DebugBuffer,
> - CurrentPosition,
> - NULL,
> - NULL);
> -
> - /* Clear the Current Position */
> - CurrentPosition = 0;
> -
> - /* A new item can be queued now */
> - ItemQueued = FALSE;
> -}
> -
> -VOID
> -NTAPI
> -KdpPrintToLog(PCH String,
> - ULONG StringLength)
> -{
> - /* Don't overflow */
> - if ((CurrentPosition + StringLength) > BufferSize) return;
> -
> - /* Add the string to the buffer */
> - RtlCopyMemory(&DebugBuffer[CurrentPosition], String, StringLength);
> -
> - /* Update the Current Position */
> - CurrentPosition += StringLength;
> -
> - /* Make sure we are initialized and can queue */
> - if (!KdpLogInitialized || (ItemQueued)) return;
> -
> - /*
> - * Queue the work item
> - * Note that we don't want to queue if we are > DISPATCH_LEVEL...
> - * The message is in the buffer and will simply be taken care of at
> - * the next time we are at <= DISPATCH, so it won't be lost.
> - */
> - if (KeGetCurrentIrql() <= DISPATCH_LEVEL)
> - {
> - ExQueueWorkItem(&KdpDebugLogQueue, HyperCriticalWorkQueue);
> - ItemQueued = TRUE;
> - }
> + KdpLoggingEnabled = TRUE;
> +
> + while (TRUE)
> + {
> + KeWaitForSingleObject(&KdpLoggerThreadEvent, 0, KernelMode, FALSE,
> NULL);
> +
> + /* Bug */
> + end = KdpCurrentPosition;
> + num = KdpFreeBytes;
> + beg = (end + num) % KdpBufferSize;
> + num = KdpBufferSize - num;
> +
> + /* Nothing to do? */
> + if (num == 0)
> + continue;
> +
> + if (end > beg)
> + {
> + NtWriteFile(KdpLogFileHandle, NULL, NULL, NULL, &Iosb,
> + KdpDebugBuffer + beg, num, NULL, NULL);
> + }
> + else
> + {
> + NtWriteFile(KdpLogFileHandle, NULL, NULL, NULL, &Iosb,
> + KdpDebugBuffer + beg, KdpBufferSize - beg, NULL,
> NULL);
> +
> + NtWriteFile(KdpLogFileHandle, NULL, NULL, NULL, &Iosb,
> + KdpDebugBuffer, end, NULL, NULL);
> + }
>
Re: [ros-dev] [ros-diffs] [dgorbachev] 43333: Fix GCC 4.1.3 warning.
Why are you using this bad/broken API? Why are you doing an exchange without even checking the result? Just use InterlockedAdd (but you're not accessing KdpFreeBytes safely elsewhere, so again, you're just wasting time doing bad synchronziation). Best regards, Alex Ionescu On Wed, Oct 7, 2009 at 4:04 PM, wrote: > Author: dgorbachev > Date: Wed Oct 7 22:04:17 2009 > New Revision: 4 > > URL: http://svn.reactos.org/svn/reactos?rev=4&view=rev > Log: > Fix GCC 4.1.3 warning. > > Modified: > trunk/reactos/ntoskrnl/kd/kdio.c > > Modified: trunk/reactos/ntoskrnl/kd/kdio.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=4&r1=43332&r2=4&view=diff > == > --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Wed Oct 7 22:04:17 2009 > @@ -68,7 +68,7 @@ > KdpDebugBuffer, end, NULL, NULL); > } > > - InterlockedExchangeAddUL(&KdpFreeBytes, num); > + (VOID)InterlockedExchangeAddUL(&KdpFreeBytes, num); > } > } > > > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dgorbachev] 43333: Fix GCC 4.1.3 warning.
On 8-Oct-09, at 9:32 AM, Dmitry Gorbachev wrote: > Hi, > >> This code has multiple synchronization issues, such as spinning on a >> test-for-spin-lock, which is non-atomic... might as well get rid of >> the spinlock. > > That synchronization code is borrowed from KdpSerialDebugPrint. Please > tell what are issues, I will fix then in both places. You (the code) is spinning non-atomically on a spinlock at passive then raising the irql to dispatch to "acquire" it. This makes no sense whatsoever. Another code can race you to this place. Why not just use a normal spinlock? > >> Also, you should probably be using a worker thread > > I have read that "because the pool of system worker threads is a > limited resource, WorkItem and WorkItemEx routines can be used only > for operations that take a short period of time. If one of these > routines runs for too long (if it contains an indefinite loop, for > example), the system can deadlock. Therefore, if a driver requires > long periods of delayed processing, it should instead call > PsCreateSystemThread to create its own system thread." So I am not > sure, whether it is better to use a worker thread or a dedicated > thread. Logging operations take a short amount of time and are spurious, in this case, a worker thread would work better, it seems. > >> instead of consuming system resources for a dedicated thread and >> mucking with priorities. > > The thread is created when booting into "ReactOS (Log file)". > >> Why are you using this bad/broken API? > > What is wrong with that API? > > This is what GCC generates: > >lock addl %eax, _KdpFreeBytes I am actually impressed -- it must've picked up MSVC's ability to understand that with the (VOID), it should not generate the full exchange sequence. > >> Why are you doing an exchange without even checking the result? > > It is not needed. > >> Just use InterlockedAdd > > Unfortunately, there is no such function. :) Uhh, MSDN says there is, and it should be an intrnsic in intrin_x86.h, please check again. > >> (but you're not accessing KdpFreeBytes safely >> elsewhere, so again, you're just wasting time doing bad >> synchronziation). > > Otherwise, if addition will be interrupted in between, some output can > become lost. This is worse then a bug above, which can cause > repeating. On a non-multiprocessor system, there seems to be no other > problems. You're doing store math: > KdpFreeBytes -= num; > KdpFreeBytes = KdpBufferSize; on the variable without an interlock, so those operations will not be safe w.r.t to your interlock. You're also doing load math: > num = KdpFreeBytes; on the variable without a fence, so this operation will not be safe w.r.t to your interlock (only MSVC generates fences around volatile variables, and even then they're not sufficient on IA64/Alpha systems). > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 43693: - Limit the number of interrupts that are handled per call to MiniportHandleInterrupt to prevent us from staying at DISPATCH_LEVEL for too long
Do the cards not support interrupt coalescing?
Best regards,
Alex Ionescu
On Fri, Oct 23, 2009 at 1:27 AM, wrote:
> Author: cgutman
> Date: Fri Oct 23 02:27:00 2009
> New Revision: 43693
>
> URL: http://svn.reactos.org/svn/reactos?rev=43693&view=rev
> Log:
> - Limit the number of interrupts that are handled per call to
> MiniportHandleInterrupt to prevent us from staying at DISPATCH_LEVEL for too
> long
>
> Modified:
> trunk/reactos/drivers/network/dd/ne2000/include/ne2000.h
> trunk/reactos/drivers/network/dd/ne2000/ne2000/8390.c
> trunk/reactos/drivers/network/dd/pcnet/pcnet.c
> trunk/reactos/drivers/network/dd/pcnet/pcnet.h
>
> Modified: trunk/reactos/drivers/network/dd/ne2000/include/ne2000.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/dd/ne2000/include/ne2000.h?rev=43693&r1=43692&r2=43693&view=diff
> ==
> --- trunk/reactos/drivers/network/dd/ne2000/include/ne2000.h [iso-8859-1]
> (original)
> +++ trunk/reactos/drivers/network/dd/ne2000/include/ne2000.h [iso-8859-1] Fri
> Oct 23 02:27:00 2009
> @@ -55,7 +55,8 @@
> /* Interrupt Mask Register value */
> #define DRIVER_INTERRUPT_MASK IMR_ALLE - IMR_RDCE
>
> -
> +/* Maximum number of interrupts handled per call to MiniportHandleInterrupt
> */
> +#define INTERRUPT_LIMIT 10
>
> /* Global structures */
>
>
> Modified: trunk/reactos/drivers/network/dd/ne2000/ne2000/8390.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/dd/ne2000/ne2000/8390.c?rev=43693&r1=43692&r2=43693&view=diff
> ==
> --- trunk/reactos/drivers/network/dd/ne2000/ne2000/8390.c [iso-8859-1]
> (original)
> +++ trunk/reactos/drivers/network/dd/ne2000/ne2000/8390.c [iso-8859-1] Fri
> Oct 23 02:27:00 2009
> @@ -1315,6 +1315,7 @@
> UCHAR ISRMask;
> UCHAR Mask;
> PNIC_ADAPTER Adapter = (PNIC_ADAPTER)MiniportAdapterContext;
> + UINT i = 0;
>
> ISRMask = Adapter->InterruptMask;
> NdisRawReadPortUchar(Adapter->IOBase + PG0_ISR, &ISRValue);
> @@ -1323,12 +1324,14 @@
>
> Adapter->InterruptStatus |= (ISRValue & ISRMask);
>
> - if (ISRValue != 0x00)
> - /* Acknowledge interrupts */
> - NdisRawWritePortUchar(Adapter->IOBase + PG0_ISR, ISRValue);
> -
> Mask = 0x01;
> - while (Adapter->InterruptStatus != 0x00) {
> + while (Adapter->InterruptStatus != 0x00 && i++ < INTERRUPT_LIMIT) {
> +
> + if (ISRValue != 0x00) {
> + /* Acknowledge interrupts */
> + NdisRawWritePortUchar(Adapter->IOBase + PG0_ISR, ISRValue);
> + Mask = 0x01;
> + }
>
> NDIS_DbgPrint(MID_TRACE, ("Adapter->InterruptStatus (0x%X) Mask
> (0x%X).\n",
> Adapter->InterruptStatus, Mask));
> @@ -1409,12 +1412,6 @@
> NDIS_DbgPrint(MID_TRACE, ("ISRValue (0x%X).\n", ISRValue));
>
> Adapter->InterruptStatus |= (ISRValue & ISRMask);
> -
> - if (ISRValue != 0x00) {
> - /* Acknowledge interrupts */
> - NdisRawWritePortUchar(Adapter->IOBase + PG0_ISR, ISRValue);
> - Mask = 0x01;
> - }
> }
>
> NICEnableInterrupts((PNIC_ADAPTER)MiniportAdapterContext);
>
> Modified: trunk/reactos/drivers/network/dd/pcnet/pcnet.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/dd/pcnet/pcnet.c?rev=43693&r1=43692&r2=43693&view=diff
> ==
> --- trunk/reactos/drivers/network/dd/pcnet/pcnet.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/dd/pcnet/pcnet.c [iso-8859-1] Fri Oct 23
> 02:27:00 2009
> @@ -66,6 +66,7 @@
> {
> PADAPTER Adapter = (PADAPTER)MiniportAdapterContext;
> USHORT Data;
> + UINT i = 0;
>
> DPRINT("Called\n");
>
> @@ -78,7 +79,7 @@
>
> DPRINT("CSR0 is 0x%x\n", Data);
>
> - while(Data & CSR0_INTR)
> + while((Data & CSR0_INTR) && i++ < INTERRUPT_LIMIT)
> {
> /* Clear interrupt flags early to avoid race conditions. */
> NdisRawWritePortUshort(Adapter->PortOffset + RDP, Data);
>
> Modified: trunk/reactos/drivers/network/dd/pcnet/pcnet.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/dd/pcnet/pcnet.h?rev=43693&r1=43692&r2=43693&view=diff
> ==
> --- trunk/reactos/drivers/network/dd/pcnet/pcnet.h [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/dd/pcnet/pcnet.h [iso-8859-1] Fri Oct 23
> 02:27:00 2009
> @@ -149,6 +149,9 @@
> /* flags */
> #define RESET_IN_PROGRESS 0x1
>
> +/* Maximum number of interrupts handled per call to MiniportHandleInterrupt
> */
> +#define INTERRUPT_LIMIT 10
> +
> #if DBG
> #define BREAKPOINT DbgBreakPoint();
> #else
>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [lsuggs] 43700: First push of nslookup implementation.
nslookup on Windows uses DNSAPI exclusively for DNS resolution, and the Rtl* network APIs for IP processing. In fact, there are even lots of Wine postings about people trying to run nslookup and failing due to missing dnsapi functionality. Best regards, Alex Ionescu On Sat, Oct 24, 2009 at 4:04 AM, KJK::Hyperion wrote: > Alex Ionescu wrote: >> Please revert this, it is implemented ass-half-backwards and does not >> use the correct DNSAPI services provided by Windows. > > nslookup doesn't use DNSAPI even on Windows (not for queries at least). > What I'm more disappointed about is that we are rewriting a standard BSD > tool, which has already been ported to Windows: > > https://www.isc.org/software/bind > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation
The real problem is that UniATA is full of shit code from Aleksey that does things like StallExecution(10). Microsoft says not to go over 50, but hey, this is ReactOSreading docs?? HAHAHA!! I've looked over Stefan's code and it is perfect, and sets a correct stall factor. On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote: It was present here in VirtualBox 3.0.8 for some time and disappeared after Stefan's change for exception management. Kind regards, Sylvain Petreolle De : Gabriel ilardi À : ros-dev Envoyé le : Mar 27 Octobre 2009, 11 h 44 min 19 s Objet : Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation calculated the stall count factor incorrectly and produced Hi Johannes, It wasn't present for VirtualBox though, at least for me. Best regards, Gabriel. > Date: Tue, 27 Oct 2009 11:34:03 +0100 > From: janderw...@reactos.org > To: ros-dev@reactos.org > Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation calculated the stall count factor incorrectly and produced bogus resu > > Gabriel ilardi schrieb: > > 2) In second stage when loading UniATA, it stays there for about 4-5 > > seconds, there was no delay before. > > > Hi, > > The UniATA delay in 2nd stage was already present before that commit. > However, only in VMware. > > > > Best regards, > > Gabriel. > > > Best regards, > Johannes Anderwald > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Conosci il tuo Messenger? Scopri tutte le novità ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation
And it continues to do its job today -- you added code telling UniATA "wait between 500ms and 5seconds", and it's working fine in trunk. Why are people complaining "it takes UniATA up to 5 seconds to boot" when this is exactly the code you intended to add? Also: "Maybe theres a better way to get this done, but it was enough for testing and did its job well." Is now my all-time favourite quote, ever. I bet Hitler would've said the same at Nuremberg On 2009-10-27, at 8:50 AM, Daniel Reimer wrote: > These timers were added because some SATA adapters are fucking slow in > initializing and uniata would continue too early for them and this > results in failures. Maybe theres a better way to get this done, but > it > was enough for testing and did its job well. > > Alex Ionescu schrieb: >> The real problem is that UniATA is full of shit code from Aleksey >> that >> does things like StallExecution(10). Microsoft says not to go >> over >> 50, but hey, this is ReactOSreading docs?? HAHAHA!! >> >> I've looked over Stefan's code and it is perfect, and sets a correct >> stall factor. >> >> On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote: >> >>> It was present here in VirtualBox 3.0.8 for some time >>> and disappeared after Stefan's change for exception management. >>> Kind regards, >>> Sylvain Petreolle >>> >>> >>>*De :* Gabriel ilardi >><mailto:gabrielila...@hotmail.it>> >>>*À :* ros-dev mailto:ros-dev@reactos.org>> >>>*Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s >>>*Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace >>>broken implementation of HalpCalibrateStallExecution with a new >>>implementation by a mysterious HAL ninja and myself. The old >>>implementation calculated the stall count factor incorrectly and >>>produced >>> >>>Hi Johannes, >>> >>>It wasn't present for VirtualBox though, at least for me. >>> >>>Best regards, >>>Gabriel. >>> >>>> Date: Tue, 27 Oct 2009 11:34:03 +0100 >>>> From: janderw...@reactos.org <mailto:janderw...@reactos.org> >>>> To: ros-dev@reactos.org <mailto:ros-dev@reactos.org> >>>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace >>>broken implementation of HalpCalibrateStallExecution with a new >>>implementation by a mysterious HAL ninja and myself. The old >>>implementation calculated the stall count factor incorrectly and >>>produced bogus resu >>>> >>>> Gabriel ilardi schrieb: >>>>> 2) In second stage when loading UniATA, it stays there for >>>about 4-5 >>>>> seconds, there was no delay before. >>>>> >>>> Hi, >>>> >>>> The UniATA delay in 2nd stage was already present before that >>>commit. >>>> However, only in VMware. >>>>> >>>>> Best regards, >>>>> Gabriel. >>>>> >>>> Best regards, >>>> Johannes Anderwald >>>> >>>> ___ >>>> Ros-dev mailing list >>>> Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >>> >>>Conosci il tuo Messenger? Scopri tutte le novità >>><http://www.messenger.it/home_novita.aspx> >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> >>> http://www.reactos.org/mailman/listinfo/ros-dev >> >> Best regards, >> Alex Ionescu >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation
Hi,
Maybe you could try not moving the mouse during VMWare?! How can you
even test this in a VM?!? It doesn't make ANY SENSE. There are a
MILLION things going on in the background of your VM whenever you test
this.
*THREE* of your 5 tests all gave nearly the SAME answer, and the two
different value are ALSO the same, simply meaning that some event
happened 2/5th of the time which slowed down the VM (like an interrupt).
Your output shows that the code is working PERFECTLY.
The code is not complex at all, it's barely 10 lines of pseudo-code.
You people don't understand the very BASICS of hardware-level
development, emulation, virtualization, timers and RTCs. it is
outrageous that you're even posting these kinds of e-mails on a public
e-mail list. You should be EMBARRASSED*.
Hint: What results are better on a VM?
500, 490, 510, 8000, 7900, 8100, 5000, 4900, 5100
OR
500, 800, 1000, 1400, 1600, 1800, 2000
???
Based on your e-mail and comparing old/new output, it seems you
believe #2 is better, because "the values are only between 500 and
2000, but new implementation goes between 500 and 5100!".
If you don't understand why #1 is better, please don't even bother
replying.
And now, for the other geniuses on this list, there is a BIG BUG in
ReactOS, that NOBODY CAN FIGURE OUT.
Can *YOU* solve it???
Here it is:
We have a function:
void a(int waitTime)
{
for (int i = waitTime * Factor; i > 0; i--);
}
And a Factor that used to be 64 or some other low value.
People called a with a very large number.
Now, the Factor is a large number, in the thousands.
People have NO idea why, now, calling a "takes much longer now?!? :(".
5000$ if you can figure it out, paid straight out of ROS foundation!
Only a genius could figure this out...
But you know what the STRANGEST thing is?
Windows behaves the same way in Vmware!
In fact, Windows drivers even DEPEND on this behavior!
Quick, someone, tell Microsoft! Their engineers are stupid too! This
kind of code should give random values between 1000 and 4000 in a VM,
not accurate timing counts based on interruptions of the VM emulation
code!
On 2009-10-27, at 12:36 PM, Aleksey Bragin wrote:
> I tested the new implementation in same vmware environment, 5 boot
> ups, here are values of the stall factor:
> 921
> 2426
> 873
> 2405
> 2405
>
> I can't say it's a huge success over the old implementation (it
> provided values in the 1000 - 4000 range in the same environment),
> taking in mind how more complex the code became (it even has its own
> ISR handler embedded into the function!!).
>
> WBR,
> Aleksey Bragin.
>
> On Oct 27, 2009, at 4:15 PM, Alex Ionescu wrote:
>
>> And it continues to do its job today -- you added code telling UniATA
>> "wait between 500ms and 5seconds", and it's working fine in trunk.
>>
>> Why are people complaining "it takes UniATA up to 5 seconds to boot"
>> when this is exactly the code you intended to add?
>>
>> Also:
>>
>> "Maybe theres a better way to get this done, but it was enough for
>> testing and did its job well."
>>
>> Is now my all-time favourite quote, ever.
>>
>> I bet Hitler would've said the same at Nuremberg
>>
>> On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
>>
>>> These timers were added because some SATA adapters are fucking
>>> slow in
>>> initializing and uniata would continue too early for them and this
>>> results in failures. Maybe theres a better way to get this done, but
>>> it
>>> was enough for testing and did its job well.
>>>
>>> Alex Ionescu schrieb:
>>>> The real problem is that UniATA is full of shit code from Aleksey
>>>> that
>>>> does things like StallExecution(10). Microsoft says not to go
>>>> over
>>>> 50, but hey, this is ReactOSreading docs?? HAHAHA!!
>>>>
>>>> I've looked over Stefan's code and it is perfect, and sets a
>>>> correct
>>>> stall factor.
>>>>
>>>> On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
>>>>
>>>>> It was present here in VirtualBox 3.0.8 for some time
>>>>> and disappeared after Stefan's change for exception management.
>>>>> Kind regards,
>>>>> Sylvain Petreolle
>>>>>
>>>>>
>>>>> *De :* Gabriel ilardi >>>> <mailto:gabrielila...@hotmail.it>>
>>>>> *À :* ros-dev mailto:ros-dev@reactos.org>>
>>>>> *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
>>>>
Re: [ros-dev] Reactos and MinWin
There are all things that KJK and myself have been striving to work on. They require changes to rbuild's underpinnings, which have yet to happen. There is a Wiki tracking some of this. The end plan is for us to ship an RDK which would ship with 1) Public SDK (libs and headers) 2) RosBE 3) Rbuild itself And those binary modules would be used unless the source module was imported into the tree (say you wanted to have your own rbuild or make changes to it). This would add major stability and testing consistency so everyone builds with the same headers, libraries, build scripts and rbuild/compiler version. The extended plan is to add things like mesa and other 3rd party libraries as binary-only packages in the RDK as well -- again allowing for the option of these to be compiled by hand if the user wants to, but normally the static versions would be linked, saving compilation time and disk space. Best regards, Alex Ionescu On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer wrote: > > One thing related to this is the sepeartion of the SDK part. > > Curently the SDK is integral part of the whole source tree. One minor > change can cause massive rebuilds even if not needed. The import > libraries are even part of the modules that export the functions which > is stupid, because the interfaces are expected to be stable. > > Separating the SDK completely from the sources is not possible atm, but > I suggest separating it from the main folder. > It could be done similar to how rosapps and rostets are managed. As a > sepeate checkout. But instead of putting it into the hardcoded modules > subfolder, I would suggest a configurable path. So that multiple reactos > checkouts could use one SDK checkout. Each of the main checkouts > contains a config file with the sdk path. A default path could be set by > RosBE or in the config-template. I would suggest to do that with rosapps > and rostests, too. So you only need one checkout of rostests for > multiple base checkouts. You can probably do that with hardlinks but not > everyone can/wants to do that. > The libraries would only be rebuild if you update the SDK. > > Sources\ > \reactos-trunk\... > \reactos-amd64\... > \reactos-arwinss\... > \reactos-sdk\ > \include\ > \lib\ <- static libs (crt, nt, ...) here > \import\ <- spec files here > \rosapps\ > \rostests\ > > It would probably be a good idea to sync our headers / libs with > mingw-w64 as much as possible, so maybe some day we could actually > outsource the whole SDK. > > Other seperations like core / win32 / wine etc can be done in a similar way. > It would require to have multiple checkouts to compile, but I think > that's a reasonable efford. > Or all parts could be put into trunk/source/... then you can checkout > the whole folder if you don't want to hassle with multiple checkouts or > trunk/source/sdk/ and trunk/source/reactos seperately if you like. > > I would also suggest that "clean" command gets fixed. Currently it > always deletes all stuff from the specified source folder. Even if I am > executing it from a different checkout folder. That sucks. It should > only clean everything in the current folder. That way modules / the sdk > would not automatically be cleaned. Because that's in most cases not > what you want. A "clean all" could be used to clean all dependencies as > well. > > Regards, > Timo > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Reactos and MinWin
You'd have to check them out as modules, and then the sources would be used on your machine instead of the static copies. But we'd probably not accept bug reports from such builders without you having checked the static versions first (just as we always refer people to official install/boot CDs to rule out any local building issues). On 2009-11-02, at 12:09 PM, King InuYasha wrote: So would the sources of the binary modules still be available in the tree? Because I personally like to compile everything to be set dynamically instead of using static libraries. On Mon, Nov 2, 2009 at 10:43 AM, Alex Ionescu wrote: There are all things that KJK and myself have been striving to work on. They require changes to rbuild's underpinnings, which have yet to happen. There is a Wiki tracking some of this. The end plan is for us to ship an RDK which would ship with 1) Public SDK (libs and headers) 2) RosBE 3) Rbuild itself And those binary modules would be used unless the source module was imported into the tree (say you wanted to have your own rbuild or make changes to it). This would add major stability and testing consistency so everyone builds with the same headers, libraries, build scripts and rbuild/compiler version. The extended plan is to add things like mesa and other 3rd party libraries as binary-only packages in the RDK as well -- again allowing for the option of these to be compiled by hand if the user wants to, but normally the static versions would be linked, saving compilation time and disk space. Best regards, Alex Ionescu On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer wrote: > > One thing related to this is the sepeartion of the SDK part. > > Curently the SDK is integral part of the whole source tree. One minor > change can cause massive rebuilds even if not needed. The import > libraries are even part of the modules that export the functions which > is stupid, because the interfaces are expected to be stable. > > Separating the SDK completely from the sources is not possible atm, but > I suggest separating it from the main folder. > It could be done similar to how rosapps and rostets are managed. As a > sepeate checkout. But instead of putting it into the hardcoded modules > subfolder, I would suggest a configurable path. So that multiple reactos > checkouts could use one SDK checkout. Each of the main checkouts > contains a config file with the sdk path. A default path could be set by > RosBE or in the config-template. I would suggest to do that with rosapps > and rostests, too. So you only need one checkout of rostests for > multiple base checkouts. You can probably do that with hardlinks but not > everyone can/wants to do that. > The libraries would only be rebuild if you update the SDK. > > Sources\ >\reactos-trunk\... >\reactos-amd64\... >\reactos-arwinss\... >\reactos-sdk\ > \include\ > \lib\ <- static libs (crt, nt, ...) here > \import\ <- spec files here >\rosapps\ >\rostests\ > > It would probably be a good idea to sync our headers / libs with > mingw-w64 as much as possible, so maybe some day we could actually > outsource the whole SDK. > > Other seperations like core / win32 / wine etc can be done in a similar way. > It would require to have multiple checkouts to compile, but I think > that's a reasonable efford. > Or all parts could be put into trunk/source/... then you can checkout > the whole folder if you don't want to hassle with multiple checkouts or > trunk/source/sdk/ and trunk/source/reactos seperately if you like. > > I would also suggest that "clean" command gets fixed. Currently it > always deletes all stuff from the specified source folder. Even if I am > executing it from a different checkout folder. That sucks. It should > only clean everything in the current folder. That way modules / the sdk > would not automatically be cleaned. Because that's in most cases not > what you want. A "clean all" could be used to clean all dependencies as > well. > > Regards, > Timo > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44052: [NDK] - Add KEXCEPTION_FRAME offsets
Did you make sure these matched the actual Microsoft-defined offsets in ksamd64? On 2009-11-09, at 2:49 PM, tkreu...@svn.reactos.org wrote: > Author: tkreuzer > Date: Mon Nov 9 20:49:47 2009 > New Revision: 44052 > > URL: http://svn.reactos.org/svn/reactos?rev=44052&view=rev > Log: > [NDK] > - Add KEXCEPTION_FRAME offsets > > Modified: >branches/ros-amd64-bringup/reactos/include/ndk/amd64/asm.h > > Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/asm.h > URL: > http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/include/ndk/amd64/asm.h?rev=44052&r1=44051&r2=44052&view=diff > == > --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/asm.h [iso-8859-1] > (original) > +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/asm.h [iso-8859-1] > Mon Nov 9 20:49:47 2009 > @@ -192,6 +192,42 @@ > #define CONTEXT_LastExceptionFromRip 0x4c8 > > // > +// KEXCEPTION_FRAME offsets > +// > +#define KEXCEPTION_FRAME_P1Home 0x000 > +#define KEXCEPTION_FRAME_P2Home 0x008 > +#define KEXCEPTION_FRAME_P3Home 0x010 > +#define KEXCEPTION_FRAME_P4Home 0x018 > +#define KEXCEPTION_FRAME_P5 0x020 > +#define KEXCEPTION_FRAME_InitialStack 0x028 > +#define KEXCEPTION_FRAME_Xmm6 0x030 > +#define KEXCEPTION_FRAME_Xmm7 0x040 > +#define KEXCEPTION_FRAME_Xmm8 0x050 > +#define KEXCEPTION_FRAME_Xmm9 0x060 > +#define KEXCEPTION_FRAME_Xmm10 0x070 > +#define KEXCEPTION_FRAME_Xmm11 0x080 > +#define KEXCEPTION_FRAME_Xmm12 0x090 > +#define KEXCEPTION_FRAME_Xmm13 0x0A0 > +#define KEXCEPTION_FRAME_Xmm14 0x0B0 > +#define KEXCEPTION_FRAME_Xmm15 0x0C0 > +#define KEXCEPTION_FRAME_TrapFrame 0x0D0 > +#define KEXCEPTION_FRAME_CallbackStack 0x0D8 > +#define KEXCEPTION_FRAME_OutputBuffer 0x0E0 > +#define KEXCEPTION_FRAME_OutputLength 0x0E8 > +#define KEXCEPTION_FRAME_MxCsr 0x0F0 > +#define KEXCEPTION_FRAME_Rbp 0x0F8 > +#define KEXCEPTION_FRAME_Rbx 0x100 > +#define KEXCEPTION_FRAME_Rdi 0x108 > +#define KEXCEPTION_FRAME_Rsi 0x110 > +#define KEXCEPTION_FRAME_R12 0x118 > +#define KEXCEPTION_FRAME_R13 0x120 > +#define KEXCEPTION_FRAME_R14 0x128 > +#define KEXCEPTION_FRAME_R15 0x130 > +#define KEXCEPTION_FRAME_Return 0x138 > +#define SIZE_KEXCEPTION_FRAME 0x140 > + > + > +// > // EXCEPTION_RECORD Offsets > // > #define EXCEPTION_RECORD_ExceptionCode 0x00 > > Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] want to learn
5th. On 2009-11-09, at 5:03 PM, Javier Agustìn Fernàndez Arroyo wrote: > Windows Internals, 4th Edition > > On Mon, Nov 9, 2009 at 4:35 PM, rahul nagpal > wrote: > Hey, i can get th source code of reactos, but i can't understand the coding, > your programmer who wrote these type of coding can also be refer any > book/notes.You please tell me the name of that book, for which i can also > take refrence for understanding the lower level of coding for making kernel > and other files.I know these type of languages(C,C++,Java Core,VC++,Oracle > 8i,html),but not for the hardware level only for making user level > programs.So Please help me do this task easier and i also tell you that i > didn't know the way to access your channel #reactos also help me i have no > sufficient time to take part in it but i try so please refer any book.Thanxxx > for making me the member of your group and Congratulations for your Project > Success :) (: > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] want to learn
I keep reading this on the forums, I don't understand how a newer, revised, edition with less mistakes than an older one is somehow "worse" to describe a clone of the OS being described. On 2009-11-09, at 6:04 PM, Javier Agustìn Fernàndez Arroyo wrote: > i thought only few parts of 5th edition are useful for ROS, and most of it > was based on 4th > > On Mon, Nov 9, 2009 at 11:15 PM, Alex Ionescu wrote: > 5th. > > On 2009-11-09, at 5:03 PM, Javier Agustìn Fernàndez Arroyo wrote: > >> Windows Internals, 4th Edition >> >> On Mon, Nov 9, 2009 at 4:35 PM, rahul nagpal >> wrote: >> Hey, i can get th source code of reactos, but i can't understand the coding, >> your programmer who wrote these type of coding can also be refer any >> book/notes.You please tell me the name of that book, for which i can also >> take refrence for understanding the lower level of coding for making kernel >> and other files.I know these type of languages(C,C++,Java Core,VC++,Oracle >> 8i,html),but not for the hardware level only for making user level >> programs.So Please help me do this task easier and i also tell you that i >> didn't know the way to access your channel #reactos also help me i have no >> sufficient time to take part in it but i try so please refer any >> book.Thanxxx for making me the member of your group and Congratulations for >> your Project Success :) (: >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > Best regards, > Alex Ionescu > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)
It's always funny to see how most people on this list talking about NT really have no clue. There would be no advantage to have a swap partition on Windows. Fast I/O and Paging I/O more than make up for any "benefits" Linux has. It's easy to have benefits to skip your FS when your FS model is worthless. It becomes a much mooter point when your FS model is the size and complexity (in terms of performance) of the competition's kernel. Not to mention you could forget about crash dumps with a separate partition. And no, Windows 7 sets up a separate system volume (this is where boot files go) to separate from the Win7 boot volume (this is where the Windows system files go) and to allow BitLocker to work. Best regards, Alex Ionescu On Thu, Nov 12, 2009 at 3:18 AM, Love Nystrom wrote: > Brian wrote: >> i was always under the impression that having a swap >> partition meant that you did not have to hassle with the file system >> allowing for marginal performance boosts. > That is generally true. In theory, APIs to access a swap partition can be > implemented to use the disk device driver directly, removing the additional > processing incurred by file systems drivers. > > In practice on NT, I believe the proper way is to implement a swap > file system driver, which can be made more efficient than regular > file systems drivers. > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] want to learn
ReactOS uses C. VC++ is an IDE made by Microsoft for writing C/C++ code, not a language. The "concepts" you are not "understanding" are the in the 3 Intel books you refuse to read. Go away. Best regards, Alex Ionescu On Thu, Nov 12, 2009 at 6:10 AM, rahul nagpal wrote: > The three Intel Book's which you refer me are only theoratical base not for > Practical.I want to learn Assembly language or system programming. > > My purpose is only that i want to understand the coding of reactos which is > done in vc++ but use many lower level programming concepts which i couldn't > understand.So you please tell me that which Book or People or Institute can > help me to understand the lower level concepts which you can use in reactos > coding.So i can also want to participate in making the coding of reactos by > using the lower level concepts... :) (: > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)
1) You would get the SAME ADVANTAGE by having the FILE on another physical drive! 2) I believe there's a book that covers that? Not to mention a bunch of easily googable information. Best regards, Alex Ionescu On Thu, Nov 12, 2009 at 11:37 AM, Love Nystrom wrote: > Alex Ionescu wrote: >> There would be no advantage to have a swap partition on Windows. >> > There most certainly is, if that partition is on another physical drive! > Two disks are faster than one ;-) > >> Not to mention you could forget about crash dumps with a >> separate partition. >> > Enlighten me.. Why? > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-general] Microsoft PDC
Say hi to Mark. On 2009-11-12, at 6:49 AM, Ged Murphy wrote: > This starts on Monday. > So nobody’s going?? > Shocker I’ll have to drink on my own then. > > Ged. > > > From: Ged Murphy [mailto:gedmur...@gmail.com] > Sent: 27 October 2009 15:41 > To: 'ReactOS Development List'; 'ReactOS General List' > Subject: Microsoft PDC > > I’ll be attending this year’s Microsoft PDC in Los Angeles and I should be > there between 16th November and 20th November. > If anyone else is going and wants to meet up for a chat at the conference or > a beer in the evening drop me a mail. > > Cheers, > Ged. > ___ > Ros-general mailing list > ros-gene...@reactos.org > http://www.reactos.org/mailman/listinfo/ros-general Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Microsoft PDC
Looks like you "missed" his entire chapter on crash dumps and page files in the Windows internals book :) On 2009-11-12, at 12:48 PM, Love Nystrom wrote: > Ged Murphy wrote: >> >> This starts on Monday. So nobody’s going?? >> >> Shocker I’ll have to drink on my own then. >> > I wish I could.. but I can't even afford to visit my mom.. > Have a good time, don't miss Mark Russinovitch. > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Why the *$#(% are you adding Vista exports?
Bugs like these would've NEVER happened if you stuck to your TARGET: NT 5.2.3790.1800 SP1: http://www.reactos.org/bugzilla/show_bug.cgi?id=4940 You can't just add Vista APIs and expect shit to work! You should really revert this kind of garbage. Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 44286: - Initialize SocketError to 0 to prevent a bogus error from GCC
Microsoft deals with this often -- they even have a macro you should probably use: // // The following macro is used to satisfy the compiler. Note that the // expressions/statements passed to this macro are not necessary for // correctness, but without them the compiler cannot compile with W4. // #define SATISFY_OVERZEALOUS_COMPILER(X) X You use it as such: SATISFY_OVERZEALOUS_COMPILER (SocketError = 0); On 2009-11-25, at 2:28 PM, Dmitry Gorbachev wrote: > Notice that the warning is "may be used uninitialized" and not "is > used uninitialized", so it is correct, in a sense. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 44286: - Initialize SocketError to 0 to prevent a bogus error from GCC
No they are correct, most of the times the "may" means "given certain code
paths", not "may" as in "uhhh... I think it could happen?"
The reason the error often happens, with GCC *AND* MSVC (see previous e-mail)
is stuff like this:
BOOLEAN HaveYourDad;
PVOID Pen15;
ULONG YourMom;
if (YourMom)
{
Pen15 = ExAllocateYourDad();
HaveYourDad = TRUE;
}
if (HaveYourDad) ExReleaseYourDad(Pen15);
In this case, the compiler might say that your Pen15 may be used without having
been initialized because it doesn't realize that I'm only going to have your
dad if I also already had your mom.
Had you written:
if (YourMom) ExReleaseYourDad(Pen15); the compiler would probably be smart
enough to realize the side-effect.
On 2009-11-25, at 3:31 PM, Timo Kreuzer wrote:
>
> Warning in cases in which the compiler doesn't know whether something is
> correct or not, is stupid in any case IMO, unless it's some
> --enable-uber-pedantic-warnings compiler flag. It could as well say
> "warning: your code could be wrong" and by chance this might be true.
>
> Dmitry Gorbachev wrote:
>> Notice that the warning is "may be used uninitialized" and not "is
>> used uninitialized", so it is correct, in a sense.
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 44348: [ntoskrnl/se] - Add a hack which prints an annoying message and grants access when it should not be. Callers/bugs should be fixed and this commit reverted a
This is stupid!!! We had this discussion countless times!
It's not a bug to get back access denied! In many situations this is
normal, and the application will try again! (Ie: Writing to a
read-only file)
Best regards,
Alex Ionescu
On Tue, Dec 1, 2009 at 10:26 PM, wrote:
> Author: fireball
> Date: Tue Dec 1 22:26:40 2009
> New Revision: 44348
>
> URL: http://svn.reactos.org/svn/reactos?rev=44348&view=rev
> Log:
> [ntoskrnl/se]
> - Add a hack which prints an annoying message and grants access when it
> should not be. Callers/bugs should be fixed and this commit reverted after
> that.
> See issue #4169 for more details.
>
> Modified:
> trunk/reactos/ntoskrnl/se/semgr.c
>
> Modified: trunk/reactos/ntoskrnl/se/semgr.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=44348&r1=44347&r2=44348&view=diff
> ==
> --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Tue Dec 1 22:26:40 2009
> @@ -608,10 +608,12 @@
> }
> else
> {
> - DPRINT1("Denying access for caller: granted 0x%lx, desired 0x%lx
> (generic mapping %p)\n",
> + DPRINT1("HACK: Should deny access for caller: granted 0x%lx, desired
> 0x%lx (generic mapping %p).\n",
> *GrantedAccess, DesiredAccess, GenericMapping);
> - *AccessStatus = STATUS_ACCESS_DENIED;
> - return FALSE;
> + //*AccessStatus = STATUS_ACCESS_DENIED;
> + //return FALSE;
> + *AccessStatus = STATUS_SUCCESS;
> + return TRUE;
> }
> }
>
>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] rbuild msvc backend
If anyone uses the 2003 Toolkit, you do know the latest Windows SDK gives you essentiall a "2008 Toolkit", as does the WDK. Just saying. I think the latest Windows SDK even ships with MSBUILD, which can build .vcproj files. Best regards, Alex Ionescu On Wed, Dec 2, 2009 at 9:14 PM, Daniel Reimer wrote: > Oh, nvm. I misread you mail. > > But the rest is still right. c::b backend is useless > > Daniel Reimer schrieb: >> Quite strange. Some hours ago you did not even know of the backend and >> now you use it? Fine, ok. I will believe this for now. But it will die >> regardless what you say. c::b is not able to fully build ROS anyway due >> to missing functions, thus its useless and can die. >> >> >> Sir Gallantmon schrieb: >> >>> The import support for MSVC projects is not perfect, so it shouldn't >>> be relied on. Never should you make the assumption that you can rely >>> on any form of import system. >>> >>> On Wed, Dec 2, 2009 at 12:43 PM, Ged Murphy>> <mailto:gedmur...@gmail.com>> wrote: >>> >>> >>> -Original Message- >>> From: ros-dev-boun...@reactos.org >>> <mailto:ros-dev-boun...@reactos.org> >>> [mailto:ros-dev-boun...@reactos.org >>> <mailto:ros-dev-boun...@reactos.org>] On >>> Behalf Of Love Nystrom >>> Sent: 02 December 2009 18:15 >>> To: ReactOS Development List >>> Subject: Re: [ros-dev] rbuild msvc backend >>> >>> > Is it really so much work to have true FOSS support ? >>> This is true FOSS support. As Colin says codeblocks can open >>> vcproj files. >>> What's the point in us trying to maintain a backend when >>> codeblocks provides >>> the support for us >>> >>> > How do these back ends work ? >>> > Translating rbuild files? >>> Yes. >>> >>> The codeblocks backend is very incomplete and very old. >>> It should have been removed a long time ago. >>> Anyway, it's gone now :) >>> >>> >>> >>> >>> >>> ___ >>> Ros-dev mailing list >>> ros-...@reactos.org<mailto:Ros-dev@reactos.org> >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44464: [RTL] Rewrite the rtl bitmap implementation. The old one was a little .... suboptimal. The new one should outperform the old one by several orders of magnit
bits, if any */
> - if (NumberToSet & 0x7)
> -*lpOut |= NTDLL_maskBits[NumberToSet & 0x7];
> -}
> -
> -
> -/*
> - * @implemented
> - */
> -BOOLEAN NTAPI
> -RtlTestBit(PRTL_BITMAP BitMapHeader,
> -ULONG BitNumber)
> -{
> - PUCHAR Ptr;
> -
> - if (BitNumber >= BitMapHeader->SizeOfBitMap)
> -return FALSE;
> -
> - Ptr = (PUCHAR)BitMapHeader->Buffer + (BitNumber / 8);
> -
> - return (BOOLEAN)(*Ptr & (1 << (BitNumber % 8)));
> -}
> -
> -/*
> - * @implemented
> - */
> -ULONG NTAPI
> -RtlFindFirstRunClear(PRTL_BITMAP BitMapHeader,
> - PULONG StartingIndex)
> -{
> -return RtlFindNextForwardRunClear(BitMapHeader, 0, StartingIndex);
> -}
> -
> -/*
> - * @implemented
> - */
> -ULONG NTAPI
> -RtlNumberOfClearBits(PRTL_BITMAP BitMapHeader)
> -{
> -
> - if (BitMapHeader)
> -return BitMapHeader->SizeOfBitMap - RtlNumberOfSetBits(BitMapHeader);
> - return 0;
> -}
> -
> -/*
> - * @implemented
> - */
> -ULONG NTAPI
> -RtlFindClearBitsAndSet(PRTL_BITMAP BitMapHeader,
> -ULONG NumberToFind,
> -ULONG HintIndex)
> -{
> - ULONG ulPos;
> -
> - ulPos = RtlFindClearBits(BitMapHeader, NumberToFind, HintIndex);
> - if (ulPos != MAXULONG)
> -RtlSetBits(BitMapHeader, ulPos, NumberToFind);
> - return ulPos;
> -}
> -
> -/*
> - * @implemented
> - */
> -CCHAR WINAPI RtlFindMostSignificantBit(ULONGLONG ulLong)
> -{
> -signed char ret = 32;
> -DWORD dw;
> -
> -if (!(dw = (DWORD)(ulLong >> 32)))
> -{
> -ret = 0;
> -dw = (DWORD)ulLong;
> -}
> -if (dw & 0x)
> -{
> -dw >>= 16;
> -ret += 16;
> -}
> -if (dw & 0xff00)
> -{
> -dw >>= 8;
> -ret += 8;
> -}
> -if (dw & 0xf0)
> -{
> -dw >>= 4;
> -ret += 4;
> -}
> -return ret + NTDLL_mostSignificant[dw];
> -}
> -
> -/*
> - * @implemented
> - */
> -CCHAR WINAPI RtlFindLeastSignificantBit(ULONGLONG ulLong)
> -{
> -signed char ret = 0;
> -DWORD dw;
> -
> -if (!(dw = (DWORD)ulLong))
> -{
> -ret = 32;
> -if (!(dw = (DWORD)(ulLong >> 32))) return -1;
> -}
> -if (!(dw & 0x))
> -{
> -dw >>= 16;
> -ret += 16;
> -}
> -if (!(dw & 0xff))
> -{
> -dw >>= 8;
> -ret += 8;
> -}
> -if (!(dw & 0x0f))
> -{
> -dw &
Re: [ros-dev] [ros-diffs] [tkreuzer] 44464: [RTL] Rewrite the rtl bitmap implementation. The old one was a little .... suboptimal. The new one should outperform the old one by several orders of magnit
Well why this then? They should be intrinsics...
On 2009-12-07, at 8:43 PM, Timo Kreuzer wrote:
>>> +unsigned char BitScanForward(ULONG * Index, unsigned long Mask)
>>> +{
>>> +*Index = 0;
>>> +while (Mask && ((Mask & 1) == 0))
>>> +{
>>> +Mask >>= 1;
>>> +++(*Index);
>>> +}
>>> +return Mask ? 1 : 0;
>>> +}
>>> +
>>> +unsigned char BitScanReverse(ULONG * const Index, unsigned long Mask)
>>> +{
>>> +*Index = 0;
>>> +while (Mask && ((Mask & (1 << 31)) == 0))
>>> +{
>>> +Mask <<= 1;
>>> +++(*Index);
>>> +}
>>> +return Mask ? 1 : 0;
>>> +}
>>
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44464: [RTL] Rewrite the rtl bitmap implementation. The old one was a little .... suboptimal. The new one should outperform the old one by several orders of magnit
So? Use intrinsics anyways.
Or __builtin_clz...
On 2009-12-07, at 10:07 PM, Timo Kreuzer wrote:
>
> Because this is a host module.
>
> Alex Ionescu wrote:
>> Well why this then? They should be intrinsics...
>>
>> On 2009-12-07, at 8:43 PM, Timo Kreuzer wrote:
>>
>>
>>>>> +unsigned char BitScanForward(ULONG * Index, unsigned long Mask)
>>>>> +{
>>>>> +*Index = 0;
>>>>> +while (Mask && ((Mask & 1) == 0))
>>>>> +{
>>>>> +Mask >>= 1;
>>>>> +++(*Index);
>>>>> +}
>>>>> +return Mask ? 1 : 0;
>>>>> +}
>>>>> +
>>>>> +unsigned char BitScanReverse(ULONG * const Index, unsigned long Mask)
>>>>> +{
>>>>> +*Index = 0;
>>>>> +while (Mask && ((Mask & (1 << 31)) == 0))
>>>>> +{
>>>>> +Mask <<= 1;
>>>>> +++(*Index);
>>>>> +}
>>>>> +return Mask ? 1 : 0;
>>>>> +}
>>>>>
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44464: [RTL] Rewrite the rtl bitmap implementation. The old one was a little .... suboptimal. The new one should outperform the old one by several orders of magnit
I'm concerned about code duplication.
Why can't our intrinsic header be used on host machines???
On 2009-12-07, at 11:16 PM, Timo Kreuzer wrote:
>
> Why should I bother reimplementing the intrinsics yet another time for
> different compilers in host headers? and what about compiling on a
> non-x86 linux machine? This code is portable and serves it's pupose very
> well.
> Or are you seriously concerned about the performance?
>
>
> Alex Ionescu schrieb:
>> So? Use intrinsics anyways.
>>
>> Or __builtin_clz...
>>
>> On 2009-12-07, at 10:07 PM, Timo Kreuzer wrote:
>>
>>
>>> Because this is a host module.
>>>
>>> Alex Ionescu wrote:
>>>
>>>> Well why this then? They should be intrinsics...
>>>>
>>>> On 2009-12-07, at 8:43 PM, Timo Kreuzer wrote:
>>>>
>>>>
>>>>
>>>>>>> +unsigned char BitScanForward(ULONG * Index, unsigned long Mask)
>>>>>>> +{
>>>>>>> +*Index = 0;
>>>>>>> +while (Mask && ((Mask & 1) == 0))
>>>>>>> +{
>>>>>>> +Mask >>= 1;
>>>>>>> +++(*Index);
>>>>>>> +}
>>>>>>> +return Mask ? 1 : 0;
>>>>>>> +}
>>>>>>> +
>>>>>>> +unsigned char BitScanReverse(ULONG * const Index, unsigned long Mask)
>>>>>>> +{
>>>>>>> +*Index = 0;
>>>>>>> +while (Mask && ((Mask & (1 << 31)) == 0))
>>>>>>> +{
>>>>>>> +Mask <<= 1;
>>>>>>> +++(*Index);
>>>>>>> +}
>>>>>>> +return Mask ? 1 : 0;
>>>>>>> +}
>>>>>>>
>>>>>>>
>>>> Best regards,
>>>> Alex Ionescu
>>>>
>>>>
>>>> ___
>>>> Ros-dev mailing list
>>>> Ros-dev@reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>>
>>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44508: updates EFLAGS definitions
There is a reason this set and names was chosen, please don't change them. It is for SDK compatibility. On 2009-12-10, at 3:22 PM, tkreu...@svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Dec 10 02:44:42 2009 > New Revision: 44508 > > URL: http://svn.reactos.org/svn/reactos?rev=44508&view=rev > Log: > updates EFLAGS definitions > > Modified: >branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > > Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > URL: > http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h?rev=44508&r1=44507&r2=44508&view=diff > == > --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] Thu Dec 10 02:44:42 2009 > @@ -82,19 +82,24 @@ > // > // EFlags > // > -#define EFLAGS_CF 0x01L > -#define EFLAGS_ZF 0x40L > -#define EFLAGS_TF 0x100L > -#define EFLAGS_INTERRUPT_MASK 0x200L > -#define EFLAGS_DF 0x400L > -#define EFLAGS_NESTED_TASK 0x4000L > -#define EFLAGS_V86_MASK 0x2 > +#define EFLAGS_CF 0x01 > +#define EFLAGS_PF 0x04 > +#define EFLAGS_AF 0x10 > +#define EFLAGS_ZF 0x40 > +#define EFLAGS_SF 0x80 > +#define EFLAGS_TF 0x100 > +#define EFLAGS_INTERRUPT_MASK 0x200 > +#define EFLAGS_DF 0x400 > +#define EFLAGS_OF 0x800 > +#define EFLAGS_IOPL_MASK0x3000 > +#define EFLAGS_NESTED_TASK 0x4000 > +#define EFLAGS_RF 0x1 > +#define EFLAGS_VM 0x2 > #define EFLAGS_ALIGN_CHECK 0x4 > #define EFLAGS_VIF 0x8 > #define EFLAGS_VIP 0x10 > +#define EFLAGS_ID 0x20 > #define EFLAGS_USER_SANITIZE0x3F4DD7 > -#define EFLAG_SIGN 0x8000 > -#define EFLAG_ZERO 0x4000 > > // > // IPI Types > > Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44508: updates EFLAGS definitions
On 2009-12-11, at 10:10 AM, Love Nystrom wrote: > Alex Ionescu wrote: >> There is a reason this set and names was chosen, please don't change them. >> It is for SDK compatibility. >> > > I see mostly additions that reflect Intel flag identifiers.. ergo, no > major panic. I created the NDK -- who are you to comment on whether or not I should panic? These changes are wrong. > None of the EFLAGS_xx show up in my public MS headers, which must mean > that they are inofficial identifiers only known to priviledged devs. LOL! Reminds me of an argument I had a couple of days ago: "I never heard of HGH being added to foods in the US, so it must not be true". Tell me, did you download ALL the Microsoft headers? ALL of them? Do you even know where to get them all? Do you have, for example, the WMP 11 SDK? Or the ADAM SDK? Why would ReactOS developers be using "inofficial" headers? What's a "privileged" developer? I just LOVE the "I can't find these definitions in some arbitrary set of headers I somehow obtained, so they must not exist" argument. > Ergo, we may define them to correctly reflect the EFLAGS register. Who is "WE"? You're not even a DEV for this project! > > However, but I think Alex is right that the compatible identifiers > should be retained. > EFLAG_SIGN and EFLAG_ZERO are used to compare flags in AH after LAHF, > and should be retained verbatim, since they are public (in NTDDK.H). > As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. Then shut up and don't post completely USELESS and wrong information. > > Best Regards // L > >> On 2009-12-10, at 3:22 PM, tkreu...@svn.reactos.org wrote: >>> Author: tkreuzer >>> Date: Thu Dec 10 02:44:42 2009 >>> New Revision: 44508 >>> >>> URL: http://svn.reactos.org/svn/reactos?rev=44508&view=rev >>> Log: >>> updates EFLAGS definitions >>> >>> Modified: >>> branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h >>> >>> Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h >>> URL: >>> http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h?rev=44508&r1=44507&r2=44508&view=diff >>> == >>> --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h >>> [iso-8859-1] (original) >>> +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h >>> [iso-8859-1] Thu Dec 10 02:44:42 2009 >>> @@ -82,19 +82,24 @@ >>> // >>> // EFlags >>> // >>> -#define EFLAGS_CF 0x01L >>> -#define EFLAGS_ZF 0x40L >>> -#define EFLAGS_TF 0x100L >>> -#define EFLAGS_INTERRUPT_MASK 0x200L >>> -#define EFLAGS_DF 0x400L >>> -#define EFLAGS_NESTED_TASK 0x4000L >>> -#define EFLAGS_V86_MASK 0x2 >>> +#define EFLAGS_CF 0x01 >>> +#define EFLAGS_PF 0x04 >>> +#define EFLAGS_AF 0x10 >>> +#define EFLAGS_ZF 0x40 >>> +#define EFLAGS_SF 0x80 >>> +#define EFLAGS_TF 0x100 >>> +#define EFLAGS_INTERRUPT_MASK 0x200 >>> +#define EFLAGS_DF 0x400 >>> +#define EFLAGS_OF 0x800 >>> +#define EFLAGS_IOPL_MASK0x3000 >>> +#define EFLAGS_NESTED_TASK 0x4000 >>> +#define EFLAGS_RF 0x1 >>> +#define EFLAGS_VM 0x2 >>> #define EFLAGS_ALIGN_CHECK 0x4 >>> #define EFLAGS_VIF 0x8 >>> #define EFLAGS_VIP 0x10 >>> +#define EFLAGS_ID 0x20 >>> #define EFLAGS_USER_SANITIZE0x3F4DD7 >>> -#define EFLAG_SIGN 0x8000 >>> -#define EFLAG_ZERO 0x4000 >>> >>> // >>> // IPI Types >> Best regards, >> Alex Ionescu > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44508: updates EFLAGS definitions
I hope you can read English. You no-devs are not supposed to challenge a coding change argument made by the person who wrote the code with the argument being "I have no idea what I'm talking about but you're wrong about how your own code should look like" and state "*we* should do this instead." On 2009-12-11, at 3:57 PM, Javier Agustìn Fernàndez Arroyo wrote: > > i hope you dont mean we no-devs cant discuss stuff and even learn from you > > On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu wrote: > > > > Ergo, we may define them to correctly reflect the EFLAGS register. > > Who is "WE"? You're not even a DEV for this project! > > > > > However, but I think Alex is right that the compatible identifiers > > should be retained. > > EFLAG_SIGN and EFLAG_ZERO are used to compare flags in AH after LAHF, > > and should be retained verbatim, since they are public (in NTDDK.H). > > As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. > > Then shut up and don't post completely USELESS and wrong information. > > _______ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 44508: updates EFLAGS definitions
On 2009-12-11, at 8:37 PM, Timo Kreuzer wrote: > Relax, dude ;-P > > The changes I made were the following: > 1.) removed EFLAGS_ZERO and EFLAG_SIGN as they are part of winddk. Any > reason to have them in the NDK, too? 1) Assembly code can't access winddk.h 2) They are in ks386.inc so they must be in asm.h (PSDK compat) > 2.) added EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF, EFLAGS_IOPL_MASK, > EFLAGS_RF, EFLAGS_ID just for completeness. Problem is these aren't in ks386.inc -- hence we lose PSDK compat. Put them in an internal ntoskrnl header or something. > 3.) renamed EFLAGS_V86_MASK to EFLAGS_VM, as this is what it is in long > mode (there is no V86 mode) Again, same issue. > > The rest is still the same, although these definitions don't match > ksasm64.inc That's the problem! > > Anyway, there's probably room for improvements. For example some > definitions are duplicated in asm.h and ketypes.h > I also wonder if there is any chance to make our assembly stuff > MSVC/MASM compatible and if we can still use #defines. The real problem is asm.h needs to be 100% compatible with ks386.inc and moved to include/psdk. Anything that was used in asm.h and is not in ks386.inc needs to go to some internal header. > > Further constructive suggestions appreciated. Same arguments apply for amd64/asm.h -- needs to match ksamd.inc > > Regards, > Timo > > > Alex Ionescu wrote: >> I hope you can read English. >> >> You no-devs are not supposed to challenge a coding change argument made by >> the person who wrote the code with the argument being "I have no idea what >> I'm talking about but you're wrong about how your own code should look like" >> and state "*we* should do this instead." >> >> >> On 2009-12-11, at 3:57 PM, Javier Agustěn Fernŕndez Arroyo wrote: >> >> >>> i hope you dont mean we no-devs cant discuss stuff and even learn from you >>> >>> On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu wrote: >>> >>> >>> >>>> Ergo, we may define them to correctly reflect the EFLAGS register. >>>> >>> Who is "WE"? You're not even a DEV for this project! >>> >>> >>>> However, but I think Alex is right that the compatible identifiers >>>> should be retained. >>>> EFLAG_SIGN and EFLAG_ZERO are used to compare flags in AH after LAHF, >>>> and should be retained verbatim, since they are public (in NTDDK.H). >>>> As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. >>>> >>> Then shut up and don't post completely USELESS and wrong information. >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> >> Best regards, >> Alex Ionescu >> >> >> >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sserapion] 44550: -Remove hacks for older gcc versions. -Black list gcc below 4.4.2 -Black list ld below 20091119. -99.99% Based on bug 4810 -Speeds up my build by 3 minutes
rsion should just contain the
> version
> +number.
> +Binutils 2.20 will hopefully contain the required features.
> */
> + if(strcmp(binutilsVersion.c_str(), "2.20") < 0)
> + return false;
> + }
> +
> + return true;
> }
>
> void
>
> Modified:
> branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/modulehandler.cpp
> URL:
> http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/modulehandler.cpp?rev=44550&r1=44549&r2=44550&view=diff
> ==
> ---
> branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/modulehandler.cpp
> [iso-8859-1] (original)
> +++
> branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/modulehandler.cpp
> [iso-8859-1] Sat Dec 12 16:41:43 2009
> @@ -1782,6 +1782,12 @@
> &module.linkerFlags,
> used_defs );
>
> + /* LD automatically exports all symbols by default if -shared is
> specified. Prevent it from doing
> +this by adding the option -exclude-all-symbols (available since
> Binutils 20091017). */
> + // FIXME: Should only be applied for -shared modules, when there's a
> smart way to check for them.
> + if ( ModuleHandlerInformations[module.type].DefaultHost == HostFalse &&
> !module.importLibrary )
> + fprintf ( fMakefile,
> "%s_LDFLAGS+=$(LDFLAG_EXCLUDE_ALL_SYMBOLS)\n", module.name.c_str() );
> +
> fprintf ( fMakefile, "\n\n" );
> }
>
>
> Modified:
> branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/rules.mak
> URL:
> http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/rules.mak?rev=44550&r1=44549&r2=44550&view=diff
> ==
> --- branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/rules.mak
> [iso-8859-1] (original)
> +++ branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/rules.mak
> [iso-8859-1] Sat Dec 12 16:41:43 2009
> @@ -259,7 +259,7 @@
> $$(ECHO_WIDL)
> $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
> RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C
> ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
>
> -${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_c.c,,-fno-unit-at-a-time,${call
> RBUILD_intermediate_path_noext,$(2)}_c.o}
> +${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call
> RBUILD_intermediate_path_noext,$(2)}_c.o}
>
> endef
>
> @@ -272,7 +272,7 @@
> $$(ECHO_WIDL)
> $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
> RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S
> ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
>
> -${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_s.c,,-fno-unit-at-a-time,${call
> RBUILD_intermediate_path_noext,$(2)}_s.o}
> +${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call
> RBUILD_intermediate_path_noext,$(2)}_s.o}
>
> endef
>
> @@ -285,7 +285,7 @@
> $$(ECHO_WIDL)
> $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
> RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_p.h -p -P
> ${call RBUILD_intermediate_path_noext,$(2)}_p.c $(2)
>
> -${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_p.c,,-fno-unit-at-a-time,${call
> RBUILD_intermediate_path_noext,$(2)}_p.o}
> +${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_p.c,,,${call
> RBUILD_intermediate_path_noext,$(2)}_p.o}
>
> endef
>
> @@ -298,7 +298,7 @@
> $$(ECHO_WIDL)
> $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
> RBUILD_dir,$(2)}} -u -U $$@ $$<
>
> -${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_i.c,,-fno-unit-at-a-time,${call
> RBUILD_intermediate_path_noext,$(2)}_i.o}
> +${call RBUILD_CC,$(1),${call
> RBUILD_intermediate_path_noext,$(2)}_i.c,,,${call
> RBUILD_intermediate_path_noext,$(2)}_i.o}
>
> endef
>
>
> Modified: branches/ros-amd64-bringup/reactos/tools/rbuild/project.cpp
> URL:
> http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/tools/rbuild/project.cpp?rev=44550&r1=44549&r2=44550&view=diff
> ==
> --- branches/ros-amd64-bringup/reactos/tools/rbuild/project.cpp [iso-8859-1]
> (original)
> +++ branches/ros-amd64-bringup/reactos/tools/rbuild/project.cpp [iso-8859-1]
> Sat Dec 12 16:41:43 2009
> @@ -527,6 +527,7 @@
> case MicrosoftC: return "msc";
> default: assert ( false );
> }
> +return "";
> }
>
> std::string
> @@ -538,4 +539,5 @@
> case MicrosoftLink: return "mslink";
> default: assert ( false );
> }
> -}
> +return "";
> +}
>
>
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
