February 2009 - Wine-Devel - list.winehq.org

re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Detlef Riekenberg

On Fr, 2009-02-13 at 22:44 -0800, Dan Kegel wrote: > Very interesting. ... but not needed > I'd been suggesting to ISVs that they create a single > winelib dll and conditionally load that if present, > but winegate.dll might be an appealing alternative. Use wine_dlopen/wine_dlclose/wine_dlsym from libwine.dll It's much better (portable) -- By by ... Detlef

Feb. 14, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Detlef Riekenberg

On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote: > Hello, > > I have created a small library to allow Win32 applications running > under Wine to load native Unix shared libraries (.so). First (one-hour > hack) version is available at > http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider > inclusion in WINE tree (dll/ directory). Please note that Makefile.in > as well as configure scripts will likely need some changes. > > Purpose of this Wine DLL is to allow Windows applications to use > directly Unix library functions. This is useful for example for > applications which talk to specific drivers and it's not > efficient/possible to create system native DLL for such driver or > library. Win32 app. vendor is required only to detect execution under > Wine and load proper native library. > > WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which > allow Windows app to load additional libraries and use them. Hi Martin. Thanks for your interest in Wine. I read your Mail, and my first impresion was: not needed After downloading winegate.tar.gz and reading the source: winegate is a nice Idea, but it's useless. Why? - Your proxy code is not portable. - It's already present in Wine: libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c -- By by ... Detlef

Feb. 14, 2009

Re: Status of USB driver support?

by Dan Kegel

On Sat, Feb 14, 2009 at 3:09 PM, Dan Kegel <dank(a)kegel.com> wrote: > Is http://wiki.winehq.org/USB up to date? > > I could have sworn that Alexander Morozov > had submitted a new version of his patch, > but I can't find it. Found it and added to the wiki page. Has anybody tried the Jan 20 patch? - Dan

Feb. 14, 2009

Status of USB driver support?

by Dan Kegel

Is http://wiki.winehq.org/USB up to date? I could have sworn that Alexander Morozov had submitted a new version of his patch, but I can't find it.

Feb. 14, 2009

Re: Wine desktop integration: current directory of app launched with doubleclick?

by Dan Kegel

On Sat, Feb 14, 2009 at 2:33 PM, Ben Klein <shacklein(a)gmail.com> wrote: > Probably. It's worth trying out, but I have an idea to work around it: > > #!/bin/sh > DIR=`dirname "$1"` > DIR=`cd "$DIR"; pwd` > pushd "$DIR" > wine "$@" & > popd > fg I don't think that'll help, offhand. Maybe the original script will work just fine, I'll see if I can find a multi-disc game to test.

Feb. 14, 2009

Re: Wine desktop integration: current directory of app launched with doubleclick?

by Ben Klein

2009/2/15 Dan Kegel <dank(a)kegel.com>: > Ran into this again today. I usually launch everything > from the commandline, but in preparation for my cebit > talk, I started trying to use the GUI and just double- > click on apps in Nautilus. (This is Ubuntu 8.10.) > Works fine until I try it with the setup.exe in the > directory created by the Adobe Photoshop CS2 downloadable > trial... at which point it aborts early with a dialog box. > > The little script I posted before still works, and lets photoshop's > inner installer run. > > I suppose this script isn't the final word, though, as I think > it will prevent switching discss on multidisc installs. Probably. It's worth trying out, but I have an idea to work around it: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` pushd "$DIR" wine "$@" & popd fg Could someone try this out? I'm not sure if I have any multi-CD installers easily accessible. Of course, you'll need some way to run "wine eject" when switching discs ...

Feb. 14, 2009

[patch but not quite ready] NamedPipes messagemode

by Luke Kenneth Casson Leighton

http://bugs.winehq.org/show_bug.cgi?id=17195 with only one significant bug - some memory corruption - the semantics are now correct in the namedpipe messagemode patch. i drew a diagram outlining the data structures / design http://bugs.winehq.org/attachment.cgi?id=19449 because it's so horrendous that even i want to throw up. assistance in finding the memory corruption would be really helpful. an assert is thrown after more than 4 short reads are performed on the same namedpipe, with this straaaange error: ead: file.c:631: server_get_named_pipe_fd: Assertion `wine_server_ptr_handle(fd_handle) == handle' failed. ead: server.c:628: server_get_unix_fd: Assertion `wine_server_ptr_handle(fd_handle) == handle' failed. wine: Assertion failed at address 0xf7ca8d7f (thread 000f), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x7bc99ee0 "server.c: fd_cache_section" wait timed out in thread 000f, blocked by 0014, retrying (60 sec) i'll try to write a simplified test because that's the "threadread" test on which this occurs. i can't quite believe that all 5 tests can be passed [by reducing the number of short reads to less than 4]. it's been a bit of a "drunken walk" development style, i'm afraid :) notes: * in order to preserve message-mode semantics correctly, each message gets ITS OWN socketpair. the socketpair is used EXCLUSIVELY for that one message and is NOT re-used by the other end. so if it's client writing to server, one message, that's one socketpair. if it's server writing to client, one message, that's another socketpair. if client writes 20 messages to server, that's 20 new socketpairs, if at same time server writes 25 messages to client, and nobody's done any reading yet, that's a total of 45 outstanding socketpairs - 90 filedescriptors. this is not a hoax. it's the only way i could think of that preserves messagemode semantics correctly. * for each end - client and server - to be able to "block", waiting at any time, there MUST be at LEAST one socketpair in each of the queues. so, initially, that's what's done: one pair of socketpairs are created, one for the client, one for the server. on the FIRST write (to server, or to client), this initial "empty" socketpair must be written to; subsequent writes (to server or to client, each) must have a NEW socketpair created. * on a read, a socketpair must "hang about" - MUST not be shut down - until there is a new one created (which happens only on a new write). in this way, multiple threads will always have a filedescriptor to block on. * when a read has read all available data, the socketpair is marked as "finished" but is NOT shut down. * on each write, if a new socketpair is created, then and ONLY then can "old" marked socketpairs be shut down. * shutdown of read-sockets, on which [potentially many] reader[s] are waiting will result in an EPIPE. this is an ACCEPTABLE error IFF no data has been read yet, i.e. at the start of a new message. what happens, basically, is that the "old" socketpair - even though it had been used already by the previous reader - is what the thread "blocks" on (because you have to block on _something_). and on the _very_ first message, of course, you block on the specially-prepared initial socketpair, the one that had to be created and marked as "as-yet unwritten to". * you can see at line 872 of ntdlls/file.c (after patch is applied) that oh whoopsie, EPIPE occurred, but we've not read any data at all, just grab another filedescriptor from wineserver and try again. in this way, wineserver hands out the next available message from the filedescriptor queue. if yet _another_ EPIPE occurs, then all that means is that another thread "got there first", wow big deal, around you go again. * indicating that data has been read is performed using a special wineserver message "NAMED_PIPE_SUB_AVAILDATA" using server_set_named_pipe_info(). this horrible hack passes information to wineserver telling it to subtract the amount of data read in userspace from the filedescriptor data structure (fdqueue) representing that socketpair. * indicating that data _will_ be available is performed again using server_set_named_pipe_info(), this time using a message "NAMED_PIPE_SET_AVAILDATA". the set is performed BEFORE the actual write, otherwise a reader will "unblock" and potentially try to set the available data to negative!!! this would be baaad. * a critical section is performed around all uses of server_set_named_pipe_info() and server_get_named_pipe_fd(). this is NOT the same critical section as server_get_handle_fd(). i don't know if this makes any difference. things that cannot be done: * you cannot do the read or the write inside wineserver (server_named_pipe_read() will be deleted, later). the reason is complex to describe, but boils down to "blocking in userspace on the socket in order to wait for a message" and "non-blocking read on the same socket in order to get the data" are unfortunately mutually incompatible. one screws up the other if you set or clear O_NONBLOCK. * you cannot send the length as a 4-byte "header" down the socket, to be read as a length and then that much data read out. if you have multiple readers blocking on the same filedescriptor, how do you make sure that only one of them reads the length?? they're all blocking on the same socket! send the length multiple times?? how do you know how many readers there are?? short answer: you can't. so - scratch that idea. [ok - maybe you could do a critical section, but you'd have to do one per file, and i'm not ready or willing to add an array of per-file-handle critical sections to ntdll without further discussion] issues: * multiple readers of the same socket, when reading data amounts that are larger than the SO_RCVBUF and/or SO_SNDBUF, could potentially end up corrupting the data because of overlaps in the reads. given that this is _already_ a problem, in the existing Wine code, i am not going to be dealing with this issue, in this iteration. particularly as solutions involve having to do per-file critical sections and YES that's a generic problem even on standard files not just pipes not just messagemode pipes ALL files. * running out of socketpairs; protecting the message queue length. i believe there's a default message queue length in NT, but even so, the number of file descriptors this [necessary] design uses up is _horrendous_. one pair per message! but - tough luck. the options are pretty limited and constrained by the requirements. so: if anyone says to me, "no this cannot work, you cannot _possibly_ have got correct messagemode semantics purely in userspace and without sending length fields, you _must_ do the reads and writes inside wineserver", then... well... that will be a good way to get me to unsubscribe from wine-devel. if anyone can think of any other ideas, or implementations, or optimisations, then... well... unless they're _really_ good ideas, they'll have to wait :) ideas such as using a separate socketpair for communicating "length" messages are welcome, if accompanied by well-laid-out explanations, because my brain is turning to jelly with this stuff and i could do with some light reading instead of working it out myself :) l.

Feb. 14, 2009

Re: Wine desktop integration: current directory of app launched with doubleclick?

by Dan Kegel

Ran into this again today. I usually launch everything from the commandline, but in preparation for my cebit talk, I started trying to use the GUI and just double- click on apps in Nautilus. (This is Ubuntu 8.10.) Works fine until I try it with the setup.exe in the directory created by the Adobe Photoshop CS2 downloadable trial... at which point it aborts early with a dialog box. The little script I posted before still works, and lets photoshop's inner installer run. I suppose this script isn't the final word, though, as I think it will prevent switching discss on multidisc installs. - Dan On Fri, Apr 6, 2007 at 10:01 PM, Dan Kegel <dank(a)kegel.com> wrote: > I *almost* have a great success story to report; the only thing > keeping it from being a success story is the current directory > chosen by Nautilus when double-clicking on .exe files. > > My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, > and had to go to a hand doctor. Along the way her hand got x-rayed, > and the doctor handed her a cd-rom with the x-ray pictures on it. > The disc has an autorun.inf on it that should start ViewSel.exe. > I don't know if that's supposed to work with Wine and Nautilus, but > probably doubleclicking on ViewSel.exe does the same thing. > > ViewSel.exe puts up two big buttons: > low res (which launches a web browser on an html file), > and high res (which launches a DICOM viewer). > If you cd to the root of the cd-rom drive and run ViewSel, it works. > If the current directory is anything else, it doesn't work. > > If you start the autorun app via Nautilus, those buttons don't work, > so presumably it sets the current directory to something other than > the root of the drive. To see, I created a wrapper shell script, > ~/bin/mywine, > containing > #!/bin/sh > pwd > /tmp/log > and used "Start with" to launch ViewSel.exe with ~/bin/mywine. > This showed that the current directory was $HOME. > > I had a look at the gnome code to see how it decided, but it was > a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) > So I tried a little shell magic. I created a new wrapper shell script > that assumes the argument is a path to a file, and > sets the current directory to the directory containing that file: > > #!/bin/sh > DIR=`dirname "$1"` > DIR=`cd "$DIR"; pwd` > cd "$DIR" > wine "$@" > > That worked better; it let ViewSel.exe launch the DICOM viewer. > > So... I suppose the next step is to look at the debian/ubuntu packages > for wine and see if that little wrapper script could be incorporated > into the default way file browsers start wine? > It sure would be nice if apps that expected the current directory > to behave like this (it's not uncommon!) Just Worked. > - Dan >

Feb. 14, 2009

Re: Proposal: put Winetricks into Wine menu

by Dan Kegel

On Sat, Feb 14, 2009 at 11:21 AM, Scott Ritchie <scott(a)open-vote.org> wrote: > I want to cut down on the number of items in the menu as it is - winecfg > will be integrated into a System -> Preferences -> Windows Applications > menu, browse C:\ drive will be in Places, and uninstall would go into > Applications->Add/Remove. Putting uninstall into Add/Remove will be an interesting bit of integration; you'd have to modify the Add/Remove app quite a bit, I think. > Once that's done, leaving winetricks in the menu would be out of place. > Though maybe it could go into the same System -> Preferences -> Windows But it's not a preferences; it's an add/remove kind of thing, so maybe it too should go into Add/Remove? Anyway, in the meantime, can you add it into the Wine menu for this release, and sort out where it really belongs later? It really is a missing piece, and having all the Wine stuff together in one menu entry is arguably a nice way to group it, at least for now. Thanks, Dan

Feb. 14, 2009

Re: Proposal: put Winetricks into Wine menu

by Scott Ritchie

Dan Kegel wrote: > I know, when I wrote Winetricks, I meant it as a developers' > tool only. But... then... people started using it, and > it made sense to provide it as a way to download missing > visual C++ runtimes etc. for average users. > > Quite a few newbies trip over the fact that it > needs cabextract installed. Let's make it easy > for folks, actually package it up along with > Wine (SuSE does this already), and put it > in the Wine menu right beneath "Uninstall Windows Software". > > What do people think? It might make life easier for a lot of folks. > I want to cut down on the number of items in the menu as it is - winecfg will be integrated into a System -> Preferences -> Windows Applications menu, browse C:\ drive will be in Places, and uninstall would go into Applications->Add/Remove. Once that's done, leaving winetricks in the menu would be out of place. Though maybe it could go into the same System -> Preferences -> Windows > (And, come to think of it, we should include some documentation > in that menu. "man wine" just doesn't cut it for the average > gui user, and "wine manual page" in the gnome > help browser is a broken link. But that's a separate issue.) > - Dan > There's already a help feature in the distribution right next to the menu - we should provide documentation there and avoid clutter. Thanks, Scott Ritchie

Feb. 14, 2009