Wine Traffic #298 For 4 Nov 2005

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.

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 http://www.itomig.de/Downloads.10.0.html.

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.

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"

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.

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

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

fixme:menu:GetSystemMenu not supported on other process window 0x1401f2 fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub

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 127.0.0.1 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?

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.

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

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.

pgrep wine|while read p; do kill -9 $p ; done;

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

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:

WINEDEBUG=+eject wine eject

and I get :

trace:eject:eject_cd ejecting h:
warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170
warn:eject:eject_cd IOCTL_STORAGE_EJECT_MEDIA failed with err 170

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

bash 1243 titan cwd DIR 0,8 0 219136 /mnt/cdrom
/mnt/cdrom wine-prel 14747 titan mem REG 0,8 2691072 219306 /mnt/cdrom/DINO.exe

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 ?

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 !?!

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:

lrwxrwxrwx 1 vinn vinn 18 Nov 5 15:37 d: -> /media/cdrecorder/

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:

[vinn@localhost dosdevices]$ WINEDEBUG=+eject wine eject trace:eject:eject_cd ejecting d:
warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170
warn:eject:eject_cd IOCTL_STORAGE_EJECT_MEDIA failed with err 21

Then the second time:

[vinn@localhost dosdevices]$ WINEDEBUG=+eject wine eject
trace:eject:eject_cd ejecting d:
warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170

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

http://www.winehq.com/hypermail/wine-devel/2003/12/index.html#231

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:

winegcc -Wall -O2 -I. -c -o test.o test.c

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:

winebuild --def -E vendor.dll.spec -o libvendor.def

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

winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o libvendor.dll.s

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

winegcc test.o libvendor.dll.o -o test [..] : multiple definition of `__wine_spec_nt_header'
: multiple definition of `__wine_spec_file_name'


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

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.

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

winegcc -o test test.o -lvendor