• Directory change notifications can use inotify now.
• Hardware breakpoints in the Wine debugger.
• Beginnings of support for tape APIs.
• A bunch of improvements to the IDL compiler.
• Better scheme for mapping My Documents etc. to Unix directories.

"Businesses tell us they want to switch to the desktop Linux operating system to reduce total cost of ownership or improve security, but it's the thought of losing one or two software applications like Quickbooks or Microsoft Project that holds them back," said Kevin Carmony, CEO of Linspire, Inc. "CrossOver Office is genius because it removes that hesitation from the equation. Yes, you can still use Quicken or Microsoft software on your Linspire machine, but you don't have to overpay for a Windows operating system license to do it."

Say, if we're expecting people to use Wine for real work, maybe we should start doing that ourselves.

Firefox-1.5 runs pretty well on Wine. How many Wine developers use it on Wine as their main web browser? Maybe we could raise that number from zero to somewhere around ten, and flush out a couple bugs.

Speaking of flushing out bugs, OpenOffice 1.1 was said to work well under wine a couple years ago (though I don't think I ever saw it do so myself). Sadly, although OpenOffice 1.1.5 seems to install fine under current wine, it crashes quickly on startup, so I guess we have a bit of work to do first. The extra payoff would be being able to use http://qa.openoffice.org/qatesttool/ to run OpenOffice's automated test suite as an automated regression test for wine.

One complication in all this is having to teach yourself to not automatically blow away your ~/.wine directory when trying a new app!

To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com.

Results for first run of app after booting (1st column is startup time):

5 Firefox run1 native 416MB
12 Firefox run1 wine 416MB
11 Firefox run1 native 96MB
15 Firefox run1 wine 96MB
11 ooo run1 native 416MB
15 ooo run1 wine 416MB
60 ooo run1 native 96MB
37 ooo run1 wine 96MB

So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?)

I then measured how long it took to start up the app the second time, when the cache was nice and hot:

3 Firefox run2 native 416MB
4 Firefox run2 wine 416MB
4 ooo run2 native 416MB
6 ooo run2 wine 416MB
4 Firefox run2 native 96MB
6 Firefox run2 wine 96MB
36 ooo run2 native 96MB
28 ooo run2 wine 96MB

The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM.

I was trying to exercise the winemp3 builtin codec using a Visual Basic control that essentially implements the Windows Media Player look (MSDXM.OCX). After specifying native quartz.dll for this app, I tested a few AVIs with mp3-encoded soundtracks. What I can notice is that the sound has very annoying jitters, and in addition, it crashes on a seek. Some people have noticed the jitters too ( http://bugs.winehq.org/show_bug.cgi?id=3853). However, rather than trying to fix the wine fork of mpeglib, I was toying with the idea of reimplementing the codec as a libmad (GPL) wrapper. Are there any issues I should take into account before trying this?

Or simply, that the sequence of:

1. getting mp3 encoded data
2. pushing them to the decoder for decoding
3. pushing the decoded data to the speaker

which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1.

I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek.

On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated.

Some more tests. I downloaded the latest version of mpglib, and compared it against the wine fork. Aside from extra spaces and an one-time-only initialization in the wine code, the current mpglib code is almost identical to the wine fork. However, the standalone mpglib decodes the extracted samples correctly. This means that there is something about the Wine environment that disturbs mpglib enough so that decoding no longer works correctly. I also noticed that mpglib uses malloc() and free() from glibc even inside the wine copy (one malloc()/free() pair per sample block to be decoded). Could this be causing some interference (especially since the wine architecture decodes in a separate thread)? Maybe it is worth it to use HeapAlloc()/HeapFree() instead.

winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer msvcrt.__unDname funtion i have written a quick and dirty program that is basicaly only a wrapper around UnDecorateSymbolName(). Most importent feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it useful. After applying the patch configure needs to be regenerated.

actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)...

but what should be done is to port back the code from msvcrt into winedump

• because we don't want winedump to be winelib app
• because winedump does a bit more than just demangling (like adding pmt names) which requires an extra level of intelligence that doesn't exist in msvcrt.__undname

Over the last few days, I have been trying to find out whether the combination of WTL and Winelib could be a promising inter-platform GUI solution.

While I have made some progress and got some new knowledge, I believe I have now come to a dead end where I'll have to give up that attempt.

In case you are interested, here's my summary report.

It might be useful to others.

The Goal:

WTL on Windows gives me:

• compact executables: small and fast
• easy-to-install executables: no DLLs needed
• programs easy to maintain and deploy
• mature GUI

The goal is to combine WTL/ATL (no COM) with Winelib to create a Linux-application with the same look and feel and roughly the same qualities: no DLL's, shared libraries, C++ ABI hassles, etc. Just one binary linked to libc.

1. ATL/WTL

ATL 3.0 (from my MSVC 6 compiler) and WTL 7.5 (from sourceforge) can be made to work. Issues are:

• GCC 4 is very picky with templates and would need lots of template prototypes; I have used GCC 3.3.5
• Some template prototypes are still needed
• Some MSVC-specific pragmas etc. need to be ifdef'd
• A few pack pragmas need to be replaced by Wine's pack headers
• Everything related to _get_uuid(class) I've commented out; I need no COM stuff
• Some GCC warnings need to be turned off, or alternatively code changes need to be made
• Various small changes
• As more parts of WTL get used (i.e. instantiated), more changes will be required

Basically, ATL+WTL can reach a state where they compile with GCC 3 and the changes are still mostly cosmetic. Some of the changes might even be incorporated in the official WTL, now that it's free.

I have read the mails of Boaz Harrosh' previous changes; apparently he has had to invest much more work because of COM.

With the modified ATL/WTL, I was able to compile the wizard-created sample SDI application on Linux.

2. Winelib "as is"

After some digging through the Web, I've been able to link the sample SDI application against Winelib.

It took somewhat longer than it should have due to

1. WTL's habit of just ATLASSERT()ing things and
2. the rather elaborate work of finding those places with wine-dbg and/or ATLTRACE()s plus WINEDEBUG=+relay.

Since I'm not familiar with the Wine debugger, it would have been very helpful to be able to use gdb on the resulting executable. However, gdb reported that it didn't know the file format.

Wishlist for Wine:

• Make gdb work on Winelib programs
• Document Winelib and the build process better (the documentation is outdated, though the tools are good).

All in all a reasonably successful endeavour, and the application runs stable and looks fine except for the font (that probably can be configured better).

BUT: ... BIG SHOCK: That's not a single ELF executable, it's a weird mixture of PE and ELF and a .so file and a wrapper program that apparently starts wine in the background ...

That doesn't fulfill my goals of building a native Linux exe with no dependencies except libc.

It's also quite slow when loading.

3. Winelib statically linked

Apparently Wine has made a decision a few years ago: that support for native Windows apps with all the infrastructure they need (Wine server, registry, resources, multithreading, etc.) is more important than support for porting applications to native Linux apps.

That decision is obviously correct, given the large number of Windows applications that are only available as binaries and require much infrastructure.

I'm aware of that, but I've still decided to give my dream of a native Linux app a try.

I tried the following method:

1. Get and compile Wine 0.9.7
2. Add rules to Makedll.rules to pack the objects into .a libraries
3. Attempt to link my program's objects against those static libs
4. Make changes and corrections and repeat

I first made a reduced WTL application that does not use a resource file. I don't know if this was a good decision.

The following changes were necessary to Wine:

• Comment out a lot of DLLMain functions
• Comment out some 16-bit functions that have name collisions
• Turn on debug mode (-O0 -g)
• Write a startup function main() (Wine's libwinecrt0.a didn't work for me) That might be the reason for more trouble
• Link to all of libs/unicode
• Link to some objects in libs/wine (I didn't link to loader, don't know if that's good)

This is where the heavy trouble started:

• Replace the assembly stuff in critical sections (due to the debug mode) ... my app is single-threaded
• Somehow set up code pages for ansi/Unix (LocaleInit() failed, see below)
• Comment out some calls to the registry where the run-time environment is registered

What eventually caused me to stop is:

• Somehow fake Wine Server or do the equivalent stuff or just jump over (Basically Register Class as atoms)
• Somehow fake a lot of initial resources (E.g. GetSystemCursor etc.)
• Overall too many modifications in interacting systems
• Altogether not a "robust" feeling

This is where I stopped.

I don't know whether I'm "so close" or miles away, but my random code editing seemed to get out of hand.

4. What is needed

What would be needed to support static linking against Winelib (if that's decided to be a supportworthy goal):

• Infrastructure to build static libs
  • separate out DllMain
  • separate out some 16 bit functions
• Possibility to provide heap based allocation through straight malloc()
• Infrastructure to fake loading resources (for those resources that come from Winelib/system)
• Infrastructure for proper initialization of modules e.g. through one setup function for each DLL and one common setup function that calls the others in some natural order. The overall initialization function should be configurable so that programs that need only a few DLL's (user, gdi, crtdll, kernel, ntdll) don't need to link everything
• Infrastructure to allow faking registry calls for those calls initiated by Winelib internal stuff (and possibly also ATL/WTL internal stuff)
• Infrastructure to handle Window class registration etc. (i.e. reduced Wine server support in the app)

What I specifically don't need/want through Winelib:

• networking
• filesystem access
• loading of external DLL's or other libraries
• C++ runtime library support

Also, if anyone is interested in hosting patches to ATL/WTL or even just looking at them, I'll gladly provide them.

You really don't want to try without wineserver support. Nearly everything depends on at least one feature that the wineserver provides. If you try to make your own version of wineserver that is somehow statically linked into the application you will have to completely change how it works and maintain that version on your own.

You're doing a noble thing in trying to get your Winelib application easy to deploy, but I think you're going about it the wrong way.

For maintainability, take a look at using the WINEPREFIX environment variable and use dynamic libraries. That way you can deploy upgrades of your application in a small installer, whilst not needing to update the Wine libraries. If you need a bug fix in a Wine library, then you can just update the one dynamic library that has changed. If the startup speed isn't good enough for you, you can use oprofile (or some other profiling framework) to work out which functions are taking up time. We would welcome any fixes to improve the startup speed. Optionally, you could comment out functions do things that you don't need.

But with WTL, it's possible to build a reasonable sophisticated application that depends only on DLLs that are already on the system.

My biggest WTL application so far, a project for the Austrian Mountain Rescue Service, has roughly 100.000 lines of code (sloccount). You can find a description on http://www.clausfischer.com/eis.en.html (a bit outdated though).

When the first phase was finished, the program would still run under Windows 98 SE upwards. It now depends on the following DLL's: VERSION, WS2_32, KERNEL32, USER32, GDI32, COMDLG32, ADVAPI32, SHELL32, OLE32, WININET, COMCTL32

On any reasonable PC with internet access (it's a networked application talking to several redundant data servers), you will find those.

Therefore, Installation is as easy as copying the EXE and starting.

That is a requirement, since the Montain Rescue Service is a volunteer organization with members from all kinds of social background, work environment, and Laptop infrastructure.

For this reason, having WTL+Winelib for Linux would have been just too nice to think of :-)

Win32 in general could never be described as "promising" no matter what libraries you wrap it with. Wine is best used for porting and compatibility rather than new app development. Libraries like GTK or Qt are far better

Your actual goal is described here - you want a program that is free of dependency hell. A noble goal indeed, but the right way to do this is to investigate things like autopackage, ELF statifier, and so on. And also to accept that a program with no dependencies is perhaps not so useful after all. For instance, you can probably find GTK+ 2.2 or higher on everybodies system these days.