Can you explain again what are you trying to do? You running vnc4server where?
What different window managers has anything to do with this?

Also please attach text file with complete terminal output, including command
you used to start Wine (as attachment, not link to external screen grab).

Created attachment 7161 [details]
tracelog

Hi
same problem here.
System: debian etch, AMD Duron 1000 CPU, 4MB graphics adapter
tried to start winecfg from a vncserver with only twm running (~/.wine
non-existant yet)

As soon as I hit enter, I get the "Wine Launch Window", then the trace runs by
and then I get "Wine exited with a successful status". I'd be happy to provide
you with more information.

Just in case: I've had a similar problem earlier. First I tried to re-compile
wine w/o OpenGL support. While that ran fine, I wasn't happy mixing my debian
with non-dpkg installations...so I played around a little and found out that
the error back then only occured when the VNC client was set to 24bit. At 256
or even less colors, everything went fine out-of-the-box. A simple entry in
user.reg helped:

[Software\\Wine\\X11 Driver]
"DesktopDoubleBuffered"="N"

Sadly it doesn't now...

cya

Daniel

Ah someone who is suffering from wine not supporting single buffering anymore.

Near line 437 in dlls/winex11.drv/x11drv_main.c you'll see:
    /* If OpenGL is available, change the default visual, etc as necessary */
    if ((desktop_vi = X11DRV_setup_opengl_visual( display )))

try to skip that line by changing it to lets say:
    /* If OpenGL is available, change the default visual, etc as necessary */
    if (0 && (desktop_vi = X11DRV_setup_opengl_visual( display )))

Hi Rod,

great, your "patch" worked!

Yesterday I tried compiling with ./configue --without-opengl but clearly your
solution is much less of an impairment. Many thanks!

cu
Daniel

how do i patch a rpm version of wine? i installed mine with "apt-get install
wine" and i have that problem too how can i fix it? i'm using Debian 3.1.

patches are for the wine source code, not for binary builds.

Hi again,

will this problem be addressed by the dev team or am I to workaround everytime a new release is made by myself? Not pressing, just wondering.

Cheers
Daniel

Confirming, since Roderick came up with a working fix for it.

James, you could submit the patch yourself to wine-patches,
I suppose.  See http://kegel.com/academy/opensource.html#patches.making
and http://winehq.org/site/sending_patches

(In reply to comment #8)
> Confirming, since Roderick came up with a working fix for it.
> 
> James, you could submit the patch yourself to wine-patches,
> I suppose.  See http://kegel.com/academy/opensource.html#patches.making
> and http://winehq.org/site/sending_patches
> 

Dan, I think the fix is a hack that won't be committed.

since the debian release of wine 0.45, the hack mentioned by Rod doesn't work anymore. I can launch e.g. winefile allright, however I get a messed up display: every bit of text gets displayed in marlett.ttf instead of the standard SSerif font. But when I manually move marlett.ttf out of its default location, it works again (renaming doesn't suffice, obviously the first found truetype font is used). Any ideas appreciated! thx

Daniel

PS: the actions in comment #10 took place not under vnc but under a remote X-Server. When I try the same thins under vncserver, this happens:
- with marlett.ttf existing, I just get the messed up display.
- with marlett.ttf gone, the attached tracelog2 applies.
cu

Created attachment 9431 [details]
relates to comment #10

one quirks in ##10 and 11: the version is not 0.45 but 0.44 - sorry for the confusion.

Using a recent git version (monday 25/2/2008 or newer) this problem should not occur anymore in 2d programs. Before OpenGL was initialised at startup due to some limitations on pixel formats in winex11.drv (we used the same pixel format for the window and GL). This limitation has been lifted and due to that we don't have to initialise opengl at startup anymore. Now you should only get the issue if you launch e.g. an opengl program.

The crash itself is a GLX bug either in Mesa or VNC/Xephyr/Xnest.

Closing bugs fixed in 0.9.57.

works fine now, thanks!