Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Wine Traffic #68 For 6 Nov 2000

By Eric Pouech

Table Of Contents


This is the 68th 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 143 posts in 716K.

There were 32 different contributors. 20 posted more than once. 22 posted last week too.

The top posters of the week were:

1. Wine configuration tools

24 Oct 2000 - 27 Oct 2000 (17 posts) Archive Link: "wine configuration issues (long)"

People: Martin PilkaFrancois GougetAlexandre JulliardOve KaavenJeremy White

Martin Pilka, keeping going with his work on Wine configuration tools (see BROKEN KCREF), ran into some interesting questions:
I'm working on easier configuration of Wine and better integration into most common desktop environments (like KDE, GNOME). As i'm tracing things down, i'm running into some problems. what's going on:

One part of the integration is that icons should appear on your linux desktop (and menu) after you run some installer under Wine. That requires correctly set paths (like Desktop, StartUp) under HKEY_CURRENT_USER key. The user who runs installer uses only the global configuration files (like /etc/wine/wine.conf, system.reg, wine.userreg). Wine is set to use fake windows installation (no real windows installed, but it's not really important in this case).

The problem is that there is no way how to set something under HKEY_CURRENT_USER registry key in global configuration files. That's probably right, because information under this key are related to concrete user, and therefore should be stored in users home directory. But this causes there is no way how to properly configure GLOBAL Wine configuration - i mean superuser runs configuration once, and all other users have Wine ready to use. In fact all users are supposed to run "regapi setValue < winedefault.reg" command before they run their first application (this translates the HKEY_CURRENT_USER key to real user name and writes this translated keys to ~/.wine/user.reg file).

I would like to solve it somehow, but before i do that i need the answers for a few questions:

Francois Gouget gave some insights on current Windows behavior:
Windows has the notion of a 'Default User': "HKEY_USERS/.Default". This should probably be checked, but I believe that when a new user is created, the information stored in this tree is duplicated to form the new user's registry tree.

Maybe this could be used for solving this problem: when root installs Wine he sets all the directories right, and this is stored in this '.Default' tree. Then when an actual user starts Wine for the first time, obviously he does not have a registry yet. So what Wine would do is copy the contents of the ".Default" tree to form the user's new HKEY_CURRENT_USER key. That way he would inherit all the right settings automatically.

The exact behavior should be checked under NT too (the above was from Windows 9x) but I believe it is similar. There is another item that works the same in NT which is profile information: in NT4 when a user logs in for the first time on a machine, the contents of 'c:\winnt\Profiles\Default User' is duplicated and used for that user. This directory contains the settings for the Start Menu, the Desktop, etc.

IIRC the same goes for Windows 2000 but the location of the directory is different.

Even if Martin liked the idea, Alexandre Julliard pin-pointed some trouble makers:
I'm afraid you cannot simply copy the values, some have to be adapted for the current user; for instance on my NT box the programs directory is in C:\WINNT\Profiles\<username>\Start Menu\Programs so you need to plug the right username in there when setting the key.

A possible approach suggested by Jeremy White is to specify a user setup script in the global configuration. Then when Wine notices that the user doesn't have a .wine directory it will launch this script, which can copy the registry files from some templates and run a sed script on them to fix the necessary things.

The discussion then refined the details of such an implementation. The last important issue, as Martin put it, is "language mutation": some registry entries (like 'Program Files', have a different name depending on the localization of the system). Shell32 should provide this flexibility, so the little script's proposal evolved into a more complex tool, even if, as Ove Kaaven suggested, it could use an existing WineLib application like regapi to do the job.

2. Wine bottling

26 Oct 2000 - 28 Oct 2000 (61 posts) Archive Link: "Wine packaging - part 2 - what RPM/DEBs do"

People: Jeremy WhiteMarcus MeissnerOve KaavenAlexandre JulliardClaus FisherAndreas Mohr

Based on some conversations, Jeremy White proposed a scheme to let users get access to Wine from the WineHQ download are:
I propose that the user see the following ordered list (and that the list be presented in a nice, friendly way):
  1. How to get Wine from CVS and build it
  2. How to get source tarballs of the snapshots Alexandre releases
  3. RPM and DEB packages of Wine, unstripped, built from the snapshots
  4. A link to other places (i.e. what exists today) where they could get stripped versions of Wine, if they want to do that to us poor, suffering, Wine hackers.

When we release Wine 1.0, the top of the list would be stripped, packaged RPM and DEB files.

Obviously, the main thrust I'm trying to set up is encouraging users to build Wine from source (at this time), or at least to use a version with symbolic info so we can get decent bug reports.

Since noone really answered this (and which came from a larger consensus), next major WineHQ revamping shall include this.

At the same time, Jeremy proposed what turned out to be a more controversial point regarding Wine RPM and DEB packaging. Several aspects have been covered.

Install the files to the appropriate place (/usr/bin? /usr[/share]/doc /usr/lib/wine)

Modify to include the lib directory

[Controversial] Modify Gnome/KDE file associations to associate .exe files with wine

[Controversial] Install a kernel patch to allow .exe files to be launched from the command line.

[Controversial] Do not install a /etc/wine.conf file. IMHO, since the global wine configuration is IMHO misleading, we shouldn't install one by default.

6/ When to run the configuration tool(s)

Claus Fisher opened another area of discussion:

In another part, Jeremy White tried to have the packaging tool make their way inside the CVS tree. As Jeremy put it:
I think that in order for Wine to succeed, it needs to have consistent, strong packaging. I think in order for that to happen, the packaging process needs to be automated, and easily replicated. And I think the best way for that to happen is for the package files to reside in a CVS tree. I'm not sure I see the flaw in having a tools/package/redhat, and a tools/package/debian, and a tools/package/openlinux and so on.

Otherwise, Marcus gets run over by a bus, and OpenLinux Wine packaging stagnates, or Ove gets abducted by Microsoft and Debian users are forever forlorn... <g>.

Alexandre Julliard didn't like the approach:
I strongly disagree with the automated part. You don't want anybody to do a 'make package' and put the package up for ftp; this is the most sure way of having tons of broken packages floating around.

You want to have knowledgeable people like Ove and Marcus, who understand what they are doing, generate the packages for the rest of us. So yes, we should have more documentation on how to do that, and this will probably include parts of sample spec files to illustrate the documentation. But it should not be possible to blindly generate a package without understanding what's going on.

The discussion ended with issues like: Q: how many packages for Wine (and what should be inside) ? A: that's a distribution oriented matter.

Q: which dependencies can winecfg rely on ? (currently it uses Tcl/Tk and some other packages) A: try to reduce the dependencies.

As a final word, things are not completely settled down. The hairy part of this kind of discussion if to find the right balance between:

3. Bitmaps in menu

27 Oct 2000 - 5 Nov 2000 (7 posts) Archive Link: "Fix for selected bitmap menu items"

People: Dmitry TimoshkovFrancois Gouget

Dmitry Timoshkov wrote a patch to
make bitmap menu items look like in windows when selected, i.e. hilited and inverted.

Francois Gouget took a look at it, and found the modification, even if fixing some issues in Wine, didn't do as Windows:

Francois resumed the issues in two blocks: calculation of the item size, where some part seemed to be overriden in some cases, and some color management issues.

Dmitry then decided to write a simple test application to help determine the color management issue. This simple app includes monochrome and color bitmaps in menus. As Dmitry put it (as a Russian byword)
things are simpler than they look: Eyes are afraid - hands are doing

Using this application, and merging Dmitry first work, and other fixes he add, Francois provided a patch which now closer mimics the drawing of bitmaps in menu (in particular, the inversions when the mouse goes over the selected menu).

4. MSC info handling in winedbg

28 Oct 2000 - 1 Nov 2000 (9 posts) Archive Link: "[Q] Status of wine debugger"

People: Uwe BonnesUlrich WeigandJuergen Schmied

Uwe Bonnes had a hard time debugging an application:
I am trying to debug some misfunction in a program (avrstudio.exe) that uses MFC. The missfunction are senseless top/left/width/height values to CreateWindowExA and that CreateWindowExA is called from the MFC library. As VC++ comes with PDB files and source for the MFC library, I thought that windebg should read that pdb files and then would give me a sensible stack backtrace at that invokation of CreateWindowExA.

However doing so it looks like: 0x405cdf46 (CreateWindowExA+0x46 [win.c:1118])
1118 FIXME("BON:Setting up SysHeader32\n");
=>0 0x405cdf46 (CreateWindowExA+0x46(exStyle=0x0, className=0x5f4a5444, windowName=0x0, style=0x40000042, x=0x5f403903, y=0x5f4d1b60,
width=0xa10af35d, height=0xa0b2e4a0, parent=0x341c, menu=0x9c70, instance=0x400000, data=0x0) [win.c:1118]) (ebp=4083cde0)
  1 0x5f407d8a (COccManager::SplitDialogTemplate+0x6(pTemplate=0x0, ppOleDlgItems=0x5f4a5444) [occmgr.cpp:182]) (ebp=4083ce50)
  2 0x5f409a6b (MFC42.DLL.2124+0x46) (ebp=4083ce8c)
  3 0x5f456a10 (MFC42.DLL.2093+0x2d) (ebp=ffffffff)
*** Invalid address 0xffffffff (SHLWAPI.DLL..reloc+0x4048dfff)

Uwe then asked by the
stack levels 2 and 3 don't get resolved in Function names and looking at the MFC source for occmgr.cpp I think winedbg doesn't get things right...

Juergen Schmied explained that
WineDbg can read pdb files if the debug information of the exe file is not stripped and the exe file is pointing directly to the pdb file. If the debug information is stripped to a dbg file and there is a record pointing to the pdb file in the dbg file, WineDgb is not able to load the filename.

Juergen said he already had some code to fix this missing feature, but the code wasn't mature yet (basically, some functions still weren't found correctly, and timestamping gave bad results - when an application compiled with MS VC++ has his debug information stored in a .DBG file, a timestamp is stored in both .EXE and .DBG file so the debugger can assume that both files are in sync).

Ulrich Weigand pointed out another possible issue:
It would appear that these .DBG files carry OMAP data. To quote Matt Pietrek (

Later on, Ulrich proposed a long patch which should support such OMAP information in MSC debug information reading.

However, this should not yet solve the name mangling issues. Yet, WineDbg doesn't support C++ features, so name mangling is part of the missing ones. This even may be a long job, because name mangling is not the same across several compilers. So, support for at least MS VC++ and GCC shall be provided. Anyway, if WineDbg has to be used in helping porting Windows applications with WineLib, (basic) C++ support is a must have.

5. Mac OS X

1 Nov 2000 - 4 Nov 2000 (7 posts) Archive Link: "Issues regarding porting WineLib to MacOS X"

People: Gavriel StateJames HathewayPatrik StridvalBertho StultiensAndrew Lewycky

James Hatheway, while thinking to port Wine to MacOS X, tried to summarize the known issues he may encounter, if starting such an adventure.

Gavriel State reported some previous actions he had on this matter:
I briefly started on a MacOS X port at MacHack, but stopped after being annoyed at how many header files for important stuff MacOS X seemed to be missing.

I have a tarball of an old hacky winelib port to LinuxPPC around. At MacHack I switched to updating it for then-current WineLib, but got stuck on the issue of thread local storage. The solution there is to apply a patch that makes wine use pthreads for Windows threads (I know that Andrew Lewycky did this for Corel for the cprof profiler).

Several detailed points were addressed:

Patrik Stridval also had a look after the unsuccessful BeOS port try (which got stalled because of missing OS level functionalities like file descriptor passing in sendmsg/recvmsg or the handling of sockets as file descriptors), but thought that this could be way easier to do the MacOS port than the BeOS one.

Anyway, this was a feasability study, and James didn't make his mind yet if he would go or not for it.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.