- Ros-dev - ReactOS.org

RE: [ros-svn] [weiden] 19755: remove obsolete shutdown tool from rosapps

by Ge van Geldorp

> From: weiden(a)svn.reactos.com > > remove obsolete shutdown tool from rosapps Didn't even know that it was there... Thanks for cleaning up. GvG

19 years, 9 months

2
1
0 0

accessing dereferenced file objects

by Hartmut Birr

Hi, looking through our file functions, we do always access a file object after it was dereferenced by the completion routine and if the FO_SYNCHRONOUS_IO flag is set. If FO_SYNCHRONOUS_IO is set, the completion routine should not dereference the file object or we have to add an additional reference. If FO_SYNCHRONOUS_IO is set, we have also to dereference the file object after calling the driver. - Hartmut

19 years, 9 months

1
0
0 0

Re: [ros-svn] [frik85] 19758: RosCMS Update:

by TwoTailedFox

Thanks a barrel load, Frik. That's fixed a few bugs that have been a pain in the arse On 11/29/05, frik85(a)svn.reactos.com <frik85(a)svn.reactos.com> wrote: > RosCMS Update: > > admin_dyncontent_edit.php: "update bug" fixed > generate_page.php: page generation by translations works now the correct way > > > Updated files: > trunk/web/reactos.org/htdocs/roscms/inc/admin_dyncontent_edit.php > trunk/web/reactos.org/htdocs/roscms/inc/generate_page.php > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn > -- "I had a handle on life, but then it broke"

19 years, 9 months

1
0
0 0

Re: [ros-diffs] [ion] 19742: - Implement RtlPrefectMemoryNonTemporal. Patch by Patrick Baggett <baggett.patrick@gmail.com> and myself.

by Thomas Weidenmueller

ion(a)svn.reactos.com wrote: > - Implement RtlPrefectMemoryNonTemporal. Patch by Patrick Baggett <baggett.patrick(a)gmail.com> and myself. > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/rtl/mem.c* > > --- trunk/reactos/lib/rtl/mem.c 2005-11-29 01:54:33 UTC (rev 19741) > +++ trunk/reactos/lib/rtl/mem.c 2005-11-29 02:40:18 UTC (rev 19742) > @@ -140,7 +140,7 @@ > > } > > /* > > -* @unimplemented > > +* @implemented > > */ > VOID > FASTCALL > @@ -149,7 +149,9 @@ > > IN SIZE_T Length > ) > { > > - UNIMPLEMENTED; > > + /* By nature of prefetch, this is non-portable. */ > + (void)Source; > + (void)Length; > > } > > > Why have a function stub then? This just encourages someone to use it without #ifdef'ing it when porting to another platform. - Thomas

19 years, 9 months

2
2
0 0

Revision: 19742

by James Tabor

(./ntoskrnl/ke/main.c:295) ----------------------------------------------------- ---------- (./ntoskrnl/ke/main.c:296) ReactOS 0.3-SVN (Build 20051129-r19742) Used memory 1015744Kb (./ntoskrnl/mm/mminit.c:386) Kernel Stack Limits. InitTop = 0x80122000, Init = 0 x8011f000 (./ntoskrnl/mm/mm.c:283) No current process (./ntoskrnl/io/driver.c:1294) Driver 'buslogic.sys' load failed, status (c000000 1) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\d rivers\sndblst.sys (Status 0xc0000034) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\d rivers\mpu401.sys (Status 0xc0000034) (./ntoskrnl/io/disk.c:630) RDiskCount 1 Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0x800affb4 could not be written: Page protection violation. kdb:>bt Eip: <ntoskrnl.exe:d7e9c (ntoskrnl/ke/i386/kernel.c:525 (Ki386SetProcessorFeatures))> Frames: <ntoskrnl.exe:ccdd3 (./ntoskrnl/ex/init.c:0 ())> <ntoskrnl.exe:cd87e (./ntoskrnl/ex/init.c:672 (ExpInitializeExecutive))> <ntoskrnl.exe:63d5 (./ntoskrnl/ke/main.c:106 (KiSystemStartup))> <ntoskrnl.exe:cb851 (./ntoskrnl/ke/main.c:300 (_main))> <ntoskrnl.exe:104b (ntoskrnl/ke/i386/main_asm.S:46 (NtProcessStartup))> (lib/rtl/i386/exception.c:90) Invalid exception frame Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0x000764e0 could not be read: Page not present. 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,0x800c939c,0x00000000,0x000764e0) *** ntoskrnl.exe - Address 0x800c939c base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:800c939c <ntoskrnl.exe:c939c (lib/string/i386/memcpy_asm.s :43 (memcpy))> cr2 764e0 cr3 22000 Proc: 81004ba0 Pid: 4 <System> Thrd: 81005630 Tid: 0 DS 23 ES 23 FS 30 GS 0 EAX: 8011b1d4 EBX: 800aee40 ECX: 00000004 EDX: 8011b130 EBP: 8011b124 ESI: 000764e0 ESP: 8011b0a8 EDI: 8011b1d4 EFLAGS: 00210002 kESP 8011b0a8 kernel stack base 80118260 Frames: <ntoskrnl.exe:a2f00 (ntoskrnl/kdbg/kdb.c:1557 (KdbpSafeReadMemory))> <ntoskrnl.exe:a3e49 (ntoskrnl/kdbg/kdb_cli.c:570 (KdbpCmdBackTrace))> <ntoskrnl.exe:a72c8 (ntoskrnl/kdbg/kdb_cli.c:2178 (KdbpDoCommand))> <ntoskrnl.exe:a7402 (ntoskrnl/kdbg/kdb_cli.c:2237 (KdbpCliMainLoop))> <ntoskrnl.exe:a2453 (ntoskrnl/kdbg/kdb.c:1119 (KdbpCallMainLoop))> <ntoskrnl.exe:a0b1d (ntoskrnl/kdbg/i386/kdb_help.S:134 (KdbpStackSwitchAndCall)) > <ntoskrnl.exe:a24e1 (ntoskrnl/kdbg/kdb.c:1150 (KdbpInternalEnter))> <ntoskrnl.exe:a2c96 (ntoskrnl/kdbg/kdb.c:1457 (KdbEnterDebuggerException))> <ntoskrnl.exe:53adb (./ntoskrnl/kd/kdmain.c:127 (KdpEnterDebuggerException))> <ntoskrnl.exe:9782d (ntoskrnl/ke/i386/exp.c:1226 (KiDispatchException))> <ntoskrnl.exe:9639f (ntoskrnl/ke/i386/exp.c:194 (KiKernelTrapHandler))> <ntoskrnl.exe:af0a4 (ntoskrnl/mm/i386/pfault.c:128 (KiPageFaultHandler))> <ntoskrnl.exe:9aab1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <ntoskrnl.exe:d7e9c (ntoskrnl/ke/i386/kernel.c:525 (Ki386SetProcessorFeatures))> <ntoskrnl.exe:ccdd3 (./ntoskrnl/ex/init.c:0 ())> <ntoskrnl.exe:cd87e (./ntoskrnl/ex/init.c:672 (ExpInitializeExecutive))> <ntoskrnl.exe:63d5 (./ntoskrnl/ke/main.c:106 (KiSystemStartup))> <ntoskrnl.exe:cb851 (./ntoskrnl/ke/main.c:300 (_main))> <ntoskrnl.exe:104b (ntoskrnl/ke/i386/main_asm.S:46 (NtProcessStartup))> Entered debugger on embedded INT3 at 0x0008:0x800b0076. (lib/rtl/i386/exception.c:90) Invalid exception frame

19 years, 9 months

2
2
0 0

Freeldr crash - real hw - INVALID OPCODE

by David Kredba

Hello. I am trying to boot ReactOS by freeldr on floppy from SCSI harddrive (80h) on an aic78xx. Freeldr loads and display Welcome message. I run Reactos HardDrive (C:) and got : An error occured in FreeLoader FreeLoader v2.1 Report this ... Exception 06: INVALID OPCODE EAX:00000001 ESP:0000FEFC CR0:00000011 DR0:00000000 EBX:2046C700 EBP:C7000000 CR1:00000000 DR1:00000000 ECX:00000000 ESI:FFFFFFFF CR2:00000000 DR2:00000000 EDX:00000001 EDI:002846C7 CR3:00000000 DR3:00000000 DR6:FFFF0FF0 DR7:00000400 CS:0008 EIP:FFFF2C46 DS:0010 ERROR CODE:00000000 ES:0010 EFLAGS:00010016 FS:0010 GDTR Base:0000842C Limit:0027 GS:0010 IDTR Base:000086E0 Limit:0100 SS:0010 LDTR:0000 TR:0000 Frames: Nothing more displayed. Computer is Dual PIII machine, Reactos is todays svn version builded on linux with mingw, 512 MB RAM. There is w2k server on second partition of the SCSI harddrive and boots and runs without errors. First partition is 4 GB FAT32, disk capacity is 18GB. Thank you. David

19 years, 9 months

1
0
0 0

'make clean' errors

by WaxDragon

Anyone else seeing this under linux? Detecting netwide assembler...detected (nasm) Detecting compiler -pipe support...detected Detecting compiler pre-compiled header support...detected Processing modules...done Creating directories...done Unpacking WINE resources...done Generating test support code...done Generating compilation unit support code...done Generating syssetup.inf...done Generating proxy makefiles...done Checking automatic dependencies...done [CC] tools/cdmake/cdmake.c [CC] tools/cdmake/llmosrt.c [LD] output-i386/tools/cdmake/cdmake [LD] output-i386/tools/mkhive/mkhive gcc: obj-i386/lib/inflib_host/infcore.o: No such file or directory gcc: obj-i386/lib/inflib_host/infget.o: No such file or directory gcc: obj-i386/lib/inflib_host/infput.o: No such file or directory gcc: obj-i386/lib/inflib_host/infhostgen.o: No such file or directory gcc: obj-i386/lib/inflib_host/infhostget.o: No such file or directory gcc: obj-i386/lib/inflib_host/infhostglue.o: No such file or directory gcc: obj-i386/lib/inflib_host/infhostput.o: No such file or directory make: *** [output-i386/tools/mkhive/mkhive] Error 1 WD -- <mikedep333> but if it isnt working, why is it even included on the CD?

19 years, 9 months

4
3
0 0

GPL Microsoft Code in the CRT

by Steven Edwards

Hi, There is some code in the C Runtime that was part of the Win32 port of perl. As such it carries the copyright Microsoft. I suggest we remove and rewrite these functions, as this will hinder us from being able to say "ReactOS is 100% free of Microsoft Code" Even if it is GPL it does not sit well with me. Anyone up to help on this? -- 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

19 years, 9 months

8
13
0 0

RE: [ros-diffs] [sedwards] 19675: XML.cpp -> xml.cpp, XML.h -> xml.h.

by Casper Hornstrup

If the rule is always lowercase filenames why not vote on it and make it official and save ourselves some trouble in the future? Casper

19 years, 9 months

2
3
0 0

Possible Compiler/Library problem?

by TwoTailedFox

http://neowin.ath.cx/twotailedfox/Error.png Can anyone help me shed some light on this rather perculiar error? GCC 3.4.4/G++ 3.4.2, MSYS 1.0, GNU Make 3.80, NASM 0.98, Binutils 2.16.91, MinGW 4.1.0 -- "I had a handle on life, but then it broke"

19 years, 9 months

1
0
0 0

Re: [ros-diffs] [sedwards] 19673: more crt, crtdll and msvcrt cleanup

by Thomas Weidenmueller

sedwards(a)svn.reactos.com wrote: > more crt, crtdll and msvcrt cleanup > +#include "precomp.h" That doesn't work, it should be <precomp.h>.... - Thomas

19 years, 9 months

2
1
0 0

Re: [ros-svn] [ion] 19693: - Remove KTSS_NOIOMP from NDK.

by Alex Ionescu

ion(a)svn.reactos.com wrote: >- Remove KTSS_NOIOMP from NDK. >- Fix KTSS definition. >- Fix KTRAP_FRAME definition. >- Fix RTL_PROCESS_BACKTRACE_INFORMATION and RTL_PROCESS_BACKTRACES definitions. >- Fix/rename RUNDOWN_DESCRIPTOR definition. >- Rename PPF_ definitions to RTL_USER_PROCESS_PARAMETERS_ >- Setup a global _REACTOS_ define when code is compiled. >- #ifdef out the multiboot flags from the NDK so they'll only be available for ReactOS. Dirty 'hack' until we stop using them. >- Update NDK Fixme list, since all major bugs are fixed now. > > > > Hi, Sorry, this breaks compiling. I think there is a bug in compilation units. I did make ntoskrnl_clean about 3 times, and even a complete "make depends -j2" and it compiled the whole tree fine. Then I started doing other changes, and I started getting build failures. Best regards, Alex Ionescu

19 years, 9 months

2
2
0 0

Do it right first time ??

by Biera Gaino

It seems to me that is always best to do it right first time. Then it is easier to get quality, Well anyway it is my opinion. Like the Japanese car manufacturers discovered first, that is always best to track down and solve problems in early stage, than later...... Bierá L. gaino

19 years, 9 months

3
2
0 0

Re: [ros-diffs] [ion] 19666: - Add DDK alignment macros and move/rename the ones in the NDK for user-mode only (since kernel-mode should use the DDK ones).

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Add DDK alignment macros and move/rename the ones in the NDK for user-mode only (since kernel-mode should use the DDK ones). > - Fix helper.h's alignment macros to protect properly and also use a faster implementation. > - Update NDK readme. > Modified: trunk/reactos/include/ndk/lpctypes.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/include/ndk/lpctypes.h* > --- trunk/reactos/include/ndk/lpctypes.h 2005-11-26 23:26:04 UTC (rev 19665) > +++ trunk/reactos/include/ndk/lpctypes.h 2005-11-27 02:55:13 UTC (rev 19666) > @@ -234,9 +234,9 @@ > // Maximum total Kernel-Mode LPC Message Structure Size > // > #define LPCP_MAX_MESSAGE_SIZE \ > > - ROUND_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \ > > + ALIGN_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \ > > sizeof(LPCP_MESSAGE) + \ > > - sizeof(LPCP_CONNECTION_MESSAGE), 16) > > + sizeof(LPCP_CONNECTION_MESSAGE), sizeof(ULONGLONG) * 2) > > > // > // Maximum actual LPC Message Length > > ------------------------------------------------------------------------ This or the definition of ALIGN_UP is wrong. ALIGN_UP needs a type as second parameter. Now the value of LPCP_MAX_MESSAGE_SIZE, LPC_MAX_MESSAGE_LENGTH and LPC_MAX_DATA_LENGTH are changed. ReactOS won't boot because csrss uses hard coded values in CsrpCreateListenPort. - Hartmut

19 years, 9 months

3
3
0 0

Re: [ros-dev] [Vote] Top-level source header

by Brandon Turner

Only developers can vote. Brandon Alex Buell wrote: > On Sun, 27 Nov 2005, Casper Hornstrup wrote: > >> http://www.reactos.org/forum/viewtopic.php?p=10398#10398 > > > Since I cannot vote (even though I've signed up), I'll stand up and > say I'd vote for option B if I could. >

19 years, 9 months

1
0
0 0

Re: [ros-diffs] [turner] 19669: Don't hardcode user to .DEFAULT when reading registry

by Thomas Weidenmueller

turner(a)svn.reactos.com wrote: > Don't hardcode user to .DEFAULT when reading registry > > Modified: trunk/reactos/subsys/win32k/ntuser/misc.c > + NtClose(CurrentUserKey); This needs to be ZwClose - Thomas

19 years, 9 months

1
0
0 0

Debian win32 port, file system, installer, ELF

by Drew Scott Daniels

Hi, For background in the Debian win32 port see the mailing list archives [1]. Basically, the only reason the port is allowed by Debian is that it could run on ReactOS or wine which are both DFSG [2] compliant. Microsoft Windows, OS/2... aren't DFSG compliant. I've read [3] that the Debian win32 ports "failed because most unix software made unforgivable presumptions about file system semantics; mainly that you could delete files that were in-use, and rename open files on top of other open files, etc." Is this something that could be resolved? I'd imagine the Installable File System (IFS) driver would need to be modified to remember open files, or perhaps something could intercept calls to an IFS driver? I think this is what some virus scanners do, and what clamav is missing. Porting Debian to ReactOS would give ReactOS a huge number of packages. The BSD ports collection method or gentoo's build systems may be useful too. All three would probably mean porting some base software though. Any comments about porting the base of another OS to ros? Packages like perl, bash, gcc, glibc seem to have native MS Windows ports. http://packages.debian.org/stable/base/ lists all the various packages in Debian's base (note some are specific to various ports, and there are some semi-duplicated packages). Another advantage of a Debian win32 port using ReactOS would be a really nice flexible, modular installer (debian-installer or d-i for short). I've had problems with the ros installer in the past, specifically I couldn't install on one system without a mouse. It also asked many questions, couldn't resize partitions... d-i is nice in that it can be used with about three prompts, has partition resizing, can download additional modules... I'd suggest checking it out (I feel like I'm starting to just advertise it). Fwiw, longhorn seems to boot from a CD to do it's graphical install that is supposed to have file system resizing. Can/does ReactOS support ELF? Alex Ionescu said that there's now an ELF loader [4]. If so, would there be anything special that would need to be done to run Linux binaries on ReactOS (beyond syscalls and porting dependencies)? Is there any advantages to the PE format? If ReactOS could support running Linux binaries it would be an easier sell to port Debian to ReactOS as it could reuse things that are already compiled for Debian. I believe the FreeBSD port (kFreeBSD that is) [5] re-uses some packages compiled for Linux. OTOH, PE would be a nicer way to go so that some support for MS Windows could be allowed... Or could MS Windows be made to support ELF? I'm afraid I also don't know much about the coff format. [1] http://lists.debian.org/debian-win32/ [2] http://www.debian.org/social_contract#guidelines (very similar or the same as the OpenSource definition) [3] http://lists.debian.org/debian-win32/2005/10/msg00003.html Message-id: <43663BFE.9010004(a)liddicott.com> [4] http://www.reactos.org/bugzilla/show_bug.cgi?id=293 [5] http://www.debian.org/ports/kfreebsd-gnu/ Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html

19 years, 9 months

3
2
0 0

Re: [ros-diffs] [chorns] 19566: Speed up compilation of ntoskrnl

by Alex Ionescu

Hi, Do these changes break the MSVC backend? Best regards, Alex Ionescu

19 years, 9 months

6
10
0 0

DOSemu for ReactOS

by crashfourit

Could we port DOSemu (http://www.dosemu.org/) to ReactOS for Dos and Win16 support? -- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/

19 years, 9 months

4
5
0 0

Registry is messed up

by Brandon Turner

I think the registry is messed up. desk.cpl isnt writing the wallpaper style values, SystemParametersInfoW isnt wrtiting the path, and IntSystemParametersInfo isnt able to read the wallpaper settings from it. Also, my livecd wont boot with an error about not finding the codepage. This all leads me to believe that something is up with the registery. The last update i have is w3seek's where he reverted filip's registry changes. I dont know when this started happening, last day or so. It all worked fine when i commited 19476. Royce: The reason you werent getting the bugcheck with my stretch patch was because desk.cpl wasnt writing the wallpaper style values to the registry and tat is why the wallpaper didnt stick. I'm kinda busy right now. But hopfully within an hour I will be free and be able to do some more debuging. Brandon

19 years, 9 months

1
1
0 0

Re: [ros-diffs] [gvg] 19572: Implement adding new sections/lines/fields and writing the resulting file

by Hartmut Birr

gvg(a)svn.reactos.com wrote: > Implement adding new sections/lines/fields and writing the resulting file > Added: trunk/reactos/lib/inflib/infhostglue.c > > *Added: trunk/reactos/lib/inflib/infhostglue.c* > --- trunk/reactos/lib/inflib/infhostglue.c 2005-11-25 21:29:16 UTC (rev 19571) > +++ trunk/reactos/lib/inflib/infhostglue.c 2005-11-25 21:37:23 UTC (rev 19572) > @@ -0,0 +1,24 @@ > +/* > + * PROJECT: .inf file parser > + * LICENSE: GPL - See COPYING in the top level directory > + * COPYRIGHT: Copyright 2005 Ge van Geldorp <gvg(a)reactos.org> > + */ > + > +/* INCLUDES *****************************************************************/ > + > +#include "inflib.h" > + > +#define NDEBUG > +#include <debug.h> > + > +void > +DbgPrint(const char *Fmt, ...) > +{ > + va_list Args; > + > + va_start(Args, Fmt); > + vfprintf(stderr, Fmt, Args); > + va_end(Args); > +} > + > +/* EOF */ > It is a little bit dirty to implement a well known function in a different way. - Hartmut

19 years, 9 months

2
3
0 0

Re: [ros-dev] Log off reboots!

by TwoTailedFox

In Short, A Lot. ReactOS needs a proper shutdown and restart sequence (Like Linux does, when it sends TERM to all processes). Log Off is a tad harder. In order for Log Off to work properly, all the core processes need to be kept running (csrss, winlogon, etc), and the system needs to "Fall back" to a login screen. To do this, a User Logon System must be implemented, complete with per-user registry files, settings storage, and all the associated functions therein. AFAIK. On 11/26/05, Alex Buell <alex.buell(a)munted.org.uk> wrote: > On Fri, 25 Nov 2005, TwoTailedFox wrote: > > > No, the Shutdown/Restart and Log Off portions are in need of a > > re-write, AFAIK. Since Local User Accounts are not implemented yet, we > > cannot "Log Off" per se on ReactOS just yet. > > Ok, what needs doing to implement this properly? I'd like to help if I > can. > > -- > http://www.munted.org.uk > > Anyone that thinks an imaginary deity is going to protect them against > earthquakes and hurricanes needs psychiatric help. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- "I had a handle on life, but then it broke"

19 years, 9 months

3
3
0 0

RE: [navaraf] 19636/19637/19638: Don't make cells smaller than they are.

by Ge van Geldorp

> From: navaraf(a)svn.reactos.com > > Don't make cells smaller than they are. Wow. Isn't it time we factor out the common code in cm, mkhive and freeldr and put it in a static library? GvG

19 years, 9 months

2
1
0 0

Re: [ros-diffs] [navaraf] 19636: Don't make cells smaller than they are.

by Hartmut Birr

navaraf(a)svn.reactos.com wrote: > Don't make cells smaller than they are. > Modified: trunk/reactos/ntoskrnl/cm/regfile.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/cm/regfile.c* > --- trunk/reactos/ntoskrnl/cm/regfile.c 2005-11-26 13:26:48 UTC (rev 19635) > +++ trunk/reactos/ntoskrnl/cm/regfile.c 2005-11-26 15:21:44 UTC (rev 19636) > @@ -3431,7 +3431,7 @@ > > RtlZeroMemory(*Cell, > CellSize); > > - ((PCELL_HEADER) (*Cell))->CellSize = -CellSize; > > + ((PCELL_HEADER) (*Cell))->CellSize *= -1; > > } > > return STATUS_SUCCESS; > This change is wrong. Possible we have split the cell. In this case, we have to set the new cell size. - Hartmut

19 years, 9 months

1
0
0 0

RE: [ros-svn] [chorns] 19566: Speed up compilation of ntoskrnl

by Ge van Geldorp

> From: chorns(a)svn.reactos.com > > Speed up compilation of ntoskrnl Hmm, an unexpected consequence is that we can no longer enable DPRINTs per file by removing the "#define NDEBUG" statement. At the moment, the first source files included by io.c and cc.c (resp io/adapter.c and cc/cacheman.c) don't define NDEBUG before including debug.h. As a result, all DPRINTs in every file included by io.c/cc.c are enabled. GvG

19 years, 9 months

3
3
0 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