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

Re: ChangeSet ID: 10178643640749867230924828 - oops.

by Huw D M Davies

On Sat, Apr 06, 2002 at 10:49:55PM -0500, lawson_whitney(a)juno.com wrote: > Log message: > Huw D M Davies <hdavies(a)codeweavers.com> > The horizontal dialog base unit is calculated as the straight average > of a-z,A-Z (tmAveCharWidth is supposed to be a weighted average > according to character usage, so we shouldn't use this). > > Good day! > > I don't pay much attention to GUI, or care much about it, but I noticed > this patch causes my app to display a progress bar (?) with the title > folded down into the progress bar, so it looks kind of lame. > > % xx > transferred: > > Without the patch, it looks more like: > > % transferred: xx > > I have no idea what this app looks like in Windows. I have never run it > with Windows, and I have no intention to buy Windows just to see, but I > think we might not want this bit of code to stay exactly as it is. > > I will gladly make any kind of traces you would like to see, or I can > live with it. The app is in fact obsolete win9x, but it is the most > recent version that can work a modem without requiring DUN or RAS or > some dam' thing. Hmmm, I wonder if a more recent version has the same > problem? Let me check... Hi Lawson, Are you using client side or server side (X11) fonts ? Huw.

April 8, 2002

Re: posting wineconf info to slashdot?

by Michael Cardenas

Steven Edwards wrote: >When is the reactos presentation going to be put up? I know it wasn't >the greatest in the world but we were on the guest list. =P > We haven't really gotten the presentations that were sent to us put up anywhere, because we were busy with our release. We released sp2 on friday, so I'll be getting the presentations put up this week and will be getting the details of the attendees' insider accounts sent out to everyone. michael

April 8, 2002

Re: [PATCH] async IO API, reworked

by Martin Wilck

Dear Alexandre, > > - separate cleanly between async scheduling and file IO related issues, > > - make the API compatible with other types of async requests (e.g. for sockets), > > - remove exports of async IO related functions for DLL separation. > > You cannot add private headers to work around the dll separation > restrictions, this only hides the dependencies between dlls it doesn't > solve them... I have applied the patch for now, but the async.h file > will have to go away eventually (or the functionality will need to be > "officially" exported from ntdll). What would be the correct solution, then? If I understand you right, each DLL that uses async IO must have its own implementation of async calls, i.e. not rely on anything implemented in ntdll except for the officially exported windows functions. To achieve that, we can put functionally equivalent code into each DLL's sources, or we can provide a header that defines only static functions - as the first version of my patch did. That approach has the advantage that we won't have to repeat the same code in source files of different DLLs. What would be wrong with that? The second version I sent (with check_async_list called automatically from call_apcs) re-introduces a hidden dependency on ntdll - obviously async calls from other DLLs won't work anymore if a native ntdll is used. That may be a step back. Still I cannot see a problem with the "static-only" header I used in the first version - can you explain that to me? Martin PS does anybody have an idea how Windows itself handles this, i.e. if the async calls in e.g. the Winsock API call ntdll functions internally? After all, it seems to be legitimate to mix ReadFile() and WSARecv() calls on sockets, although it would certainly be bad programming style. If we could only conceive of a way to implement async calls only on top of "official" windows functions... -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 8, 2002

Re: Running tests on windows

by Shachar Shemesh

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.

April 8, 2002

RE: Running tests on windows

by Steven Edwards

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

April 8, 2002

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 8, 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 8, 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 8, 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 8, 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 8, 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 8, 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

Re: ChangeSet ID: 10178643640749867230924828 - oops.

by lawson_whitney＠juno.com

On Sat, 6 Apr 2002 whit(a)giftie.alien.org wrote: > Hmmm, I wonder if a more recent version has the same > problem? Let me check... As it happens, Juno version 4 puts the title under the progress bar, Transferred xx% and the patch doesn't cause it to fold. Maybe it isn't important, but if you would like to debug Juno version 2 I will be glad to help. Regards, Lawson | We apologize if this message has reached you in error. | Save the Planet, Save the Trees! Advertise via E mail.

April 7, 2002

MAC WINE Project?

by Lonnie Cumberland

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 -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

April 7, 2002

ChangeSet ID: 10178643640749867230924828 - oops.

by lawson_whitney＠juno.com

Log message: Huw D M Davies <hdavies(a)codeweavers.com> The horizontal dialog base unit is calculated as the straight average of a-z,A-Z (tmAveCharWidth is supposed to be a weighted average according to character usage, so we shouldn't use this). Good day! I don't pay much attention to GUI, or care much about it, but I noticed this patch causes my app to display a progress bar (?) with the title folded down into the progress bar, so it looks kind of lame. % xx transferred: Without the patch, it looks more like: % transferred: xx I have no idea what this app looks like in Windows. I have never run it with Windows, and I have no intention to buy Windows just to see, but I think we might not want this bit of code to stay exactly as it is. I will gladly make any kind of traces you would like to see, or I can live with it. The app is in fact obsolete win9x, but it is the most recent version that can work a modem without requiring DUN or RAS or some dam' thing. Hmmm, I wonder if a more recent version has the same problem? Let me check... Regards, Lawson ---oof---

April 7, 2002

Re: How to debug an exception handler ?

by Laurent Pinchart

> [...] > > > I was wondering if it was a bug or a normal behaviour, and if it is > > normal behaviour, is there a workaround ? > > Did you try pass? Sorry, spoke too fast :-( 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. Laurent Pinchart

April 6, 2002

Re: How to debug an exception handler ?

by Laurent Pinchart

> > I was wondering if it was a bug or a normal behaviour, and if it is > > normal behaviour, is there a workaround ? > > Did you try pass? > > See: > http://wine.codeweavers.com/docs/wine-devel/dbg-commands.shtml#AEN576 I had missed it. Thanks a lot. Laurent Pinchart

April 6, 2002

Re: How to debug an exception handler ?

by Francois Gouget

On Sat, 6 Apr 2002, Laurent Pinchart wrote: [...] > I was wondering if it was a bug or a normal behaviour, and if it is normal > behaviour, is there a workaround ? Did you try pass? See: http://wine.codeweavers.com/docs/wine-devel/dbg-commands.shtml#AEN576 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

April 6, 2002

Re: How to debug an exception handler ?

by Laurent Pinchart

> >I have a windows program which raises an exception as part of its normal > >execution (it tries to call int 0x01). The program setups an exception > >handler, catches the exception, and resumes it execution after the call to > >int 0x01. This works fine when run in wine. > > > >However, when I try to run the program in winedbg, the debugger catches > > the exeception, interrupts the program execution, prints a register dump, > > stack dump & backtrace, and waits. If I continue the execution using > > 'cont' (after incrementing $eip by 2 to skip int 0x01), the program > > continues but the exception handler installed bu the user program is not > > called. > > > >I was wondering if it was a bug or a normal behaviour, and if it is normal > >behaviour, is there a workaround ? > > > > Keep in mind that I am NOT a wine guru but it looks like copy protection > to me. My guess it you use trace relay the same thing will occure as > when you use the debugger. Thanks for your answer, but I want to use the debugger because I need to put a breakpoint at some point in the code and check some register values there. Laurent Pinchart PS: Yes, it's copy protection

April 6, 2002

Re: How to debug an exception handler ?

by Tony Lambregts

Laurent Pinchart wrote: >Hi everybody, > >I have a windows program which raises an exception as part of its normal >execution (it tries to call int 0x01). The program setups an exception >handler, catches the exception, and resumes it execution after the call to >int 0x01. This works fine when run in wine. > >However, when I try to run the program in winedbg, the debugger catches the >exeception, interrupts the program execution, prints a register dump, stack >dump & backtrace, and waits. If I continue the execution using 'cont' (after >incrementing $eip by 2 to skip int 0x01), the program continues but the >exception handler installed bu the user program is not called. > >I was wondering if it was a bug or a normal behaviour, and if it is normal >behaviour, is there a workaround ? > >Thanks in advance for your help. > >Laurent Pinchart > > Keep in mind that I am NOT a wine guru but it looks like copy protection to me. My guess it you use trace relay the same thing will occure as when you use the debugger. Tony Lambregts

April 6, 2002

How to debug an exception handler ?

by Laurent Pinchart

Hi everybody, I have a windows program which raises an exception as part of its normal execution (it tries to call int 0x01). The program setups an exception handler, catches the exception, and resumes it execution after the call to int 0x01. This works fine when run in wine. However, when I try to run the program in winedbg, the debugger catches the exeception, interrupts the program execution, prints a register dump, stack dump & backtrace, and waits. If I continue the execution using 'cont' (after incrementing $eip by 2 to skip int 0x01), the program continues but the exception handler installed bu the user program is not called. I was wondering if it was a bug or a normal behaviour, and if it is normal behaviour, is there a workaround ? Thanks in advance for your help. Laurent Pinchart

April 6, 2002

Windows NT, int 0x01 & EXCEPTION_ACCESS_VIOLATION

by Laurent Pinchart

Hi everybody, It seems that calling int 0x01 on windows NT should raise an EXCEPTION_ACCESS_VIOLATION instead of EXCEPTION_PRIV_INSTRUCTION. Could anyone confirm ? (I don't know how to test it. Calling the interruption is trivial, but how does a user program test the exception type ?) Laurent Pinchart

April 6, 2002