- Wine-Devel - list.winehq.org

Scrollbars, an application bug or a wine regression ? (#2314)
by Gabriele Giorgetti June 30, 2004

June 30, 2004

Hello, I've noticed a problem with scrollbars in the latest Wine's release (20040615). With wine version 20040505 everything was just fine. I've attacched a zip file with two screenshots (pls. see wine BUG #2314 @ bugs.winehq.org ) the first one is the correct behavior of the app using wine 20040505 the second one is wine 20040615 and the app in its wrong behavior. Trying to describe the problem: The application show up with a bottom scrollbar and a right scrollbar even if they are not needed. When executing the very same application, with the very same settings and size with wine 20040505 the scrollbars are not there. I hope you get it Thanks. NB: BUG #2314 at bugs.winehq.org

5 9

err:opengl:X11DRV_ChoosePixelFormat Flag not supported
by Tobias Burnus June 30, 2004

June 30, 2004

Hello, I have the following problems with WINE, CVS version as of yesterday and Crystal Impact's Diamond http://www.crystalimpact.com/diamond/ http://www.crystalimpact.com/download/diamond/demo/dm2demo.exe, which installs flawlessly. a) I get a err:opengl:X11DRV_ChoosePixelFormat Flag not supported when I open e.g. ./Samples/Minerals/Copper.dsf and a dialogbox with the following text is shown: ChoosePixelFormat() returns 0 (last error = 0) SetPixelFormat() returns 1 (last error = 0) wglCreateContext() returns 0 (last error 2000) wglMakeCurrent() returns 1 (last error = 0) (Workaround: disable rendering) b) Some data is displayed as list, e.g. like http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png under WINE this is completely mangled: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list_wine.png Sometimes some spread numbers appear, but in this case one can only mark cells. Any ideas how to fix/debug this? (I have unfortunally no experience at all in programming in Wine/Windows.) Anyone volunteering to look at this? I'm willing to spend some $$ (but not $$$) on that (I know that this is not much, but some rewarding of volunteer work doesn't hurd either). Regards, Tobias

1 0

Re: Typo in winedbg
by Mike Hearn June 30, 2004

June 30, 2004

On Mon, 28 Jun 2004 20:45:35 -0400, Andrei Barbu wrote: > This fixes debuggee to debugger. I think debuggee is the right word, it means "the one that is being debugged". Ctrl-C doesn't interrupt winedbg, it interrupts the process you are currently attached to.

2 1

Failed to compile on Sparc/Solaris 9
by John O'Donnell June 30, 2004

June 30, 2004

make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/export/home/root/wine/wine/dlls/newdev' make[2]: Entering directory `/export/home/root/wine/wine/dlls/ntdll' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o error.o exception.o file.o heap.o large_int.o loader.o loadorder.o misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o wcstring.o relay32.o ntdll.dll.dbg.o -o ntdll.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lresolv -lsocket -lnsl ntdll.dll-IHmocZ.spec.c:20:1: warning: "__stdcall" redefined <command line>:17:1: warning: this is the location of the previous definition thread.o: In function `NtCurrentTeb': /export/home/root/wine/wine/dlls/ntdll/thread.c:582: undefined reference to `wine_pthread_get_current_teb' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ntdll.dll.so] Error 2 make[2]: Leaving directory `/export/home/root/wine/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/export/home/root/wine/wine/dlls' make: *** [dlls] Error 2 root(a)gold251:/root/wine/wine# This is CVS'ed a day ago. Any ideas? Any more info needed?

1 0

[RFC] Wine upgrade procedure (spec)
by Dimitrie O. Paun June 30, 2004

June 30, 2004

Hi folks, It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): -- native vs. builtin DLLs handling -- multiple Wine installations on a box -- updating only some DLLs -- integrating into the Unix environment -- dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: -- administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). -- the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a conprehensive view of the problem we are trying to solve. Thanks for reading this far! -- Dimi.

3 3

A wine magic trace key
by Andrei Barbu June 29, 2004

June 29, 2004

I'm about to implement a set of keys that lets me enable disable traces any time. Seems to me like it's a good idea, like that I can get traces for exactly what I need. Especially when I'm faced with weird debugger output that's 10 minutes into the game and I can't turn traces on to begin with. Is there another way, possibly existing, to do this? Is this a really bad idea? If people are interested I can post a patch later on today or tomorrow with it. It'll be implemented in the x11 driver and calling the existing wine_dbg_parse_options with a new options string. It can even be made a commandline option to enable and disable that key combination (and possibly the key combination could be set in wineconfig) but that's if enough people are interested in the idea. Thanks, Andrei

3 4

Temporary moderator needed
by Duane Clark June 29, 2004

June 29, 2004

Howdy, Someone is needed for the period June 30-July 5 to handle moderation of the Wine lists. If you are willing to do it, please email me off list. Thanks.

1 0

Re: Missing declaration for MSVCRT_div_t and MSVCRT_ldiv_t
by Dimitrie O. Paun June 29, 2004

June 29, 2004

On Tue, Jun 29, 2004 at 01:27:23PM +0200, Pierre d'Herbemont wrote: > Hi! > > On non-i386 we have to define MSVCRT_div_t and MSVCRT_ldiv_t. Please also add the appropriate tests to tests/headers.c. -- Dimi.

1 0

Re: parameter checking in CoMarshalInterface
by Uwe Bonnes June 29, 2004

June 29, 2004

>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: Aric> Changlog: return an error if the IUnknown pointer is NULL and dont Aric> crash tested with win2k and this is proper behavior Index: The test is welcome in the test suite... Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Mandrake RPMs
by Ivan June 29, 2004

June 29, 2004

> It turns out the reason they don't work on Fedora is because they don't > work at all No, wine segfaulted, so it probably wasn't a packaging related problem. > wine.inf is in /usr/share/doc/wine-20040615 which is wrong, > it needs to be in /usr/share/wine. This is strange because I tested both RPMs on multiple versions of Mandrake before releasing them. Anyway, new RPMs will be up soon. Ivan.

2 1