headers suggestion

[Jonathan Wilson]

In light of e.g. 
http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html
I would like to suggest the following header ideas.

Currently MingW has:
1.A set of headers that contain a copy of part of the platform SDK
2.Some extra stuff (like that ntdll.h)
3.A set of headers that contain a copy of part of the windows DDK
4.Mabie again some extra stuff MS doesnt have (I dont know)
5.A set of headers that contain a copy of part of the visual C++ runtime 
library
6.Some extra stuff (mainly bits required to deal with differences between 
GCC and Visual C I think)

WINE has:
1.A set of headers that are supposed to contain a copy of part of the 
platform SDK (although some things have been claimed to be wrong)
2.A set of headers that are supposed to contain a copy of part of the 
visual C++ runtime library (although again there may be things that are wrong)
and 3.Extra definitions for stuff in both header sets microsoft doesnt 
define in the platform SDK (e.g. internal bits, functions microsoft doesnt 
document etc)

ReactOS has:
w32api (the ROS import of it)
include/ddk (the ReactOS version of the windows DDK)
include/wine (the WINE windows API headers)
include/msvcrt (the MSVCRT headers ROS uses to build and link with msvcrt)
include (various misc ReactOS specific headers)

What I suggest for ReactOS (and I think some of this is already being done) 
is as follows:
grab any headers from include/* that are public DDK headers (if there are 
any) and make sure they are all in include/ddk
grab everything from the current WINE headers MingW is missing. Check that 
its all correct and stuff and add it to the ReactOS import of w32api. (if 
anything is found to be wrong in the wine headers, it should be fixed)
grab anything from include itself and add to w32api as needed
Get permission to relicence the stuff and contribute back to the main 
w32api tree.
grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE and 
also mingw-runtime.
Create one set of header files from the 3 sets such that it matches the 
microsoft headers as closely as possible.
Merge w32api DDK headers with ROS DDK headers and create one set that, 
again, matches the MS headers.

For w32api/mingw-runtime, the suggestion is that they look at all the "new 
stuff" generated by the merging of the 3 sets of msvcrt headers plus the 
ROS/WINE/w32api merger plus the DDK merger and look at acccepting it.

For WINE, I suggest they start using the new "merged" headers if at all 
possible.

Basicly, the idea is that mingw-runtime would become the "definitive" set 
of msvcrt.dll headers out there and that ReactOS, MingW and WINE would 
start using it for any case where you are talking to msvcrt.dll from the 
public side.
both ROS and WINE would then have their own internal msvcrt headers as 
necessary to build their msvcrt* builds
Then, w32api would become the "definitive" set of win32 api headers and 
would contain as much of the Microsoft Platform SDK as people have legally 
cloned. All userland components of ReactOS (as well as kernel-side bits 
that need the stuff in the userland headers e.g. win32k.sys) would use 
this. Be nice if WINE were to use this too but because of what WINE is and 
how it is built/used, there may be reasons for the WINE team not to use 
w32api as the build headers used to build WINE.
And, there would be one "definitive" set of DDK headers which would be good 
enough for building ReactOS with. And for building any kernel-side stuff 
WINE decides to add (e.g. that stuff to load the device drivers for 
vaerious copy protection systems that was being worked on). And for anyone 
using MingW and MingW GCC to build kernel-mode stuff.
Anything private or project specific would go into a set of private headers 
as needed for the different projects and sub-sections (dlls etc) within them
Anything exported by microsoft but undocumented would go into a set of 
"undocumented" headers (which could then be shared between ReactOS and WINE 
  since I dont think w32api would accept anything not documented in MSDN)

Just suggestions btw, if they are good, say so
If they are bad, say so (and say why)
If there are issues with my idea, say what they are.

[Alex Ionescu]

Hi Jonathan,

I am already working on a complete header system overhaul that's been 
approved and very much requested by the other developers.

Thanks for your suggestions. Some of them aren't so right, but the main 
parts of what you said I'm already doing, but in a more orderly and 
simplified fashion to guarnatee support with MS PSDK/DDK/IFS.

I invite you to read one of my older blog entries to find out more about it.

Best Regards,
Alex Ionescu

Jonathan Wilson wrote:

>   In light of e.g. 
>  http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html
>  I would like to suggest the following header ideas.
>
>  Currently MingW has:
>  1.A set of headers that contain a copy of part of the platform SDK
>  2.Some extra stuff (like that ntdll.h)
>  3.A set of headers that contain a copy of part of the windows DDK
>  4.Mabie again some extra stuff MS doesnt have (I dont know)
>  5.A set of headers that contain a copy of part of the visual C++ 
>  runtime library
>  6.Some extra stuff (mainly bits required to deal with differences 
>  between GCC and Visual C I think)
>
>  WINE has:
>  1.A set of headers that are supposed to contain a copy of part of the 
>  platform SDK (although some things have been claimed to be wrong)
>  2.A set of headers that are supposed to contain a copy of part of the 
>  visual C++ runtime library (although again there may be things that 
>  are wrong)
>  and 3.Extra definitions for stuff in both header sets microsoft doesnt 
>  define in the platform SDK (e.g. internal bits, functions microsoft 
>  doesnt document etc)
>
>  ReactOS has:
>  w32api (the ROS import of it)
>  include/ddk (the ReactOS version of the windows DDK)
>  include/wine (the WINE windows API headers)
>  include/msvcrt (the MSVCRT headers ROS uses to build and link with 
>  msvcrt)
>  include (various misc ReactOS specific headers)
>
>  What I suggest for ReactOS (and I think some of this is already being 
>  done) is as follows:
>  grab any headers from include/* that are public DDK headers (if there 
>  are any) and make sure they are all in include/ddk
>  grab everything from the current WINE headers MingW is missing. Check 
>  that its all correct and stuff and add it to the ReactOS import of 
>  w32api. (if anything is found to be wrong in the wine headers, it 
>  should be fixed)
>  grab anything from include itself and add to w32api as needed
>  Get permission to relicence the stuff and contribute back to the main 
>  w32api tree.
>  grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE 
>  and also mingw-runtime.
>  Create one set of header files from the 3 sets such that it matches 
>  the microsoft headers as closely as possible.
>  Merge w32api DDK headers with ROS DDK headers and create one set that, 
>  again, matches the MS headers.
>
>  For w32api/mingw-runtime, the suggestion is that they look at all the 
>  "new stuff" generated by the merging of the 3 sets of msvcrt headers 
>  plus the ROS/WINE/w32api merger plus the DDK merger and look at 
>  acccepting it.
>
>  For WINE, I suggest they start using the new "merged" headers if at 
>  all possible.
>
>  Basicly, the idea is that mingw-runtime would become the "definitive" 
>  set of msvcrt.dll headers out there and that ReactOS, MingW and WINE 
>  would start using it for any case where you are talking to msvcrt.dll 
>  from the public side.
>  both ROS and WINE would then have their own internal msvcrt headers as 
>  necessary to build their msvcrt* builds
>  Then, w32api would become the "definitive" set of win32 api headers 
>  and would contain as much of the Microsoft Platform SDK as people have 
>  legally cloned. All userland components of ReactOS (as well as 
>  kernel-side bits that need the stuff in the userland headers e.g. 
>  win32k.sys) would use this. Be nice if WINE were to use this too but 
>  because of what WINE is and how it is built/used, there may be reasons 
>  for the WINE team not to use w32api as the build headers used to build 
>  WINE.
>  And, there would be one "definitive" set of DDK headers which would be 
>  good enough for building ReactOS with. And for building any 
>  kernel-side stuff WINE decides to add (e.g. that stuff to load the 
>  device drivers for vaerious copy protection systems that was being 
>  worked on). And for anyone using MingW and MingW GCC to build 
>  kernel-mode stuff.
>  Anything private or project specific would go into a set of private 
>  headers as needed for the different projects and sub-sections (dlls 
>  etc) within them
>  Anything exported by microsoft but undocumented would go into a set of 
>  "undocumented" headers (which could then be shared between ReactOS and 
>  WINE  since I dont think w32api would accept anything not documented 
>  in MSDN)
>
>  Just suggestions btw, if they are good, say so
>  If they are bad, say so (and say why)
>  If there are issues with my idea, say what they are.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Jonathan Wilson]

This sounds good.
What will happen to the msvcrt headers?
msvcrt itself (and things like crtdll and the others that build off msvcrt) 
should put all their internal stuff (including internal copies of the 
public headers like Microsoft does if that is required)
But I think that any part of ReactOS that needs to talk to 
msvcrt/crtdll/etc should use mingw-runtime (i.e. we make it better using 
stuff in our msvcrt headers if we need to then use and import if needed 
mingw-runtime)

as for the other stuff, I assume that /sdk will basicly be w32api and that 
/ddk will be the w32api DDK. Anything that w32api wont take because its 
documented but not publically (e.g. the aformentioned fdi.h and fci.h) 
should go into the NDK IMO.
I assume then that ndk will contain all the stuff that is exported by the 
various parts of windows but is not documented outside of microsoft. 
Assuming this to be the case, I suggest it is split up (logically if not 
physically split up into different bits) into a set of kernel headers 
(basicly everything exported by ntoskrnl, hal and the various kernel mode 
drivers like win32k.sys, videoprt.sys, ndis.sys etc) and a set of userland 
headers (i.e. all the stuff exported from userland dlls that microsoft 
doesnt document). Also, the NDK should contain something saying that this 
stuff is undocumented and there are no gaurantees that, if you use it, your 
program will work in the future or that it will work on real windows if 
microsoft changes the undocumented stuff)

IMO, anything that is exported by a dll or driver or whatever in ReactOS 
but which is not exported by the MS dlls should be seperate from the NDK 
(at least in a seperate set of headers anyway) and it should be clear that 
using these functions prevents your code from running on real windows.

[Alex Ionescu]

Jonathan Wilson wrote:

>   This sounds good.
>  What will happen to the msvcrt headers?
>  msvcrt itself (and things like crtdll and the others that build off 
>  msvcrt) should put all their internal stuff (including internal copies 
>  of the public headers like Microsoft does if that is required)
>  But I think that any part of ReactOS that needs to talk to 
>  msvcrt/crtdll/etc should use mingw-runtime (i.e. we make it better 
>  using stuff in our msvcrt headers if we need to then use and import if 
>  needed mingw-runtime) 

I don't have much experience with those headers... I always assumed they 
were provided by deafault by mingw+gcc.

>  
>  as for the other stuff, I assume that /sdk will basicly be w32api  

Yes, with documented additions.

>   and that /ddk will be the w32api DDK.  

As well as the IFS, with documented additions that we have in our 
"internal" ddk/ifs

>   Anything that w32api wont take because its documented
> but not 
>  publically (e.g. the aformentioned fdi.h and fci.h) should go into the 
>  NDK IMO. 
Yes, the NDK has undocumented windows apis organized much like our old 
headers: "kefuncs.h/ketypes.h" "exfuncs.h/extypes.h" as well as 
"umtypes.h" which contains User-Mode Native types.

>   I assume then that ndk will contain all the stuff that
> is exported by 
>  the various parts of windows but is not documented outside of microsoft. 
Yes.

>   Assuming this to be the case, I suggest it is split up
> (logically if 
>  not physically split up into different bits) into a set of kernel 
>  headers (basicly everything exported by ntoskrnl,  

See the funcs/types organization.

>   hal  

Halfuncs/Types

>   and the various kernel mode drivers like win32k.sys

I haven't thought about exported win32k functions yet... I haven't met 
any yet. But I suppose w32kfuncs/w32ktypes will do, but I'm still not 
sure if those should be in the NDK...I've never heard about many people 
calling them.

>   , videoprt.sys, ndis.sys etc) 

Once again, I'm not sure those have exported functions that are usually 
being called, so I don't see why to include them in the NDK. They should 
just have their own set of internal headers.

>   and a set of userland headers (i.e. all the stuff
> exported from 
>  userland dlls that microsoft doesnt document). 

Once again, the NDK is mostly for kernel functions that are either 
native or undocumented...so undocumented userland dlls (apart ntdll) 
probably don't have much use being called. But if it's something really 
useful, then they'll be documented.


>   Also, the NDK should contain something saying that
> this stuff is 
>  undocumented and there are no gaurantees that, if you use it, your 
>  program will work in the future or that it will work on real windows 
>  if microsoft changes the undocumented stuff) 
It's the whole point of a NDK :)

>  
>  IMO, anything that is exported by a dll or driver or whatever in 
>  ReactOS but which is not exported by the MS dlls should be seperate 
>  from the NDK (at least in a seperate set of headers anyway)  
Of course. For now there's a rosfuncs/types in inclue/reactos in my new 
design.

>   and it should be clear that using these functions
> prevents your code 
>  from running on real windows. 
Yes, the best would be to declare them as deprecated or somethign to 
make sure that nobody can use them in a compiled app/driver.

Best regards,
Alex Ionescu

[Jonathan Wilson]

> >   ,
> > videoprt.sys, ndis.sys etc) 
>
>
>  Once again, I'm not sure those have exported functions that are usually
>  being called, so I don't see why to include them in the NDK. They should
>  just have their own set of internal headers. 
just ask vizzini (our ndis guru) about
ndis.sys and calling functions in it 
that are not documented by microsoft.
I suspect that there are things in videoprt.sys not documented by microsoft 
either.
IMO the NDK should basicly be 3 things:
1.a "native" API header file or files (i.e. the "nt.h" which has been

referenced in at least one microsoft example or code somewhere) and would 
provide interfaces for everything in ntdll.dll that we can get prototypes for.
2.a set of header files that document everything exported by ntoskrnl, hal, 
win32k (the Engxxx functions), videoprt.sys, ndis.sys, scsiport.sys etc and 
not documented by microsoft.
then 3.anything else in userland that isnt documeneted (e.g. undocumented 
shell32 functions or undocumented user32 functions or whatever else). I 
have actually seen some of this undocumented stuff in real-world usage.
Lots of people use undocumented shell32 functions for various things.
And several code examples out there subclass the menu windows in that app 
with a hook and hook various undocumented menu messages (I have seen 
references to MN_xxx messages that I think are the messages in question 
although I cant remember where I saw them). So, people are using the 
undocumented functionality.
Since we are implementing it (to be compatible with windows), I see no 
reason not to document it somewhere for all to see...

Are we going to actually get permission to re-licence then submit all the 
w23api changes back to w32api?
If so, I suggest we keep the stuff (like IFS) that w32api wont accept 
seperate (i.e. in seperate header files) from the base w32api (i.e. our 
w32api would only be w32api + stuff we are working on getting into w32api)

Given that anything that goes into our SDK and DDK headers will be stuff 
that is documented in the platform SDK with any ros-specific additions 
(e.g. for stuff that is documented)

[Steven Edwards]

--- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
>   Are we going to actually get permission to re-licence
> then submit all
>  the 
>  w23api changes back to w32api? 
Unless its its on MSDN or something thats undocumented that you can
find via a simple google search then the w32api people will not accept
it. As far as I care we should just maintain our own SDK based on the
Wine headers, The DDK based on the Mingw DDK and our own NDK for the
undocumented stuff.

Thanks
Steven



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com

[Jonathan Wilson]

Steven Edwards wrote:

>   --- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
>  
> >  Are we going to actually get permission to
> > re-licence then submit all
> > the 
> > w23api changes back to w32api? 
>  
>  
>  Unless its its on MSDN or something thats undocumented that you can
>  find via a simple google search then the w32api people will not accept
>  it. As far as I care we should just maintain our own SDK based on the
>  Wine headers, The DDK based on the Mingw DDK and our own NDK for the
>  undocumented stuff. 
Most of what is in the WINE headers is the stuff that is in the
"platform 
SDK" and then "the undocumented stuff".
Keeping the "undocumented" stuff (i.e. the bits microsoft doesnt document 
in the Platform SDK) and the "documented" stuff seperate (i.e. putting the 
undocumented stuff into seperate headers) is a good idea IMO. (e.g. have a 
"userundoc.h" for the undocumented stuff or whatever)
And if we are doing that, we can (if people will re-licence) contribute the 
documented stuff (all of which is in the MS platform SDK or the DDK) back 
to w32api itself to make w32api into something that gets 1 step closer to 
the Platform SDK/DDK (IMO thats what w32api should be aiming at, a clone of 
anything in the microsoft Platform SDK that someone wants to cleanroom 
clone and also anything in the DDK that anyone wants to cleanroom clone)

Anyone else think that keeping the undocumented stuff seperate from the 
regular documented stuff is a good idea? bad idea?

[Alex Ionescu]

Jonathan Wilson wrote:

>   Steven Edwards wrote:
>
> >   --- Jonathan Wilson <jonwil(a)tpgi.com.au>
> > wrote:
> >
> > >   Are we going to actually get permission to
> > > re-licence then submit all
> > >  the w23api changes back to w32api? 
> >
> >
> >  Unless its its on MSDN or something thats undocumented that you can
> >  find via a simple google search then the w32api people will not accept
> >  it. As far as I care we should just maintain our own SDK based on the
> >  Wine headers, The DDK based on the Mingw DDK and our own NDK for the
> >  undocumented stuff. 
>  Most of what is in the WINE headers is the stuff that is in the 
>  "platform SDK" and then "the undocumented stuff".
>  Keeping the "undocumented" stuff (i.e. the bits microsoft doesnt 
>  document in the Platform SDK) and the "documented" stuff seperate 
>  (i.e. putting the undocumented stuff into seperate headers) is a good 
>  idea IMO. (e.g. have a "userundoc.h" for the undocumented stuff or 
>  whatever)
>  And if we are doing that, we can (if people will re-licence) 
>  contribute the documented stuff (all of which is in the MS platform 
>  SDK or the DDK) back to w32api itself to make w32api into something 
>  that gets 1 step closer to the Platform SDK/DDK (IMO thats what w32api 
>  should be aiming at, a clone of anything in the microsoft Platform SDK 
>  that someone wants to cleanroom clone and also anything in the DDK 
>  that anyone wants to cleanroom clone)
>
>  Anyone else think that keeping the undocumented stuff seperate from 
>  the regular documented stuff is a good idea? bad idea?
>
>  
We will do as planned and put undocumented stuff in the NDK

Best regards,
Alex Ionescu

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Steven Edwards
>  Sent: 21. november 2004 01:43
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] headers suggestion
>  
>  
>  --- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
> >   Are we going to actually get permission to
> > re-licence then  
>  submit all 
> >   the w23api changes back to w32api? 
>  
>  Unless its its on MSDN or something thats undocumented that 
>  you can find via a simple google search then the w32api 
>  people will not accept it. As far as I care we should just 
>  maintain our own SDK based on the Wine headers, The DDK based 
>  on the Mingw DDK and our own NDK for the undocumented stuff.
>  
>  Thanks
>  Steven 
I don't understand why you want two free SDK projects.

Casper

[Steven Edwards]

--- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
>  
>  I don't understand why you want two free SDK projects. 
I am not wanting to create two free SDK Projects. Lets be clear the the
mingw SDK/DDK is good but the rules for getting anything in to it are
crazy. MSDN has been known to be wrong almost every other day so using
it as a primary source of information flawed. The Wine headers already
exist so its not like I am talking about creating something new here.
They have shown a willingness to work with us so we should work with
them.

Thanks
Steven



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Steven Edwards
>  Sent: 21. november 2004 15:03
>  To: ReactOS Development List
>  Subject: RE: [ros-dev] headers suggestion
>  
>  
>  --- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
> >  
> >  I don't understand why you want two free SDK projects. 
>  
>  I am not wanting to create two free SDK Projects. Lets be 
>  clear the the mingw SDK/DDK is good but the rules for getting 
>  anything in to it are crazy. MSDN has been known to be wrong 
>  almost every other day so using it as a primary source of 
>  information flawed. The Wine headers already exist so its not 
>  like I am talking about creating something new here.
>  They have shown a willingness to work with us so we should 
>  work with them.
>  
>  Thanks
>  Steven 
Which rules are crazy? MSDN is usually right btw. You are
greatly exaggerating. You have to see it in the bigger
perspective. MSDN has tons of information and is made by
humans and since humans tend to make mistakes every now and then,
MSDN will have them too. Why don't you post in their newsgroups
about the mistakes you've found so they have a chance of fixing
them? I've found the MS newgroups to be a valuable way to get
your voice heard and to get help with problems.

Casper

[Steven Edwards]

Casper,

--- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
>   Which rules are crazy? MSDN is usually right btw. You
> are
>  greatly exaggerating. You have to see it in the bigger
>  perspective. MSDN has tons of information and is made by
>  humans and since humans tend to make mistakes every now and then,
>  MSDN will have them too. Why don't you post in their newsgroups
>  about the mistakes you've found so they have a chance of fixing
>  them? I've found the MS newgroups to be a valuable way to get
>  your voice heard and to get help with problems. 
Maybe I should have been more clear. Unless its on MSDN and does not
require downloading a SDK package then they will accept it. Never mind
the fact that the cabinet.dll information is published in a SDK on MSDN
and the PSDK. They will not accept it as you have to click though a
EULA to get to it. I know. I went through the trouble of asking the
Wine authors to relicense the FCI/FDI headers only to have the Mingw
people say "find it on MSDN" which I did, in a downloadable SDK. After
I sent that they said "we can not accept this, it has a EULA"

Take a look at the headers that are in Wine that are missing in our
w32api. I doubt most of them are even in the latest w32api. The Wine
people are happy to work with us to fix them. Should we rewrite them
from scratch only to be told by the Mingw people sorry MSDN has a
broken URL or what you submit does not match, even if I can prove it is
wrong via a real world regression test.

I don't want to fight about it. If you want to duplicate a lot of work
go ahead and I will keep my mouth shut.

Thanks
Steven


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

[Alex Ionescu]

Steven Edwards wrote:

>  Casper,
>
> --- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
>   
>
> >  Which rules are crazy? MSDN is usually right btw.
> > You are
> > greatly exaggerating. You have to see it in the bigger
> > perspective. MSDN has tons of information and is made by
> > humans and since humans tend to make mistakes every now and then,
> > MSDN will have them too. Why don't you post in their newsgroups
> > about the mistakes you've found so they have a chance of fixing
> > them? I've found the MS newgroups to be a valuable way to get
> > your voice heard and to get help with problems.
> >     
> >  
> Maybe I should have been more clear. Unless its on MSDN and does not
> require downloading a SDK package then they will accept it. Never mind
> the fact that the cabinet.dll information is published in a SDK on MSDN
> and the PSDK. They will not accept it as you have to click though a
> EULA to get to it. I know. I went through the trouble of asking the
> Wine authors to relicense the FCI/FDI headers only to have the Mingw
> people say "find it on MSDN" which I did, in a downloadable SDK. After
> I sent that they said "we can not accept this, it has a EULA"
>
> Take a look at the headers that are in Wine that are missing in our
> w32api. I doubt most of them are even in the latest w32api. The Wine
> people are happy to work with us to fix them. Should we rewrite them
> from scratch only to be told by the Mingw people sorry MSDN has a
> broken URL or what you submit does not match, even if I can prove it is
> wrong via a real world regression test.
>
> I don't want to fight about it. If you want to duplicate a lot of work
> go ahead and I will keep my mouth shut.
>
> Thanks
> Steven
>
>
> 		
> __________________________________ 
> Do you Yahoo!? 
> Meet the all-new My Yahoo! - Try it today! 
> http://my.yahoo.com 
>  
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
>   
>  
Let's all just wait for what I'm working on and then you can all flame 
me instead of arguing with each others :)

Best regards,
Alex Ionescu