26 Oct
2009
26 Oct
'09
8:47 p.m.
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.
26 Oct
26 Oct
8:56 p.m.
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
9:41 p.m.
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 ;-)
9:54 p.m.
On Mon, Oct 26, 2009 at 4:41 PM, Timo Kreuzer <timo.kreuzer(a)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(a)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?
10:09 p.m.
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(a)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?
27 Oct
27 Oct
12:10 a.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
12:41 a.m.
fun :)
On Tue, Oct 27, 2009 at 1:10 AM, Zachary Gorden <drakekaizer666(a)gmail.com>wrote;wrote:
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
2 Nov
2 Nov
4:14 p.m.
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
4:43 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
5:09 p.m.
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(a)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
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
8:20 p.m.
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(a)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
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(a)web.de>
wrote:
Best regards,
Alex Ionescu
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 
3 Nov
3 Nov
11:32 a.m.
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
1:53 p.m.
Love Nystrom wrote:
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.
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.
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.
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.
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.
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!
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
2:53 p.m.
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.
2:55 p.m.
Timo Kreuzer wrote:
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.
Love Nystrom wrote:
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)).
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 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. "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
5530
days inactive
5538
days old
16 comments
10 participants
participants (10)
-
Alex Ionescu -
Ged Murphy -
Gerard Murphy
-
Javier Agustìn Fernàndez Arroyo -
King InuYasha -
KJK::Hyperion -
Love Nystrom -
Sarocet -
Timo Kreuzer -
Zachary Gorden