Ros-dev January 2006

ros-dev@reactos.org

69 participants
136 discussions

Re: [ros-diffs] [jimtabor] 20609: Should have placed extern in there.

by Thomas Weidenmueller

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

18 years, 8 months

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

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

18 years, 8 months

Project Status Report

by Steven Edwards

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

18 years, 8 months

servman.rc

by Alex Buell

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.

18 years, 8 months

Build 20583 bluescreens

by Alex Buell

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.

18 years, 8 months

Build 20583 blows up with the following

by Alex Buell

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.

18 years, 8 months

RE: [ion] 20554: - Fix shamefully dangerously broken WorkThread/Queue/Item implementation:

by Ge van Geldorp

> 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

18 years, 8 months

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

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

18 years, 8 months

tools/rbuild/backend/mingw/modulehandler.h

by Reuben Perelman

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;'?

18 years, 8 months

Optimization Proposal

by Alex Ionescu

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

18 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2006