Wine Traffic #52 For 17 Jul 2000
Table Of Contents
This is the 52nd 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 20000716 has been released. Main changes include:
- DirectSound restructured and improved.
- More builtin dlls (ws2_32, setupapi, rpcrt4, serialui).
- Several internationalisation improvements
- Lots of bug fixes.
Mailing List Stats For This Week
We looked at 106 posts in 262K.
There were 52 different contributors.
21 posted more than once.
19 posted last week too.
The top posters of the week were:
- 10 posts in 21K by Ove Kaaven <firstname.lastname@example.org>
- 8 posts in 19K by Uwe Bonnes <email@example.com>
- 7 posts in 16K by gerard patel <firstname.lastname@example.org>
- 5 posts in 12K by Martin Pilka <email@example.com>
- 4 posts in 8K by Bertho Stultiens <firstname.lastname@example.org>
- Full Stats
Jobs around Wine (cont'd)
30 Jun 2000
Archive Link: "Wine jobs"
, Doug Ridgway
In BROKEN KCREF, Doug Ridgway proposed three
items to be worked upon inside the Wine community:
Since last week, some people volunteered to take care of second
item. The third one remains open: if you're interested, please contact
- Run the Wine bug database
- Graphic redesign for WineHQ
- Run the party fund
A visual configuration tool for Wine
10 Jul 2000 - 12 Jul 2000
Archive Link: "wine.conf graphical front-end development"
Martin Pilka, Ove Kaaven, CodeWeavers, , Ove Kåven
Martin Pilka (from CodeWeavers) made the following proposal:
and asked for comments on the proposal.
Lots of people were enthusiast about Martin's proposal.
Petr Tomasek was asking for a great integration of this tool with the
different desktops (Gnome, KDE...). Petr wanted this configuration
tool to be written as a different application for each targeted
desktop, but with a clean design helping to share as much code as
possible. Even if some items were of interest (having some Wine's
component being more integrated into the desktop (like buttons...), or
integrating Wine's start-menu with the desktop's one), Martin
explained he started implementing this tool in tk/tcl. Those features
will not be part of the first version of Martin's tool.
Ove Kåven remembered two existing tools of interest:
I'm working on graphical front-end for wine.conf
file. the goal is to provide useful tool for both newbie and linux-guru. It
will be something like wizard you know from windows, but it will also accept
the command line, which allows you to directly jump into something like
advanced section, where can you edit everything.
Following is the VERY PRELIMINARY draft, what should single screens
contains. your boggles are welcomed.
- you can choose if you want to generate new or edit existing
- choose a location of your wine.conf file
- add/remove disks which will be accessible from wine
- where the windows/profile/temp directory is ([wine] section of
- default wine look ([tweak.layout] section)
- you can choose if you want to answer more questions, or if it
is enough and you want save it and finish configuration. If you
choosed more questions:
- dll load order
- things like "managed windows" ([x11drv] section)
- ports ([serialports] [parallelports] [spooler] sections)
- registry ([registry] section)
- complete screen, where you can see and edit everything
Martin already knew about TkWine, but described it as being a
complement to his tool (like automatic generation tool) being later on
added to the graphical front-end for editing wine.conf).
- You're of course already aware of the existing (but abandoned)
TkWine project, which it'd be nice to build on?
- Perhaps it'd also be nice if it was possible to use this in
conjunction with tools/wineinstall.
Kernel security path
11 Jul 2000 - 12 Jul 2000
Archive Link: "Kernel security Patch"
Gérard Patel, Peter Bortas, Alexandre Julliard,
Gérard posted some follow-up of a debugging discussion he had on
comp.emulators.ms-windows.wine (Title was 'Wine with ASS won't run
A kernel security patch changed the mapping of a program when loaded
into memory. This had some dramatic effects on Wine, since this
changed the memory layout of modules. Since some modules (without
relocation records) must be loaded at their default address, already
having some stuff mapped at this address broke the whole loader.
Since this patch is an unofficial one, Gérard asked:
Peter Bortas quoted Linus' position regarding this Linux patch:
- what are the chances of this patch to become the default in
some near future ?
- what could be the best way to solve such problem ?
Linus has stated (several times) on LKML (EdNote: Linux Kernel
Mailing List) that he doesn't like pseudo security fixes like that
and that he won't let it in. So getting it in to mainstream kernels
would involve abduction and brainwashing of Mr T.
Alexandre Julliard then proposed to simply
more explicit error message and die. Patch should by now in
the CVS tree.
Borland's developer conference report
14 Jul 2000
Archive Link: "BorCon Trip Report (long)"
Jim Graham, CodeWeavers, , codeweavers
Jim Graham (CodeWeaver's CTO) gave a long report of his trip to
I was at BorCon for CodeWeavers. I hosted the BOF on "Using Wine to
Port Application Software to Linux" and also gave a talk on "Porting
Windows Application Software To Linux" (which really covered all of
the tools, technologies, and techniques).
I also worked in the booth all day Tuesday and Wednesday. CodeWeavers
also had a BOF on porting Delphi code to Linux using Wine, but I
missed that one, so can't talk about how it did.
Overall impression: good show, lot's of interest and enthusiasm in both
Linux and Wine.
The BOF was surprisingly well attended, especially since it started at
7:00am on the last day of the conference. We had about 30 people in
all, mostly windows application developers using C/C++ & Delphi.
I spent about 30 minutes simply talking about what Wine is, what it
does, it's history, and status. It turned out to be a great forum for
educating the audience about Wine, since many of them were highly
pessimistic about it (complaints about it not being able to run Word
or Excel are all too common - argh). Most of the questions that came
in related to winelib, which I was glad to talk about (beats having to
discuss why Quicken won't work!). Most of the audience had never heard
of it, and even those that had misunderstood its purpose. The only
complaints that came in were in regard to it not being perfect (duh)
and the "poor" documentation. Other than that, it was really well
received. I really blew them away at the end when I showed them MS
PowerPoint2000 running on Wine (thanks to all of you!).
They were also excited about the future of Wine. In fact, when I
discussed the objectives/goals of Wine 1.0, it generated a lot of
discussion, and certainly a lot of enthusiasm. What surprised me
though, is that the 1.0 discussion was not about "cool, it'll work
with all of my windows apps," but instead, "cool, it'll work well with
some of my windows apps," and "cool, it will be better documented and
easier to install/configure."
The talk focused on tools and technologies that are available for
deploying windows software on linux. I covered everything from VMWare
to (what I call) "pure porting" (using Xlib/Xaw/Xm/libc, etc.). I
focused on teaching the differences between the technologies, and
showing what's good and bad about each. I emphasized Wine and winelib
quite a bit, but again had to educate the audience about what it is. I
think most of the audience agreed that, even if it's not your final
solution, using winelib to get to Linux was the best starting point.
According to some of the other exhibitors, this year's exhibit floor
was the biggest one yet. Personally, I thought it looked small. It
certainly wasn't LinuxWorld. Heck, it wasn't even as big as The
Bazaar. But it was intimate, and we were able to meet a lot of great
people. We were also able to talk to quite a few people for a longer
period of time, which was a nice change. Traffic through the booth was
near zero during the day (while sessions were running), but during
lunch, and after the sessions ended, it was always busy. Again, a lot
of interest in moving to Linux. I think the Borland development
community is suddenly taking Linux very seriously, and as Kylix
becomes available, we'll start to see more and more interest (at least
from the business world). That interest will drive additional
enthusiasm, and Wine is becoming an obvious consideration for everyone
from users to developers and ISV's.
That's about it for now. Feel free to ping me if you need/want more
details. I'll be posting the talk on www.codeweavers.com, and for
anyone that was at the show, it'll be on the post-conference CD.
16 Jul 2000
Archive Link: "nice benchmark results (fwd)"
Thomas Elger, , Ove Kåven
Ove Kåven forwarded a note from Thomas Elger which shed some lights on
Wine performances (compared to Windows):
If you have comparisons like this one, feel free to submit them to the editorial team. If there is enough material,
we'll build a page containing all those good (and bad ?) figures.
I have a computer program GAUSS for Windows NT/95, Version
3.2.32. Aptech does provide a Linux version of the program, but they
charge for a completely new license. It is a highly advanced
statistical package used by many econometricians and mathematical
statisticians. I was very pleased to find that the NT version works
on Linux using WINE. I found a benchmark program for the
On the site, there is an extensive list of test results using various
operating systems and computers. The author states in the benchmark
program that it belongs to the public domain and can be used freely.
My test results were as follows (On an Intel PII 400, 128n Mb RAM,
Mandrake Linux 6.0 using the WINE distributed with Corel Photo paint
(since it is nicely preconfigured with printing etc)):
GAUSS - Benchmarkprogram
300x300 normal distributed random matrix^1000 : 1.837 sec.
Eigenval. of a normal distr. 200x200 randommatrix : 2.777 sec.
Inverse of a 500x500 uniform distr. random matrix : 6.073 sec.
500000 values sorted ascending : 2.113 sec.
800x800 Toeplitzmatrix : 0.333 sec.
Cholesky decomposition of a 500x500-matrix : 0.623 sec.
600x600 correlation matrix : 6.963 sec.
500x500 cross-product matrix : 3.887 sec.
FFT over 100000 values : 0.887 sec.
Gaussian error function over a 500x500 matrix : 0.643 sec.
Gamma function over a 500x500 matrix : 0.410 sec.
Linear regression over a 500x500 matrix : 5.257 sec.
Overall Performance : 31.803 sec.
These results are truly amazing. Running Gauss under WINE on Linux is
just as fast as running gauss natively under NT 4.0 (or faster) !!! On
the site referred above, a Dell Pentium II computer with 128 Mb RAM
gets an overall performance of 32.484.
A screenshot of Gauss running the benchmark is available on:
Feature: Replacing Windows by Ove Kåven
The last poll showed that people are interested in obviating the need
for having a real MS Windows installed to run Windows applications.
I will now attempt to explain Wine's strategy towards this end.
A Windows installation consists of many different parts.
While the users are of course free to set up everything themselves, the
Wine team will make the automated Wine installation script,
tools/wineinstall, do everything we find necessary to do;
running the convential "configure && make depend && make && make install"
cycle is thus not recommended, unless you know what you're doing.
At the moment, tools/wineinstall is able to create a configuration file,
install the registry, and create the directory structure itself.
- Registry. Many keys are supposed to exist and contain meaningful
data, even in a newly-installed Windows.
- Directory structure. Applications expect to find and/or install
things in specific predetermined locations. Most of these directories
are expected to exist. But unlike Unix directory structures, most of
these locations are not hardcoded, and can be queried via the Windows
API and the registry. This places additional requirements on a Wine
- System DLLs. In Windows, these usually reside in the system (or
system32) directories. Some Windows applications check for their
existence in these directories before attempting to load them.
While Wine is able to load its own internal DLLs (.so files) when
the application asks for a DLL, Wine does not simulate the existence
of nonexisting files.
The default registry is in the file "winedefault.reg". It contains
directory paths, class IDs, and more; it must be installed before
most INSTALL.EXEs or SETUP.EXEs will work. The registry is covered
in more detail in an earlier article.
Here's the fundamental layout that Windows applications
and installers expect. Without it, they seldom operate correctly.
Wine emulates drives by placing their virtual drive roots to
user-configurable points in the Unix filesystem, so it's your
choice where C:'s root should be (tools/wineinstall will even ask you).
If you choose, say, /var/wine, as the root of your virtual drive C,
then you'd put this in your wine.conf:
||Root directory of primary disk drive
||Windows directory, containing .INI files, accessories, etc
||Win3.x/95/98/ME directory for common DLLs
WinNT/2000 directory for common 16-bit DLLs
||WinNT/2000 directory for common 32-bit DLLs
||Program launcher directory structure
||Program launcher links (.LNK files) to applications
||Application binaries (.EXE and .DLL files)
With this configuration, what windows apps think of as "c:\windows\system"
would map to /var/wine/windows/system in the Unix filesystem. Note that
you need to specify "Filesystem=win95", NOT "Filesystem=unix", to make
Wine simulate a Windows-compatible (case-insensitive) filesystem,
otherwise most apps won't work.
The Wine team has determined that it is necessary to create fake DLL
files to trick many applications that check for file existence to
determine whether a particular feature (such as Winsock and its
TCP/IP networking) is available. If this is a problem for you,
you can create empty files in the "system" directory to make
the application think it's there, and Wine's built-in DLL will be
loaded when the application actually asks for it. (Unfortunately,
tools/wineinstall does not create such empty files itself.)
Applications sometimes also try to inspect the version resources from
the physical files (for example, to determine the DirectX version).
Empty files will not do in this case, it is rather necessary to
install files with complete version resources. This problem
is currently being worked on. In the meantime, you may still need
to grab some real DLL files to fool these apps with.
And there are of course DLLs that wine does not currently implement
very well (or at all). If you do not have a real Windows you can steal
necessary DLLs from, you can always get some from a DLL archive such as
Sharon And Joy