Wine Traffic #72 For 4�Dec�2000

By Eric Pouech

Table Of Contents

Introduction

This is the 72nd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 105 posts in 299K.

There were 33 different contributors. 17 posted more than once. 14 posted last week too.

The top posters of the week were:

1. Headlines

People:

Wine-20001202 has been released. Major changes include:

MusicMatch also announced the availability of a JukeBox program of its own, ported to Linux using Wine. You can check out the beta version here (http://www.musicmatch.com/download/?OEM=LINUX using wine) .

WineHQ new design (which was announced a while ago) has been promoted to the official skin level. We hope you'll enjoy the new surf on WineHQ and find it more readable and easy to browse to get all the relevant information, even if everything is not finished (<fresh painting marks still float around>).

2. Exporting variables from DLLs

26�Nov�2000�-�29�Nov�2000 (10 posts) Archive Link: ".spec file "extern" entries"

People: Ove Kaaven,�Alexandre Julliard,�Francois Gouget,�,�Ove K�ven

Ove K�ven asked Alexandre Julliard for some more information on the newly introduced DLLs in .so file mechanism. Ove found that access to most global variable exported from another DLL failed with the new mechanism (BROKEN KCREF):
In some DLLs, like CRTDLL, not only functions are exported, but also variables, for example:

crtdll/crtdll.spec:@ extern __argc_dll CRTDLL_argc_dll
crtdll/crtdll.spec:@ extern __argv_dll CRTDLL_argv_dll
crtdll/crtdll.spec:@ extern _ctype CRTDLL_ctype
crtdll/crtdll.spec:@ extern _environ_dll CRTDLL_environ_dll

But winebuild doesn't cope with these. It can either generate "jmp" import stubs, which is broken, or not generate anything at all, which fails linking. We're having some problems with this around here... how does Alexandre plan to solve this?

Alexandre answered:
I'm not planning to solve it at the moment, and given that there are very few such variables, I doubt solving it at all is worth the effort. If you need these variables you should declare pointers to them and use GetProcAddress (or for argc/argv/environ you can declare your own variables and use _GetMainArgs to fill them).

After some investigation, Ove reported that
the unlinkable variables are GUIDs, like those defined in ddraw.h
and wondered if winebuild should be extended to allow the definition of GUIDs from a given header file (like ddraw.h) ?

Francois Gouget replied:
On Windows you are supposed to link with static libraries to get these GUIDs. I found three such libraries: uuid.lib (the main one), ciuuid.lib and daouuid.lib.

Francois then proposed to fix this in Wine by providing static libraries (or even .o files) like Windows do, meaning that nor an extension to the .spec file, nor dynamic linking (and symbol exportation) is required.

3. Wine debugger and a DOS driver

2�Dec�2000 (2 posts) Archive Link: "debugger on DOW drive?"

People: Dennis Bj�rklund,�Ove Kaaven,�,�Ove K�ven

Dennis Bjorklund had tried to set the debugger as indicated in the doc-file using a UNIX style path name (like /usr/local/bin/winedbg), and reported failure to get the debugger started on a crash.

Dennis asked
does this mean that winedbg can't live in the normal path but have to be in a windows partition (these strange things with letters like H:). It sort of makes sense since it's used from the windowsworld (ie registry) but in that case the documentation doesn't make sense any more.

Ove K�ven explained:
(it) is probably that many developers have catch-all drives, like below - and Wine is easily able to change a Unix path to a Windows path (and back) if such a definition exists in the ~/.winerc file.
[Drive Z]
Path=/

4. Wine developers still have time to play

2�Dec�2000�-�3�Dec�2000 (12 posts) Archive Link: "civ2"

People: Dennis Bj�rklund,�Ove Kaaven,�Andreas Mohr,�,�Francois Gouget,�Ove K�ven

Dennis Bjorklund reported:
civ2 (EdNote: Civilization II) is really slow in Wine. When I move a unit one square the move takes something like 5 seconds. Also the blinking that the units do when they are selected is very slow. And CPU usage are at 100% all the time, but that might be true in windows also.. It looks good at least.

Francois Gouget reported some other type of slowness (in an sample for a Programming Windows book) which faded away if the user actively wiggles the mouse (Andreas Mohr reported the same bad behavior for WinAmp about box). None of them gave a clear explanation about what may fail, but this issue really need some fix.

But, the "mad mouse" approach didn't solve Dennis' issue.

Ove K�ven went into with some thoughts:
Civilization II uses WinG, which is implemented in Wine in terms of DIB sections (which was introduced in Win95 as the successor to WinG anyway).

Lately I've been working on DIB sections in x11drv - they are handled in quite some involved ways in x11drv, and I've been working on improving the flexibility, threadsafety, and the possibility of reducing the overhead. Maybe I'll submit what I have done sometime next week.

It may not help Civ2 directly, since the experimental DIBsection->screen blt optimization I did currently only handles 16bpp and above, while WinG operates on 8bpp, but it should be very obvious where the extra work needs to be done...

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.