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

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

by Roderick Colenbrander

> I don't want to be rude, but I have better things to do than > propagandize my solution. We can live without such library in Wine, it > would just require us to maintain separate libraries for different > libc or wine versions. Having it in wine distribution would solve this > problem smoothly, reducing our task only to maintain native Linux > shared lib for hardware access. If anything changes in your position, > let me know, I am willing to help with it. > > Martin > So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. Perhaps that should be done on the Wine wiki (not sure if we can upload files to there). I can imagine that we should put a porting page there and mention winelib and winegate. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Feb. 15, 2009

Re: Proposal: put Winetricks into Wine menu

by Scott Ritchie

Dan Kegel wrote: > 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. > Not too much. Others have been kind enough to write command line applications as front-ends to uninstallation already. >> 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? > Actually that's not a bad point. That would require some hacking though (though perhaps not too much, since winetricks is also command line driven). > 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. > Agreed. Thanks, Scott Ritchie

Feb. 15, 2009

Re: 1.1.15 failing to build -- what changed?

by Scott Ritchie

Roderick Colenbrander wrote: >> 1.1.15 fails to build using an identical layout to 1.1.14, which means >> something has changed with either the build dependencies or the way >> configure is working. >> >> Here's the build failure I'm getting on amd64, but it fails on all >> arches: >> http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_… >> >> I'm going to sleep now, but hopefully I'll figure this out Valentine's >> day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages >> just yet. >> >> Thanks, >> Scott Ritchie >> > > 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'. > > Personally I consider it a misconfigured build system. It can be fixed by installing the proper binutils package for this architecture which I'm sure debian has. The same should be done for your ubuntu packages. You can't expect apps to build if you only have one half of the build apps (the compiler). > > Roderick I've tried manually build-depending on the binutils and binutils-multiarch packages, however neither fix the build failure. I'm not quite sure what I'm looking for here. Thanks, Scott Ritchie

Feb. 15, 2009

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

by Dan Kegel

On Sat, Feb 14, 2009 at 10:09 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Dan Kegel wrote: >> 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 > > That's clearly invalid and not what wine.desktop contains. I'd call it a > downstream bug which needs to be fixed in ubuntu. Oddly, though, it works for me in the one app I tried it on. Do you know of an app that will make the bug obvious, offhand? Thanks, Dan

Feb. 15, 2009

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

by Vitaliy Margolen

Martin Hinner wrote: > reducing our task only to maintain native Linux > shared lib for hardware access. Which means you'll have to maintain it anyway. No, what you proposed not going to fly. It can not work within Wine. It's called "hack" and things with that name not getting into Wine. Vitaliy

Feb. 15, 2009

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

by Vitaliy Margolen

Dan Kegel wrote: > 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 > ... That's clearly invalid and not what wine.desktop contains. I'd call it a downstream bug which needs to be fixed in ubuntu. Vitaliy.

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 Dmitry Timoshkov

"Austin English" <austinenglish(a)gmail.com> wrote: > 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? I think Dan is right, there is no any hurry to close the bugs right away, but it's very helpful for users to see the bug reported as fixed in Wine announce, otherwise there is no point in providing the list of fixed bugs at all. -- Dmitry.

Feb. 15, 2009

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

by Ben Klein

2009/2/15 Dan Kegel <dank(a)kegel.com>: > 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... >From what I understand, they're not accessible to full win32 apps. 2009/2/15 Martin Hinner <martin(a)hinner.info>: > I understand this and in my opinion (if there will be any "official" > WINEGATE.DLL) I can't speak for the people who make these decisions in the Wine project, but I don't believe winegate is or will ever be a candidate for inclusion in Wine. If there's a good reason, it's thos: > Yes, the WINEGATE.DLL is not solving any problem on its own, it just > simplifies "porting" process. If it doesn't solve a problem, it doesn't make it much easier. In any case, that's what winelib does too, you know, make porting easier. And from what I understand, you can just as easily use a winelib wrapper around a win32 application. > I don't want to be rude, but I have better things to do than > propagandize my solution. We can live without such library in Wine, it > would just require us to maintain separate libraries for different > libc or wine versions. If you foresee that you will have to maintain different versions of your library for different libc or Wine versions, you have big design flaws. It should "just work" without requiring maintenance. The Linux component may require a recompile on occasion to keep up with a change in libc (more likely frequent recompiling/code maintenance due to changes in the kernel every time you upgrade).

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>: > > --- 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 . scguy318 just brought this to my attention on IRC: http://bugs.winehq.org/show_bug.cgi?id=17340

Feb. 15, 2009

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

by Martin Hinner

VItaliy, On Sun, Feb 15, 2009 at 3:21 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > 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. I understand this. For ourselves, it is intended to gain access to native Linux drivers. It would be nightmare to try to create wine dll that would act as a wrapper between "virgin" Win32 app and Linux driver. > 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. I understand this and in my opinion (if there will be any "official" WINEGATE.DLL) there should be documentation mentioning things like this one. In addition there should be also functions to convert file handles between posix & wine handles + path conversion tool (but we do not need any of these, I mean they migh be useful to someone else). > 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. Yes, the WINEGATE.DLL is not solving any problem on its own, it just simplifies "porting" process. Using it is NOT as complex as writing winelib application, because you have to write only Linux-dependent parts, the rest of application can remain untouched. Please note that to my knowledge it is not even legal to create winelib application if it is using some libraries such as MFC (depends on version, license, etc.). I think I have clearly explained in my previous posts what this library should do and what would advantages of having it be. Now I would like to hear if you (wine people) accept such solution and include it in some way in Wine distribution. Currently I understand there is no interest. I don't want to be rude, but I have better things to do than propagandize my solution. We can live without such library in Wine, it would just require us to maintain separate libraries for different libc or wine versions. Having it in wine distribution would solve this problem smoothly, reducing our task only to maintain native Linux shared lib for hardware access. If anything changes in your position, let me know, I am willing to help with it. Martin

Feb. 15, 2009