I've recently been taking an interest in MinWin, especially as it's now visible in Windows 7, and I want to bring up the possibility of introducing something similar into ReactOS.
I know some of you will be familiar with WinWin and I know at least one of you will know quite a bit more about it than I do, but for those who don't here's an overview.
What is WinMin?
MinWin is an internal project at Microsoft that manifested around the time of the Vista rewrite. Very basically explained, the aim is to detangle the very core components from the full operating system, resulting in something which can be built separately and leaving just enough components for a working system. This minimal operating system can then boot and be tested separately or be built as part of the full OS and tested in internally as before.
The main problem in doing this, and one of the main benefits in solving it, is module dependencies. By simply cutting out the bottom part of the OS you're left with modules which potentially call out to other modules which may now be missing. If these dependencies aren't understood you have the possibility of an unstable OS as you never know where a code path may lead. It also means you need to build more components to get the thing to link, which also undermines one of the reasons for doing it.
What Microsoft did is to draw up a dependency tree and structure it in a layered hierarchy. Modules were then rearranged to make architectural sense according to the NT design and a top layer was decided upon. API call were then rewritten within this hierarchy such that anything in one layer would only call API's in the layers below it. Therefore if something in layer 8 called something in layer 7 which then called something in layer 12, the APIs would be fixed to only use APIs at or below its level according to the hierarchy. You're then left with a clean line where nothing calls out and you have a tightly bound core OS which is completely independent from anything.
What is essentially left in Microsoft's WinMin is what people class as Cutlers NT along with supporting components to get a bootable system. The main components are:
The kernel (main kernel, not the full ntoskrnl module), parts of the executive, memory manager, networking, a file system driver and core drivers (basc IO and Bus, etc)
This is then exposed in usermode by 2 dlls, ntdll.dll and the new kernelbase.dll. On top of this you have a console for issuing commands.
This comprises of the full OS and amounts to about 25Mb on disk and has around a 40Mb working set.
Let's quickly explain the new kernelbase dll.
As many of the API's in the lower level dlls such as kernel32 and advapi32 were targeting functionality which wasn't in WinMin, it was decided to pull out any of the API's which were required to exercise WinMin and put them into kernelbase. This dll could then be used when building a running WinMin to provide all the functionality this kernel offered. The dlls which had their APIs removed now forwarded their call onto kernelbase so from a user perspective, nothing had changed.
Microsoft went a step further and designed a new technology around virtual dlls. They split functionality of dlls into 'api sets' These can now be seen in Win 7 in the system32 dir with the prefix 'api-ms-win-core-<function>-<num of>-1-0.dll'. WinMin components now link against these virtual dlls which load up the real libs listed in apisetschema.dll.
However this involves modification to the loader and I don't think it's something worth us considering right now.
What are the reasons for doing this?
For a start, it's a much better design from an engineering perspective.
The more software you have running on a system the more noise is created and the more things can interfere with each other.
It gives us a base to innovate with without worrying about affecting anything outside.
It gives us a more reliable base for the OS and a better platform to run comprehensive and efficient tests.
It makes us more attractive to external companies as we would have a slick NT compatible kernel ready for companies to build their products on, especially embedded applications.
With a few more additional items such as the base win32 subsystem, we'd have something along the lines of a stripped out ServerCore or Windows PE.
This is only a quick overview for discussion purposes, but it outlines the main design and goals of WinMin.
Comments, questions, concerns and gripes welcome J
Ged.
Gerard Murphy writes:
I’ve recently been taking an interest in MinWin, especially as it’s now visible in Windows 7, and I want to bring up the possibility of introducing something similar into ReactOS.
I know some of you will be familiar with WinWin and I know at least one of you will know quite a bit more about it than I do, but for those who don’t here’s an overview.
Looks really good. IMHO, ReactOS would benefit a lot from targetting WinMin
I absolutely support this approach. I've actually been advocating this half a year ago.
You can develop the individual layers / components more independently. Prerequisite is a stable and complete interface between the layers. Then breaking one component doesn't neccessarily mean breaking the whole.
More developers will also make more noise. Recompiling the whole OS due to a small fix in some user mode app seems to be an archaic method. The build times won't decrease and the number of commits per day (hopefully) also won't decrease. A layered structure also in the sources would help to decrease build times and avoid breakages or at least make them less fatal.
"make ntdll_clean" + "make bootcd" ...Will lead to a relink of all usermode stuff. Did someone change the ntdll exports? Probably not. Can I exclude all dlls from build? No way. The apps require the import libs. Exclude all apps? No, some dlls require explorer to be built. I highly suggest seperating the import libraries from the dlls and keep them in a seperate sdk. That would be the first step of unlinking the modules. The sdk should only be modifies very conservatively, because it can cause full rebuilds.
Then a seperation in layers / components would be great. The core (like MinWin), the win32 core, Highlevel dlls, networking, audio, tools.
Just my 1st 2 cents Timo
PS: yes, kjk, I know it won't work ;-)
On Mon, Oct 26, 2009 at 4:41 PM, Timo Kreuzer timo.kreuzer@web.de wrote:
I absolutely support this approach. I've actually been advocating this half a year ago.
You can develop the individual layers / components more independently. Prerequisite is a stable and complete interface between the layers. Then breaking one component doesn't neccessarily mean breaking the whole.
More developers will also make more noise. Recompiling the whole OS due to a small fix in some user mode app seems to be an archaic method. The build times won't decrease and the number of commits per day (hopefully) also won't decrease. A layered structure also in the sources would help to decrease build times and avoid breakages or at least make them less fatal.
"make ntdll_clean" + "make bootcd" ...Will lead to a relink of all usermode stuff. Did someone change the ntdll exports? Probably not. Can I exclude all dlls from build? No way. The apps require the import libs. Exclude all apps? No, some dlls require explorer to be built. I highly suggest seperating the import libraries from the dlls and keep them in a seperate sdk. That would be the first step of unlinking the modules. The sdk should only be modifies very conservatively, because it can cause full rebuilds.
Then a seperation in layers / components would be great. The core (like MinWin), the win32 core, Highlevel dlls, networking, audio, tools.
Just my 1st 2 cents Timo
PS: yes, kjk, I know it won't work ;-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
With this approach, does it make it possible to make a UNIX style OS using the ReactOS kernel, because it wouldn't be necessary to include the Win32 part, the OS could be adapted to use POSIX APIs and such?
You could theoretically build a unix subsystem layer on top of this but you would have to design and write it yourself.
However, it wouldn't in any way be a unix style OS, it would be an NT OS with a unix layer.
It's an insane amount of work and doesn't make much sense when there's perfectly good unix kernels available.
Following the NT method, the unix subsystem (posix) relies on the win32 subsystem for all its calls so you cannot exclude the win32 part.
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of King InuYasha Sent: 26 October 2009 21:54 To: ReactOS Development List Subject: Re: [ros-dev] Reactos and MinWin
With this approach, does it make it possible to make a UNIX style OS using the ReactOS kernel, because it wouldn't be necessary to include the Win32 part, the OS could be adapted to use POSIX APIs and such?
Why exactly would one want to do this?
With this approach, does it make it possible to make a UNIX style OS using
the ReactOS kernel, because it wouldn't be necessary to include the Win32 part, the OS could be adapted to use POSIX APIs and such?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
fun :)
On Tue, Oct 27, 2009 at 1:10 AM, Zachary Gorden drakekaizer666@gmail.comwrote:
Why exactly would one want to do this?
With this approach, does it make it possible to make a UNIX style OS using
the ReactOS kernel, because it wouldn't be necessary to include the Win32 part, the OS could be adapted to use POSIX APIs and such?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
One thing related to this is the sepeartion of the SDK part.
Curently the SDK is integral part of the whole source tree. One minor change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions which is stupid, because the interfaces are expected to be stable.
Separating the SDK completely from the sources is not possible atm, but I suggest separating it from the main folder. It could be done similar to how rosapps and rostets are managed. As a sepeate checkout. But instead of putting it into the hardcoded modules subfolder, I would suggest a configurable path. So that multiple reactos checkouts could use one SDK checkout. Each of the main checkouts contains a config file with the sdk path. A default path could be set by RosBE or in the config-template. I would suggest to do that with rosapps and rostests, too. So you only need one checkout of rostests for multiple base checkouts. You can probably do that with hardlinks but not everyone can/wants to do that. The libraries would only be rebuild if you update the SDK.
Sources\ \reactos-trunk... \reactos-amd64... \reactos-arwinss... \reactos-sdk\ \include\ \lib\ <- static libs (crt, nt, ...) here \import\ <- spec files here \rosapps\ \rostests\
It would probably be a good idea to sync our headers / libs with mingw-w64 as much as possible, so maybe some day we could actually outsource the whole SDK.
Other seperations like core / win32 / wine etc can be done in a similar way. It would require to have multiple checkouts to compile, but I think that's a reasonable efford. Or all parts could be put into trunk/source/... then you can checkout the whole folder if you don't want to hassle with multiple checkouts or trunk/source/sdk/ and trunk/source/reactos seperately if you like.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if I am executing it from a different checkout folder. That sucks. It should only clean everything in the current folder. That way modules / the sdk would not automatically be cleaned. Because that's in most cases not what you want. A "clean all" could be used to clean all dependencies as well.
Regards, Timo
There are all things that KJK and myself have been striving to work on. They require changes to rbuild's underpinnings, which have yet to happen. There is a Wiki tracking some of this.
The end plan is for us to ship an RDK which would ship with
1) Public SDK (libs and headers) 2) RosBE 3) Rbuild itself
And those binary modules would be used unless the source module was imported into the tree (say you wanted to have your own rbuild or make changes to it).
This would add major stability and testing consistency so everyone builds with the same headers, libraries, build scripts and rbuild/compiler version.
The extended plan is to add things like mesa and other 3rd party libraries as binary-only packages in the RDK as well -- again allowing for the option of these to be compiled by hand if the user wants to, but normally the static versions would be linked, saving compilation time and disk space.
Best regards, Alex Ionescu
On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
One thing related to this is the sepeartion of the SDK part.
Curently the SDK is integral part of the whole source tree. One minor change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions which is stupid, because the interfaces are expected to be stable.
Separating the SDK completely from the sources is not possible atm, but I suggest separating it from the main folder. It could be done similar to how rosapps and rostets are managed. As a sepeate checkout. But instead of putting it into the hardcoded modules subfolder, I would suggest a configurable path. So that multiple reactos checkouts could use one SDK checkout. Each of the main checkouts contains a config file with the sdk path. A default path could be set by RosBE or in the config-template. I would suggest to do that with rosapps and rostests, too. So you only need one checkout of rostests for multiple base checkouts. You can probably do that with hardlinks but not everyone can/wants to do that. The libraries would only be rebuild if you update the SDK.
Sources\ \reactos-trunk... \reactos-amd64... \reactos-arwinss... \reactos-sdk\ \include\ \lib\ <- static libs (crt, nt, ...) here \import\ <- spec files here \rosapps\ \rostests\
It would probably be a good idea to sync our headers / libs with mingw-w64 as much as possible, so maybe some day we could actually outsource the whole SDK.
Other seperations like core / win32 / wine etc can be done in a similar way. It would require to have multiple checkouts to compile, but I think that's a reasonable efford. Or all parts could be put into trunk/source/... then you can checkout the whole folder if you don't want to hassle with multiple checkouts or trunk/source/sdk/ and trunk/source/reactos seperately if you like.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if I am executing it from a different checkout folder. That sucks. It should only clean everything in the current folder. That way modules / the sdk would not automatically be cleaned. Because that's in most cases not what you want. A "clean all" could be used to clean all dependencies as well.
Regards, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
So would the sources of the binary modules still be available in the tree? Because I personally like to compile everything to be set dynamically instead of using static libraries.
On Mon, Nov 2, 2009 at 10:43 AM, Alex Ionescu ionucu@videotron.ca wrote:
There are all things that KJK and myself have been striving to work on. They require changes to rbuild's underpinnings, which have yet to happen. There is a Wiki tracking some of this.
The end plan is for us to ship an RDK which would ship with
- Public SDK (libs and headers)
- RosBE
- Rbuild itself
And those binary modules would be used unless the source module was imported into the tree (say you wanted to have your own rbuild or make changes to it).
This would add major stability and testing consistency so everyone builds with the same headers, libraries, build scripts and rbuild/compiler version.
The extended plan is to add things like mesa and other 3rd party libraries as binary-only packages in the RDK as well -- again allowing for the option of these to be compiled by hand if the user wants to, but normally the static versions would be linked, saving compilation time and disk space.
Best regards, Alex Ionescu
On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
One thing related to this is the sepeartion of the SDK part.
Curently the SDK is integral part of the whole source tree. One minor change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions which is stupid, because the interfaces are expected to be stable.
Separating the SDK completely from the sources is not possible atm, but I suggest separating it from the main folder. It could be done similar to how rosapps and rostets are managed. As a sepeate checkout. But instead of putting it into the hardcoded modules subfolder, I would suggest a configurable path. So that multiple reactos checkouts could use one SDK checkout. Each of the main checkouts contains a config file with the sdk path. A default path could be set by RosBE or in the config-template. I would suggest to do that with rosapps and rostests, too. So you only need one checkout of rostests for multiple base checkouts. You can probably do that with hardlinks but not everyone can/wants to do that. The libraries would only be rebuild if you update the SDK.
Sources\ \reactos-trunk... \reactos-amd64... \reactos-arwinss... \reactos-sdk\ \include\ \lib\ <- static libs (crt, nt, ...) here \import\ <- spec files here \rosapps\ \rostests\
It would probably be a good idea to sync our headers / libs with mingw-w64 as much as possible, so maybe some day we could actually outsource the whole SDK.
Other seperations like core / win32 / wine etc can be done in a similar
way.
It would require to have multiple checkouts to compile, but I think that's a reasonable efford. Or all parts could be put into trunk/source/... then you can checkout the whole folder if you don't want to hassle with multiple checkouts or trunk/source/sdk/ and trunk/source/reactos seperately if you like.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if I am executing it from a different checkout folder. That sucks. It should only clean everything in the current folder. That way modules / the sdk would not automatically be cleaned. Because that's in most cases not what you want. A "clean all" could be used to clean all dependencies as well.
Regards, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
You'd have to check them out as modules, and then the sources would be used on your machine instead of the static copies.
But we'd probably not accept bug reports from such builders without you having checked the static versions first (just as we always refer people to official install/boot CDs to rule out any local building issues).
On 2009-11-02, at 12:09 PM, King InuYasha wrote:
So would the sources of the binary modules still be available in the tree? Because I personally like to compile everything to be set dynamically instead of using static libraries.
On Mon, Nov 2, 2009 at 10:43 AM, Alex Ionescu ionucu@videotron.ca wrote: There are all things that KJK and myself have been striving to work on. They require changes to rbuild's underpinnings, which have yet to happen. There is a Wiki tracking some of this.
The end plan is for us to ship an RDK which would ship with
- Public SDK (libs and headers)
- RosBE
- Rbuild itself
And those binary modules would be used unless the source module was imported into the tree (say you wanted to have your own rbuild or make changes to it).
This would add major stability and testing consistency so everyone builds with the same headers, libraries, build scripts and rbuild/compiler version.
The extended plan is to add things like mesa and other 3rd party libraries as binary-only packages in the RDK as well -- again allowing for the option of these to be compiled by hand if the user wants to, but normally the static versions would be linked, saving compilation time and disk space.
Best regards, Alex Ionescu
On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
One thing related to this is the sepeartion of the SDK part.
Curently the SDK is integral part of the whole source tree. One
minor
change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions
which
is stupid, because the interfaces are expected to be stable.
Separating the SDK completely from the sources is not possible
atm, but
I suggest separating it from the main folder. It could be done similar to how rosapps and rostets are managed.
As a
sepeate checkout. But instead of putting it into the hardcoded
modules
subfolder, I would suggest a configurable path. So that multiple
reactos
checkouts could use one SDK checkout. Each of the main checkouts contains a config file with the sdk path. A default path could be
set by
RosBE or in the config-template. I would suggest to do that with
rosapps
and rostests, too. So you only need one checkout of rostests for multiple base checkouts. You can probably do that with hardlinks
but not
everyone can/wants to do that. The libraries would only be rebuild if you update the SDK.
Sources\ \reactos-trunk... \reactos-amd64... \reactos-arwinss... \reactos-sdk\ \include\ \lib\ <- static libs (crt, nt, ...) here \import\ <- spec files here \rosapps\ \rostests\
It would probably be a good idea to sync our headers / libs with mingw-w64 as much as possible, so maybe some day we could actually outsource the whole SDK.
Other seperations like core / win32 / wine etc can be done in a
similar way.
It would require to have multiple checkouts to compile, but I think that's a reasonable efford. Or all parts could be put into trunk/source/... then you can
checkout
the whole folder if you don't want to hassle with multiple
checkouts or
trunk/source/sdk/ and trunk/source/reactos seperately if you like.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if
I am
executing it from a different checkout folder. That sucks. It should only clean everything in the current folder. That way modules /
the sdk
would not automatically be cleaned. Because that's in most cases not what you want. A "clean all" could be used to clean all
dependencies as
well.
Regards, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Timo Kreuzer wrote:
Curently the SDK is integral part of the whole source tree. One minor change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions which is stupid, because the interfaces are expected to be stable.
Reorganizing the source dependencies etc to ease partial OS rebuilds and facilitate app development without dependency of OS source is of course a good/necessary step.
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 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?
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.
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.
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.
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 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 ?
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'. Likewise moving user callable progs like 'format' from 'base\system' to 'base\applications' so 'base\system' will contain progs that are only called by the system, not by the user. Yes ? No ?
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!
Other seperations like core / win32 / wine etc can be done in a similar way.
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.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if I am executing it from a different checkout folder. That sucks. It should only clean everything in the current folder.
Good point. Sounds reasonable to me too. Then 'clean all' can do what 'clean' does today ?
Just some food for further thought. Rock on // Love
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
Timo Kreuzer wrote:
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.
It's for this exact reason why our build system to be changed to support building subsets of the codebase before any work on a 'minros' can begin.
We need to define core areas of the OS and rearrange the tree to suit. Next we need to and add support to rbuild for building groups and add each module in the tree to a group. One of these groups will be 'MinRos'. Other such groups could include 'Apps', 'Win32', 'Cpls', etc. Only after all this has been done should we actually look at fixing our code dependencies in the way I described in our original email.
I had started going through the rbuild code last week, but in light of Alex's recent mail regarding this I need to catch with him and kjk to go through it with them.
Ged.
Timo Kreuzer wrote:
Love Nystrom wrote:
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
Eeh, sorry I didn't express myself clearly. Of *course* I did't mean fundamental in respect to MinWin. 8P I meant they are a legacy part of the OS as a whole, and ought to reside where other OS commandline utils reside. (I actually use sort now and then (some DOS habits die hard)).
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.
Sounds like the way to go. ReactOS should lead.. not follow ;) Their headers don't even have argument identifiers in the function prototypes, for crying out loud. Huuu.
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.
I'll take your word for that. One can always review the complete headers for documentary reference if the generated headers are unclear. Thank God for OpenSource!
Frankly, I think the current code structure could stand in this regard.
And it's all wrong.
Ahso.. Your point is well taken, thank You. As you probably know, I'm still rather new to this project and still haven't quite got the "knowledge of the terrain". I'll gladly defer to your knowledge of this source.
"clean" currently cleans the folder you specified when you installed rosbe. The current folder stays untouched.
You can't really mean it doesn't even respect the currently configured source path?? That sounds odd. I seem to remember it doing it's job in the configured source path when I switched between building 0.3.10 and trunk.
Best Regards // Love
-
Alex Ionescu -
Ged Murphy -
Gerard Murphy
-
Javier Agustìn Fernàndez Arroyo -
King InuYasha -
KJK::Hyperion -
Love Nystrom -
Sarocet -
Timo Kreuzer -
Zachary Gorden