Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Andreas M. <an...@rh...> - 2002-04-28 20:41:29
|
On Sun, Apr 28, 2002 at 01:15:17PM -0700, Francois Gouget wrote: > On Sun, 28 Apr 2002, Robert Collins wrote: > [...] > > > 4. add -liberty to the makefile for wrc and wmc. This is > > > needed because of getopt and optarg > > > > Cygwin has a BSD licenced getopt.c that doesn't need libiberty to link, > > only mingw (AFAIK). Anyway worth investigating? > > I usually regard getopt functions as higly unportable and always try > to avoid them. I did not check how they are used in wrc&co, but it > should not be very difficult to do entirely without them. I believe that > would be the best solution. Yep, probably, given getopt()s slightly dainbramaged way of handling commands with or without spacing. It's only sooo often a major annoyance ! (witness e.g. the current wineinstall "su" mess) But OTOH command line handling/spacing issues are a difficult thing, so maybe it's not even getopt that's to blame, because it's difficult per se. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/ |
|
From: Brian P. <br...@sg...> - 2002-04-28 20:28:42
|
Modified files:
freeldr/fs/fat.c
Added files:
CHANGELOG
Log Message:
Fixed FAT short file name buffer overflow that was causing some long
filenames not to work correctly.
|
|
From: Francois G. <fg...@fr...> - 2002-04-28 20:15:38
|
On Sun, 28 Apr 2002, Robert Collins wrote: [...] > > 4. add -liberty to the makefile for wrc and wmc. This is > > needed because of getopt and optarg > > Cygwin has a BSD licenced getopt.c that doesn't need libiberty to link, > only mingw (AFAIK). Anyway worth investigating? I usually regard getopt functions as higly unportable and always try to avoid them. I did not check how they are used in wrc&co, but it should not be very difficult to do entirely without them. I believe that would be the best solution. -- Francois Gouget fg...@fr... http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95 |
|
From: KJK::Hyperion <no...@li...> - 2002-04-28 15:56:50
|
At 09.50 28/04/2002, you wrote:
>For instance, "A:" is meaningful only in the W32 subsystem, because when
>you type
>C:\> type A:\README.TXT
>KERNEL32.CreateFile("A:\README.TXT") will call internally
>NTDLL.NtCreateFile("\??\A:\README.TXT")
>which will be translated in
>\Device\Floppy0\README.TXT
>because "\??\A:" is a symbolic link in the system name space to that
>device object.
what about paths starting with one or two (back-)slashes? I think those, as
far as possible, should be portable, that is translate to the same path in
all subsystems. It's the only way we can guarantee interoperability
>For the PSX subsystem, we could define that "/dev/x" will be translated by
>PSXDLL.DLL into "\POSIX+\SYSTEM\x" and PSXSS.EXE, at initialization time,
>will create symbolic links in "\POSIX+\SYSTEM" to real devices.
if it's not a real directory it shouldn't appear like a real directory.
Until we have a filesystem that can host a true /dev directory, better use
a double-slash path for such virtual directories, like //./dev/ or similar.
The Single Unix Specification (SUS) as of version 3 allows double-slash
paths with implementation-specific meaning, and Win32 accepts double-slash
paths too. /dev in itself is not defined by the SUS, it is by Filesystem
Hierarchy Standard (FHS), but we're far from being able to implement it
fully anyway
|
|
From: Eric K. <ek...@rz...> - 2002-04-28 15:46:01
|
"KJK::Hyperion" <no...@li...> wrote: > >Probably the LGPL ((lesser|library) gnu public licence) is more suitable > >for the 'publicly linkable' libraries, and let everything that is run in > >kernel-mode be GPL. > > ok, but where do you draw the line? device drivers use the kernel and HAL > as runtime DLLs, what parts of ntoskrnl.exe and hal.dll are public and what > are private? and what about non-kernel stuff? like the subsystems? We don't have to draw a line. The dynamic linking of binaries (.exe, .dll, .sys files) is entirely irrelevant to the license discussion. The only important fact is that we cannot exclude third-party developers from building non-GPL'd binaries (applications, drivers, dlls) for ReactOS. So we have to make sure they can build these binaries without having to GPL their 'property'. Now what do you need to build a binary? You need header files, import libraries and perhaps some documentation. So these must not be GPL'd. Personally I don't care if they are LGPL'd or in the public domain. Everything else is MS FUD. According to the great Craig Mundie, William Henry Gates III (aka Bill) must be GPL'd as soon as someone runs a GPL'd program on an MS Windows Operating System. In this case everyone was allowed to clone Billy-Boy. But actually I don't think anyone would want to do that. ;-) Eric |
|
From: Eric K. <ek...@rz...> - 2002-04-28 15:33:17
|
"Steven Edwards" <Ste...@ya...> wrote: > We should license the system utils as LGPL such as regedit, resrv, and > others so the wine project can make use of them. I don't agree with this. IMO the whole ReactOS-project should be GPL'd. The author of a driver, dll or utility is always free to relicense his code to the Wine project under the LGPL or X11 license. Eric |
|
From: KJK::Hyperion <no...@li...> - 2002-04-28 10:38:32
|
At 19.33 26/04/2002, you wrote: >Probably the LGPL ((lesser|library) gnu public licence) is more suitable >for the 'publicly linkable' libraries, and let everything that is run in >kernel-mode be GPL. ok, but where do you draw the line? device drivers use the kernel and HAL as runtime DLLs, what parts of ntoskrnl.exe and hal.dll are public and what are private? and what about non-kernel stuff? like the subsystems? |
|
From: Aliberti E. <ea...@us...> - 2002-04-28 07:52:48
|
It may be a FAQ or a trivial question. What are the file dependencies and "must be there" files for booting with loadros? What are the minimum parameters to pass to loadros? |
|
From: Aliberti E. <ea...@us...> - 2002-04-28 07:49:27
|
It seems this one got lost at listserver switch. I resend it now.
------- Forwarded message follows -------
From: Aliberti Emanuele <ea...@us...>
To: <ros...@re...>
Subject: Re: [ros-general] Re: File system struct
Date sent: Sun, 14 Apr 2002 15:19:17 +0200
On 14 Apr 2002 at 0:11, Yuri Prokushev wrote:
> >my term virtual dir is different from a symbolic link. a virtual
> >dir doesn't exist in the FS but only in the brain of the ss
> Doesn't matter. Virtual dir - it is like doscalls.dll. Handled by
> subsystem services.
Oh, it does really matter instead!
Do not forget that what a process running in the context of an
environment subsystem CAN see is what the subsystem client library
and
server want (unless it calls the native API bypassing the host
subsystem).
For instance, "A:" is meaningful only in the W32 subsystem, because
when you type
C:\> type A:\README.TXT
KERNEL32.CreateFile("A:\README.TXT") will call internally
NTDLL.NtCreateFile("\??\A:\README.TXT")
which will be translated in
\Device\Floppy0\README.TXT
because "\??\A:" is a symbolic link in the system name space to that
device object.
For the PSX subsystem, we could define that "/dev/x" will be
translated by PSXDLL.DLL into "\POSIX+\SYSTEM\x" and PSXSS.EXE, at
initialization time, will create symbolic links in "\POSIX+\SYSTEM"
to
real devices.
That will allow a PSX process to call open("/dev/tty0") with no real
"/dev" directory on any physical volume. PSXDLL.open will translate
"/dev/tty0" in "\POSIX+\SYSTEM\tty0" which probably will be a link to
"\Device\Serial0".
------- End of forwarded message -------
|
|
From: Robert C. <rob...@it...> - 2002-04-28 05:42:29
|
> -----Original Message----- > From: Steven Edwards [mailto:Ste...@ya...]=20 > Sent: Sunday, April 28, 2002 2:35 PM > 2. run ./configure --host=3Dmingw32 --target=3Dmingw32=20 > --build=3Dmingw32 CFLAGS=3D"-D_MINGW_ -D_WINDOWS -DWINE_NOWINSOCK" You should probably add CC=3D"gcc -mno-cygwin" CXX=3D"gcc -mno-cygwin" to the configure line if = you don't have a mingw cross compiler installed. =20 > 4. add -liberty to the makefile for wrc and wmc. This is=20 > needed because of getopt and optarg Cygwin has a BSD licenced getopt.c that doesn't need libiberty to link, only mingw (AFAIK). Anyway worth investigating? =20 Rob |
|
From: Steven E. <Ste...@ya...> - 2002-04-28 04:34:18
|
Note: send any spelling/grammer errors to /dev/null. I've compiled a little list of things that are still lacking on the port of wine to mingw/msys/cygwin. Unless I mention cygwin as the target it can be assumed for the purpose of this doc I am speaking about a mingw target. About 5 or 6 months ago James Tablor and Casper Hornstroup ported wine to Mingw for ReactOS. ReactOS is very close to having basic Windowing support so I have set out to compleate the work they have started by bringing the wine/Rewind trees up to speed with our changes. The current wine build system still has a few things Missing before we can build without needing the reactos source tree/makefiles. Note: I have ordered the list by importance and the steps needed to build. 1. Make configure changes to build wine support under mingw/cygwin. Currently configure Has issues detecting how it should build the wine files as either dlls,so or .a I have submitted a patch for this but it was rejected because it was just a work-around And did not fix the problem. You will need to still run ./configure under cygwin as dlltool/wrap do not detect properly under msys with configure. With the current port in the ReactOS source tree we use our own Makefiles/resources and I would like to get away from this. 2. run ./configure --host=mingw32 --target=mingw32 --build=mingw32 CFLAGS="-D_MINGW_ -D_WINDOWS -DWINE_NOWINSOCK" 3. Remove winedump from the tools/Makefile as Mingw/Cygwin and others have support for dumping PE executable information and it is loaded with Unixisms. 4. add -liberty to the makefile for wrc and wmc. This is needed because of getopt and optarg 5. add a configure check to #define snprintf _snprintf for wrc when building with mingw. 6. Remove server, library and tsx11 for mingw. If you want to build wineserver under cygwin we will need to adapt get/set thread context from GDB's win32 support. 7. 90% of the source from the dlls compiles with no problems. The issue is when you want to link the objects as a dll and compile in the resources. winebuild now has support to build the *.def files needed for dlltool so there will need to be changes on the way that the spec/def files are used when building on a Win32 host. If one tries to build wine currently under Mingw/Cygwin it will puke when linking to the needed imports because winebuild will try to import from lib*.so rather then from dllname.a I've also been having troble linking with resources compiled with wrc under Mingw/Cygwin. 7. We do not want to build advapi32, Kernel32, ntdll, user32, gdi, msvcrt or crt.dll 8. These are the dlls we know that we can build and need: avicap32, avifile32, comctl32, commdlg, crypt32, ddraw, dinput, dplay, dplayx dsound(needs imports from winmm), imagehlp, lzexpand, mapi32, ole32, oleaut32 olecli, oledlg, olepro32, olesvr, richedit, rpcrt4, serialui, setupapi, shdocvw shell32, shfolder, shlwapi, tapi32, twain, url, urlmon, version, winmm, winspool wintrust. 9. Debugging will be differnt under Windows/ReactOS due to the wine debugger not working. Under ReactOS currently we have all of the FIXMEs and TRACES mapped to our NTDLL as DbgPrnt and others. I'm not 100% sure as to how we are doing this yet. 10. DLL seperation and Wineserver dependace. I wont even really be able to start looking at this untill the 10 issues above are worked out. I know that when I tested programs/dlls from our first wine port under ReactOS there were issues due to a lack of internal wineserver functions. 11. The chain of dependance for the Sound/Graphics for Winmm/DirectX and others will need interfaces developed for the HAL (Codeweavers/Transgamming?) Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Steven E. <Ste...@ya...> - 2002-04-28 03:55:31
|
> PS: by the way: pole of a streetlight? :-D He only likes talking to them after I run in to them when sending patches In to the wine project =P. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Hartmut B. <har...@te...> - 2002-04-27 19:25:14
|
lib\kernel32\file\create.c: lib\kernel32\file\delete.c: Fixed a memory leakage in CreateFileW/DeleteFileW. lib\kernel32\file\curdir.c: Added a trailing '\' to the directory in GetTempPathW. lib\kernel32\file\file.c: Made GetTempFileNameA/W workable. lib\kernel32\file\move.c: Moved CloseFile within MoveFileExW. lib\msvcrt\stdio\tempnam.c: Fixed a minor bug. lib\msvcrt\sys_stat\fstat.c: Removed S_IFREG for files. aboot.bat: boot.bat: loaders\dos\loadros.asm: Moved '/DEBUGPORT=SCREEN' from loadros to (a)boot.bat. ntoskrnl\io\cleanup.c: ntoskrnl\io\file.c: Moved dereferencing of file objects to IoSecondStageCompletion(). ntoskrnl\io\dir.c: ntoskrnl\io\page.c: ntoskrnl\io\rw.c: Fixed the test for FO_SYNCHONOUS_IO. ntoskrnl\io\fs.c: ntoskrnl\io\ioctrl.c: Changed to event object from file object. ntoskrnl\io\vpb.c: Added IoFileObjectType to ObReferenceObjectByHandle. If the function is not called with a file handle, there occures a page fault. Moved dereferencing of the file object to IoSecondStageCompletion(). ntoskrnl\ldr\loader.c: Added npfs.sys to the automatic loaded drivers. ntoskrnl\mm\mdl.c: Fixed a bug in MmUnmapLockedPages. ntoskrnl\ps\kill.c: Added seting of exit status in NtTerminateProcess. services\fs\vfat\dirwr.c: Fixed a bug in findDirSpace(). lib\kernel32\process\create.c: Added support for bat/cmd files. Added support for shell piping. - Hartmut |
|
From: KJK::Hyperion <no...@li...> - 2002-04-27 19:14:48
|
At 03.27 27/04/2002, you wrote: >> - empty, dead directories. I know this is because of limitations of >> CVS, but sure it's annoying >use the -P for the update command prune empty directories. Sounds like "sweeping under the carpet" to me... >> - no separation of Win32 and native applications, libraries and >> services. And they cannot be moved because of, again, CVS limitations >> (AFAIK). What was the name of that other, better version system again? >they can be moved, its just tedious to do so. Care to explain why and how? Most of the guides to CVS I found just say it's tedious but don't explain why >As for the 'better' version control system, I have yet to see one that is >free. Last time I looked at VC options, I found mostly vaporware. If I can >find some time in the near future, I'll take a look at CVS's supposed >competition and see if there is anything even worth experimenting with. Currently, there are Subversion and arch that look promising |
|
From: KJK::Hyperion <no...@li...> - 2002-04-27 19:14:44
|
At 20.23 26/04/2002, you wrote: > > - a TON of duplicated code. We all know the hideous amount of identical C > > runtime functions that MSVCRT, CRTDLL and NTDLL happily implement each by > > its own. MSVCRT and CRTDLL also have duplicated streams (stdio.h) > > libraries. NTDLL and NTOSKRNL contain two distinct duplicates of the RTL. > > In most of these cases even the compiled binary objects could be shared >IMO it is mostly a question of required disk space versus readability. I >don't like to move to another 'common' directory to have a look at a >function which is shared by multiple binaries. My idea was to get some well-known C library and port it to NT/ReactOS. Compiling MSVCRT rather than CRTDLL would then become just a matter of two different makefiles. The best candidate seems RedHat's newlib (the hearth of Cygwin, among others), but just porting it could be a project of its own. Right now I'm stuck between reinventing the wheel for the third time just to have a PSXDLL that at least a hello_world.c would compile against, and going the hard way by porting newlib >Another point is the MSVCRT vs. CRTDLL and NTDLL vs. NTOSKRNL thingy. >These two pairs of binaries seem to share a lot of code but when you have >a close look at them, you will see that they are not the same! For >example, MSVCRT and CRTDLL seem to export the same functions. But they are >*not* the same. MSVCRT should be thread-safe and CRTDLL must not be >thread-safe. Thanks, I didn't know. But newlib should be flexible enough in terms of compilation switches to get any flavor of C library imaginable >The situation is similar for NTDLL and NTOSKRNL. Have a very close look at >the Rtl-functions Can you explain? Maybe I just looked at the wrong files, but they mostly look plain C code to me > > - no separation of Win32 and native applications, libraries and services. > > And they cannot be moved because of, again, CVS limitations (AFAIK). What > > was the name of that other, better version system again? >Agreed! I guess you mean 'arch'. Since you are complaining about CVS, >would you volunteer as an arch-tester and try to find out whether it suits >our needs? I'm reading some arch documentation now. It looks like I'll need to install Cygwin, at last, but I can live with that. Some of the features (for example the support for offline operation through distributed repositories) sound interesting, and some of the concepts too (most of the operations are done on the client side). On the server side it just requires a FTP server. All in all, sounds cool. I just hope it doesn't suffer of the same odd time&date issues of CVS > > - no support for the CodeView symbol format, only the "ancient" textual > > symbol lists >That's not a real issue because gcc can generate much better debugging >information. It's nm that extracts the 'ancient' .sym files. But this means we should provide a debugger at least equivalent to WinDbg... > > - no BUILD utility. This means they have to maintain separatedly a > > makefile for ReactOS and DIRS/FILES files for the Microsoft DDK. >Is there any technical reason to switch to BUILD? IMO, using make is >sufficient because developers will not use the (not yet existing) ReactOS >DDK and the Microsoft DDK at the same time. I don't mean "switching" to build. Just supporting it as a secondary mean of compiling stuff. Maybe just including it in the DDK could be fine >The MS DDK is incomplete and no longer freely available. huh? are you sure about the latter? > > I think I'm done now :-) Hope I didn't sound rude or something > > Comments? >No, you don't sound rude! At least as long as you volunteer for at least one >of the tasks. I definitely want to put an end to the MSVCRT/CRTDLL/NTDLL craze. My pet subproject POSIX+ is pretty much stuck until then. And I think I can help with evaluating arch I'm more interested in converting our build system to a single makefile, but I don't think I have enough experience with make (but, well, I can learn ;-) >Btw, could you consider using your real name on the ReactOS lists? I feel >like I'm talking to the pole of a streetlight. ;-) I don't know, I got so used to this nickname, at the point that most of my friends call me this way (and don't know, or remember, my real name ;-) PS: by the way: pole of a streetlight? :-D |
|
From: Eric K. <ek...@rz...> - 2002-04-27 18:59:47
|
Modified Files:
ntoskrnl/cm/import.c
services/storage/class2/class2.c
Added code to import REG_MULTI_SZ values.
Release MDL on IRP-Completion. Thanks to Hartmut Birr.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-04-27 14:27:24
|
"Hartmut Birr" <har...@te...> wrote: > The call to IoCompletRequest from atapi doesn't free the virtual address > space and the memory from the mdl within the irp. Normaly > IoSecondStageCompletion does call IoReadWriteCompletion for read/write > requests and IoReadWriteCompletion does the job. ScsiClassBuildRequest sets > the function within the irp to IRP_MJ_SCSI and IoReadWriteCompletion is > never called. I have added the necessary code to ScsiClassIoComplete, but > I'm not sure, if this is the right position. There is also a wrong call to > IoMarkIrpPending in ScsiClassReadWrite. You're totally right. I changed my local sources and will commit the changes later. Thanks, Eric Kohl |
|
From: Hartmut B. <har...@te...> - 2002-04-27 10:37:08
|
The call to IoCompletRequest from atapi doesn't free the virtual address space and the memory from the mdl within the irp. Normaly IoSecondStageCompletion does call IoReadWriteCompletion for read/write requests and IoReadWriteCompletion does the job. ScsiClassBuildRequest sets the function within the irp to IRP_MJ_SCSI and IoReadWriteCompletion is never called. I have added the necessary code to ScsiClassIoComplete, but I'm not sure, if this is the right position. There is also a wrong call to IoMarkIrpPending in ScsiClassReadWrite. - Hartmut |
|
From: Steven E. <Ste...@ya...> - 2002-04-27 05:37:43
|
We should license the system utils as LGPL such as regedit, resrv, and others so the wine project can make use of them. I'm not saying this should be a requirement just a recommendation. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson > -----Original Message----- > From: Robert Collins [mailto:rob...@it...] > Sent: Friday, April 26, 2002 10:46 PM > To: Ste...@ya...; ReactOS-Kernel > Subject: RE: [ros-kernel] Possible licensing issues? > > > > > > -----Original Message----- > > From: Steven Edwards [mailto:Ste...@ya...] > > Sent: Saturday, April 27, 2002 12:16 PM > > To: 'ReactOS-Kernel' > > Subject: RE: [ros-kernel] Possible licensing issues? > > > > > > This was something Eric, Jason and I discussed a while back > > in regards to the wine port and driver also. Mabey we should > > do something like this as per Eric Suggestions > > > > Kernel - GPL with the exceptions > > Librarys - LGPL > > Headers - X11/public domain > > Programs - LGPL > > Programs should be GPL surely? > > ROb > |
|
From: Robert C. <rob...@it...> - 2002-04-27 02:46:06
|
> -----Original Message----- > From: Steven Edwards [mailto:Ste...@ya...]=20 > Sent: Saturday, April 27, 2002 12:16 PM > To: 'ReactOS-Kernel' > Subject: RE: [ros-kernel] Possible licensing issues? >=20 >=20 > This was something Eric, Jason and I discussed a while back=20 > in regards to the wine port and driver also. Mabey we should=20 > do something like this as per Eric Suggestions >=20 > Kernel - GPL with the exceptions > Librarys - LGPL > Headers - X11/public domain > Programs - LGPL Programs should be GPL surely? ROb |
|
From: Steven E. <Ste...@ya...> - 2002-04-27 02:14:59
|
This was something Eric, Jason and I discussed a while back in regards to the wine port and driver also. Mabey we should do something like this as per Eric Suggestions Kernel - GPL with the exceptions Librarys - LGPL Headers - X11/public domain Programs - LGPL I've started sending patches to wine for mingw licensed as X11 so both wine and rewind can use them, once I get all of that done I'm going to start a dialog with the wine/rewind/mingw developers on the header mess. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Genadi V. Z. <mg...@po...> - 2002-04-27 00:13:05
|
http://www.compuware.com/products/driverstudio/resources/papers/spinlocks.htm |
|
From: Genadi V. Z. <mg...@po...> - 2002-04-27 00:07:33
|
Hello all. Who known layout of KLOCK_QUEUE_HANDLE structure? NTKERNELAPI VOID FASTCALL KeAcquireInStackQueuedSpinLock( IN PKSPIN_LOCK SpinLock, IN PKLOCK_QUEUE_HANDLE LockHandle ); NTKERNELAPI VOID FASTCALL KeReleaseInStackQueuedSpinLock( IN PKLOCK_QUEUE_HANDLE LockHandle ); NTKERNELAPI VOID FASTCALL KeAcquireInStackQueuedSpinLockAtDpcLevel( IN PKSPIN_LOCK SpinLock, IN PKLOCK_QUEUE_HANDLE LockHandle ); NTKERNELAPI VOID FASTCALL KeReleaseInStackQueuedSpinLockFromDpcLevel( IN PKLOCK_QUEUE_HANDLE LockHandle ); |
|
From: Eric K. <ek...@rz...> - 2002-04-26 23:23:06
|
Modified Files:
services/fs/cdfs/common.c
services/fs/cdfs/dirctl.c
services/fs/cdfs/fcb.c
services/fs/cdfs/fsctl.c
Added media change support (untested).
Added directory listing (works only on the root directory).
Eric
|
|
From: David W. <we...@cw...> - 2002-04-26 22:57:49
|
On Fri, Apr 26, 2002 at 05:13:16PM +0200, KJK::Hyperion wrote: > - no support for the CodeView symbol format, only the "ancient" textual > symbol lists > Adding support for codeview to gcc/binutils would be a major project in its own right; however gcc does generate equivalent debugging information which can be used when debugging ReactOS with gdb. > - we mix source files with generated binaries. This is messy, and > inflexible: how do you handle multiple different builds of some target? for > example "debug version for the i386 architecture, with Microsoft Windows > compatibility options, statically linked", "release version for the SPARC > architecture, with support for large files", and so on? > I agree this is a problem (and similarly for debug/release) but it shouldn't very difficult to fix, though hopefully compile time options can be kept to a minimum. |
8 messages has been excluded from this view by a project administrator.
