ReactOS/Mingw32 port

[Steven Edwards]

Hello,
I am in the process of merging our wine tree back in to the main WINE
branch and have a few issues that need to be addressed:

1. Makefiles and Resources
Alexandre: I know you said you might not accept our makefiles but I went
ahead and sent them for your review, if you don’t want to apply them no
problem. Will you accept the .def's for the dlls as we cannot use the
.specs? No big deal if not because we can keep them on our CVS. Also due
to a bug in windress we cannot use the wine resources so we have to use
binary resources for our port. Will you accept those? If not, once again
no big deal we can keep the makefiles, resources and defs in our CVS
tree.

2. Winsock.h problems
I've been looking at what our guys changed in the wine headers vs the
current wine headers and the current winsock.h seems to have
compatiblity problems for non-posix-like platforms. Any suggestions on
how to fix it for our port?

3. Everything else
I'm still new to the whole programming thing so I'm open for suggestions
from everyone. If anyone has a better way of doing the port rather then
#ifdef/#endif let me know.

I'm going to start submitting patches to the headers today.
Thanks
Steven Edwards

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Casper Hornstrup]

On Sunday 27 January 2002 22:07, you wrote:
> Hello,
> I am in the process of merging our wine tree back in to the main WINE
> branch and have a few issues that need to be addressed:
> - Makefiles and Resources
>
> Alexandre: I know you said you might not accept our makefiles but I went
> ahead and sent them for your review, if you don’t want to apply them no
> problem. Will you accept the .def's for the dlls as we cannot use the
> .specs? No big deal if not because we can keep them on our CVS. Also due
> to a bug in windress we cannot use the wine resources so we have to use
> binary resources for our port. Will you accept those? If not, once again
> no big deal we can keep the makefiles, resources and defs in our CVS
> tree.
> - Winsock.h problems
>
> I've been looking at what our guys changed in the wine headers vs the
> current wine headers and the current winsock.h seems to have
> compatiblity problems for non-posix-like platforms. Any suggestions on
> how to fix it for our port?
> - Everything else
>
> I'm still new to the whole programming thing so I'm open for suggestions
> from everyone. If anyone has a better way of doing the port rather then
> #ifdef/#endif let me know.
>
> I'm going to start submitting patches to the headers today.
> Thanks
> Steven Edwards

Well, eventually I would like to see the the three projects 
(WINE/MinGW/ReactOS) use the same headers. IMO all three projects have 
incomplete and messy Windows headers. If the same headers were used, there 
would be no need for #ifdefs _PROJECT_NAME_ in them. Of course this would 
take a long time to implement. Also I would like to see Win16 and Win32 
headers seperated as they do not have much in common and they are not 
important to the ReactOS project. Finally it would be nice to seperate WINE 
modules that only use the Win32 API from those that uses other APIs (like 
WINE internal APIs and Win16 APIs) as ReactOS can only share Win32 only 
modules with WINE.

Casper Hornstrup

[Steven Edwards]

> Well, eventually I would like to see the the three projects 
> (WINE/MinGW/ReactOS) use the same headers. IMO all three projects have 
> incomplete and messy Windows headers. If the same headers were used,

there
> would be no need for #ifdefs _PROJECT_NAME_ in them. Of course this

would
> take a long time to implement. Also I would like to see Win16 and Win32
> headers seperated as they do not have much in common and they are not 
> important to the ReactOS project. Finally it would be nice to seperate

WINE
> modules that only use the Win32 API from those that uses other APIs

(like
> WINE internal APIs and Win16 APIs) as ReactOS can only share Win32 only
> modules with WINE.

The header part I agree with 100%, Headers and specs/defs need to really
be looked at for WINE/REACTOS/MINGW. This is making for a lot of
redundant work. As for the Win32/Win16/otherAPI separation, I don’t
think this is going to happen. I think the idea behind the wine dll
structure when it comes to the win16 bit stuff is just to forward it to
the win32 equivalent.

Steven

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Alexandre Julliard]

"Steven Edwards"  writes:
> - Makefiles and Resources
>
> Alexandre: I know you said you might not accept our makefiles but I went
> ahead and sent them for your review, if you don�t want to apply them no
> problem. Will you accept the .def's for the dlls as we cannot use the
> .specs? No big deal if not because we can keep them on our CVS. Also due
> to a bug in windress we cannot use the wine resources so we have to use
> binary resources for our port. Will you accept those? If not, once again
> no big deal we can keep the makefiles, resources and defs in our CVS
> tree.

I don't think any of these belong in Wine CVS. For Makefiles the best
solution would be to fix whatever is needed in the Wine makefiles to
make them work for you.

.def files could either be generated from the .spec file, or winebuild
could be modified to work with .def files. But in any case we should
not have to maintain the same information at two different places.

Binary resources obviously shouldn't be put into the tree; why can't
you build them from source under ReactOS?  Can't you use Wine wrc for
that?
> - Everything else
>
> I'm still new to the whole programming thing so I'm open for suggestions
> from everyone. If anyone has a better way of doing the port rather then
> #ifdef/#endif let me know.

You should be using configure if possible. If you use #ifdefs you have
to test features detected by configure (the HAVE_xxx symbols); as a
rule platform-specific #ifdefs (like #ifdef REACTOS) must be avoided.
But all kinds of ifdefs should be avoided as much as possible.

[Steven Edwards]

> .def files could either be generated from the .spec file, or winebuild
> could be modified to work with .def files. But in any case we should
> not have to maintain the same information at two different places.

Ok no problem, I will take a look at that and see what I can come up
with
> Binary resources obviously shouldn't be put into the tree; why can't
> you build them from source under ReactOS?  Can't you use Wine wrc for
> that?

I will have to take another look and see whats up. I didn’t do the port
to ReactOS so I'm just going on what I find and whats been told.
> You should be using configure if possible. If you use #ifdefs you have
> to test features detected by configure (the HAVE_xxx symbols); as a
> rule platform-specific #ifdefs (like #ifdef REACTOS) must be avoided.
> But all kinds of ifdefs should be avoided as much as possible.

Currently we are using our own makefile and helper makefile stucture
with mingw, I will take a look at using configure and adding a ReactOS
target this week.

Are you accepting the latest patches for wcmd and osversioncheck? The
last ones don’t require #ifdefs and fix the old wine_main entry.

Thanks
Steven

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com