Wine Experiences

[wine at baker-net.org.uk]

I've been experimenting with wine for a few weeks now and thought I'd write 
down my experiences in case they are of use to others.

First of all I should say that I'm using Suse 8.1 (2.4.19 kernel) and have 
been using LGPL wine from CVS, building it myself and using fake_windows. I 
have also got a Win98 install on this machine but find I don't need to boot 
it too often.

Generally it seems to do pretty well in terms of the number of programs that 
work well enough to be useable, the biggest issue is in finding up to date 
documentation on how to configure things as google usually comes up with out 
of date instructions. e.g.:

The general view seems to be that although Wine works best with Win9x DLLs it 
behaves more like NT in a lot of respects so getting it to tell programs it 
is Noften helps, especially if the program tries to use VxDs on 9x. Lots of 
comments suggest using "-winver nt40" to acheive this but the current way to 
do it is to include a [Version] section in the wine config file that contains
"Windows" = "nt40"

Another example, the DLL load order in the config file changed recently so 
that so is no longer a supported type. Wine's error message for this isn't 
very informative as to where the problem is - if anyone else feels the same 
way here is the code change I put in my copy
diff -r1.62 loadorder.c
458c458
<        ERR("Invalid load order module-type %s, ignored\n", debugstr_w(str));
---
>        ERR("Invalid load order module (%s), type (%s), ignored\n", module, 
debugstr_w(str));

It also took me a while to realise that the reason all of my attempts to 
access the ASPI layer were failing was because only root had access to the 
generic SCSI devices - I guess there isn't much that can be done about that. 
Exact Audio Copy did seem to work succesfully once it was setup so that's 
another useful program that runs.

Yet another example, I've found various description on how to set up a printer 
that uses gimp-print rather than going direct to CUPS but they seem to be 
based on an old version. The generic postscript driver doesn't seem to handle 
many advanced printer features even if they are in the PPD so that provides a 
good way of controlling things like what paper type and feed options you 
want. If no-one knows of a good description of how to set that up these days 
I might have a go at doing it then try to document it.

One issue that I have is whether strating the debugger is really the right 
action for wine_unimplemented. One program I use tries to use some 
functionality in CTL3D32.DLL that isn't implemented in the builtin version. 
Starting up the debugger just for it to announce that it has fallen over on a 
wine_unimplemented call seems a bit of a waste of time and means that if the 
debugger isn't set up properly you can't see what is wrong - do other people 
think that an appropriate message to stderr followed by an exit would be more 
helpful?

The next problem I've encountered also involves CTL3D32.DLL. Once I've 
specified to use the native version then when a program that uses it crashes 
the debugger falls over trying to load symbols for CTL3D32.DLL. It then 
starts another copy of winedbg to debug the first one with. As I start using 
the second winedbg to try and work out what is going on that falls over when 
I try to print the values of some of the variables that are causing a problem 
and dumps me into gdb.  For now I've just made the assumption that no native 
DLLs are likely to contain any useful debug info so told it not to load it 
with the following change:
diff -r1.1 msc.c
3064c3064,3065
<         dil = DEBUG_ProcessDebugDirectory( module, file_map, mpd_dbg, nDbg);
---
>         dil = DIL_NOINFO; /*DEBUG_ProcessDebugDirectory( module, file_map,
> mpd_dbg, nDbg );*/
if anyone wants to look at this I'd suspect the fixme comments starting at 
line 3041 in msc.c and the following stack backtrace are the place to start 
looking.
Wine-dbg>where
Backtrace:
=>0 0x404c3723 (DEBUG_ProcessDebugDirectory+0x23(module=0x3d681e48, 
file_map=0x40810000, dbg=0x4081b000, nDbg=0x1) [msc.c:2861] in 
winedbg.exe.so) (ebp=40712ae4)
  1 0x404c3b3b (DEBUG_RegisterMSCDebugInfo+0x25b(module=0x3d681e48, 
hFile=0x38, _nth=0x40712ba0, nth_ofs=0x80) [msc.c:3064] in winedbg.exe.so) 
(ebp=40712b3c)
  2 0x404c03db (DEBUG_LoadModule32+0x1ab(name=0x40712cc8, hFile=0x38, 
base=0x7ec50000) [module.c:307] in winedbg.exe.so) (ebp=40712cac)
  3 0x404cb85b (.L274+0x5a [winedbg.c] in winedbg.exe.so) (ebp=40712dd4)
  4 0x404cbb72 (DEBUG_MainLoop+0x52 [winedbg.c:928] in winedbg.exe.so) 
(ebp=40712e48)
  5 0x404cbf38 (main+0x108(argc=0x3, argv=0xbffff380) [winedbg.c:1161] in 
winedbg.exe.so) (ebp=40712e80)
  6 0x404b3177 (__wine_exe_main+0x37 [winedbg.exe.spec.c:544] in 
winedbg.exe.so) (ebp=40712e94)
  7 0x400a3a44 (start_process+0x234 [process.c:566] in libntdll.dll.so) 
(ebp=40712f30)
  8 0x400a7d0a (call_on_thread_stack+0x7a(func=0x400a3810) [sysdeps.c:171] in 
libntdll.dll.so) (ebp=40712ff4)
  9 0x400a7e70 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000)

Wine-dbg>print dbg[0]
{Characteristics=*** Invalid address 0x4081b000 (_end+0x14a44)
, TimeDateStamp=*** Invalid address 0x4081b004 (_end+0x14a48)
, MajorVersion=*** Invalid address 0x4081b008 (_end+0x14a4c)
, MinorVersion=*** Invalid address 0x4081b00a (_end+0x14a4e)
, Type=*** Invalid address 0x4081b00c (_end+0x14a50)
, SizeOfData=*** Invalid address 0x4081b010 (_end+0x14a54)
, AddressOfRawData=*** Invalid address 0x4081b014 (_end+0x14a58)
, PointerToRawData=*** Invalid address 0x4081b018 (_end+0x14a5c)
}

Wine-dbg>print i
0
Wine-dbg>print nDbg
1
Wine-dbg>print *module
{load_addr=0x7ec50000, size=69632, 
module_name="C:\WINDOWS\SYSTEM\CTL3D32.DLL", dil=DIL_DEFERRED, type=DMT_PE,
wine_dbg_cmd: Exception c0000005

If anyone is still reading I'll point out another gotcha with the latest CVS - 
When building the D3D8 DLL a few OpenGL functions are called which only 
appear to be in libGL.a and not libGL.so. In order to get it to link I had to 
link with the static library but I'm not sure if that will cause problems if 
other code is linked with the shared version. The functions affected are all 
of the glMultiTexCoord?f(...) ones in device.c

Finally a couple of observations that it might not be beyond my skills to fix 
if other people have the same problems. When applications try to flash the 
title bar - presumably by calling FlashWindow it doesn't seem to do anything 
and setting a maximum window size seems to be ignored. (This is using KDE - 
whether this works could be window manager dependent.) Of course I'll need a 
Windows development environment to test this, preferably one that works under 
wine. I had been using cygwin under Win98 so that will probably be the first 
thing I try.