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

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

by Dan Kegel

On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein <shacklein(a)gmail.com> wrote: > You obviously don't understand how Wine works. It's not in win32, nor > is it in any other API standard Wine has to deal with (such as > Directx). It won't be shipped with Wine. I think that's not quite true. There are a couple supported wine extensions to win32, aren't there? I think there's an ioctl to get the unix path, or something... - Dan

Feb. 15, 2009

Re: Updated cebit presentation. Looking for ideas...

by Dan Kegel

On Sat, Feb 14, 2009 at 5:03 PM, Austin English <austinenglish(a)gmail.com> wrote: > Perhaps a shot of wine running firefox, with, e.g., > http://thismachine.info, to show it's running on wine. I'll probably do that live. > A before/after of Safari with corefonts might also be good, to show an > example of what winetricks can fix. Heh. Safari without corefonts hangs. Hard to capture that in a screenshot :-)

Feb. 15, 2009

Re: Closing fixed bugs

by Dan Kegel

On Sat, Feb 14, 2009 at 5:59 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Agreed meaning for "closed" status was "the fix present in Wine release". Right, agreed. > If bug reporter wasn't fast enough to report bug fixed in the 5 minutes > elapsed between AJ pushing new release tag and wholesale closing of all > fixed bugs in bugzilla... ? Not sure what you're saying there. Nobody has to act unreasonably fast. They just have to mark bugs fixed when they're fixed in git. > does that mean we have to wait for 2 more weeks to > close such bugs? Exactly, I'm proposing letting them sit there, fixed but open, until the next release, so Alexandre doesn't have to change the simple way he generates his list of fixed bugs. > [Aren't people allowed to close] their bugs themselves after > verifying the fix in latest git? They're encouraged to mark them fixed once the fix is in git. As you pointed out, 'closed' is for when the fix is in a release. > If they not supposed to do that, then > prohibit anyone except AJ from closing bugs. It seems overkill to modify bugzilla for this, since there's no reason to prohibit closing of invalid or duplicate bugs, and changing bugzilla is hardish. I just kind of like the simple model of "we fix 'em, Alexandre closes 'em", and was hoping we could agree to follow it. - Dan

Feb. 15, 2009

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

by Dan Kegel

On Sat, Feb 14, 2009 at 6:04 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > What happened with 'wine start /unix %f'? Doesn't it work for you? It turns out that having cxchromium installed does interesting things to nautilus's treatment of .exe files. I think uninstalling cxchromium made things work better. For reference: dpkg-query -L wine | grep mime shows that the ubuntu wine package is creating a file /usr/lib/mime/packages/wine which contains lines like application/x-msdos-program; /usr/bin/wine '%s'; description=Windows Executable application/x-msdownload; /usr/bin/wine '%s'; description=Windows Executable application/exe; /usr/bin/wine '%s'; description=Windows Executable ... and I presume that's what's controlling the doubleclick action on .exe's now that I've uninstalled cxchromium. - Dan

Feb. 15, 2009

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

by Vitaliy Margolen

Martin Hinner wrote: > On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: >> - It's already present in Wine: >> libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym >> please read: libs/wine/loader.c > > I saw it, but I don't understand how is it exported to the "Win32 > world", i.e. how do I import these using GetProcAddress() Win32 API ? They are not part of any Wine "dll" so you can't get their address that way. They meant to be used by Wine itself or winelib apps. Vitaliy.

Feb. 15, 2009

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

by Vitaliy Margolen

Martin Hinner wrote: > Hello, > > 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. Depending on what you need to do it might be a good thing or might be a complete no-go. Remember that Wine has an additional layer on top of system. If you bypass it, you can potentially create lots and lots of problems. For example, handles, synchronization, GUI, messages, d3d, ddraw (and most other things) depend on those extra layers. You won't be able to use them together without major risk of instability. Eg. you can't pass fd to ReadFile(). Nor can you block on read() and expect message processing in the same thread. Not saying it can't be done. It just needs to be coded with consideration of Wine inerworkings. What I want to say, what you did is just an API that doesn't solve anything on its own. Anything using it will be as complex as writing winelib application. Or will have to be expanded to properly fit into Wine. Vitaliy.

Feb. 15, 2009

Re: 1.1.15 failing to build -- what changed?

by Hin-Tak Leung

--- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > > I have no idea why suddenly at wine 1.1.15 it requires > the > > x86_64-redhat-linux-{as,ld,nm} form of the binutils > tools. It seems to treat x86_64 suddenly as a > cross-compiling environment. > > Are you sure nothing in the build environment just happened > to change > in the last 2 weeks or so? Well, I do my weekly fedora update, so a few hundred MB changes weekly. Given that this problem happens with both Debian/Ubuntu systems and fedora, this week... and I have had my rpmbuild system working smoothly for about a year... If I am going to guess, I think the change has something to do with cross-compiling, instead of just the occasional -m32 .

Feb. 15, 2009

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

by Vitaliy Margolen

Dan Kegel wrote: > 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. What happened with 'wine start /unix %f'? Doesn't it work for you? Vitaliy.

Feb. 15, 2009

Re: Closing fixed bugs

by Vitaliy Margolen

Dan Kegel wrote: > A few months ago, Alexandre started including lists of fixed > bugs in his release announcements. > See e.g. http://www.winehq.org/announce/1.1.15, which says > > Bugs fixed in 1.1.15: > 5694 Lionhead Black & White 2 demo crashes > 7014 Unhandled page fault when exiting Commandos - BEL > 7297 MIDI in/out fails, ports recognized > ... > > I rather like those lists. He generates them by simply querying > for open but fixed bugs right when he does the release; > he then closes the bugs. They're good for PR if nothing else. IMHO there are always enough bugs fixed for each release in buzilla. Agreed meaning for "closed" status was "the fix present in Wine release". If bug reporter wasn't fast enough to report bug fixed in the 5 minutes elapsed between AJ pushing new release tag and wholesale closing of all fixed bugs in bugzilla does that mean we have to wait for 2 more weeks to close such bugs? Same applies to people closing their bugs themselves after verifying the fix in latest git. If they not supposed to do that, then prohibit anyone except AJ from closing bugs. Vitaliy.

Feb. 15, 2009

Re: 1.1.15 failing to build -- what changed?

by Ben Klein

2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > I have no idea why suddenly at wine 1.1.15 it requires the > x86_64-redhat-linux-{as,ld,nm} form of the binutils tools. It seems to treat x86_64 suddenly as a cross-compiling environment. Are you sure nothing in the build environment just happened to change in the last 2 weeks or so?

Feb. 15, 2009