[ros-dev] Reactos and MinWin

[Timo Kreuzer]

Love Nystrom wrote:
> It may be a superfluous remark, but in all of this, I hope You don't
> loose sight of that the goal is to loose any up-layer calls in the
> architecture itself, so a subsystem change don't cause a core
>   
The source / sdk separation is a different task, but a neccessary step
in that direction.

> incompatibility. F.ex Win32 is by design a subsystem layer,
> and should have a stable interface to the native core of the OS,
> and the core should *not* call subsystem functions. Due to this
> we will (probably) need a 'glue' dll besides ntdll, where we put
> primitives for the core to use wherever it was calling subsystems.
> I don't really think we *have* to draw the core lines where MS did.
> Our ntoskrnl seems a prime candidate as it stands.
> Perhaps a superfluous remark?
>   
We do this already. The nt-core includes ntdll in usermode. And of cause
ntdll doesn't call win32 functions. And ntoskrnl doesn't call win32k
functions. (Except callbacks)

>> I would suggest a configurable [SDK] path. So that multiple reactos
>> checkouts could use one SDK checkout. Each of the main checkouts
>> contains a config file with the sdk path.
>>     
>
> Should it not be the other way around also ?
> That the SDK would have a configurable path to the OS subversion
> you're working with if you're f.ex trying to regress an app malfunction,
> so your binaries end up in the right place.
>   
The binaries are always placed in the appropriate folders beneath your
toplevel checkout folder. If you use multiple checkouts of the same
source (branches), you wouldn't want to reconfigure your SDK each time
you want to compile the other branch. It also doesn't make sense, as the
SDK stays the same, no matter what you use it for. Or are you talking
about the target OS version defines? These are managed in the source
checkout, too.


>   
>> Sources\
>>     \reactos-trunk\...
>>     \reactos-amd64\...
>>     \reactos-arwinss\...
>>     \reactos-sdk\
>>        \include\
>>        \lib\       <- static libs (crt, nt, ...) here
>>        \import\  <- spec files here
>>     \rosapps\
>>     \rostests\
>>     
>
> IMHO the current source tree structure is not too bad as it is.
> I don't think any *major* reshuffling under 'trunk' is required.
>   
To claryfy, the above was thought as local folders on your harddisk, not
the repository.

Regarding the repository, IMO the current structure is complete crap. It
mixes core and subsystem, win32 and NT, audio and network, 3rd party and
reactos all under the same folder because the modules happen to have the
same extension. Bigger commits usually spread through multiple top level
folders, though they only affect one functionality.

> Making an 'sdk' directory as a sibling of 'trunk', 'tags', et. al.
> Separating all 'public' headers and libs (including 3rdparty) and
> putting them under 'sdk' (I think this is the most daunting task),
> so that 'reactos\include' and 'reactos\lib' will contain only
> 'os internal' headers and libs.
>   
Moving the stuff is the smaller part. Getting the stuff right beforehand
(complete and compatible) is the bigger task. Getting everyone fix their
checkouts is probably the biggest part ;-P

> It occurs to me that the public headers would be more or less a
> drop-in replacement for the ones in the MS SDK, with anonymous
>   
Thats the point, yes.
> stub declarations for internal data structs and so on. It might
> be an interesting test to try an app build with their headers
> instead of our own, but maybe someone tried that already ?
>   
Most of our apps should build fine with ms headers. I never did it
myself, but afaik other people are doing that regularly.

> Under 'trunk' I think only some minor shuffling could be good.
> Moving prog source like f.ex 'mode' and 'sort' which are fundamental 
> parts of a full ReactOS to 'base\applications' instead of 'rosapps'.
>   
LOL, mode and sort are fundamental? I think you didn't quite get the
idea of MinWin / MinRos. This is everything but not fundamental. I think
I never even executed one of them on reactos. Or windows. We could as
well delete them and noone would care.

>> It would probably be a good idea to sync our headers / libs with
>> mingw-w64 as much as possible
>>     
>
> Probably.. but I hope You don't mean to use them verbatim.
> I think MinGW's headers are rather hideous with their dense
> format and total lack of comments, so I'm no huge fan of them.
> I don't know about You, but to me the headers are usually
> the main documentation!
>   
Maybe. We could try to make sure our headers are minimum as complete and
correct as mingw headers and with more documentation, then maybe
mingw-w64 people would be interested in using them.

For DDK headers we could use an autocreate way like MS does. Create a
set of *complete* headers and autocreate wdm, ntddk, ntifs, etc from them.

> Frankly, I think the current code structure could stand in this regard.
> One may already checkout only f.ex 'ntoskrnl' to work on the core
> and 'subsystems' already has it's separate directory etc.
>   
And it's all wrong.
user32 and gdi32 are parts of the win32 core subsystem. they are in
dlls/win32 mixed with all the wine stuff.
ntdll is part of the nt-core and it's also in dlls, just next to
keyboard layouts and control panel applets.
freeldr is part of the ntcore and in the boot folder
kdcom is part of the ntcore and in drivers/base.
etc etc
Show me how to checkout ntoskrnl only and build that. You need the whole
tree to build anything.

> Good point. Sounds reasonable to me too.
> Then 'clean all' can do what 'clean' does today ?
>   
"clean" currently cleans the folder you specified when you installed
rosbe. The current folder stays untouched.

Regards,
Timo