September 2008 - Wine-Devel

Bad patch, what's the procedure?

by Kjell Rune Skaaraas

Hello,I've submitted a patch to wine-patches for IWineD3DResourceImpl_GetPriority/SetPriority that's incorrect (it makes changes to exception.c which shouldn't be there, they were just part of me trying to debug something). Is there anything like a cancel procedure I should do, or should I just fix up the patch and submit it again? Oh yeah and this will teach me to read the diff more thoroughly next time...Regards,Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

Sept. 30, 2008

re: Detecting Wine

by Dan Kegel

Mark W. wrote: >As part of the installation process, under Windows our >program does a full-disk search of all local hard drives, >but ignoring network drives and removable media. >Under Wine, this doesn't work too well, as there's not >a one-to-one mapping between disks and drive letters, >and there's usually at least one way to access the entire *nix >filesystem. If someone's got a few network drives mounted, >the installer could spend hours searching them. We have a similar issue in Picasa. There, we try to default to just searching the user's home directory when running on Wine, and I think we blacklist known do-not-search directories like /proc. We have gone back and forth about whether to follow symlinks; there are often symlinks to network filesystems inside people's home directories. The right thing to do is probably something like: a) get the set of initial seeds by using the output of the 'mount' command and ignoring anything with a type field that is not a known local filesystem type (e.g. ext2, ext3, ufs, reiserfs, xfs); you'll need to expand this whitelist as customers complain about their pet filesystems (And you'll need to ignore any that can't be mapped to Wine paths, but people usually map Z: to /.) (You could use /proc/mounts under Linux, but better to use the standardized 'mount' command or maybe /etc/mtab, otherwise your code will break on MacOSX or Solaris.) b) when recursing, and you find a reparse point aka symlink, check the filesystem type of the symlink destination before following it. You might need to get bug http://bugs.winehq.org/show_bug.cgi?id=12401 fixed before this works the windows way, but you could probably do something wine-specific now by converting each directory path you encounter into a unix path, then using a unix api to check whether it's a symbolic link. Bleah. Best way to do that is to patch wine, and then you're part way to fixing bug 12401 :-) c) beware: Wine's implementation of FindFirstChange/FindNextChange does not really work if you ask it to monitor two different names for the same directory. See http://bugs.winehq.org/show_bug.cgi?id=7216 - Dan

Sept. 30, 2008

Re: Detecting Wine

by Markus Hitter

Am 30.09.2008 um 12:55 schrieb Eric Pouech: > Your design is wrong IMO. You don't handle reparse points at all; > you only > rely on the nature of a drive, which isn't sufficient in most > cases. See > mounting volumes for example where you can mount a whole volume > anywhere in > an NTFS partition. > > The correct fix would be to: > - ensure your code handles those cases correctly (which it doesn't) > - ensure that wine returns the correct relevant information for remote > mounted FS (which I'm pretty sure sure it's not done today) A reasonable 99% shortcut would probably be to parse C: only. This should be sufficient for almost all users, especially the clueless ones, on Wine as well as on Windows. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Sept. 30, 2008

Re: Detecting Wine

by Eric Pouech

Your design is wrong IMO. You don't handle reparse points at all; you only rely on the nature of a drive, which isn't sufficient in most cases. See mounting volumes for example where you can mount a whole volume anywhere in an NTFS partition. The correct fix would be to: - ensure your code handles those cases correctly (which it doesn't) - ensure that wine returns the correct relevant information for remote mounted FS (which I'm pretty sure sure it's not done today) A+ 2008/9/30 Mark Wagner <carnildo(a)gmail.com> > > On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote: > >> Did you read the second paragraph of my original email? I'm not > >> working around a bug in Wine, unless it's a bug that a user can map > >> "/" to "C:" and call it a "fixed disk". > > > > Yes, I read it. And scanning "/" shouldn't be a problem, unless > > you've also mapped network drives there. That seems to be the root of > > the problem. > > Yes, that's the root of the problem. I can't prevent the end-user > from mounting network drives -- in fact, in the expected installation > environment, the average user will have several very large network > drives mounted. > > Under Windows, installation takes about five minutes, and the > full-disk search provides a nicer user experience if they're upgrading > from an ancient copy of the software. Under Wine, I need to either > skip the full-disk search, or warn the user that it may take several > hours. > > -- > Mark > > > > > -- -- Eric Pouech

Sept. 30, 2008

Re: wined3d: Convert between A8R8G8B8 and X8R8G8B8

by Kjell Rune Skaaraas

Henri Verbeet wrote: >2008/9/29 Kjell Rune Skaaraas <kjella79 at yahoo.no>: >> Hello, >> >> A simple patch which adds converting between A8R8G8B8 and X8R8G8B8 that >> gives me one less warning to deal with while trying to make a game function. >> It zeroes out the alpha channel to be on the safe side, though it should >> never be used in the destination format anyway. >> >What does this fix, in practice? A D3D surface is being converted from A8R8G8B8 to X8R8G8B8 and wine warns that there is no conversion function, so I added it. In practise it doesn't matter because the RGB parts are still valid, so nothing should change unless any app uses the X8 bits = unused. Just fixed a warning and was the right skill level for my first wine patch. I'm working on one that does a little more real work now. Regards, Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

Sept. 30, 2008

Re: OpenGL child windows

by Florian Köberle

Hello Chris Robinson, A long time ago you wrote in http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html that you got my example program running: "If I force offscreen rendering and add the flag, the demo works." Could you have a look at the following bug report and may explain how to "force offscreen rendering"? http://bugs.winehq.org/show_bug.cgi?id=15232 Best regards, Florian Köberle

Sept. 30, 2008

Re: Detecting Wine

by Steven Edwards

On Mon, Sep 29, 2008 at 5:58 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Not acceptable practice. See e.g. the old faq entry: > http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE I don't understand why this should still be the case. We have a stable Wine now and Alexadre exported this symbol for some good reason. I understand detecting Wine and having your application depend on certain behaviors would be wrong with unstable versions but in a post 1.0 would this seems acceptable. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Sept. 30, 2008

Re: OT [ReactOS-related] Win32s API dosumentation

by Wesley Parish

Thanks. I'll get onto it right away. Wesley Parish Quoting Owen Rudge <owen(a)owenrudge.net>: > > Does anyone know where to get copies of the Win32s documentation, such > as > > it > > is? > > I don't know where to find a copy as such (perhaps tucked away in the > old > Microsoft FTP server, or linked to from a KB article?), but I do have a > > couple of versions here, shipped with various old compilers. Probably > the > more detailed file I have is came with the Win32 SDK shipped with Watcom > > C/C++ 10.6. You may be able to find a copy of it on eBay, I guess. > Another > version came with Borland C++ 4.51, in a self-contained .hlp file, > although > this only seems to apply to Win32s 1.1 (the help file is dated > 1992-1993). > According to http://wrc.gro.clinux.org/johnfindlay/lcc-win32/links.htm, > > Borland used to have a copy of those help files on its FTP server. They > no > longer seem to be there, but I've taken the liberty of uploading the old > 1.1 > programmer's guide to http://www.owenrudge.net/various/win32s.hlp. Note > that > Win32s 1.1 didn't support things like OLE 2.0, MAPI, ODBC, etc (which > later > versions of Win32s did, I believe), so getting the latest documentation > > would probably be best. > > Hope this helps, > > -- > Owen Rudge > http://www.owenrudge.net/ > > > "Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge "I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press

Sept. 30, 2008

Re: Detecting Wine

by Mark Wagner

On Mon, Sep 29, 2008 at 15:15, Guillaume VanderEst <me(a)gn0.me> wrote: > Based on the current information, wouldn't it be smartest to ask the users > which drive(s) they would like included in the search, or is it actually > required that all disks be scanned? The average non-Wine user of this software has only a vague idea of what's going on inside the box on their desk. Asking the user what disks should be scanned will get blank stares and wrong answers 99% of the time. -- Mark Wagner

Sept. 29, 2008

Re: Detecting Wine

by Guillaume VanderEst

Based on the current information, wouldn't it be smartest to ask the users which drive(s) they would like included in the search, or is it actually required that all disks be scanned? On Mon, Sep 29, 2008 at 3:06 PM, Mark Wagner <carnildo(a)gmail.com> wrote: > On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote: > >> Did you read the second paragraph of my original email? I'm not > >> working around a bug in Wine, unless it's a bug that a user can map > >> "/" to "C:" and call it a "fixed disk". > > > > Yes, I read it. And scanning "/" shouldn't be a problem, unless > > you've also mapped network drives there. That seems to be the root of > > the problem. > > Yes, that's the root of the problem. I can't prevent the end-user > from mounting network drives -- in fact, in the expected installation > environment, the average user will have several very large network > drives mounted. > > Under Windows, installation takes about five minutes, and the > full-disk search provides a nicer user experience if they're upgrading > from an ancient copy of the software. Under Wine, I need to either > skip the full-disk search, or warn the user that it may take several > hours. > > -- > Mark > > >

Sept. 29, 2008