Wine Traffic #48 For 19�Jun�2000

By Eric Pouech

Table Of Contents


This is the 48th 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).

Wine 20000614 has been released. Main changes include:

Garrett Goebel provided some answers on a thread from last week on unexpected compilation results with gcc 2.95 and -O6 option (thanks Garrett),
Some insight into the function inlining problem due to gcc optimization might be found in the current Kernel Traffic Weekly news ( . It appears that compiling the questionable code with the -fno-inline-functions argument would turn off inlining...

Mailing List Stats For This Week

We looked at 110 posts in 264K.

There were 39 different contributors. 24 posted more than once. 27 posted last week too.

The top posters of the week were:

1. MZ (aka DOS) executable support

15�Jun�2000 (8 posts) Archive Link: "loader/dos/module.c"

People: Alexandre Julliard,�Ove Kaaven,�Gerald Pfeifer,�,�Ove K�ven

Gerald Pfeifer asked why the MZ_CreateProcess was #if 0:ed (EdNote: this function is the horse power for starting DOS applications. The header for DOS applications file start with the MZ signature, hence the name.)

Alexandre Julliard answered:
The DOS support has been broken by address space separation. The function is inside #if 0 waiting for someone to re-implement it properly...

Ove K�ven seems to be (partially ?) this very one person:
Now actually, I have mostly done so; I am able to start some DOS apps, but not as many as before the ASS yet, and I've changed large parts of DOS support code, so it's also hard to separate into a set of independent patches that I can submit. [snip]

But I don't have time to work more on this currently. But if anyone wants the megapatch and would like to work on it (or think that I can just submit said megapatch myself without more cleaning up or bugfixing) then I can probably send it somehow...

and answered more precisely to Gerald
Though since I seem to recall you were a FreeBSD person, I doubt you're particularly interested, since the DOS support is currently only implemented for Linux anyway...

Alexandre continued of more details of what he liked to see done:

Ove and Alexandre kept on discussing the implementation details, including interrupts handling, VGA mode support.

2. Merging DSound and WinMM drivers

16�Jun�2000 (2 posts) Archive Link: "dsound and winmm"

People: Ove Kaaven,�,�Ove K�ven,�Eric Pouech,�TransGaming

Ove K�ven, starting his new assignment at TransGaming, wrote:
I'm looking at moving/merging the DirectSound device-specific code with the WINMM device drivers, so that we'd have common drivers for both standard WINMM and DirectSound, instead of the current mess of two different implementations. (The same thing should preferably be done about DirectInput, but I'm concentrating on DirectSound right now.)

So I looked at the DirectX DDK to see how Windows does it. As expected, DirectSound is just extra functionality in the normal soundcard device drivers. The Win95 interface for this is supposedly obsoleted by Win98's new WDM device driver structure, but since the current WINMM use Win95's model and not the WDM model, I'll just ignore WDM (it doesn't really matter for us since we can't use native soundcard drivers anyway).

Ove gave also some more detailed view on the way Windows does it: basically, the audio driver registers a specific function table (as any DirectX object, but thru a VxD), which will be grabbed later on by the DSound DLL. Ove then asked for an authoritative (EdNote: :-/) answer on the preferred way of exporting this function table from the audio driver (since VxDs don't provide a realistic solution on Wine).

Eric Pouech discussed some options with Ove. The less intrusive option seems to look undocumented features of the WinMM DLL which allow to send a message to any driver loaded by WinMM. Using this feature, one can kill two birds with one stone:

3. WineDbg freezes at startup

16�Jun�2000�-�18�Jun�2000 (6 posts) Archive Link: "Is the debugger broken?"

People: James Hatheway,�,�Ulrich Weigand

Dave Hawkes reported some freeze while WineDbg starts up and asked whether someone had some idea of what's going on.

James Hatheway (and later on other Macadamiam folks) shed some light on the bug, and provided a work around as well:
I have found that the WINE debugger has problems loading some .PDB files, and will freeze up on loading. Just as a test, move all your pdb files somewhere WINE can't see them, and try to load the debugger again. If it works then, then that is the problem.
(EdNote: PDB files contain debugging information. Those are generated by Microsoft's MSVC compiler)

Ulrich Weigand offered to have a look (if possible) to the offending files to help fixing the freeze.

4. Feature: The Registry by Ove K�ven


After Win3.x, the registry became a fundamental part of Windows. It is the place where both Windows itself, and all Win95/98/NT/2000/whatever-compliant applications, store configuration and state data. While most sane system administrators (and Wine developers) curse badly at the twisted nature of the Windows registry, it is still necessary for Wine to support it somehow.

Registry structure

The Windows registry is an elaborate tree structure, and not even most Windows programmers are fully aware of how the registry is laid out, with its different "hives" and numerous links between them; a full coverage is out of the scope of this article. But here are the basic registry keys you might need to know about for now.
This fundamental root key (in win9x, stored in the hidden file system.dat) contains everything pertaining to the current Windows installation.
This fundamental root key (in win9x, stored in the hidden file user.dat) contains configuration data for every user of the installation.
This is a link to HKEY_LOCAL_MACHINE\Software\Classes. It contains data describing things like file associations, OLE document handlers, and COM classes.
This is a link to HKEY_USERS\your_username, i.e., your personal configuration.

Using a Windows registry

If you point Wine at an existing MS Windows installation (by setting the appropriate directories in wine.conf/.winerc), then Wine is able to load registry data from it. However, Wine will not save anything to the real Windows registry, but rather to its own registry files (see below). Of course, if a particular registry value exists in both the Windows registry and in the Wine registry, then Wine will use the latter.

Occasionally, Wine may have trouble loading the Windows registry. Usually, this is because the registry is inconsistent or damaged in some way. If that becomes a problem, you may want to download the regclean.exe from the MS website and use it to clean up the registry. Alternatively, you can always use regedit.exe to export the registry data you want into a text file, and then import it in Wine.

Wine registry data files

In the user's home directory, there is a subdirectory named .wine, where Wine will try to save its registry by default. It saves into four files, which are:
This file contains HKEY_LOCAL_MACHINE.
This file contains HKEY_CURRENT_USER.
This file contains HKEY_USERS\.Default (i.e. the default user settings).
Wine saves HKEY_USERS to this file (both current and default user), but does not load from it, unless userdef.reg is missing.
All of these files are human-readable text files, so unlike Windows, you can actually use an ordinary text editor on them if you must.

In addition to these files, Wine can also optionally load from global registry files residing in the same directory as the global wine.conf (i.e. /usr/local/etc if you compiled from source). These are:
Contains HKEY_USERS.

System administration

With the above file structure, it is possible for a system administrator to configure the system so that a system Wine installation (and applications) can be shared by all the users, and still let the users all have their own personalized configuration. An administrator can, after having installed Wine and any Windows application software he wants the users to have access to, copy the resulting system.reg and wine.userreg over to the global registry files (which we assume will reside in /usr/local/etc here), with:

cd ~/.wine
cp system.reg /usr/local/etc/wine.systemreg
cp wine.userreg /usr/local/etc/wine.userreg

and perhaps even symlink these back to the administrator's account, to make it easier to install apps system-wide later:

ln -sf /usr/local/etc/wine.systemreg system.reg
ln -sf /usr/local/etc/wine.userreg wine.userreg

Note that the tools/wineinstall script already does all of this for you, if you install Wine as root. If you then install Windows applications while logged in as root, all your users will automatically be able to use them. While the application setup will be taken from the global registry, the users' personalized configurations will be saved in their own home directories.

But be careful with what you do with the administrator account - if you do copy or link the administrator's registry to the global registry, any user might be able to read the administrator's preferences, which might not be good if sensitive information (passwords, personal information, etc) is stored there. Only use the administrator account to install software, not for daily work; use an ordinary user account for that.

The default registry

A Windows registry contains many keys by default, and some of them are necessary for even installers to operate correctly. The keys that the Wine developers have found necessary to install applications are distributed in a file called "winedefault.reg". It is automatically installed for you if you use the tools/wineinstall script, but if you want to install it manually, you can do so by using the regapi tool. You can find more information about this in the documentation/no-windows document in the Wine distribution.

The [registry] section

With the above information fresh in mind, let's look at the wine.conf/.winerc options for handling the registry.

Controls whether to try to load the global registry files, if they exist.
Controls whether to try to load the user's registry files (in the .wine subdirectory of the user's home directory).
Controls whether Wine will attempt to load registry data from a real Windows registry in an existing MS Windows installation.
Controls whether registry data will be written to the user's registry files. (Currently, there is no alternative, so if you turn this off, Wine cannot save the registry on disk at all; after you exit Wine, your changes will be lost.)
This option is obsolete. Wine now always use the new format; support for the old format was removed a while ago.
If this option is set to a nonzero value, it specifies that you want the registry to be saved to disk at the given interval. If it is not set, the registry will only be saved to disk when the wineserver terminates.
Controls whether the entire registry is saved to the user's registry files, or only subkeys the user have actually changed. Considering that the user's registry will override any global registry files and Windows registry files, it usually makes sense to only save user-modified subkeys; that way, changes to the rest of the global or Windows registries will still affect the user.

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.