Some more MSVC fixes

[Patrik Stridvall]

> 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. :-)