On Tue, 5 Feb 2002, Patrik Stridvall wrote:
I have finally tried to compile Wine with MSVC. Eventhough I had to do some hack on the whole it compiled quite well.
Great. On a slightly related note, is it possible that we compile Wine with the MS headers? What would it take to do that?
Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "....\include" to the include path to get it to use the Wine header.
As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority.
Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-(
Additionally windef.h must be included first.
#include "winbase.h" #include "windef.h"
doesn't work. You have to do
#include "windef.h" #include "winbase.h"
This is a minor issue though.
I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand.
In short it was a terrible mess so I primarily tested it with the Wine headers.
I have only tested a few DLL since doing .dsp files for each them was some work. I might do a script to automatically generate .dsp files for MSVC some day.
If we could, we would have one more degree of freedom:
Platform Compilers BinFmt Headers
Linux gcc ELF Wine *BSD MSVC PE MS Solaris Borland ReactOS(?) Cygwin
Esentially, most of the above possible cobinations should work (except, of course Windows-base compilers and ELF).
Well. I think GNU C chokes on the MS headers so that won't work either.
If we get this level of portability, would be nice to set an automatic compile farm which tries all the possible combinations, and reports problems early, so they get fixed.
Yes, that would probably be a good idea.
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "....\include" to the include path to get it to use the Wine header.
Sorry Patrik if my questions are sometimes naive, but I don't have a Windows partition, let alone MSVC. So, here goes the question:
MSVC must have a command line version of the compiler. Wouldn't it be easier to use our Makefile system under cygwin to compile Wine with MSVC?
As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority.
That's why all our private headers must reside in include/wine. That needs to be fixed, eventually.
Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-(
Yeah, but that could be determined by configure.
Additionally windef.h must be included first.
#include "winbase.h" #include "windef.h"
doesn't work. You have to do
Of course. I was thinking would be nice to have a
#include "wine/prologue.h" <whatever includes you have> #include "wine/epilogue.h"
#include "windef.h" #include "winbase.h"
This is a minor issue though.
Which should be fixed, I think.
I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand.
In short it was a terrible mess so I primarily tested it with the Wine headers.
It would be sooo nice if we could compile with other headers as well. Just compiling would be great, running the resulting executable would be fantastic!
-- Dimi.
On Wed, 6 Feb 2002, Patrik Stridvall wrote: [...]
I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand.
You must define _X86_ before including 'winnt.h'. Otherwise it won't known on which architecture it's being compile and it won't define CONTEXT. And you must also include 'windef.h'. Otherwise CONST is not getting defined and again, errors ensue.
#define _X86_ #include <windef.h> #include <winnt.h>
Defining _X86_ is done in 'windows.h' which means that it is virtually impossible to use these headers without including the big beast itself.
Also, to answer Dimitrie:
On Wed, 6 Feb 2002, Dimitrie O. Paun wrote: [...]
Additionally windef.h must be included first.
#include "winbase.h" #include "windef.h"
doesn't work. You have to do
[...]
#include "windef.h" #include "winbase.h"
This is a minor issue though.
Which should be fixed, I think.
Windows does not support including 'winbase.h' first either so we don't really need to support it either. If you want to include 'winbase.h' yourself, on Windows you have to write:
#define _X86_ #include <windef.h> #include <winnt.h> #include <stdarg.h> #include <winbase.h>
Wine is already much more flexible. You can even just include 'windef.h' and it will include 'winnt.h' for you, how sophisticated!
More seriously, we could make it so that you can just #include <winbase.h> in Wine, but that may not be very easy and is obviously not required by Winelib.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
-
Dimitrie O. Paun -
Francois Gouget -
Patrik Stridvall