Wine Traffic

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).

Ove Kaaven Jeremy White

Martin Pilka, keeping going with his work on Wine configuration tools (see issue #62), 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:

let's say superuser configured system for all users at once, so Wine is ready-to-use for all normal users. is that scenario what we want?
if yes, then:
how to manage that users will have correctly set paths under HKEY_CURRENT_USER key? one solution is to allow something like HKEY_CURRENT_USER in /etc/wine/wine.userreg file. Is that the right solution?

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.

Andreas 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):

How to get Wine from CVS and build it
How to get source tarballs of the snapshots Alexandre releases
RPM and DEB packages of Wine, unstripped, built from the snapshots
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.

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

Not much was discussed here, not even the regular /usr/ vs /usr/local flamewar.

2/ Modify ld.so.conf to include the lib directory

see previous issue

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

see previous issue

Marcus Meissner proposed to add a wrapper should put up a messagebox "Launching WINE...", since WINE startup takes longer than the n seconds that the casual user expects a application startup to take. (We had several people clicking on .exe and wondering why nothing happens since on the first run it takes like > 30 seconds to calculate fonts.)

Jeremy went even further, proposing to add a global KDE/Gnome menu entry for Wine, put Winecfg under it, and maybe also put in a simple Windows application launcher. Hmmm. This could be cool; we could make a little launcher with checkboxes that turn on good debug info, and facilitate the creation of a decent bug report. Also, the wine launcher could control (hide) the stdout/stderr of Wine, and give the user an option to see it if/when Wine crashes. Thus, the wine launcher would be the thing tied to the .exe associations.

This sound useful to some people. Jeremy even wrote a first implementation of such a tool (which now sits in tools/winelauncher in the CVS tree).

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

kernel patches aren't necessary. If the user has binfmt_misc in the kernel, it's just a matter of injecting a descriptor into /proc/sys/fs/binfmt_misc after boot...

5/ [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.

Since the first wording wasn't very clear (and/or understood), Jeremy White explained further: AFAIK, the global wine configuration has no effect if you have a local .winerc. Since I think almost everyone will run with a ~/.winerc (so the Wine settings can be tweaked at user level, not by root), I feel that is misleading.

I do, however, think it's a great idea to have a /etc/wine/wine.conf.default (along with the default registry files).

Alexandre agreed saying that Wine should only try to load the user config file. If someone really wants a global config, it is always possible to make the user config a symlink to some central file.

There was also some tough exchanges to determine whether multi-user configuration (read some installation could be done for several users at the same time) versus single-user (each user is responsible for his configuration). First option would ease up the life of system administrators in deploying a new application on top of Wine.

Even if everyone agreed it was a neat features, Jeremy and Martin feared this was too high an achievement for 1.0 and were keen to drop it for 1.0 (or to add it to the wish list for 1.1). Ove, on the other hand, didn't think it was an heavy task to accomplish Why's that? It can't be harder to do than agreeing on a clean design and writing a couple of lines of code... the current registry model would only require minor tweaks to enable registry sharing.

However, such a clear design has not been agreed on yet.

6/ When to run the configuration tool(s)

In both case, it should also be defined whether the installation shall be made with a native Windows system if one is found (note, that it can also not be found, like when the C: partition is not mounted at the time the tool is run). In any cases, the configuration system should be able to prepare a windows-less installation. It seemed also an agreement was reached upon reducing the interactivity of the installation process.

Also, Ove suggested, for Debian, the use of debconf to get most of the needed information (which could be done in an non interactive way).

Jeremy White summed the last two points divergence: At package install time, should we create a global wine.conf?

View 2: Yes. We autobuild a global wine.conf file during the install process. With debian, we can do this somewhat elegantly due to debconf.

Side issues: With View 2, there is a hope that Wine can support a true multiple user configuration. Some of us feel that this is not worthwhile to try to support at this time.

Perhaps we resolve this by saying that for debian, because of debconf, we take view 2, and for RPMS, we take view 1. I hate to diverge, but I think the opposing views are pretty entrenched.

However, if View #2 can be easily reached, it's likely it'll be the default approach.

Claus Fisher opened another area of discussion:

Perhaps it's time to talk to the FHS guys about a possible inclusion of Wine windows/pseudo-windows directories in the Filesystem Hierarchy Standard. Probably in two versions: with native Windows on disk, and without.

Define guidelines

which drive letters should hold globally installed applications if possible
which drive letters should be for the users' stuff (home dir), which tmp directories are used
how packages for installation under Wine should be prepared (if possible)

Marcus Meissner explained the setup he uses on a Caldera system:

A: first floppy pointing to floppy automountpoint
B: (commented out) second floppy
C: users homedirectory / windows base installation
...
R: cdrom (just a generic choice) pointing to CD-ROM automountpoint
...
T: temp drive, pointing to /tmp/
W: point to shared windows directory (so we can use w:\ and w:\system in paths later.
U: users homedirectory / $HOME. As network drive, so windows don't try to use it as temp storage.
Z: the / drive, a network drive, so windows apps don't try to use it as temp storage.)

Of course, lots of people disagreed on the naming of letters and what they should be used for (everyone is used to his own setup).

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:

Wine providing enough tools, features and guidelines so that packagers can write easy to use but consistent across distributions packages.
Wine providing enough flexibility so that packagers can tweak them to the distribution philosophy or intented use (more games oriented, or more Office application oriented...)

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:

in Win95
- the normal display is black text on the regular gray background when an item is selected its background becomes white, the text stays black
- except for the checkboxes which become white on the regular gray background
in win98
- same as Win95 when the window is active and the mouse is not over the menu bar
- if the window is inactive then the black parts become dark gray, i.e. it looks the same as if we had a regular menu
- when the mouse is over a menu bar item, there's a raised border drawn around the bitmap (even if the window is inactive)
- when a menubar item is selected, there is a sunken border drwan around it and, unlike in Win95, the background remains grey
- when a menu item is selected, it is highlighted like any other, i.e. we have the dark blue background. But the bitmap is indeed displayed kind of inverted. I get dark blue on white. And I also note that the size of the menu item is calculated so that there is a 1 pixel dark blue border above and below the bitmap.

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).

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"); Wine-dbg>bt Backtrace: =>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 ( http://www.microsoft.com/msj/0597/hood0597.htm):

Yet another form of debug information is relatively new and undocumented, except for a few obscure references in WINNT.H and the Win32 SDK help. This type of information is known as OMAP. Apparently, as part of Microsoft's internal build procedure, small fragments of code in EXEs and DLLs are moved around to put the most commonly used code at the beginning of the code section. This presumably keeps the process memory working set as small as possible. However, when shifting around the blocks of code, the corresponding debug information isn't updated. Instead, OMAP information is created. It lets symbol table code translate between the original address in a symbol table and the modified address where the variable or line of code really exists in memory.

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.

James Hatheway Patrik Stridval Bertho Stultiens Andrew 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:

Endianess. First question links to the way resource shall be stored (using the endianess of the CPU, meaning that resource compiler and Wine must be run on machine sharing the same endianess, or storing the resources with a predefined endianness, leaving the resource compiler and the Wine resource loader to do any conversion if necessary). Gav reminded of an old discussion he had with Bertho Stultiens on this very matter. Even resources by themselves shall be converted (for example, width or height of a bitmap, stored in .bmp header).
Regarding alignment issues, Gav thought it was more a matter of performance (either using packed or unpacked structures). The CPU shall be used to do several aligned memory accesses to handle an unaligned data.
Driver interfaces shall be reworked. This would include the X11 driver (Gav commented the GDI side should be fairly straightforwards, but the window/event management will be nasty.), but also the multimedia driver (mainly for audio support).
James feared the Wine debugger to be too tightly bound to the x86 architecture to be useful as it is. Gav reminded that gdb worked just fine.

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.