headers in reactos/w32api/include and reactos/include/wine

[Steven Edwards]

Does anyone care if I merge the duplicate headers from
reactos/include/wine in to the headers in the reactos/w32api/include
folder? There are a few headers we will want to keep in
reactos/include/wine but now that we have our own copy of the w32api we
dont need most of these headers that do the #include_next thing.

Thanks
Steven



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

I do care. some wine header are wrong. it will only work for wine.
until some fix wine compatible with mingw headers. And I am working on porting
some of wine dx support to ros. and wine dx header are not compatible with mingw
ones. for it contain wine specfiy define and struct. That goes for most of
wine.

Citerar Steven Edwards <steven_ed4153(a)yahoo.com>om>:

>   Does anyone care if I merge the duplicate headers
> from
>  reactos/include/wine in to the headers in the reactos/w32api/include
>  folder? There are a few headers we will want to keep in
>  reactos/include/wine but now that we have our own copy of the w32api we
>  dont need most of these headers that do the #include_next thing.
>
>  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
>

[James Tabor]

Hi all!
magnus(a)itkonsult-olsen.com wrote:
>   I do care. some wine header are wrong. it will only
> work for wine.
>  until some fix wine compatible with mingw headers. And I am working on porting
>  some of wine dx support to ros. and wine dx header are not compatible with mingw
>  ones. for it contain wine specfiy define and struct. That goes for most of
>  wine.
>   
I agree! Porting msi.dll was not hard but I can see Wine is not trying to help
with porting. The new version of Wines Advpack.dll is one that comes to mind.
Cross link dll libraries and so on!


Make one think they are doing it on purpose, you know~ 8^o

>   Citerar Steven Edwards
> <steven_ed4153(a)yahoo.com>om>:
>  
>  
> >Does anyone care if I merge the duplicate headers from
> >reactos/include/wine in to the headers in the reactos/w32api/include
> >folder? There are a few headers we will want to keep in
> >reactos/include/wine but now that we have our own copy of the w32api we
> >dont need most of these headers that do the #include_next thing.
> >
> >Thanks
> >Steven
> >
> >
> > 
Thanks,
James

[Steven Edwards]

Hi,

--- James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> 
>   I agree! Porting msi.dll was not hard but I can see
> Wine is not
>  trying to help
>  with porting. The new version of Wines Advpack.dll is one that comes
>  to mind.
>  Cross link dll libraries and so on! 
The problem is the Wine people have a goal that is not the same as
ours. They try to follow most of the same rules we do most of them are
Linux developers first and as such they dont always check to make sure
everything they are doing is implemented in the same way as windows. 

They are quite happy to accept patches from us the correct these
problems.

Thanks
Steven



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

[Jonathan Wilson]

I think that if WINE used the new w32api merge I mentioned for its DDK/API 
headers and the new mingw-runtime merge I mentioned for its msvcrt public 
headers and wrote to those (plus private wine only headers and 
"undocumented" headers), that would be a good start to making WINE more 
like windows IMO.

[Steven Edwards]

Hi,

--- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
>   I think that if WINE used the new w32api merge I
> mentioned for its
>  DDK/API 
>  headers and the new mingw-runtime merge I mentioned for its msvcrt
>  public 
>  headers and wrote to those (plus private wine only headers and 
>  "undocumented" headers), that would be a good start to making WINE
>  more 
>  like windows IMO. 
Its not worth the time or effort to take that method to restructure the
two projects. More effort should be focused on building ReactOS and
WINE with the PSDK headers. Once both Wine and ReactOS can be built
with the PSDK headers both projects headers will be close enough that
we can switch anytime we want.

Thanks
Steven



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

[Jonathan Wilson]

Thats what my suggestion is.
Update w32api (already being done) such that both ReactOS and WINE can be 
compiled with it (and the platform SDK headers too) and move anything that 
doesnt go into w32api from the ReactOS and WINE existing "API" headers out 
and into wherever they fit.
 From there, ReactOS (at least) can drop all the mess of win32api headers 
there is now (i.e. the stuff in \include like structs.h and friends and the 
WINE stuff) and switch to w32api full time for the entire project.

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Steven Edwards
>  Sent: 19. november 2004 05:49
>  To: ros-dev(a)reactos.com
>  Subject: [ros-dev] headers in reactos/w32api/include and 
>  reactos/include/wine
>  
>  Does anyone care if I merge the duplicate headers from 
>  reactos/include/wine in to the headers in the 
>  reactos/w32api/include folder? There are a few headers we 
>  will want to keep in reactos/include/wine but now that we 
>  have our own copy of the w32api we dont need most of these 
>  headers that do the #include_next thing.
>  
>  Thanks
>  Steven 
As long as you get the copyright holders to change the license to
the W32API license, I'm fine with it. Otherwise we will get a
maintainance hell.

Casper

[Ge van Geldorp]

>   From: Steven Edwards
>  
>  Does anyone care if I merge the duplicate headers from 
>  reactos/include/wine in to the headers in the 
>  reactos/w32api/include folder? There are a few headers we 
>  will want to keep in reactos/include/wine but now that we 
>  have our own copy of the w32api we dont need most of these 
>  headers that do the #include_next thing. 
I've looked at a few of the headers, and (apart from the #include_next) they
seem to define Wine-isms only. I don't think we should move those to
w32api/include. My personal rule so far has been: if it's in PSDK, move it
to w32api/include, if not keep it in include/wine.

Ge van Geldorp.

[Alex Ionescu]

Ge van Geldorp wrote:

> >  From: Steven
> > Edwards
> >
> > Does anyone care if I merge the duplicate headers from 
> > reactos/include/wine in to the headers in the 
> > reactos/w32api/include folder? There are a few headers we 
> > will want to keep in reactos/include/wine but now that we 
> > have our own copy of the w32api we dont need most of these 
> > headers that do the #include_next thing.
> >     
> >  
> I've looked at a few of the headers, and (apart from the #include_next) they
> seem to define Wine-isms only. I don't think we should move those to
> w32api/include. My personal rule so far has been: if it's in PSDK, move it
> to w32api/include, if not keep it in include/wine.
>
> Ge van Geldorp.
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
>   
>  
Also, it's probable that whatever w32api is legitimately missing (as in, 
it's in the PSDK but not in w32api), I've already added it to my header 
branch. Maybe wait until it's complete and see if theres's anything that 
really should go there from wine's headers.

Best regards,
Alex Ionescu

[Steven Edwards]

Hi,

--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   Also, it's probable that whatever w32api is
> legitimately missing (as
>  in, 
>  it's in the PSDK but not in w32api), I've already added it to my
>  header 
>  branch. Maybe wait until it's complete and see if theres's anything
>  that 
>  really should go there from wine's headers. 
One problem that we face is that some of the headers such as FDI.h and
FCI.h mingw wont accept because Microsoft only publishes the specs in a
package you have to accept a EULA to read.

Thanks
Steven



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