Wine Traffic #52 For 17�Jul�2000

By Eric Pouech

Table Of Contents

Introduction

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:

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:

1. Jobs around Wine (cont'd)

30�Jun�2000 (3 posts) Archive Link: "Wine jobs"

People: ,�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 Doug (mailto:ridgway@winehq.com) .

2. A visual configuration tool for Wine

10�Jul�2000�-�12�Jul�2000 (10 posts) Archive Link: "wine.conf graphical front-end development"

People: Martin Pilka,�Ove Kaaven,�CodeWeavers,�,�Ove K�ven

Martin Pilka (from CodeWeavers) made the following proposal:
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.
  1. you can choose if you want to generate new or edit existing wine.conf file.
  2. choose a location of your wine.conf file
  3. add/remove disks which will be accessible from wine
  4. where the windows/profile/temp directory is ([wine] section of wine.conf file)
  5. default wine look ([tweak.layout] section)
  6. 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)
  7. complete screen, where you can see and edit everything

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:

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

3. Kernel security path

11�Jul�2000�-�12�Jul�2000 (5 posts) Archive Link: "Kernel security Patch"

People: 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 (news:///comp.emulators.ms-windows.wine) (Title was 'Wine with ASS won't run stripped binaries').

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:
  1. what are the chances of this patch to become the default in some near future ?
  2. what could be the best way to solve such problem ?

Peter Bortas quoted Linus' position regarding this Linux patch:
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
print a more explicit error message and die.
Patch should by now in the CVS tree.

4. Borland's developer conference report

14�Jul�2000 (1 post) Archive Link: "BorCon Trip Report (long)"

People: Jim Graham,�CodeWeavers,�,�codeweavers

Jim Graham (CodeWeaver's CTO) gave a long report of his trip to BorCon:
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 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 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.

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

5. Wine benchmarks

16�Jul�2000 (1 post) Archive Link: "nice benchmark results (fwd)"

People: Thomas Elger,�,�Ove K�ven

Ove K�ven forwarded a note from Thomas Elger which shed some lights on Wine performances (compared to Windows):
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 flawlessly on Linux using WINE. I found a benchmark program for the program on http://www.steinhaus-net.de/science/gaussst.html (http://www.steinhaus-net.de/science/gaussst.html) .

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: http://www.nek.lu.se/nektel/bench.jpg (http://www.nek.lu.se/nektel/bench.jpg)

If you have comparisons like this one, feel free to submit them to the editorial team (mailto:wwn@winehq.com) . If there is enough material, we'll build a page containing all those good (and bad ?) figures.

6. Feature: Replacing Windows by Ove K�ven

People:

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.

Installation Overview

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.

The Registry

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.

Directory Structure

Here's the fundamental layout that Windows applications and installers expect. Without it, they seldom operate correctly.

C:\ Root directory of primary disk drive
Windows\ Windows directory, containing .INI files, accessories, etc
System\ Win3.x/95/98/ME directory for common DLLs
WinNT/2000 directory for common 16-bit DLLs
System32\ WinNT/2000 directory for common 32-bit DLLs
Start Menu\ Program launcher directory structure
Programs\ Program launcher links (.LNK files) to applications
Program Files\ Application binaries (.EXE and .DLL files)

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:

[Drive C]
Path=/var/wine
Type=hd
Label=MS-DOS
Filesystem=win95

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.

System DLLs

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 http://solo.abac.com/dllarchive/.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.