April 2002 - Wine-Devel - list.winehq.org

Re: Running tests on windows

by Francois Gouget

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.

April 8, 2002

Re: mIRC fails to start (Wine CVS 20020407)

by mdew

my error...ignore it :) > heres a debug report.... > > > [01:40pm 08-Apr-02]$ /usr/bin/wine --winver=nt2k -debugmsg +relay > ./mirc32.exe > 0806fcf8:Call kernel32.__wine_register_dll_16(40615c7c) ret=406131b4 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40615c7c > ret=406131b4 > 0806fcf8:Call kernel32.__wine_register_dll_16(4033c854) ret=40337460 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4033c854 > ret=40337460 > Warning: loading builtin kernel32.dll, but native version already > present. Expect trouble. > 0806fcf8:Call kernel32.__wine_register_dll_16(4063a648) ret=4062e8a0 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4063a648 > ret=4062e8a0 > 0806fcf8:Call kernel32.__wine_register_dll_16(409edc20) ret=409b40ec > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409edc20 > ret=409b40ec > 0806fcf8:Call kernel32.__wine_register_dll_16(409edf28) ret=409b439c > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409edf28 > ret=409b439c > 0806fcf8:Call kernel32.__wine_register_dll_16(409ee0e0) ret=409b4504 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee0e0 > ret=409b4504 > 0806fcf8:Call kernel32.__wine_register_dll_16(409ee1f0) ret=409b45bc > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee1f0 > ret=409b45bc > 0806fcf8:Call kernel32.__wine_register_dll_16(409ee3d4) ret=409b4724 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee3d4 > ret=409b4724 > 0806fcf8:Call kernel32.__wine_register_dll_16(409eebe4) ret=409b4ee8 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409eebe4 > ret=409b4ee8 > 0806fcf8:Call kernel32.__wine_register_dll_16(409f1214) ret=409b6918 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409f1214 > ret=409b6918 > 0806fcf8:Call kernel32.__wine_register_dll_16(409949d0) ret=4094e774 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409949d0 > ret=4094e774 > 0806fcf8:Call kernel32.__wine_register_dll_16(4092d46c) ret=408df1f8 > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4092d46c > ret=408df1f8 > 0806fcf8:Call kernel32.__wine_register_dll_16(40ab6ec8) ret=40a72a6c > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40ab6ec8 > ret=40a72a6c > 0806fcf8:Call kernel32.__wine_register_dll_16(40ab7290) ret=40a72c7c > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40ab7290 > ret=40a72c7c > 0806fcf8:Call kernel32.__wine_register_dll_16(40b00ba0) ret=40ad409c > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40b00ba0 > ret=40ad409c > 0806fcf8:Call kernel32.__wine_register_dll_16(40b00e54) ret=40ad42ec > 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40b00e54 > ret=40ad42ec > 0806fcf8:Call PE DLL (proc=0x405d01ec,module=405c0000,type=1,res=0x1) > 0806fcf8:Call PE DLL (proc=0x4080f1ec,module=407ff000,type=1,res=(nil)) > 0806fcf8:Ret PE DLL (proc=0x4080f1ec,module=407ff000,type=1,res=(nil)) > retval=1 > 0806fcf8:Ret PE DLL (proc=0x405d01ec,module=405c0000,type=1,res=0x1) > retval=1 > 0806fcf8:Call PE DLL (proc=0x4078dd30,module=40780000,type=1,res=0x1) > 0806fcf8:Ret PE DLL (proc=0x4078dd30,module=40780000,type=1,res=0x1) > retval=1 > 0806fcf8:Call PE DLL (proc=0x40684eb8,module=40667000,type=1,res=0x1) > Warning: loading builtin user32.dll, but native version already present. > Expect trouble. > 0806fcf8:Call PE DLL (proc=0x40c0aea8,module=40bed000,type=1,res=(nil)) > 0806fcf8:Call x11drv.CreateDC(40362fc0,40566930 > "DISPLAY",00000000,00000000,00000000) ret=4079fa81 > wine: Unhandled exception, starting debugger... > err:seh:start_debugger Couldn't start debugger ((null)) (127) > Read the Wine Developers Guide on how to set up winedbg or another > debugger > Wine failed with return code 5 > > > aswell as my previous report on Usenet.. > http://groups.google.co.nz/groups?q=mirc+group:comp.emulators.ms-windows.wi… > > > > -- ph33r! Linux mdew 2.4.18-xfs #1 Sun Mar 31 15:53:58 NZST 2002 i686 unknown

April 7, 2002

mIRC fails to start (Wine CVS 20020407)

by mdew

heres a debug report.... [01:40pm 08-Apr-02]$ /usr/bin/wine --winver=nt2k -debugmsg +relay ./mirc32.exe 0806fcf8:Call kernel32.__wine_register_dll_16(40615c7c) ret=406131b4 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40615c7c ret=406131b4 0806fcf8:Call kernel32.__wine_register_dll_16(4033c854) ret=40337460 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4033c854 ret=40337460 Warning: loading builtin kernel32.dll, but native version already present. Expect trouble. 0806fcf8:Call kernel32.__wine_register_dll_16(4063a648) ret=4062e8a0 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4063a648 ret=4062e8a0 0806fcf8:Call kernel32.__wine_register_dll_16(409edc20) ret=409b40ec 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409edc20 ret=409b40ec 0806fcf8:Call kernel32.__wine_register_dll_16(409edf28) ret=409b439c 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409edf28 ret=409b439c 0806fcf8:Call kernel32.__wine_register_dll_16(409ee0e0) ret=409b4504 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee0e0 ret=409b4504 0806fcf8:Call kernel32.__wine_register_dll_16(409ee1f0) ret=409b45bc 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee1f0 ret=409b45bc 0806fcf8:Call kernel32.__wine_register_dll_16(409ee3d4) ret=409b4724 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409ee3d4 ret=409b4724 0806fcf8:Call kernel32.__wine_register_dll_16(409eebe4) ret=409b4ee8 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409eebe4 ret=409b4ee8 0806fcf8:Call kernel32.__wine_register_dll_16(409f1214) ret=409b6918 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409f1214 ret=409b6918 0806fcf8:Call kernel32.__wine_register_dll_16(409949d0) ret=4094e774 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=409949d0 ret=4094e774 0806fcf8:Call kernel32.__wine_register_dll_16(4092d46c) ret=408df1f8 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=4092d46c ret=408df1f8 0806fcf8:Call kernel32.__wine_register_dll_16(40ab6ec8) ret=40a72a6c 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40ab6ec8 ret=40a72a6c 0806fcf8:Call kernel32.__wine_register_dll_16(40ab7290) ret=40a72c7c 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40ab7290 ret=40a72c7c 0806fcf8:Call kernel32.__wine_register_dll_16(40b00ba0) ret=40ad409c 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40b00ba0 ret=40ad409c 0806fcf8:Call kernel32.__wine_register_dll_16(40b00e54) ret=40ad42ec 0806fcf8:Ret kernel32.__wine_register_dll_16() retval=40b00e54 ret=40ad42ec 0806fcf8:Call PE DLL (proc=0x405d01ec,module=405c0000,type=1,res=0x1) 0806fcf8:Call PE DLL (proc=0x4080f1ec,module=407ff000,type=1,res=(nil)) 0806fcf8:Ret PE DLL (proc=0x4080f1ec,module=407ff000,type=1,res=(nil)) retval=1 0806fcf8:Ret PE DLL (proc=0x405d01ec,module=405c0000,type=1,res=0x1) retval=1 0806fcf8:Call PE DLL (proc=0x4078dd30,module=40780000,type=1,res=0x1) 0806fcf8:Ret PE DLL (proc=0x4078dd30,module=40780000,type=1,res=0x1) retval=1 0806fcf8:Call PE DLL (proc=0x40684eb8,module=40667000,type=1,res=0x1) Warning: loading builtin user32.dll, but native version already present. Expect trouble. 0806fcf8:Call PE DLL (proc=0x40c0aea8,module=40bed000,type=1,res=(nil)) 0806fcf8:Call x11drv.CreateDC(40362fc0,40566930 "DISPLAY",00000000,00000000,00000000) ret=4079fa81 wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ((null)) (127) Read the Wine Developers Guide on how to set up winedbg or another debugger Wine failed with return code 5 aswell as my previous report on Usenet.. http://groups.google.co.nz/groups?q=mirc+group:comp.emulators.ms-windows.wi…

April 7, 2002

winver

by Rizsanyi Zsolt

Hi! I have tried to run my program with --winver nt40. And it was ok But when I started the program by the means of setup.exe (its the autorun program on a cd which detects if the program is already installed, and automatically starts it), then the program was not running like it had got the winver argument. It was looking for VxD only used in win9x mode (the output is same as if I run it without --winver). Interestingly I have also noticed that when I start the program through setup.exe it is not managed, although I have managed mode set in ~/.wine/config I think that the processes created by other executables get the hardcoded options, and not from the configuration. Also winver option in the config file would be useful. Best regards Zsolt Rizsanyi

April 7, 2002

Re: Running tests on windows

by Geoffrey Hausheer

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

April 7, 2002

Re: Running tests on windows

by Dmitry Timoshkov

"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.

April 7, 2002

Running tests on windows

by Geoffrey Hausheer

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

April 7, 2002

Re: How to debug an exception handler ?

by Eric Pouech

> I get this when I try pass. > > Wine-dbg>pass > Invalid address for breakpoint 1, disabling it > Invalid address for breakpoint 2, disabling it > Invalid address for breakpoint 3, disabling it > Invalid address for breakpoint 4, disabling it > Process of pid=08071a50 has terminated > > The process shouldn't terminate so fast. this should be fixed in latest CVS. A+

April 7, 2002

Re: MAC WINE Project?

by Robert Claeson

nog wrote: > Lonnie Cumberland wrote: > >> Hello All, >> >> Could someone please tell me if there is a MAC WINE type project that >> would use native libraries to run MAC applications on Linux without >> having to install the MAC OS? >> >> I was just courious if one existed, >> thanks, >> Lonnie >> > Have a look at macehq.cjb.net. Its not complete by any means ( havent > been able to run a single application in it ) but it might be worth a look. Yellowdog Linux for Mac contains something Wine-like that is able to run MacOS apps under Linux. I guess it's the same as the stuff on macehq.cjb.net, but just in case it isn't... /roc

April 7, 2002

Re: MAC WINE Project?

by nog

Lonnie Cumberland wrote: >Hello All, > >Could someone please tell me if there is a MAC WINE type project that >would use native libraries to run MAC applications on Linux without >having to install the MAC OS? > >I was just courious if one existed, >thanks, >Lonnie > Have a look at macehq.cjb.net. Its not complete by any means ( havent been able to run a single application in it ) but it might be worth a look.

April 7, 2002