Re: [ros-kernel] Some thoughts on the source tree and build system

[KJK::Hyperion <no...@li...>]

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