Running tests on windows
Last week I submitted a perl script that makes a Makefile (and archive bundle) for building tests on Windows boxes under cygwin. Well, it works fine with mingw too (when using msys at least), but there is a snag. In order to compile tests under Windows, I seem to need to include windows.h before any other .h files. I did this using the '-include' directive in gcc, but it requires knowledge of the absolute path to the windows.h file. This means I need to specify the path in the Makefile, which is completely non-portable (especialy with mingw which doesn't really have a default setup like cygwin does). 1) So it seems I have three options. I can append '#include <windows.h>' to each .c file (either wrapped in #define, or through the perl script) 2) I can include the entire wine /include directory in the archive, and use that 'windows.h' to build against. 3) I can just force the user to edit the Makefile to point to the correct include directory. I don't really like any of these options (though 3 is the the easiest to implement, as this is how it works now) So is there a better solution than the three I've listed? And why won't wine let me include 'windows.h', but under windows it is required? Thanks, .Geoff
"Geoffrey Hausheer" <i8e7fkwmsl1(a)phracturedblue.com> wrote:
So is there a better solution than the three I've listed? And why won't wine let me include 'windows.h', but under windows it is required?
Probably it would be better to use Wine headers to compile Wine tests. -- Dmitry.
On Sunday 07 April 2002 20:29, you wrote:
"Geoffrey Hausheer" <i8e7fkwmsl1(a)phracturedblue.com> wrote:
So is there a better solution than the three I've listed? And why won't wine let me include 'windows.h', but under windows it is required?
Probably it would be better to use Wine headers to compile Wine tests.
I disagree that this is a good idea. The idea is to test that wine behaves in the same manner as Windows does. This may include errors in the headers. The only way to be sure would be to compile against Native windows headers. Now I suppose cygwin/mingw headers aren't identical to Microsoft's own, but it is lall that I have access to currently .Geoff
Geoffrey Hausheer wrote:
On Sunday 07 April 2002 20:29, you wrote:
"Geoffrey Hausheer" <i8e7fkwmsl1(a)phracturedblue.com> wrote:
So is there a better solution than the three I've listed? And why won't wine let me include 'windows.h', but under windows it is required?
Probably it would be better to use Wine headers to compile Wine tests.
I disagree that this is a good idea. The idea is to test that wine behaves in the same manner as Windows does.
While I agree with that sentiment, I would like to point out that it may be that WINE has an incorrect function definition that is backed up by an incorrect declaration in the .h file. Such a situation may result in compiling for wine with the wine headers working, as well as compiling for Windows with the windows headers, but missing the binary compatibility support goal.
On Sun, 7 Apr 2002, Geoffrey Hausheer wrote:
Last week I submitted a perl script that makes a Makefile (and archive bundle) for building tests on Windows boxes under cygwin. Well, it works fine with mingw too (when using msys at least), but there is a snag.
In order to compile tests under Windows, I seem to need to include windows.h before any other .h files. I did this using the '-include' directive in gcc, but it requires knowledge of the absolute path to the windows.h file. This means I need to specify the path in the Makefile, which is completely non-portable (especialy with mingw which doesn't really have a default setup like cygwin does).
1) So it seems I have three options. I can append '#include <windows.h>' to each .c file (either wrapped in #define, or through the perl script)
2) I can include the entire wine /include directory in the archive, and use that 'windows.h' to build against.
3) I can just force the user to edit the Makefile to point to the correct include directory.
I don't really like any of these options (though 3 is the the easiest to implement, as this is how it works now)
So is there a better solution than the three I've listed?
I think I will work on extending your script to also generate Makefiles for use with Visual C++. The way it will work with Visual C++ is that you are supposed to run a batch script provided by Visual C++ (vcvars32.bat). This script sets a number of environment variables which point to the location of the headers, etc. and which you can also use in your Makefiles. Does Mingw provide something similar? Could we have a way of forcing the user to set some environment variables or query the values from him? (my batch-script skills are pretty rusty :-)
And why won't wine let me include 'windows.h', but under windows it is required?
Because winedows.h includes everythign and anything. We want Wine files to only include the headers they need. The problem is that the Wine tests are compiled as if they were part of the Wine sources instead of being compiled like Winelib applications, which they are. This means they are subject to the same restrictions as Wine sources: windows.h is forbidden, and Xxx is forbidden, you must use XxxA or XxxW (see IDI_APPLICATION & co for why this is a problem). About using the Mingw headers vs. the Wine headers vs. Visual C++ headers. I say: use the headers of the environment in which you are. So when compiling with Mingw use the Mingw headers and when compiling with Visual C++ use the Visual C++ headers. As long as we don't use the Wine headers on Windows... Hopefully the Mingw headers will be complete enough for our tests. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
I use mingw with the wine headers for the winelib applications and dlls and it worked fine a few months back. Please use the WINELIB headers. We are using wine as our Win32 subsystem under reactos and I want to keep it as self-contained as possible. Mingw32s headers are very incompleate. This is a issue Jason and I discussed a little at wineconf. A good example is the comctrl headers, Mingw32's SUCK. If you want to use mingws header be prepard to send them a lot of patches. Also, certain changes to Winsock have made it a bitch for me to build the current tree under mingw and I've been too busy to track the problems down but have had a lack of time as of late. The DLLs wont work under windows/reactos anyway because of dll seperation issues. You will need to check 2 lines in include/basestd.h and I think include/windef.h and you can get almost everything to compile. I'm still having trouble linking resources built with wrc to the dlls/applications on mingw though. I will submit a patch or two over the next few weeks as I have time. Steven P.S. if you want to see how we have done our port with mingw, you can get our cvs information from reactos.com and just checkout wine instead of reactos.
-----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Francois Gouget Sent: Monday, April 08, 2002 1:24 AM To: Geoffrey Hausheer Cc: wine-devel(a)winehq.com Subject: Re: Running tests on windows
On Sun, 7 Apr 2002, Geoffrey Hausheer wrote:
Last week I submitted a perl script that makes a Makefile (and archive bundle) for building tests on Windows boxes under cygwin. Well, it works fine with mingw too (when using msys at least), but there is a snag.
In order to compile tests under Windows, I seem to need to include windows.h before any other .h files. I did this using the '-include' directive in gcc, but it requires knowledge of the absolute path to the windows.h file. This means I need to specify the path in the Makefile, which is completely non-portable (especialy with mingw which doesn't really have a default setup like cygwin does).
1) So it seems I have three options. I can append '#include <windows.h>' to each .c file (either wrapped in #define, or through the perl script)
2) I can include the entire wine /include directory in the archive, and use that 'windows.h' to build against.
3) I can just force the user to edit the Makefile to point to the correct include directory.
I don't really like any of these options (though 3 is the the easiest to implement, as this is how it works now)
So is there a better solution than the three I've listed?
I think I will work on extending your script to also generate Makefiles for use with Visual C++. The way it will work with Visual C++ is that you are supposed to run a batch script provided by Visual C++ (vcvars32.bat). This script sets a number of environment variables which point to the location of the headers, etc. and which you can also use in your Makefiles. Does Mingw provide something similar? Could we have a way of forcing the user to set some environment variables or query the values from him? (my batch-script skills are pretty rusty :-)
And why won't wine let me include 'windows.h', but under windows it is required?
Because winedows.h includes everythign and anything. We want Wine files to only include the headers they need. The problem is that the Wine tests are compiled as if they were part of the Wine sources instead of being compiled like Winelib applications, which they are. This means they are subject to the same restrictions as Wine sources: windows.h is forbidden, and Xxx is forbidden, you must use XxxA or XxxW (see IDI_APPLICATION & co for why this is a problem).
About using the Mingw headers vs. the Wine headers vs. Visual C++ headers. I say: use the headers of the environment in which you are. So when compiling with Mingw use the Mingw headers and when compiling with Visual C++ use the Visual C++ headers. As long as we don't use the Wine headers on Windows... Hopefully the Mingw headers will be complete enough for our tests.
-- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Monday 08 April 2002 00:23, Francois Gouget wrote:
I think I will work on extending your script to also generate Makefiles for use with Visual C++. The way it will work with Visual C++ is that you are supposed to run a batch script provided by Visual C++ (vcvars32.bat). This script sets a number of environment variables which point to the location of the headers, etc. and which you can also use in your Makefiles. Does Mingw provide something similar? Could we have a way of forcing the user to set some environment variables or query the values from him? (my batch-script skills are pretty rusty :-)
No mingw does not by default provide anything like that. We could force the user to set an environment variable pointing to the mingw root dir (but we might as well just have them change one line in the Makefile instead). Or we could do something really nasty and try to locate it by searching the path. I can do all of this in cygwin/(mingw w/ msys) using gnu-make specifics (which I think is a bad idea, since I was trying to keep the Makefile as portable as possible). Or maybe this can be done by launching make through a .bat file which locates the necessary headers, though I haven't written one for nearly 10 years, and am probably a bit rusty too.
About using the Mingw headers vs. the Wine headers vs. Visual C++ headers. I say: use the headers of the environment in which you are. So when compiling with Mingw use the Mingw headers and when compiling with Visual C++ use the Visual C++ headers. As long as we don't use the Wine headers on Windows... Hopefully the Mingw headers will be complete enough for our tests.
It sounds like it is not likely that mingw/cygwin headers will be complete enough for our needs (I already ran into this with OpenThread...which wine got wrong too). However, I was able to work around this for the tests I've written. As a middle gound, I will submit a patch for the perl script that allows the user to use either native or wine's headers. This should make everyone happy. Also, there is no reason not to submit patches to cygwin/mingw. If we ever get a reasonably thorough test suite, it would be just as valid for testing them as it is for testing wine. Of course we'd probably have to send them patches based on the X11 fork, since wine's headers are now all LGPLd (I haven't looked at the mingw/cygwin licenses) Thanks, .Geoff
participants (5)
-
Dmitry Timoshkov -
Francois Gouget -
Geoffrey Hausheer -
Shachar Shemesh -
Steven Edwards