In , Doug Ridgway proposed three items to be worked upon inside the Wine community:

• Run the Wine bug database
• Graphic redesign for WineHQ
• Run the party fund

Since last week, some people volunteered to take care of second item. The third one remains open: if you're interested, please contact Doug.

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:

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

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

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

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.

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.

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

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.

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

• 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 installation.
• 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 Registry

Directory Structure

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

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