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.