New subject: .wine (was: Re: (long) From the front lines: 20050628 release impressions)

1 Jul 2005

      Hi,

This didn't seem appropriate for the user's list, as I don't intend to
report "problems" that I want "solved" but to provide an overview of how
the recent changes affect users like me -- for good (mostly) and ill--
in the Real World (TM).

First of all, good job! Last night I upgraded from 20050111 to 20050628
(wiped my .wine folder and uninstalled completely), and my first
impression is: snazzy!

This was the first time in a long time I've installed using
./tools/wineinstall from the source package (the ebuild isn't in Portage
yet, or wasn't last night, anyway), and I was pleased to find that it
went 99% perfectly.

What I loved (Install):

1. It compiled, no problems, errors, or hitches of any kind (and pretty
fast, too-- I wouldn't really have been able to watch that video it was
recommended I rent). This may have been true for a long time of course,
but it was New To Me using wineinstall, so I was happy.

2. It *asked me* about things I might want to change-- and didn't make
assumptions about its own detection!! No, I really don't have a Windows
drive, so you were right, but I don't want my c_drive in ~/.wine so put
it somewhere else, thank you very much. After all the discussion on
whichever list about wanting to put the c_drive somewhere else, it's
really nice to see that we can now do that. Of course the

Problem ?

is that since most users will be installing pre-compiled packages, the
install will probably just take the defaults (as it has done in the
past? Has this capability been available for months now?) rather than
proposing the questions, which is a real shame.

Other small disappointment:

I did request a config file:

Create local config file ~/.wine/config?
(yes/no) yes

....but did not get one:

Configuring Wine for a no-windows install in
/home/motub/local_games/wine/drive_c...
/home/motub/.wine updated successfully.
cp: cannot stat `documentation/samples/config': Onbekend bestand of map

Created /home/motub/.wine/config using default Wine configuration.
You probably want to review the file, though.

cp: cannot stat `/tmp/wineinstall.conf': Onbekend bestand of map

Admittedly, I don't necessarily need one, now that we have winecfg, but
I still feel a bit insecure without one, and I did after all assent to
one when I was offered it. So I see that as a problem-- either the
install should not offer it, or it should be able to give it to you when
 you say yes to the offer. And it certainly shouldn't say that it gave
you a config file when it didn't!

But OK, it gives me an excuse to fire up Winecfg.

First of all, good job! I give it a 90% on all points (attractiveness,
understandablility, useability).

What I loved (Winecfg):

It works. No hitches, crashes, sloppy or missing text, it's snappy
(doesn't take an eon to do anything) and it is very much a "normal" app
insofar as it provides the type of feedback that I expect from an
application (buttons grey out and become active exactly as I would
expect, notably the "Apply" button), so I "know" (in the sense that a
user 'knows' anything) that the program is working.

It's pretty smart. The detection of my current environment seems good--
of course everything was 'correct', such as ALSA being selected in the
Audio section, but the important thing is that I the user believed that
winecfg had correctly selected the proper choice from a range of
possibilities, rather than just the first thing on the drop-down list. I
 could very well be wrong (having just tried the autodetection, and
therefore switched to OSS) but I *feel* nonetheless confident that, were
I using OSS (only) or aRTs, that would have been selected instead-- and
to a great extent, it's my belief that's important, rather than the
truth. Even if I am wrong, it's nice to see sufficient confidence in the
ALSA driver that it would be the default setting on a system like mine,
rather than OSS as it has been in the past. If the driver was so bad
that the OSS driver was far and away the better choice, even
alphabetization shouldn't/wouldn't save ALSA from being first on the
list (and thus the default for users who can't be bothered to configure
their systems).

It's pretty smart. Love the fact that I can set per-application defaults
in the program. I haven't installed any native DLLs yet, so the
Overrides are grayed out-- except for the text entry, so my impression
is that if there was an available DLL to appear in that menu, the dialog
would become active. This is supported by the 'not implemented yet' that
I saw in another section of winecfg. If something doesn't work, you
demonstrably mark it as not yet working, so being greyed out means what
it's supposed to mean-- "not active because the conditions have not been
met to activate" as opposed to "not working", or "half-working" or
$DEITY knows what. I appreciate that and it increases my confidence in
the application.

It's pretty smart-- or is it? OK, the Drives tab was kind of a mixed bag
for me. It works, and does what it says on the tin, as it were, but it
seems kind of inflexible, which threw me off somewhat.

Minor useablility niggle:

You have to select the drive letter to adjust any setting; clicking on
the drive's mapping in the list doesn't change the selection (but
decolors the active selection). This is really confusing, especially
since the mapping takes up a much bigger area than the drive letter, so
is more likely to be clicked-- and more especially if one has not shown
the expanded options, so you can see what you're actually working with.

Major useability niggle:

In the default setup, the D drive did not appear-- it was (as it has
been for some time) invisibly mapped to my CD-ROM device, but
incorrectly, so (it was mapped to /cdrom, which does not exist on my
system; my device is mounted at /media/cdrecorder).

Since the mapping was invisible (did not appear in winecfg's list, as in
fact no CD-ROM device did), I tried the 'Automatic detection' to see if
that would cause it to pop up. It did, since there's a mapping to
/media/cdrecorder in my /etc/fstab-- but so did everything else in my
/etc/fstab, much of which I did not want to be mapped as I don't expect
to be using certain mounts with Wine. Using autodetect,
/proc/sys/fs/binfmt_misc is mapped to the I drive, for goodness' sake!

But I can remove mappings, so I did that.... and then I had big gaps in
my drive lettering, which would make it difficult if not impossible to
remember which drive letter pointed to what mount or folder.
Unfortunately, only two of the eleven drives listed had an entry in the
expanded "Manual Installation=> Name" field that suggested that if I
changed the name there, it would change the drive letter; the other 9
drives were blank in that field. I found this alarming, so I renamed and
redirected the symlinks in a file manager the way I normally would.
Reopening winecfg afterwards displayed the changed settings properly
(which is good), but my impression was that I shouldn't have had to be
d*cking around with a file manager at all-- certainly if I wasn't
already familiar with Wine configuration, I would have had a mess on my
hands.

So fine, Wine was now configured; time to install and run a program. My
choice was Pretty Good Solitaire version 10.2.0 (trial version available
from http://www.goodsol.com ). In the past, this program always
installed fine, but would not run without DCOM installed, and with
oleaut32 overridden.

So first of all, good job! The OLE implementation is distinctly better!
The program installed fine (of course, it generally does), and this is
one of the apps that allows you to launch it at the end of the install.
So I did. And it ran! The trial version splash opened up "normally"
(meaning in a normal amount of time, and fully drawn). Some of the text
was displaced (the buttons were fine, but the message area some text was
on top of other text), but the buttons worked properly and I was able to
enter a username and serial number (still not with the right-click
"paste" command, which still causes a CTD, but ctrl-v worked perfectly
well), the data was accepted, and I was able to create a user and enter
the program.

That's pretty much where the good news ends, though-- the game menu text
(not the window text, but the game selector menus) is *huge* (it's
clear, it's legible, it's complete, it's just noticeably way too big),
and trying to select anything from any menu at all (window menu, game
selector, toolbar button) results in a

Run-time error '6':
overflow

[OK]

dialog. Clicking OK closes the program cleanly, leaving me looking at a
huge number of fixme: ole errors in the terminal.

So then I installed DCOM98 (I have a Win98 license, so I try to stick
with Win98 DLLs wherever possible), overriding ole32, oleaut32, and
rpcrt4, and then ran the program from the terminal with the same
overrides. It ran fine (naturally), but what surprised me was that the
game selector menu text was now displayed at a normal font size for my
resolution.

Now it was time to see if I could set a per-application override using
winecfg. This turned out to be confusing, and ultimately crashed winecfg
(!).

First I added the application on the Applications tab, but all that let
me do was set the Win version for that app-- I was not really clear if
having the application selected in the first tab would mean that
settings in subsequent tabs would apply to that application only. So I
removed PGS from the first tab, and went to the Libraries tab. I was
able to type 'oleaut32.dll' in the text field, and, as I had thought,
this activated the "Add" button, which then added oleaut32 (native,
builtin) correctly-- but then I thought that I was perhaps making that
the default setting, which I didn't want. So I removed that, and went to
restart the process by adding PGS again to the Applications tab. I
selected it fine (btw, *very* nice that the application's proper Windows
icon appears in the file browser-- the file browser is also much, *much*
faster), but when I hit OK to add it, winecfg crashed:

winecfg
fixme:winecfg:mode_to_label translate mewine: Unhandled exception
(thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on read access to 0x00000000 in 32-bit
code (0x41b26a33).
In 32 bit mode.
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
 EIP:41b26a33 ESP:7ba8cf94 EBP:7bab3820 EFLAGS:00010202(   - 00      - -RI1)
 EAX:00000056 EBX:41be7ff4 ECX:7badbfe8 EDX:00000076
 ESI:00000000 EDI:00000056
Stack dump:
0x7ba8cf94:  7bab74ac 7bc88810 7babf290 7ba8cfdc
0x7ba8cfa4:  7bab0e9c 7bab3820 00000000 7bc88fe0
0x7ba8cfb4:  7bab5ecb 7ba8cfcc 7bab74ac 7bab2029
0x7ba8cfc4:  7babefd4 7bab5ecb 7bc88ec8 7bab74ac
0x7ba8cfd4:  7bab3c29 00010036 7ba8d754 7baaaa54
0x7ba8cfe4:  00000044 7bc88fe0 7bab3820 7bab3c29
Backtrace:
=>1 0x41b26a33 __strcasecmp+0x43 in libc.so.6 (0x7bab3820)
0x41b26a33 __strcasecmp+0x43 in libc.so.6: movzbl	0x0(%esi),%eax
Modules:
Module	Address			Debug info	Name (60 modules)
ELF	0x41a9e000-41ab7000	Deferred        ld-linux.so.2
ELF	0x41ab9000-41bec000	Export          libc.so.6
ELF	0x41bee000-41c14000	Deferred        libm.so.6
ELF	0x41c16000-41c1a000	Deferred        libdl.so.2
ELF	0x41c1c000-41ce9000	Deferred        libx11.so.6
ELF	0x41ceb000-41cfa000	Deferred        libxext.so.6
ELF	0x41cfc000-41d0d000	Deferred        libz.so.1
ELF	0x41d0f000-41d22000	Deferred        libpthread.so.0
ELF	0x41d24000-41d2d000	Deferred        libsm.so.6
ELF	0x41d2f000-41d46000	Deferred        libice.so.6
ELF	0x41d48000-41dbb000	Deferred        libfreetype.so.6
ELF	0x41dbd000-41ddd000	Deferred        libexpat.so.0
ELF	0x41ddf000-41e06000	Deferred        libfontconfig.so.1
ELF	0x41e12000-41e1a000	Deferred        libxrender.so.1
ELF	0x41eb3000-41eb9000	Deferred        libxxf86dga.so.1
ELF	0x41f0a000-41f13000	Deferred        libxcursor.so.1.0.2
ELF	0x41f15000-41f19000	Deferred        libxrandr.so.2
ELF	0x42047000-42050000	Deferred        libgcc_s.so.1
ELF	0x422c8000-42380000	Deferred        libgl.so.1
ELF	0x42605000-4261d000	Deferred        libnsl.so.1
ELF	0x4261f000-42628000	Deferred        librt.so.1
ELF	0x43010000-43015000	Deferred        libxxf86vm.so.1
ELF	0x7b3f3000-7b41b000	Deferred        winspool.drv<elf>
  \-PE	0x7b400000-7b41b000	\               winspool.drv
ELF	0x7b41b000-7b4da000	Deferred        comctl32<elf>
  \-PE	0x7b430000-7b4da000	\               comctl32
ELF	0x7b4da000-7b4fa000	Deferred        iphlpapi<elf>
  \-PE	0x7b4e0000-7b4fa000	\               iphlpapi
ELF	0x7b4fa000-7b545000	Deferred        rpcrt4<elf>
  \-PE	0x7b510000-7b545000	\               rpcrt4
ELF	0x7b545000-7b5d4000	Deferred        gdi32<elf>
  \-PE	0x7b560000-7b5d4000	\               gdi32
ELF	0x7b5d4000-7b707000	Deferred        user32<elf>
  \-PE	0x7b600000-7b707000	\               user32
ELF	0x7b707000-7b749000	Deferred        advapi32<elf>
  \-PE	0x7b720000-7b749000	\               advapi32
ELF	0x7b749000-7b7d8000	Deferred        ole32<elf>
  \-PE	0x7b760000-7b7d8000	\               ole32
ELF	0x7b7d8000-7b837000	Deferred        shlwapi<elf>
  \-PE	0x7b7f0000-7b837000	\               shlwapi
ELF	0x7b837000-7b900000	Deferred        shell32<elf>
  \-PE	0x7b850000-7b900000	\               shell32
ELF	0x7b900000-7b990000	Deferred        comdlg32<elf>
  \-PE	0x7b910000-7b990000	\               comdlg32
ELF	0x7ba96000-7bac0000	Deferred        winecfg<elf>
  \-PE	0x7baa0000-7bac0000	\               winecfg
ELF	0x7bb0f000-7bc20000	Deferred        kernel32<elf>
  \-PE	0x7bb40000-7bc20000	\               kernel32
ELF	0x7bd37000-7bd42000	Deferred        libnss_files.so.2
ELF	0x7bd42000-7bd4d000	Deferred        libnss_nis.so.2
ELF	0x7bd4d000-7bd58000	Deferred        libnss_compat.so.2
ELF	0x7bd74000-7be69000	Deferred        libwine_unicode.so.1
ELF	0x7be85000-7bf00000	Deferred        ntdll<elf>
  \-PE	0x7bea0000-7bf00000	\               ntdll
ELF	0x7bf00000-7bf03000	Deferred        <wine-loader>
ELF	0x7f852000-7f856000	Deferred        iso8859-15.so
ELF	0x7f878000-7ff7a000	Deferred        fglrx_dri.so
ELF	0x7ff7a000-80000000	Deferred        winex11.drv<elf>
  \-PE	0x7ff90000-80000000	\               winex11.drv
ELF	0xb7fcb000-b7fe4000	Deferred        libwine.so.1
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) c:\windows\system\winecfg.exe
	00000009    0 <==
WineDbg terminated on pid 0x8

... maybe that means something to you.

I reopened winecfg, and added and selected goodsol.exe again. *Now* I
see that the titlebar changes to "Wine configuration for goodsol.exe" as
I progress through the other tabs! That's actually quite nifty, but who
really looks at their titlebar? I wish I could think of a more "in your
face" indication that I was now creating a per-application setting
rather than a default one, but I can't, so this will have to do (and it
is, after all, nifty).

So I added ole32 and oleaut32 (at first with .dll, but then I took that
out), saved and ran just plain old wine goodsol.exe (I was in the
directory), and it ran properly.

So winecfg does that right, too. PGS is the only app I've tried so far,
and the only problem I've found is that I usually run with the game's
sound off, but I turned it on to test and the game essentially slowed to
a crawl when dealing the cards, then redraw seemed to hang (I switched
desktops, and when I came back I had only a titlebar, no game window.

All it said in the terminal was

ALSA lib pcm_dmix.c:746:(snd_pcm_dmix_open) The dmix plugin supports
only playback stream

I then set a per-application setting using winecfg that this application
should use OSS, and that solved it.

So the long and the short of it is that winecfg does make it easier for
you to solve many of these problems and configure Wine properly
(excepting registry entry creation issues), but it doesn't make it any
easier to recognize what the problem in fact is-- you still have to be
able to figure that out yourself and know what needs to be done. But
once you do, winecfg makes putting it all together much easier, and is,
in and of itself, a real nice app.

Wine has also incorporated noticeable improvements, which I could see
even in this very limited test, so while I expect that apps I commonly
run will still encounter problems, I feel that things are on the upswing
once again and that, during the upcoming months, I will see more
problems I currently have melting away... which is just what I, as a
user, want to see, and how I want to feel when I install a new Wine.

So thanks!! Good work!! And I hope that this feedback is useful to you.

Holly

(long) From the front lines: 20050628 release impressions

Holly Bostick

Michael Jung

Holly Bostick

Paul van Schayck

Jules Richardson

wino＠piments.com

Scott Ritchie

tags

participants (6)