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.
Yes, MS Visual Studio always calls the command line version to compile. It is called "cl.exe".
Wouldn't it be easier to use our Makefile system under cygwin to compile Wine with MSVC?
Possible. However I don't know exactly cygwin works. I try to avoid Windows as much as possible. I know how MSVS project files work though so I tryed with them first. Personally I think that the ultimate solution would be to automatically generate the .dsp files from Makefile.in or otherwise. There is a huge advantage of using the Microsoft format since Visual Studio can read them and you can for example just point and click on the files of each DLL to open them inside Visual Studio. The .dsp format is not very difficult to generate. It is just some sort of glorified Makefile.
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.
Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things. If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC. This is solvable by doing #include <winbase.h> but this requires changes in almost all .h files but it is just a simple search and replace. Hmm. I wonder if doing this will cause any bad effect with GNU C or other compilers?
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.
True.
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.
Yes. It will investigate some more.
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!
Yes. :-)
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
On Wed, 6 Feb 2002, Patrik Stridvall wrote: [...] Wouldn't it be easier to use our Makefile system under cygwin to compile Wine with MSVC?
Possible. However I don't know exactly cygwin works.
There are subtle differences between how the Unix makefiles work and how the Windows makefiles work. In addition to that the MSVC compiler supports different options, etc. Using the cygwin make tool (i guess they provide one) could help but it would not solve the compiler option problem. Plus cygwin works in a world where all paths are Unix paths while the MSVC compiler expects you to use drive letters (but will happily accept '/'s). In any case you would most likely end up rewriting the makefiles and this would as much work as just generating brand new .dsp files.
Personally I think that the ultimate solution would be to automatically generate the .dsp files from Makefile.in or otherwise.
May not be easy but you are pretty good with perl so if anyone can pull it off it's you :-) Once you have all the .dsp files, make a big .dsw file in the top-level directory that references all the other .dsp files. That way you can double-click on the .dsw, and then pick which dll you want to build, build them all at once, etc. I guess you already know about them (and they are really simple to generate).
Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things.
If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC.
No, that's because we use '-I .', which is a questionable practice. Unfortunately I believe there is something that makes it hard to avoid in Wine's case. I cannot remember what though.
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.
True.
But you would have to run configure on Windows, no? Since configure is a shell script this means you need something like cygwin to compile the source :-/ Or did you mean to run configure on Unix to generate just the right Makefiles for use on Windows? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
On Wed, 6 Feb 2002, Francois Gouget wrote:
There are subtle differences between how the Unix makefiles work and how the Windows makefiles work.
Yes, but I suggested using cygwin, which comes with GNU make, which is quite compatible with the one on Unix, because... it's the same one! :) Really, some time ago I tried to port Wine to cygwin, and I had no problems whatsoever with the make system. This is a red herring.
In addition to that the MSVC compiler supports different options, etc.
Right. But's that's why we have configure.
Using the cygwin make tool (i guess they provide one)
Read about cygwin here: http://www.cygwin.com (I think...) It is a Unix emulation layer build on top of Win32. It is Wine^-1 :) As such, it come with the same, unmodified utils familliar to Linux users.
could help but it would not solve the compiler option problem.
That's trivial to solve, come on...
Plus cygwin works in a world where all paths are Unix paths while the MSVC compiler expects you to use drive letters (but will happily accept '/'s).
If it accepts '/'s, what's the problem? Where (and why) would you use drive letters??? We only deal with relative paths to Wine's root...
In any case you would most likely end up rewriting the makefiles and this would as much work as just generating brand new .dsp files.
I strongly disagree, but since I don't have VC to show you... :)
But you would have to run configure on Windows, no? Since configure is a shell script this means you need something like cygwin to compile the source :-/ Or did you mean to run configure on Unix to generate just the right Makefiles for use on Windows?
No, you have bash in cygwin. It will work just fine. -- Dimi.
Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things.
If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC.
This is solvable by doing #include <winbase.h> but this requires changes in almost all .h files but it is just a simple search and replace.
Hmm. I wonder if doing this will cause any bad effect with GNU C or other compilers?
This is the standard behaviour for C includes. It is actually usually best to use <> not "" for all header files - unless you explicitely want the file included from the current directory. David
participants (4)
-
David Laight -
Dimitrie O. Paun -
Francois Gouget -
Patrik Stridvall