Wine Traffic #68 For 6 Nov 2000
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:
- 20 posts in 48K by Alexandre Julliard <firstname.lastname@example.org>
- 20 posts in 105K by Francois Gouget <email@example.com>
- 9 posts in 43K by Jeremy White <firstname.lastname@example.org>
- 9 posts in 42K by Patrik Stridvall <email@example.com>
- 8 posts in 113K by David Elliott <firstname.lastname@example.org>
- Full Stats
Wine configuration tools
24 Oct 2000 - 27 Oct 2000
Archive Link: "wine configuration issues (long)"
Martin Pilka, Francois Gouget, Alexandre Julliard, , Ove Kaaven, Jeremy White
Martin Pilka, keeping going with his work on Wine configuration tools
(see BROKEN KCREF), ran into some
Francois Gouget gave some insights on current Windows behavior:
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
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
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
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
- 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?
Even if Martin liked the idea, Alexandre Julliard pin-pointed some
Windows has the notion of a 'Default User':
". 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
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
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.
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
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.
26 Oct 2000 - 28 Oct 2000
Archive Link: "Wine packaging - part 2 - what RPM/DEBs do"
Jeremy White, Marcus Meissner, Ove Kaaven, Alexandre Julliard, Claus Fisher, Andreas Mohr,
Based on some conversations, Jeremy White proposed a scheme to let
users get access to Wine from the WineHQ download are:
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.
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.
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
Modify ld.so.conf to include the lib
As Marcus Meissner pointed out (and also implemented for the Caldera
package), updating /etc/ld.conf is not necessary if -rpath is used
while linking modules (BROKEN KCREF). Ove Kaaven now also does it for Debian packages.
[Controversial] Modify Gnome/KDE file associations
to associate .exe files with wine
This is an old idea (BROKEN KCREF), which got agreed.
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
Jeremy went even further, proposing to add
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
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).
[Controversial] Install a kernel patch to allow
.exe files to be launched from the command line.
Ove Kaaven noticed that
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... Andreas Mohr also pointed out that .exe should have
been 'chmod +x':ed which is not always the case (evenmore, when .exe
resides on a FAT partition, you cannot set the +x attribute on a per
file basis). So, the KDE/Gnome association is a better solution
(which doesn't prevent from implementing this other one).
[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:
6/ When to run the configuration tool(s)
Alexandre agreed saying that
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).
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
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
However, such a clear design has not been agreed on yet.
It wasn't not clear either when to run the configuration tools. The
first approach required to have it run on the post-installation
process, but on a non interactive way. The second approach rejoigned
what's presented in previous article: when a user starts Wine for the
first time, it's configuration is then created.
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
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:
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:
However, if View #2 can be easily reached, it's likely it'll be the
At package install time, should we create a global wine.conf?
View 1: No - we supply something like wine.conf.template, and
then walk the user through using winecfg of wineconf to get their own .winerc.
View 2: Yes. We autobuild a global wine.conf file during the
install process. With debian, we can do this somewhat elegantly due to
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.
Alexandre Julliard didn't like the approach:
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>.
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:
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.
- Wine providing enough tools, features and guidelines so
that packagers can write easy to use but consistent across
- 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...)
Bitmaps in menu
27 Oct 2000 - 5 Nov 2000
Archive Link: "Fix for selected bitmap menu items"
Dmitry Timoshkov, Francois Gouget,
Dmitry Timoshkov wrote a patch to
make bitmap menu
items look like in windows when selected, i.e. hilited and
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
- 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
- when a menubar item is selected, there is a sunken
border drwan around it and, unlike in Win95, the background remains
- 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.
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).
MSC info handling in winedbg
28 Oct 2000 - 1 Nov 2000
Archive Link: "[Q] Status of wine debugger"
Uwe Bonnes, Ulrich Weigand, Juergen Schmied,
Uwe Bonnes had a hard time debugging an application:
Uwe then asked by the
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
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)
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:
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.
It would appear that these .DBG files carry OMAP data. To quote Matt
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.
Mac OS X
1 Nov 2000 - 4 Nov 2000
Archive Link: "Issues regarding porting WineLib to MacOS X"
Gavriel State, 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
Gavriel State reported some previous actions he had on this matter:
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.
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).
Sharon And Joy