Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #298 For 4 Nov 2005

By Brian Vincent

Table Of Contents


This is the 298th issue of the Wine Weekly News publication. Its main goal is to start skiing again. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at

Mailing List Stats For This Week

We looked at 261 posts in 478K.

There were 88 different contributors. 50 posted more than once. 49 posted last week too.

The top posters of the week were:

1. News: Another Beta Article

(1 post) Archive Link: "News"

Topics: News

People: IT JungleNews

A short bit of news covering Wine's beta release was in IT Jungle this past week. From the article:

The Wine emulator will allow popular Windows desktop and server applications to run on Linux and Unix without the need for a Windows platform. This is a goal that many people have tried to shoot for in other operating systems--lxrun inside various Unixes and Windows 3.0 inside of OS/2, just to name two--and such emulation has received mixed results in the market because emulators tend to make emulated applications run slowly and emulators are often cranky and buggy. Now is your chance to see if the open source Win Project community can--and has done--a better job than prior commercial emulators of the past.

2. WineProbe, Part II

(4 posts) Archive Link: "WineProbe part II; Propaganda for Wine"


David Gümbel announced some news coming out of Germany:

As most of you probably remember, my company (ITOMIG) launched an initiative called WineProbe (=~ "WineTasting" in English) some time ago. As part of this initiative, we're arranging an informational event next week on thursday afternoon in Stuttgart. We'll present Wine and its capabilities for migrating and porting applications to Unix. Details are available online (in German).

The target audience are software vendors who would like to create a Linux or cross-platform version of their Windows-based products. However, anyone interested is cordially invited to come, listen and discuss, and have a glass of good wine afterwards ;) The event is free, you just need to send us a small application form available online.

Aside from that, I wrote an article titled "Grenzen überschreiten" ("Crossing Borders") about Wine and its use in the city of Böblingen in a project we're running together with Böblingen and Tübingen University. It was published in print this week in the magazine Kommune21. Kommune21 is a magazine about the use of information technology in municipalities (german: "Kommunen"). About 11 000 copies are printed every month, and I'd say the CIO of pretty much every major german city has a subscription.

They do not normally have a free online version of their contents available. However, they provided me with a PDF of the article, which we're allowed to put online on our web site. I think this is very nice advertisement for Wine, in particular because of the very specific audience of that publication. Anyone interested can find the article available online at

3. Multimonitor Support

(5 posts) Archive Link: "Multimonitor support in Wine?"

Topics: Graphics

People: Rob DoneMarcus Meissner

Two threads popped up this week that ended up being related. We'll cover them as two separate threads. Rob Done had a Winelib app he wanted to run on Solaris x86:

Ive been trying to figure how to get a (single) Wine application to be able to display dialogs on each of 3 monitors in a non xinerama setup (DISPLAY :0.0, :0.1, and :0.2).

I am well aware that xinerama mode would allow this quite easily, but xinerama is not an option, partly since CDE on Solaris will not work in xinerama mode, and a little thing called Software Requirements Specification.

I am also aware this isnt specifically a wine issue, but in researching what could be done about over the past week, I found several references to gdi_display, x11drv_thread_data, and various other constructs and class members in Wine that describe which display to use. This leads me to believe there is some method to allow Wine to enable the desired functionality.

Whether the method to support this functionality is built in or needs to be coded, I have not yet determined, since nearly every file in dlls/x11drv directory uses these members and constructs.

If someone has any insight on how to implement this or where I should focus my efforts, it would be very helpful.

Marcus Meissner described some ideas and translated from Windows to Unix-speak:

The .x DISPLAY component is "Screen" in X11 speak.

So far we have no special X11 Screen handling in our code as far as I know.

I would also not know how to map the Windows API to X11 Screens :/ There are "WindowStations"

Rob thought about it more and came up with something to try, " Since alot of the Wine code refers to "thread_display" attributes, I spose I could try to create a separate helper thread for each display, each somehow kludged to link to a separate display at startup, and marshal display requests for each, but it seems that there could be an easier way. "

Thomas Tornblom wanted to know why he didn't just use Xinerma, but Rob replied that it only worked with Sparc machines. Rob persued some different techniques for getting his app to display on different monitors, but nothing seemed to work. Then the next thread popped up...

4. Multiple App Support

(6 posts) Archive Link: "wine for two, please."

People: wino_at_piments.comMarcus MeissnerRob Done

Someone wanted to know how to get two Windows apps to talk to each other with Wine:

I dont know much about the message queue works on Wine but wondered if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact.

As I understand it, running two instance of command line wine is more analogous to having two different computers running each app under windows.

My goal is getting NatSpeak dictated text messages freed from the confines of the wine instance of the app. This would seem to be one approach if wine can run more than one process at a time.

Marcus Meissner explained Wine was not like having two separate computers and was specifically designed for something like that to work:

Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that.

The original poster reported success:

Many thanks, that is indeed what happens.

And the best part: Dragon can actually type into editboxes on a concurrently running app!

None of the voice control stuff works, even internally, so I may get to looking into that mechanism later to see if it can be made to work. (eg "click file" should bring down the file menu) Indeed this seems to upset the dictation function and leaves it in an inconclusive state . Playing back some text seems to clear it tho'.

This does not look too far from working either.

Now the big one here is to get this output sent to Linux programs. I have been considering different routes to this end.

  1. Using winedebug or spy output piped through grep then somehow injecting it into various X programs.
  2. Patching something into wine or better hooking into and existing mechanism that could send the output to the X window with the input focus.
  3. Using wininet to open a link to a bespoke client on that could redirect the output in X.

As you can see are barely thought out ideas just to map possible ways to explore.

Any comments on the merit of any of these approaches?

There weren't any ideas concerning the integration with Linux apps. It could be a cool project for someone looking to hook speech-to-text into Linux apps though.

Rob then replied with an idea about his earlier thread concerning multimonitor supoort:

So I could create 2 wine apps that simply duplicate the window creation and message handling , and have them use FindWindow and the like to enable using SendMessage and such to synchronize the windows?

If so, that would MUCH simpler than the method I had started formulating.

He replied to himself about four hours later:

I was going to wait til tomorrow to test this, but couldnt wait. This works perfectly for my app and couldnt have came at a better time.

I just created a simple Win32 dispatcher program for each screen and sent the window creation messages to the HWNDs from FindWindow instead of the local app and it creates the dialogs on any screen I want. Joy Joy!!!!!

It worked out perfectly since the threads that create windows have to send messages to the main loop for it to create them so that the dialogs dont from close when the thread exits anyway.

It is refreshing that after I went through all the battles of getting multihead display, gcc, and wine running on Solaris that FINALLY something would work so simply.

Thanks again to the whole Wine crew that made this possible!!!

5. Killing Wine Processes

(8 posts) Archive Link: "killing wine dregs"

Topics: Fixes

People: wino_at_piments.comMike McCormackFrancois GougetWalt OgburnDan Kegel

When apps hang it can be a pain to kill Wine. Someone asked this week about the merits of a particular method:

I often have wine finish uncleanly or need to break in if it is misbehaving , this leaves some processes lying around and often means wine cannot be restarted correctly.

I find killing it by hand labourious so I used the following command to clean up and have now defined it as an alias to make life easier.

It works nicely but just wondered if anyone would say OMG dont do that !

That launched a series of people describing their favorite methods for killing off wine processes. Walt Ogburn and Dan Kegel both suggested using wineserver -k. Mike McCormack suggested another way, " killall -9 wine-preloader works for me every time, however some older kernels have a bug which causes zombie processes (a placeholder for the process return code) to never be removed in the kernel. I think this was fixed around Linux 2.6.7 (ie. the unpatched Linux kernel)."

Francois Gouget explained another gotcha, " Besides the zombie processes mentionned before, some processes may be stopped (e.g. by the debugger) and won't die until you send them a CONT signal."

6. Wine Eject

(10 posts) Archive Link: "New eject command issue"

Topics: Multimedia

People: Christian CostaAlexandre JulliardBrian Vincent

Alexandre came up with a new Winelib helper utility: eject. Not to be confused with the regular Linux eject command, it gets invoked by wine eject. The idea remains the same though, to eject CD-ROMs. It's particularly useful for things like multidisc installation programs. Christian Cost ran into problems using it:

I tried to use the new eject command and this does not seem to work.

For that, I run a exe on the cdrom and try to eject the cdrom with:

and I get :

and nothing happen and files are still open on the cdrom as shown below :

Is there anything particular to do ?

Morover, it seems eject is not installed so I have to run from the programs directory. I have also found that there is already a eject command in my distro (Mandrake). So this conflict may require renaming the eject command.

Any idea ?

With regards to the last item, Alexandre explained, " Now you know why it's not installed. <g> Just do 'wine eject'. "

Alexandre guessed that Christian's CD-ROM hadn't been detected as a removable device. He asked if it was a real CD or just a disk image. Christian said it was a real CD-ROM and the appropriate entries in ~/.wine/dosdevices were correct. Alexandre suggested, " You should set it to autodetect and check what GetDriveType returns then. If it still returns CD-ROM then please send me a +server trace. "

Christian reported the outcome of autodetect, " If I set H: to autodetect, GetDriveType returns DRIVE_FIXED (3)."

Alexandre pointed to the next part of the chain, " Then you need to figure out why FILE_GetDeviceInfo doesn't recognize it as a CDROM."

After more investigation decided to hack it into working:

I will hack FILE_GetDeviceInfo just to make it recognize my cdrom as removable and try to see if it helps.

However, I don't understand well why forcing the drive as cdrom (instead of relying on autodetection) is not taken into account. This could be also usefull for ISO images. Unless this option is planned to be removed !?!

Alexandre explained why that was a bad idea, " We can't do that because all we have is a file handle, and there's no way to know which drive it was opened from. Besides, you don't really want that anyway, whether you open d:\foo or z:\mnt\cdrom\foo doesn't change the fact that foo is on a removable device. So we really need to make autodetection work properly (it does work fine for ISO images BTW). "

As I was covering this, I decided to try it out as well. I ran into the following problem:

Odd thing here as well. Fedora Core 4. This is wine CVS as of a few days ago, I don't think anything has changed in this area.

If dosdevices contains a normal:

Then "wine eject" doesn't work the first time I try it. The second time I run it, it works fine.

Debugging output shows this the first time I try it:

Then the second time:

Then I replied to myself, " Maybe I'm just unclear on the usage. It appears the first time it unmounts the drive and then the second time it actually ejects it. Is that intended behavior?"

There was no answer by the time this issue came out.

7. Linking Windows Libraries

(5 posts) Archive Link: "Calling PE DLLs"

Topics: Winelib

People: Daniel StoddenMike McCormackAlexandre Julliard

A common reason for wanting to use Winelib is to take advantage of proprietary Windows libraries and use them in a Winelib program to interact natively on Linux. One such example is audio codecs. Daniel Stodden asked how to do something like that:

I'm stuck at the process of loading PE dlls.

Like some others before me, i've got a native w32 dll which i would like to hook into on a linux box. no source code available. the case is almost identical to

though, there's not much application code yet, except a small test program written by myself, currently only meant to call a single function on the dll.

so, using winemaker does not seem to spit out anything usable, and there seems to be no official documentation on how to use winebuild here.

the program is called test.c, calling symbols from a vendor-supplied header file.

created test.o through winegcc:

let's call the library vendor.dll again. i've played with winedump, finally got a vendor.dll.spec.

i'm calling winebuild to get a .def as follows:

then, one of my better guesses on how to proceed seemed to be:

the assembler code looks reasonable. though, linking fails with duplicate symbols:

i'm aware that i could probably avoid all of this by just using LoadLibrary() and resolving the symbols at runtime. otoh, the approach above is potentially simpler, if i just knew how. :)

could someone please enlighten me? what am i doing wrong?

Mike McCormack asked, " Why not just use LoadLibrary("vendor.dll") and GetProcAddress() in you winelib application instead of mucking round with winegcc and winebuild in order to directly link your dll? "

Daniel said it was an option, but wanted to know how to get the method he described to work:

you're right. as i said, that's an obvious option.

but since linking directly would work on windows and since the .def-mechanism with wine tools is supposed to support just that, and since, for the purpose in question, i really don't see the point in programming the dynamic loader manually, why not give it a try as well?

but basically you're right.

Alexandre replied:

Once you have libvendor.def you should be able to simply do:

Daniel replied that it worked and the runtime loading method did as well.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.