Wine Traffic #254 For 24 Dec 2004

Seriously, we were all ready to go to gold, with the plan being to ship this afternoon, when we got a beta report that made us nervous.

I woke Alexandre up and asked him to look into it, with the hopes that we could understand the issue well enough to go ahead and ship. So we'd either ship in 30 minutes if he figured it out, or we'd ship tomorrow, after working feverishly through the night... <grin>.

But the good news is that Alexandre did figure it out and we shipped

You'll be happy to know that we're already hard at work on 5.0, with Office 2003 support. We're also seeing that the major Window management overhaul that Alexandre is in the middle of is addressing a lot of the nasty painting issues we've had through the years, so that will be exciting to bring you next year.

We're also ready to launch a whole new set of tools around regression testing and broader Wine testing; I'm hopeful that next year is the year that Wine really hits is 'tipping' point, with most things starting to 'just work'.

In the world of emulation, software emulators are where life gets interesting. A software emulator is not running your program on a virtual machine -- it's running it on the fly without a virtual machine. These programs work by setting up an environment in which a program's code can run normally, but attempts by the program to access the operating system get routed through an emulation layer of some sort. WINE is a great example (albeit for Windows), although it is officially not an emulator.

ChangeLog

Add support for loading nt native binaries

Add ntoskrnl, only a few stub functions for now, so we have something to work on. All the functions needed by safedisc are in the spec, we can't implement them all as stubs at the moment because for two of them we need defines from the ddk, I'll be sending a patch to add ntddk.h in the near future.

I want to announce the newly born WineTools. WineTools is an menu driven installer for installing Windows programs under wine. This software lets you install the following Windows software for Linux under WINE:

• DCOM98
• IE6
• Windows Core Fonts
• Windows System Software
• Office & Office Viewer
• Adobe Photoshop 7, Illustrator 9, Acrobat
• Reader 5.1
• many other programs

It also sets up your .wine directory in the correct way, downloads the files to install from the web (only the free and shareware ones for sure), installs Windows fonts and lets you uninstall and configure your software. And it does much more than Sidenet, although it uses a part of the configuration for IE6 (thanks for that!).

WineTools was initially written by Frank Hendriksen <frank_at_franksworld.net> and was extended by me (Joachim von Thadden <thadden_at_web.de> It is licensed under the GPL.

The actual version wt207jo works with wine-20041019 and wine-20040914. Look at

http://www.von-thadden.de/Joachim/WineTools/

to get more informations and to download. Note that you should definitely start with the "Base setup" and create a new fake Windows drive. If you want to save your old .wine directory, you can use the backup function of WineTools.

as my colleague Stefan Munz has already pointed out recently[1] on this list, Wirtschaftsforderung Region Stutgart GmbH (WRS) and us (ITOMIG) are launching an initiative called WINEprobe[2]. Its goal is to make local software vendors aware of the potential bussiness opportunity in a WINE-based port or a WINE/Linux version of their software.

WRS is quite committed as far as Open Source is concerned[3], and is pushing OSS in the region since quite a time. It has co-organized, among others, the KDE World Summit 2004 in Ludwigsburg near Stuttgart[4]. The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) [5], ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. (You can find a description of WRS at the bottom of this mail.)

In order to make the WINEprobe initiative beneficial for the WINE project as much as possible, three things are in the making:

1. At the option of the respective software vendor whose product we'll be analyzing for WINE compatibility, Application Database Entries will be maintained by us once a software product has been analyzed for its compatibility with WINE.
2. Reports of successful porting or migration projects will be given back to the community as success stories. My colleage is already working on merging some success stories supplied by third parties (see [6]).
3. WRS has offered to help out in hosting the WINE developers conference Wineconf in 2005 in the Stuttgart area[7].

Mr. Schmid from WRS has asked me (please see the mail below) to provide some information about this initiative to the WINE community. He thinks (and I agree ;) that it would help us a great deal in making the campaign a success if the WINE community somehow "officially" (as official as a community can be :) approved of this initiative. So my question, on behalf of Mr. Schmid, is simply if there are objections against us saying that this initiative is approved of by the WINE community?

[1] http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html

[2] WINEprobe means be something like WINEtasting in english an maybe "degustation de WINE" in french.

[3] See http://opensource.region-stuttgart.de/ (.de only, sorry)

[4] http://conference2004.kde.org/

[5] http://2005.guadec.org/papers.html

[6] http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html

[7] http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html

So as far as official endorsement.. I'm sure someone in the Wine community will speak up if they disagree with anything. (Conversely, they won't speak up if they agree.) The three projects you mentioned all sound great and they're things that really should be worked on. So in the sense that stuff should get done - I think we all want that. That leads up to your question of whether the Wine community approves of the initiative? Well.. I'm not qualified to answer that question.

If you do contribute to Wine, we'll gladly add you to our acknowledgements page ( http://www.winehq.org/site/acknowledgement ). Then you can say things in press releases like, "WRS, an acknowledged Wine contributor, ....." Anyone disagree with that idea?

While debugging one of applications I'm working on I noticed a lot of GetPrivateProfileString calls with the same file name but in different case causes profile code to open and parse system.ini again. I sent a patch which helps to find a cached file in that case and do not parse it again.

I had a thought that another speed improvement might be to use FindFirstFileW instead of CreateFileW/GetFileTime to retrieve last modification time of a file. I wrote a test under Windows to see which of FindFirstFileW or CreateFileW is faster. The test is attached.

Here are the results (for 10000 loops) running the same binaries in Wine and Windows 2000 SP4 (hard disks are the same in both systems):

Win2k SP4/NTFS volume:
test_CreateFileW: P3/1GHz time elapsed 363 ms
test_FindFirstFileW: P3/1GHz time elapsed 547 ms
Wine/ext3 volume:
test_CreateFileW: P3/1GHz time elapsed 543 ms
test_FindFirstFileW: P3/1GHz time elapsed 1650 ms

CreateFileW is only 1.5 times slower in Wine than in Windows, that's really not bad (especially taking into account Wine boot time), but still there is a possibility for an improvement.

FindFirstFileW is 3 times slower in Wine than CreateFileW, while it's only 1.5 times slower in Windows. This needs to be optimized.

Wine currently creates launchers (.desktop files) with an Exec line like this:

Exec=wine 'c:\games\supreme\supreme.exe'

But, some games expects to be run from its working directory. As working directory typically doesn't matter to UNIX apps, some desktop environments like GNOME don't let you set it. Really, this is a Wine specific issue.

So I'm wondering how we should fix this. The most obvious is a way to tell Wine to change the working directory to the path of the EXE file before running it, but we can't introduce command line switches any more and an environment variable for this doesn't make much sense.

My proposal is to have a new winelib app "winemenulauncher" which simply takes the working directory, program and arguments, and runs the program but switching current directory first, ie the menu entry would look like:

Exec=wine winemenulauncher c:\games\supreme supreme.exe

Hopefully this should let us fix the case of games like Dungeon Keeper which actually crash when run from their install directory.

Does this sound sensible?