Wine Traffic #48 For 19�Jun�2000
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
- Address space separation
- Message compiler
- Beginnings of multiple codepages support
- The usual common controls fixes and improvements
- Lots of bug fixes.
Some insight into the function inlining
problem due to gcc optimization might be found in the current Kernel
Traffic Weekly news (http://kt.zork.net/kernel-traffic/kt20000612_71.html#3
. 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:
- 14 posts in 28K by Ove Kaaven <email@example.com>
- 9 posts in 23K by Uwe Bonnes <firstname.lastname@example.org>
- 9 posts in 16K by Alexandre Julliard <email@example.com>
- 6 posts in 14K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 4 posts in 9K by Wilbur N. Dale <firstname.lastname@example.org>
- Full Stats
MZ (aka DOS) executable support
Archive Link: "loader/dos/module.c"
Alexandre Julliard,�Ove Kaaven,�Gerald Pfeifer,�,�Ove K�ven
Gerald Pfeifer asked why the MZ_CreateProcess was
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
Ove K�ven seems to be (partially ?) this very one person:
0 waiting for someone to re-implement it properly...
and answered more precisely to Gerald
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...
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
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.
- 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.
Merging DSound and WinMM drivers
Archive Link: "dsound and winmm"
Ove Kaaven,�,�Ove K�ven,�Eric Pouech,�TransGaming
Ove K�ven, starting his new assignment at TransGaming, wrote:
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:
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).
- enumerate thru the installed drivers without knowing what they
- send a (wine specific) message to grab the function table (if
the driver supports the DSound driver interface)
WineDbg freezes at startup
Archive Link: "Is the debugger broken?"
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.
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.
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
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).
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:
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
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