- Ros-dev - ReactOS.org

RE: [ros-diffs] [jimtabor] 20610: Revert, thx Thomas, wasnt sure.
by Murphy, Ged (Bolton) 06 Jan '06

06 Jan '06

Do those debug prints really need to be DPRINT1's ?? -----Original Message----- From: jimtabor(a)svn.reactos.org [mailto:jimtabor@svn.reactos.org] Sent: 06 January 2006 14:24 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jimtabor] 20610: Revert, thx Thomas, wasnt sure. Revert, thx Thomas, wasnt sure. Modified: trunk/reactos/subsys/win32k/ntuser/menu.c _____ Modified: trunk/reactos/subsys/win32k/ntuser/menu.c --- trunk/reactos/subsys/win32k/ntuser/menu.c 2006-01-06 13:57:38 UTC (rev 20609) +++ trunk/reactos/subsys/win32k/ntuser/menu.c 2006-01-06 14:23:26 UTC (rev 20610) @@ -33,7 +33,7 @@ #define NDEBUG #include <debug.h> -extern PMENU_OBJECT FASTCALL +PMENU_OBJECT FASTCALL IntGetSystemMenu(PWINDOW_OBJECT Window, BOOL bRevert, BOOL RetMenu); @@ -1659,7 +1659,7 @@ MENUBARINFO kmbi; DECLARE_RETURN(BOOL); - DPRINT("Enter NtUserGetMenuBarInfo\n"); + DPRINT1("Enter NtUserGetMenuBarInfo\n"); UserEnterShared(); if (!(WindowObject = UserGetWindowObject(hwnd))) @@ -1849,7 +1849,7 @@ RETURN(Res); CLEANUP: - DPRINT("Leave NtUserGetMenuBarInfo, ret=%i\n",_ret_); + DPRINT1("Leave NtUserGetMenuBarInfo, ret=%i\n",_ret_); UserLeave(); END_CLEANUP; } @@ -1887,7 +1887,7 @@ PMENU_ITEM MenuItem; DECLARE_RETURN(BOOL); - DPRINT("Enter NtUserGetMenuItemRect\n"); + DPRINT1("Enter NtUserGetMenuItemRect\n"); UserEnterShared(); if (!(Menu = UserGetMenuObject(hMenu))) @@ -1923,7 +1923,7 @@ RETURN( TRUE); CLEANUP: - DPRINT("Leave NtUserGetMenuItemRect, ret=%i\n",_ret_); + DPRINT1("Leave NtUserGetMenuItemRect, ret=%i\n",_ret_); UserLeave(); END_CLEANUP; } ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

2 1

Re: [ros-diffs] [jimtabor] 20609: Should have placed extern in there.
by Thomas Weidenmueller 06 Jan '06

06 Jan '06

jimtabor(a)svn.reactos.org wrote: > Should have placed extern in there. > > Modified: trunk/reactos/subsys/win32k/ntuser/menu.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/subsys/win32k/ntuser/menu.c* > > --- trunk/reactos/subsys/win32k/ntuser/menu.c 2006-01-06 11:58:17 UTC (rev 20608) > +++ trunk/reactos/subsys/win32k/ntuser/menu.c 2006-01-06 13:57:38 UTC (rev 20609) > @@ -33,7 +33,7 @@ > > #define NDEBUG > #include <debug.h> > > > -PMENU_OBJECT FASTCALL > > +extern PMENU_OBJECT FASTCALL > > IntGetSystemMenu(PWINDOW_OBJECT Window, BOOL bRevert, BOOL RetMenu); > > > 'extern' for forward declarations of functions is obsolete. The standards don't require it. - Thomas

1 0

Re: [ros-svn] [ion] 20580: - New ERESOURCE implementation: fixes the return value of some functions (VOID vs NTSTATUS, USHORT vs ULONG), as well as optimized the code loops and general structure of the code. Additionnaly, functions do not simply call other functions with similar names; the exact implementation of each function has now been properly separated (see the DDK for more information on this) to have the most optimized scenarios.
by Hartmut Birr 05 Jan '06

05 Jan '06

ion(a)svn.reactos.org wrote: > - New ERESOURCE implementation: fixes the return value of some functions (VOID vs NTSTATUS, USHORT vs ULONG), as well as optimized the code loops and general structure of the code. Additionnaly, functions do not simply call other functions with similar names; the exact implementation of each function has now been properly separated (see the DDK for more information on this) to have the most optimized scenarios. > - Also, the spinlock is not actually acquired on non-SMP builds; instead, interrupts are blocked and unblocked for acquire/release, this optimizes locking. > - Added many asserts and bugcheck scenarios. > - Added thread priority boosting. > - Added some debugging helpers and deadlock detection. > - Added RESOURCE_NOT_OWNED bugcehck message. > * Thanks again to Waxdragon (Andrew) for testing this build. It seems, that your implementation is broken. On a non SMP machine during 'make clean' on the ros source: KeBugCheckEx at ./ntoskrnl/ex/resource.c:1847 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x000000E3 (0x81a5eb0c,0x81a55c70,0x00000000,0x00000002) Frames: <ntoskrnl.exe:2599 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:27ac4 (./ntoskrnl/ex/resource.c:1843 (ExReleaseResourceLite))> <vfatfs.sys:3ee2 (drivers/fs/vfat/dir.c:471 (DoQuery))> <vfatfs.sys:416f (drivers/fs/vfat/dir.c:486 (VfatDirectoryControl))> <vfatfs.sys:dc06 (drivers/fs/vfat/misc.c:119 (VfatDispatchRequest))> <vfatfs.sys:dd8f (drivers/fs/vfat/misc.c:167 (VfatBuildRequest))> <ntoskrnl.exe:4369b (./ntoskrnl/io/irp.c:1076 (IofCallDriver))> <ntoskrnl.exe:53a3a (ntoskrnl/io/file.c:2607 (NtQueryDirectoryFile))> <ntoskrnl.exe:a0daa (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))> <kernel32.dll:9b22 (./lib/kernel32/file/find.c:143 (InternalFindNextFile))> The same on a SMP machine (no back trace available): KeBugCheckEx at ./ntoskrnl/ex/resource.c:1868 (./ntoskrnl/mm/mm.c:292 CPU0) Page fault at high IRQL was 2, address c2410 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x000000E3 (0x8131d0d8,0x81620d68,0x81376640,0x00000002) - Hartmut

2 4

Project Status Report
by Steven Edwards 05 Jan '06

05 Jan '06

Hi, So here is the first in what I hope to be quarterly reports. In future reports I will provide more detail such as charts and graphs if I feel so inclined. Depending on how much goes on in a period we may make it every 6 months instead of every 3 months. Basically this report just covers what has gone on during the 0.2.x development and where we plan on going. Developers that I spoke with in private or that I have worked with are listed here as to the project I know you have or are working on. If your not listed please add yourself to http://www.reactos.org/wiki/index.php/People_of_ReactOS Also could someone convert this from Microsoft Word to OpenOffice and or PDF and check the formatting of the doc? I lack good artistic skill so feel free to make corrections before spamming it anywhere. I think I spelled all the names right. Sorry if I left off any accent. Also as a final note if I left of your project or did not give it the coverage you feel it deserves do not take it personal. We are working on a massive project and I have not even talked to all of the people with commit access let alone know all of the things people are working on. I have tried to keep the information here as general as possible except where I feel that the public may have interest. Thanks -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 3

servman.rc
by Alex Buell 05 Jan '06

05 Jan '06

Please remember that some of us don't use Windows ;o) make[1]: Entering directory `/home/alex/src/OpSys/reactos' [CC] subsys/system/servman/servman.c [WRC] obj-i386/subsys/system/servman/servman.coff subsys/system/servman/servman.rc:15:17: En.rc: No such file or directory make[1]: *** [obj-i386/subsys/system/servman/servman.coff] Error 1 make[1]: Leaving directory `/home/alex/src/OpSys/reactos' -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

1 0

Build 20583 bluescreens
by Alex Buell 05 Jan '06

05 Jan '06

Just got ReactOS to build and boot, but bluescreens during the GUI based setup. It looks like there's something wrong with the code that services the mouse. (./ntoskrnl/ke/main.c:295) --------------------------------------------------------------- (./ntoskrnl/ke/main.c:296) ReactOS 0.3-SVN (Build 20060105-r20584) Used memory 131072Kb (./ntoskrnl/mm/mminit.c:386) Kernel Stack Limits. InitTop = 0x800ba000, Init = 0x800b7000 (./ntoskrnl/mm/mm.c:283) No current process (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pcnet.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service PCNet failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\vmx_svga.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service vmx_svga failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pcnet.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service PCNet failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\vmx_svga.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service vmx_svga failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000001) (./ntoskrnl/io/pnpreport.c:86) IoReportResourceForDetection partly implemented (./ntoskrnl/io/pnpmgr.c:545) IoOpenDeviceRegistryKey(): Base key doesn't exist, exiting... (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000034) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000034) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (./ntoskrnl/io/disk.c:630) RDiskCount 2 (./subsys/win32k/ntuser/winsta.c:108) IntWinStaObjectOpen (./subsys/win32k/ntuser/winsta.c:118) Create winsta atomtable (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows \WindowStations\WinSta0\Default) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows\WindowStations\WinSta0\Winlogon) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows \WindowStations\WinSta0\Screen-Saver) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! WL-Status: ReactOS is starting up... WARNING: WSHGetSockaddrType at drivers/net/wshtcpip/wshtcpip.c:103 is UNIMPLEMENTED! (services/dhcp/util.c:72) ERROR: util.c read_client_conf not implemented! 81178950: 00 00 00 00 c8 e4 64 00 01 00 00 00 00 00 00 00 ......d......... 81178960: 34 e5 64 00 34 20 76 00 ac 10 75 02 03 00 00 00 4.d.4 v...u..... 81178970: ac 18 65 00 c8 e4 64 00 00 00 00 00 b8 43 76 00 ..e...d......Cv. 81178980: 00 00 00 00 .... FIXME: CopyImage doesn't support IMAGE_ICON correctly! (lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (SAMLIB:lib/samlib/samlib.c:399) User already exists! (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (./lib/advapi32/service/scm.c:2036) dwBufSize: 0 (subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called (./ntoskrnl/mm/mm.c:275) Page fault at high IRQL was 2, address 156 KeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1242 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0xc0000005,0x800028dd,0x00000000,0x00000156) *** ntoskrnl.exe - Address 0x800028dd base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:800028dd <ntoskrnl.exe:28dd (./ntoskrnl/ke/wait.c:0 ())> cr2 156 cr3 26000 Proc: 80804c20 Pid: 4 <System> Thrd: 80d6c7d8 Tid: 80 DS 23 ES 23 FS 30 GS 0 EAX: 9e458c14 EBX: 00000102 ECX: 00000102 EDX: 00000004 EBP: 9e458b80 ESI: 00000000 ESP: 9e458b04 EDI: 80d6c7d8 EFLAGS: 00010206 kESP 9e458b04 kernel stack base 9e456000 Frames: <ntoskrnl.exe:34d5 (./ntoskrnl/ke/event.c:207 (KeSetEvent))> <ntoskrnl.exe:29109 (./ntoskrnl/io/irp.c:0 (IopCompleteRequest))> <ntoskrnl.exe:3164 (./ntoskrnl/ke/apc.c:0 (KiDeliverApc))> <80405EAE> <win32k.sys:3b3ed (./subsys/win32k/eng/mouse.c:588 (IntEngMovePointer))> <win32k.sys:5d299 (./subsys/win32k/ntuser/input.c:0 ())> <win32k.sys:5dc4b (./subsys/win32k/ntuser/input.c:148 (ProcessMouseInputData))> <win32k.sys:5de0f (./subsys/win32k/ntuser/input.c:227 (MouseThreadMain))> <ntoskrnl.exe:5aeab (./ntoskrnl/ps/thread.c:94 (PspSystemThreadStartup)) > <ntoskrnl.exe:62265 (ntoskrnl/ke/i386/ctxswitch.S:82 (KiThreadStartup))> -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

2 1

Build 20583 blows up with the following
by Alex Buell 05 Jan '06

05 Jan '06

obj-i386/ntoskrnl/ke/i386/kernel.o: In function `KeApplicationProcessorInitDispatcher': /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:147: undefined reference to `@KeAcquireDispatcherDatabaseLock@0' /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:149: undefined reference to `@KeReleaseDispatcherDatabaseLock@4' obj-i386/ntoskrnl/ke/i386/kernel.o: In function `KeInit2': /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:442: undefined reference to `@KeInitializeDispatcher@0' collect2: ld returned 1 exit status -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

3 3

RE: [ion] 20554: - Fix shamefully dangerously broken WorkThread/Queue/Item implementation:
by Ge van Geldorp 05 Jan '06

05 Jan '06

> From: ion(a)svn.reactos.org > > * Do not pollute the kernel with 10 real-time threads and 5 > high-priority threads in order to manage work items. Work > threads are very-low priority (< 7) and should never pre-empt > userthreads like they do now. 1 priority 7, 5 priority 5 and > 3 priority 4 threads are now properly created. I haven't looked at your code yet, but the comment worries me. Does it mean that if a usermode app is stuck in a "while (1) ;" loop stuff queued by IoAllocateWorkItem( ) never gets executed? If I misunderstood, nevermind, disregard this message. If this is true we're in big trouble. We're using work items in a lot of places to get from DPC level to PASSIVE level. For example, the networking stack queues a work item when data was received from the network card. I'd hate to see a stuck usermode app halt all network communications... GvG

8 16

Re: [ros-diffs] [ion] 20579: - Change dispatcher lock release to be more like documented in Windows Internals II and to allow an easier move to Queued Spinlock.
by Hartmut Birr 05 Jan '06

05 Jan '06

ion(a)svn.reactos.org wrote: > - Change dispatcher lock release to be more like documented in Windows Internals II and to allow an easier move to Queued Spinlock. > Modified: trunk/reactos/ntoskrnl/include/internal/ke.h > Modified: trunk/reactos/ntoskrnl/ke/wait.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/include/internal/ke.h* > --- trunk/reactos/ntoskrnl/include/internal/ke.h 2006-01-05 15:29:08 UTC (rev 20578) > +++ trunk/reactos/ntoskrnl/include/internal/ke.h 2006-01-05 15:32:08 UTC (rev 20579) > @@ -51,6 +51,7 @@ > #ifndef CONFIG_SMP > #define KeInitializeDispatcher() > #define KeAcquireDispatcherDatabaseLock() KeRaiseIrqlToDpcLevel(); > > +#define KeReleaseDispatcherDatabaseLock(OldIrql) KiExitDispatcher(OldIrql); > > #define KeAcquireDispatcherDatabaseLockAtDpcLevel() > #define KeReleaseDispatcherDatabaseLockFromDpcLevel() > #else > @@ -60,6 +61,9 @@ > > KeAcquireSpinLockAtDpcLevel (&DispatcherDatabaseLock); > #define KeReleaseDispatcherDatabaseLockFromDpcLevel() \ > KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); > > +#define KeReleaseDispatcherDatabaseLock(OldIrql) \ > + KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); \ > + KiExitDispatcher(OldIrql); > > #endif > I don't like inverted logic. It is more readable like this: #ifdef CONFIG_SMP ... #else ... #endif - Hartmut

1 0

tools/rbuild/backend/mingw/modulehandler.h
by Reuben Perelman 05 Jan '06

05 Jan '06

I was getting this error when trying to compile reactos: > reub2000@reub2000 ~/reactos $ make > [MKDIR] obj-i386/tools > [MKDIR] obj-i386/tools/rbuild > [MKDIR] obj-i386/tools/rbuild/backend > [MKDIR] obj-i386/tools/rbuild/backend/mingw > [CC] tools/rbuild/backend/mingw/mingw.cpp > tools/rbuild/backend/mingw/modulehandler.h:91: error: extra > qualification ‘MingwModuleHandler::’ on member > ‘GetCompilationUnitDependencies’ > tools/rbuild/backend/mingw/modulehandler.h:150: error: extra > qualification ‘MingwModuleHandler::’ on member > ‘GetPrecompiledHeaderFilename’ > make: *** [obj-i386/tools/rbuild/backend/mingw/mingw.o] Error 1 Looking at the file, I couldn't understand why MingwModuleHandler:: was being used within the class of the same name, so I removed it from before the definition of the functions. I'm guessing that it was copied from the function definition outside of the class in a .cpp file? Anyways, this seems to allow reactos to compile: > Index: tools/rbuild/backend/mingw/modulehandler.h > =================================================================== > --- tools/rbuild/backend/mingw/modulehandler.h (revision 20484) > +++ tools/rbuild/backend/mingw/modulehandler.h (working copy) > @@ -88,7 +88,7 @@ > std::string GetBasename ( const std::string& filename ) const; > FileLocation* GetActualSourceFilename ( const FileLocation* > fileLocation ) const; > std::string GetExtraDependencies ( const std::string& filename ) const; > - std::string MingwModuleHandler::GetCompilationUnitDependencies ( > const CompilationUnit& compilationUnit ) const; > + std::string GetCompilationUnitDependencies ( const CompilationUnit& > compilationUnit ) const; > std::string GetModuleArchiveFilename () const; > bool IsGeneratedFile ( const File& file ) const; > std::string GetImportLibraryDependency ( const Module& importedModule ); > @@ -147,7 +147,7 @@ > std::string GenerateGccIncludeParameters () const; > std::string GenerateGccParameters () const; > std::string GenerateNasmParameters () const; > - std::string MingwModuleHandler::GetPrecompiledHeaderFilename () const; > + std::string GetPrecompiledHeaderFilename () const; > void GenerateGccCommand ( const FileLocation* sourceFileLocation, > const std::string& extraDependencies, > const std::string& cc, Also, I saw a lot of 'std::'. Why not use 'using namespace std;'?

2 4

Optimization Proposal
by Alex Ionescu 04 Jan '06

04 Jan '06

Hi, I have come to the conclusion that using -O2 is beneficial even for DBG = 1 builds, and that it should be set on by default on all builds. The typically given reason for not using optimizations on a "Debug" build is because these apparently make assembly code harder to read. I have realized otherwise, and as seen in the example that I will include below, I'm sure this will be mutually agreed on. I note the following advantages in using -O2 on a DBG = 1 build as well: - -O2 makes the compiler do additional checks. For example, gcc will NOT detect uninitialized variables unless -O2 is being used, even though they are a very important programming bug. Apart from finding more bugs, it also makes trunk compilable. Right now, I see at least two commits by Thomas or others being made every week in order to fix some code which used unitinialized variables (I myself have been guilty of this). This means that some of us, like Thomas, have to constantly fix other people's mistakes. - -O2 means less last-minute blockers. Because we release in -O2 but almost never build it like that, this creates a big problem for people like Andrew or Brandon, which handle the release process and do testing. Because the -O2 build gets less testing coverage, it is very possible for a critical bug to be in ROS for a month before anyone notices it at release time, in which case we will all have to scramble to find a fix for it. - -O2 will not undefine DBG or change anything else in the code. All the advatanges, extra error checking and assertions of the DBG =1 build would remain. - -O2 builds are much faster, greatly helping testing speed. - -O2 builds are much more likely to bring up race conditions and other important timing bugs we need to watch out for. - -O2 means easier debugging. This point is really important because until I realized how true it was, I didn't want to bring this up. Here is a pseudo(but real) disassembly of something I've seen in my dbg = 1 kernel binary while debugging: 0x40b845: push ebp mov ebp, esp sub esp, 4 mov [ebp-4], fs:18h mov eax, [ebp-4] leave retn 0x4bc8a5: push ebp mov ebp, esp sub esp, 4 call 0x40b845 mov ecx, [eax+1c] mov [ebp-4], eax mov eax, [ebp-4] leave retn 0x42b845: push ebp mov ebp, esp sub esp, 4 call 0x4bc8a5 mov ecx, [eax+124] mov [ebp-4], eax mov eax, [ebp-4] leave retn KeFooBar: push ebp mov ebp, esp sub esp, 4c call 0x42b845 mov [ebp-0xc], eax mov eax, [ebp-0xc] <..> leave retn This is how it looks with -O2 KeFooBar: push ebp mov ebp, esp sub esp, 4c mov eax, fs:124h <..> leave retn I hope we can all agree on which one of these is readable. The -O2 build clearly shows you that eax is fs:124h, which you oughta know is Pcrb->CurrentThread; even if you don't, you can easily check in a header. The non-o2 build calls 3 other functions, out of which 2 are merely calling other functions themselves (due to lack of symbols you have no way of knowing what these functions are doing), until we finally get to a function which does fs:18, which you then realize is the PCR, you then walk back and realize pcr->0x1c is PCRB, and Prcb->0x124 is current thread. Yes, this example could easily be destroyed by saying " use a #define with inline assembly" but I can bring many more; we can't start using inline assembly everywhere... msvc does an amazing job at optimizing these things, and even gcc isn't that bad, if only you let it. Code built without -o2 makes horrible usage of the stack, which makes you have to memory a lot more addresses then code which simple stores values in registers. Because humans are smart, the loops generated by -O2 are also much closer to what someone that understands assembly is used to (for example, the loop will use ecx, and not a stack variable that you need to memorize). I consider myself an expert on assembly coding, and I simply have great trouble reading non-O2 kernels, so how exactly does it help debugging? In the end, I am convinced that the only disadvantage of using -O2 by default is that it will slightly increase build times. I don't think this increase is more then, at most 1 minute or two for a complete build. If this issue is really critical to someone people, then perhaps only core system files should use -O2 (kernel32, ntdll, ntoskrnl, csr, win32k, drivers, etc). I know some of the developers on IRC are strongly for this, but I want to make sure I get a broader opinion. Best regards, Alex Ionescu

7 9

RE: [ros-dev] Optimization Proposal
by Murphy, Ged (Bolton) 04 Jan '06

04 Jan '06

Ge van Geldorp wrote: > Yup, using Insight (the cygwin GUI for gdb), which connects > over a null > modem to the GDB stub in ntoskrnl. I'm using a > slightly-modified version, > since the official one insists that when doing a stack > backtrace the frame > pointer should increase for each stack frame (which is > correct generally but > breaks when you're backtracing from the kernelmode stack back into the > usermode stack). Also the official version has a problem with hardware > watchpoints. I use the Win32 port which comes as an add-on package with DevCpp. However I've recently switched my pen drive compiler from DevCpp to Code::Blocks I'm finding the Code::Blocks built in debugger (which also uses mingw gdb) to be excellent and have started using that in place of Insight, as it doesn't seem have any of the problems Insight has. In fact, I'm so impressed with Code::Blocks as a whole, I think it makes DevCpp obsolete and needs a backend writing for rbuild. It's certainly the best mingw enabled development tool for ROS I've come across. ;) Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

1 0

Re: [ros-svn] [jimtabor] 20559: Clean up and fixed NtUserGetMenuItemRect. Needs more testing. I watch mplayerc swip all the menu items with crashing.
by James Tabor 04 Jan '06

04 Jan '06

jimtabor(a)svn.reactos.org wrote: > Clean up and fixed NtUserGetMenuItemRect. Needs more testing. I watch mplayerc swip all the menu items with out crashing. > > > Updated files: > trunk/reactos/subsys/win32k/ntuser/menu.c > *out

1 0

Info about debugger
by Juan Rodriguez 04 Jan '06

04 Jan '06

what debugger can i use on ros?

1 0

install problem
by Hartmut Birr 04 Jan '06

04 Jan '06

Hi, it seems, some people have problems to install reactos from the boot cd. The reason is, all newer pc with a P4-HT or an AMD64X2 cpu are multiprocessor compliant. In this case, the auto choice is multiprocessor for the computer type. If the choice isn't changed, the multiprocessor hal and the uniprocessor kernel are installed. The next boot will show an empty colored (light green or red) screen after freeldr has started reactos. I think, we should disable the auto choice for the computer type. - Hartmut

2 1

RE: [ros-dev] RE: [ros-diffs] [mbosma] 20543: fix typos.
by Murphy, Ged (Bolton) 03 Jan '06

03 Jan '06

Thomas Weidenmueller wrote: > Murphy, Ged (Bolton) wrote: > > which, IIRC (I don't have a compiler to hand) would throw > up 'assignment in > > expression' errors with our MSVC /w4 setting. We would > therefore need > > something like : > > Then don't use that warning level if it rejects good code that's not > even confusing. It's set via rbuilds MSDN backend. It needs functionality to set different warning levels for different components. e.g. /w4 for core components only. Having to do it manually is far too much effort for your average programmer ;) Maybe I should stop moaning and correct it .... hmmm :p > > Which has suddenly become rather long for a normally simple > message loop > > routine ..... LOL > > It's exactly the same, just ugly IMO. I know, as I said, it was just for fun. First day back at work after the Christmas break is hard going ;) (and why are these mails being sent to both ros-diff and ros-dev when only addressed to ros-dev, Gé ?) Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

3 2

Re: [ros-svn] [greatlrd] 20548: forget remove a calc value in the for loop it can do outside the loop.
by James Tabor 03 Jan '06

03 Jan '06

Hi GreatLord! greatlrd(a)svn.reactos.org wrote: > forget remove a calc value in the for loop it can do outside the loop. > > > > Updated files: > trunk/reactos/subsys/win32k/dib/dib16bpp.c > I'm getting this even after a make clean, [CC] subsys/win32k/dib/dib16bpp.c subsys/win32k/dib/dib16bpp.c: In function `CheckClipRegion': subsys/win32k/dib/dib16bpp.c:631: error: structure has no member named `Height' make[1]: *** [obj-i386/subsys/win32k/dib/dib16bpp.o] Error 1 Thanks, James

2 1

Why GAS not NASM?
by Alex Buell 03 Jan '06

03 Jan '06

I think our problem is because we are using GAS and NASM to assemble the various assembly files. Oughtn't we standardise on NASM? Why not? -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

3 3

RE: [ros-diffs] [mbosma] 20543: fix typos.
by Murphy, Ged (Bolton) 03 Jan '06

03 Jan '06

This should really be while( GetMessage( &msg, NULL, 0, 0 ) > 0 ) as GetMessage returns <0 on failure. It will then break on failure or WM_QUIT Just being anal though as GetMessage should never really fail ;) -----Original Message----- From: mbosma(a)svn.reactos.org [mailto:mbosma@svn.reactos.org] Sent: 03 January 2006 11:50 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mbosma] 20543: fix typos. + while(GetMessage(&msg,NULL,0,0)) ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

3 2

RE: [ros-dev] RE: [ros-diffs] [mbosma] 20543: fix typos.
by Murphy, Ged (Bolton) 03 Jan '06

03 Jan '06

Thomas Weidenmueller wrote > Murphy, Ged (Bolton) wrote: > > This should really be > > > > while( GetMessage( &msg, NULL, 0, 0 ) > 0 ) > > > > as GetMessage returns <0 on failure. > > It will then break on failure or WM_QUIT > > > > Just being anal though as GetMessage should never really fail ;) > > See > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/winui/WinUI/WindowsUserInterface/Windowing/MessagesandMessa > geQueues/MessagesandMessageQueuesReference/MessagesandMessageQ > ueuesFunctions/GetMessage.asp > > The loop shouldn't be broken if GetMessage returns -1. > > - Thomas True, I suppose it depends on the reasoning behind the GetMessage error. MSDN does have this to say: "Warning Because the return value can be nonzero, zero, or -1, avoid code like this: while (GetMessage( lpMsg, hWnd, 0, 0)) ..." For a bit of light hearted fun, here is the MSDN suggestion: while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } which, IIRC (I don't have a compiler to hand) would throw up 'assignment in expression' errors with our MSVC /w4 setting. We would therefore need something like : bRet = GetMessage( &msg, NULL, 0, 0 ); while( bRet != 0 ) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } bRet = GetMessage( &msg, NULL, 0, 0 ); } Which has suddenly become rather long for a normally simple message loop routine ..... LOL A nice case for a #pragma warning() ..... or reduce the warning level for non core components (ping) Ged ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

2 1

Re: [ros-svn] [hbirr] 20532: Simplified the definition of the interrupt handlers for non smp machines.
by Alex Ionescu 02 Jan '06

02 Jan '06

hbirr(a)svn.reactos.org wrote: >Simplified the definition of the interrupt handlers for non smp machines. > > > >Updated files: >trunk/reactos/ntoskrnl/ke/i386/irqhand.s > > > > GMTA :) Best regards, Alex Ionescu

1 0

ntoskrnl/ex/i386/interlck_asm.S fails to compile due to EFLAG_SELECT
by Alex Buell 02 Jan '06

02 Jan '06

I thought that it was agreed that the minimum version of binutils would be at least 2.15.90.0.2? The fix for this requires a newer version? make[1]: Entering directory `/home/alex/src/OpSys/reactos' [GAS] ntoskrnl/ex/i386/interlck_asm.S ntoskrnl/ex/i386/interlck_asm.S: Assembler messages: ntoskrnl/ex/i386/interlck_asm.S:440: Error: Unrecognized token `|0x4000' ntoskrnl/ex/i386/interlck_asm.S:459: Error: Unrecognized token `| 0x4000)' ntoskrnl/ex/i386/interlck_asm.S:459: Error: Unexpected token `' ntoskrnl/ex/i386/interlck_asm.S:508: Error: Unrecognized token `| 0x4000)' ntoskrnl/ex/i386/interlck_asm.S:508: Error: Unexpected token `' ntoskrnl/ex/i386/interlck_asm.S:527: Error: Unrecognized token `| 0x4000)' ntoskrnl/ex/i386/interlck_asm.S:527: Error: Unexpected token `' make[1]: *** [obj-i386/ntoskrnl/ex/i386/interlck_asm.o] Error 1 -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

3 8

Different problem with fastinterlck_asm.S ;-(
by Alex Buell 02 Jan '06

02 Jan '06

[GAS] ntoskrnl/ex/i386/fastinterlck_asm.S ntoskrnl/ex/i386/fastinterlck_asm.S: Assembler messages: ntoskrnl/ex/i386/fastinterlck_asm.S:408: Error: suffix or operands invalid for `cmpxchg8b' ntoskrnl/ex/i386/fastinterlck_asm.S:452: Error: suffix or operands invalid for `cmpxchg8b' ntoskrnl/ex/i386/fastinterlck_asm.S:492: Error: suffix or operands invalid for `cmpxchg8b' ntoskrnl/ex/i386/fastinterlck_asm.S:626: Error: suffix or operands invalid for `cmpxchg8b' ntoskrnl/ex/i386/fastinterlck_asm.S:658: Error: suffix or operands invalid for `cmpxchg8b' make[1]: *** [obj-i386/ntoskrnl/ex/i386/fastinterlck_asm.o] Error 1 -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

5 8

Happy New Year!
by Casper Hornstrup 02 Jan '06

02 Jan '06

Happy New Year to you all! 2005 was a great year for ReactOS. The core ReactOS code base is now 120MB large. The repository is currently 624MB large and contains ~20500 revisions. ~8000 of these revisions were created in 2005. This mean 39% of the total number of revisions created during ReactOS' entire 8 year history was created in 2005! I'm positive that we will see similar growth (if not more) in 2006. Keep up the good work! Best regards, Casper

5 4

WineFile Tile Window Problem
by James Tabor 02 Jan '06

02 Jan '06

Hi, Can anyone test revision 20525 and select more than one drive and select Tile. After multiple time selecting cascade and tile it becomes lost! Thanks, James Debug info, (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (./subsys/win32k/ntuser/timer.c:157) Unable to locate timer in message queue (./subsys/win32k/ntuser/timer.c:92) Invalid window handle MDITile (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (./subsys/win32k/ntuser/timer.c:157) Unable to locate timer in message queue (./subsys/win32k/ntuser/timer.c:92) Invalid window handle MDICascade (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (./subsys/win32k/ntuser/timer.c:157) Unable to locate timer in message queue (./subsys/win32k/ntuser/timer.c:92) Invalid window handle (./subsys/win32k/ntuser/timer.c:157) Unable to locate timer in message queue (./subsys/win32k/ntuser/timer.c:92) Invalid window handle (./subsys/win32k/ntuser/timer.c:157) Unable to locate timer in message queue (./subsys/win32k/ntuser/timer.c:92) Invalid window handle MDITile (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsys/win32k/ntuser/message.c:1121) Failed to copy message to kernel: invali d usermode buffer

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev