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

Re: 1.1.15 failing to build -- what changed?

by Hin-Tak Leung

--- On Sat, 14/2/09, Ben Klein <shacklein(a)gmail.com> wrote: > > A packager of a debian based distro reported the same > issue. They are doing: > > CFLAGS="$(CFLAGS)" > LDFLAGS="$(LDFLAGS)" ./configure > --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) > --prefix=/usr --mandir=\$${prefix}/share/man > --infodir=\$${prefix}/share/info $(CONFFLAGS) > > > > Where the two DEB_* variables are: > > DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture > -qDEB_HOST_GNU_TYPE) > > DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture > -qDEB_BUILD_GNU_TYPE) > > > > When building 32-bit packages DEB_HOST_GNU_TYPE is set > to i486-linux-gnu and this results in 'i486-linux-gnu-as > not found'. I have a similiar problem on fedora 10 x86_64 via an rpm driven build process. rpmbuild has a macro %configure which does ./configure --host=%{_host} --build=%{_build} I have managed to work around the problem by creating x86_64-redhat-linux-{as,ld,nm} sym-links to {as,ld,nm}. (x86_64-redhat-linux-{gcc,g++,...} already exists). But I wish I didn't have to do that. 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.

Feb. 15, 2009

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

by Ben Klein

2009/2/15 Dan Kegel <dank(a)kegel.com>: > 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. Well, I suppose it would depend where the script is run from. If the problem is the shell staying in the CD directory until wine finishes, it should fix it. An alternative would be to replace pushd/popd with: cd "$DIR" and cd respectively ... > Maybe the original script will work just fine, I'll see if I can find > a multi-disc game > to test. Let me know :)

Feb. 15, 2009

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

by Ben Klein

2009/2/15 Martin Hinner <martin(a)hinner.info>: > If wine-team decides not to include this (or similar .dll) in the Wine > package, we'll just redistribute it with the application, but I think > there is need for such library. You repeat yourself in another post: 2009/2/15 Martin Hinner <martin(a)hinner.info>: > I am not pushing on WINEGATE.DLL inclusion in Wine package. If it's > not included, we'll include it in our installers and problem is > solved. 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. If you want to ship it with your product, that's your prerogative. If you want to release your project on public domain or under an open-source license such as LGPL, by all means. > But I think other developers need such library to make their > apps. working under Wine and it's much better to have one "standard" > and well documented library than 10 or 20 proprietary solutions. I > understand it is not clean solution, but world is not perfect. A standard like, for example, what was mentioned earlier with wine_dlopen stuff? I don't know all the details about winelib, but from what I understand you should be using those. > My feeling is that Linux desperately needs applications that currently > run only on Windows. It's my feeling that it doesn't. "Would be nice", yes, but nowhere near "desperately needs". > Companies will not use Linux if they cannot run > their applications on it. It's like binary drivers. No it's not. Businesses in general have never been particularly receptive to stuff they don't already know (read Microsoft). Vendor lock-in contracts are quite common. Some contracts (probably most) bar businesses from installing any other operating system on any machine they run or suffer heavy fines. There's also cost of retraining staff, tech support, systems administrators ... > They are bad, but better than nothing. In an ideal world > there would be no need for Wine anyway :-). If you haven't noticed, we don't live in an ideal world. Wine has its uses, the set of which continues to increase. Being able to run proprietary drivers where there is no way to run a device natively on Linux sounds good, but what you're talking about is essentially wrapping a win32 "driver" around native libs. It would be better for everyone involved if there was a fully-native Linux library that supports the device, with appropriate wrappers in winelib, possibly even using your winegate, if the companies really are that serious about supporting Linux systems.

Feb. 15, 2009

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

by Austin English

On Sat, Feb 14, 2009 at 6:49 PM, Dan Kegel <dank(a)kegel.com> wrote: > I've been slowly finishing my cebit presentation. The current draft is at > http://kegel.com/cebit/ > > It now talks briefly about winetricks, > and uses firefox and safari as examples > of installing and running platinum and bronze > apps. Perhaps a shot of wine running firefox, with, e.g., http://thismachine.info, to show it's running on wine. A before/after of Safari with corefonts might also be good, to show an example of what winetricks can fix. -- -Austin

Feb. 15, 2009

Updated cebit presentation. Looking for ideas...

by Dan Kegel

I've been slowly finishing my cebit presentation. The current draft is at http://kegel.com/cebit/ It now talks briefly about winetricks, and uses firefox and safari as examples of installing and running platinum and bronze apps. It also talks more about support, since a windows admin I showed it to said windows admins were generally scared of trying to support open source apps. If anyone has suggestions for how to make this presentation more appealing/informative/convincing to newbies who are only familiar with windows, please let me know. Also, if anyone can tell my why firefox doesn't show the Windows logo until you refresh sometimes, I'd be grateful. Maybe it's because the same image is used twice in the same page? - Dan

Feb. 15, 2009

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

by Martin Hinner

Ben, On Sat, Feb 14, 2009 at 7:10 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/14 Martin Hinner <martin(a)hinner.info>: > Wine is (or has been) working on a driver system to handle native > Windows USB device drivers via libusb, for things like printers and > scanners where there are no Linux-native drivers. This is a better > solution. Yes, but it is only for some devices. I will give you again one example I was mentioning: FTD2XX.DLL driver from FTDI. They have versions for many systems, but these behave a little bit different way. Tell me how would you solve this problem. Write a complicated libftd2xx.dll.so wrapper to maintain compatibility ? For how many applications would it work? There are thousands of similar problems between Win32-Linux world. Do you think that ISVs will find budget for this to support Linux or just not do it? > All this is what WINEGATE.DLL sovles with minimum possible effort. You >> simply create class "CWin32Driver" "CLinuxWineDriver" and you're done. > > Only when a suitable native Linux library already exists, correct? > There aren't many cases of this, from what I understand. I think it's more cases than you think. I can give a lot of examples, but that would be "spamming" of this mailing-list. Just one more thing, I tried one of our applications using HID-usb device. Does not work under Wine. I have no idea why, it's probably possible to fix the problem (in wine), but this clearly shows that world is not always ideal. >>> Why not use winelib for these cases if *nix support is important >>> enough to modify the source so it works nicer in Wine? >> >> Because sometimes you don't get enough customers to get paid for >> native Linux version and it's quite complicated to port even mid-sized >> projects using winelib. For example try to compile MFC ... > > Given that for your system to work there has to be a Linux-native > library for winegate to hook into, the effort involved in porting to > Linux via winelib would likely be equal. I disagree... I am not pushing on WINEGATE.DLL inclusion in Wine package. If it's not included, we'll include it in our installers and problem is solved. But I think other developers need such library to make their apps. working under Wine and it's much better to have one "standard" and well documented library than 10 or 20 proprietary solutions. I understand it is not clean solution, but world is not perfect. If it's included, I am willing to help with maintenance and write some documentation. My feeling is that Linux desperately needs applications that currently run only on Windows. Companies will not use Linux if they cannot run their applications on it. It's like binary drivers. They are bad, but better than nothing. In an ideal world there would be no need for Wine anyway :-). Martin

Feb. 15, 2009

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

by Martin Hinner

Dan, On Sat, Feb 14, 2009 at 7:44 AM, Dan Kegel <dank(a)kegel.com> wrote: > 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. I think wine needs some universal library so as there is not 20 other ISV-specific solutions... If wine-team decides not to include this (or similar .dll) in the Wine package, we'll just redistribute it with the application, but I think there is need for such library. > I don't think this really brings up any security considerations > but it is a reminder that Windows programs under Wine > have access to the entire Linux system just like Linux > programs do. > > btw nice name, but it pulls up 7 million hits for me, > not sure what you mean by "google doesn't reveal > any other uses of the name". :-))) I was searching for "winegate.dll", not just plain winegate. I meant that there will likely be no collision with other .DLL. Now it finds my post + some garbage. Google is damn fast. Martin

Feb. 15, 2009

Closing fixed bugs

by Dan Kegel

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. For this to work, we have to let Alexandre be the only person to close fixed bugs. (Of course, it's ok for other people to mark bugs fixed, and it's ok for anyone to close invalid or dup bugs.) If anybody else closes a fixed bug, it won't show up in the list of fixed bugs for any release. A corner case is when a bug is marked fixed sometime after release. I think it's ok to leave it for Alexandre to close; that way it shows up in at least one release announcement. Even if it shows up a few releases late, that's better than not showing up at all. Sound reasonable? I ask because Vitaliy closed http://bugs.winehq.org/show_bug.cgi?id=10923 even after I tried to explain this to him, so I figured it needed a wider discussion. - Dan

Feb. 15, 2009

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

by Martin Hinner

On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote: > 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. I am aware of this, it was proof-of-concept, I am definitely NOT against using wine_dlopen or add #ifdefs to make it portable (for systems not having dlfcn.h). > - 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 ? find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not reveal anything except winegate.dll :-). Martin

Feb. 15, 2009

Re: [Bug 17104] Drives in winecfg can not be set correctly for paths containing non-latin (probably multibyte) characters. [utf-8]

by Austin English

On Sat, Feb 14, 2009 at 5:59 PM, <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=17104 > > > Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > > > --- Comment #10 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-02-14 17:59:35 --- > Confirming fixed. > > Closing bug fixed in wine-1.1.15. > > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > Do not reply to this email, post in Bugzilla using the > above URL to reply. > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > Perhaps we should wait for bugs to be closed by AJ in the next release, even if they were fixed in a previous release? That way, they should up in the release notes. Dan brought it up on another bug, and I agree...but figured it should be brought up here. Thoughts? -- -Austin

Feb. 15, 2009