WineHQ

World Wine News

All the news that fits, we print.

19 Jun 2000 00:00:00 -0800
by Eric Pouech
Issue: 48

XML source
More Issues...

This is the 48th release of the Wine's kernel cousin publication. Its 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:
  • Address space separation
  • Message compiler
  • Beginnings of multiple codepages support
  • The usual common controls fixes and improvements
  • Lots of bug fixes.

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

This week, 110 posts consumed 264 K. There were 39 different contributors. 24 (61%) posted more than once. 27 (69%) posted last week too.

The top 5 posters of the week were:

  1. 14 posts in 28K by Ove Kaaven
  2. 9 posts in 16K by Alexandre Julliard
  3. 9 posts in 23K by Uwe Bonnes
  4. 6 posts in 14K by Eric Pouech
  5. 4 posts in 13K by Dmitry Timoshkov

MZ (aka DOS) executable support 15 Jun 2000 00:00:00 -0800 Archive

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:
  • first of all, Wine uses an UNIX application (dosmod) to run any DOS application (sort of a DOS emulator, a la DOSEMU). Alexandre would like to see dosmod evolves into a WineLib application dedicated to running DOS applications. This very scheme has already been used to provide 16 bit applications support.
  • lots of DOS support still uses either internals of regular DLLs, and hinders a clean DLL separation.

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

Merging DSound and WinMM drivers 16 Jun 2000 00:00:00 -0800 Archive

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:
  • enumerate thru the installed drivers without knowing what they are
  • send a (wine specific) message to grab the function table (if the driver supports the DSound driver interface)

WineDbg freezes at startup 16 Jun 2000 00:00:00 -0800 Archive

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.

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.

<h3>Registry structure</h3> 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.
HKEY_LOCAL_MACHINE
This fundamental root key (in win9x, stored in the hidden file system.dat) contains everything pertaining to the current Windows installation.
HKEY_USERS
This fundamental root key (in win9x, stored in the hidden file user.dat) contains configuration data for every user of the installation.
HKEY_CLASSES_ROOT
This is a link to HKEY_LOCAL_MACHINE\Software\Classes. It contains data describing things like file associations, OLE document handlers, and COM classes.
HKEY_CURRENT_USER
This is a link to HKEY_USERS\your_username, i.e., your personal configuration.

<h3>Using a Windows registry</h3> 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.

<h3>Wine registry data files</h3> 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:
system.reg
This file contains HKEY_LOCAL_MACHINE.
user.reg
This file contains HKEY_CURRENT_USER.
userdef.reg
This file contains HKEY_USERS\.Default (i.e. the default user settings).
wine.userreg
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:
wine.systemreg
Contains HKEY_LOCAL_MACHINE.
wine.userreg
Contains HKEY_USERS.

<h3>System administration</h3> 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.

<h3>The default registry</h3> 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.

<h3>The [registry] section</h3> With the above information fresh in mind, let's look at the wine.conf/.winerc options for handling the registry.

LoadGlobalRegistryFiles
Controls whether to try to load the global registry files, if they exist.
LoadHomeRegistryFiles
Controls whether to try to load the user's registry files (in the .wine subdirectory of the user's home directory).
LoadWindowsRegistryFiles
Controls whether Wine will attempt to load registry data from a real Windows registry in an existing MS Windows installation.
WritetoHomeRegistryFiles
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.)
UseNewFormat
This option is obsolete. Wine now always use the new format; support for the old format was removed a while ago.
PeriodicSave
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.
SaveOnlyUpdatedKeys
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.

All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.