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 dont 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
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 dont 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
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 dont 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
"Steven Edwards" [email protected] 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.
.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
-
Alexandre Julliard -
Casper Hornstrup -
Steven Edwards