Wine Traffic #68 For 6 Nov 2000
Table Of Contents
Introduction
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 <julliard@winehq.com>
- 20 posts in 105K by Francois Gouget <fgouget@free.fr>
- 9 posts in 43K by Jeremy White <jwhite@codeweavers.com>
- 9 posts in 42K by Patrik Stridvall <ps@leissner.se>
- 8 posts in 113K by David Elliott <dfe@infinite-internet.net>
- Full Stats
1.
Wine configuration tools
24 Oct 2000 - 27 Oct 2000
(17 posts)
Archive Link: "wine configuration issues (long)"
People:
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
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?
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.
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.
2.
Wine bottling
26 Oct 2000 - 28 Oct 2000
(61 posts)
Archive Link: "Wine packaging - part 2 - what RPM/DEBs do"
People:
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:
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
flamewar.
2/ Modify ld.so.conf to include the lib
directory
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.
3/ [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
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.
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).
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).
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)
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
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 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
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.
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:
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>.
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
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...)
3.
Bitmaps in menu
27 Oct 2000 - 5 Nov 2000
(7 posts)
Archive Link: "Fix for selected bitmap menu items"
People:
Dmitry Timoshkov, Francois Gouget,
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).4.
MSC info handling in winedbg
28 Oct 2000 - 1 Nov 2000
(9 posts)
Archive Link: "[Q] Status of wine debugger"
People:
Uwe Bonnes, Ulrich Weigand, Juergen Schmied,
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)
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.
5.
Mac OS X
1 Nov 2000 - 4 Nov 2000
(7 posts)
Archive Link: "Issues regarding porting WineLib to MacOS X"
People:
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
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).
Sharon And Joy