January 2012 - Wine-Devel - list.winehq.org

Re: Best way to overlay a filesystem for a Wine app?

by Francois Gouget

On Fri, 27 Jan 2012, Scott Ritchie wrote: [...] > To me, this sounds an awful lot like an overlay file system. Would > unionfs-fuse be the correct solution here? The .desktop file that sets > the Wine prefix and also launches the app could mount the FUSE > filesystem, and the user-space Wine prefix's files could take priority > over those in /opt. Stuff like user-modding and update/repair systems > could work properly in that context as well. The main issue with copy-on-write overlay filesystems is that they cannot deal with registry files for two reasons: * First, once a file has been written to and thus copied to the user's wineprefix, it will never be updated when you upgrade the application's package. This means after an upgrade the user's system.reg and user.reg files (the latter containing the dll overrides) will be unchanged which may cause the application to be broken. * The second issue is that the registry really contains both application data and user data. The former should be upgraded while the latter should be preserved. So neither a copying the new registry files nor preserving the old registry files policies are appropriate (and these policies are the only two available to overlay filesystems). Besides that there are other issues, most of which Dan already mentioned: * As far as I know most overlay filesystems don't deal well with changes in the underlying filesystem. This pretty much breaks the upgrade scenario. * They are not available on all Linux distributions (not to talk about Mac OS X or FreeBSD). But I guess this is fine for a latest-Ubuntu-only approach (like for menus and the trash!). Another issue is applications that require a license key to be entered during installation. This causes trouble for both the overlay and symlink approaches since both have the packager install the application and then ship the installed image... along with its single license key. So for these applications a way to enter the license key on first run has to be found. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Jan. 30, 2012

Re: mmdevapi: Correctly convert UINT32 to INT64

by Michael Stefaniuc

Hello Joerg, On 01/30/2012 09:46 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > thank you very much for finding a bug in my code. > > I'll have to meditate signed/unsigned conversions for the next months. > > Perhaps it's my lack of familiarity with the MS-Windows API that had > me not find a signed equivalent of UINT32. Indeed there's none in > windef.h. So I choose 'long'. But now I see basestd.h defines LONG32. LONG32 is kinda redundant. LONG is 32bit on all Windows versions on 16bit, 32bit and 64bit Windows. > INT64 is not appropriate. getbuf_last should be of the same size than > the other frame holding types. I once wrote a patch to turn all > #frame holding entities from UINT64 into 32. Please rewrite the patch > to use the LONG32 type, then you'll need no surprising cast. > > If the loss of 1 bit worries you, the solution IMHO is not to go to > INT64 rather than prevent a duration that large in Initialize. In > shared mode, there's no 2s limit. My tests opened a 10s buffer. I've > not tested anything larger. > LONG32 leaves enough room for 10000 seconds at 200000fps. bye michael

Jan. 30, 2012

mmdevapi: Correctly convert UINT32 to INT64

by Joerg-Cyril.Hoehle＠t-systems.com

Andrew, thank you very much for finding a bug in my code. I'll have to meditate signed/unsigned conversions for the next months. Perhaps it's my lack of familiarity with the MS-Windows API that had me not find a signed equivalent of UINT32. Indeed there's none in windef.h. So I choose 'long'. But now I see basestd.h defines LONG32. INT64 is not appropriate. getbuf_last should be of the same size than the other frame holding types. I once wrote a patch to turn all #frame holding entities from UINT64 into 32. Please rewrite the patch to use the LONG32 type, then you'll need no surprising cast. If the loss of 1 bit worries you, the solution IMHO is not to go to INT64 rather than prevent a duration that large in Initialize. In shared mode, there's no 2s limit. My tests opened a 10s buffer. I've not tested anything larger. LONG32 leaves enough room for 10000 seconds at 200000fps. Regards, Jörg Höhle

Jan. 30, 2012

Re: [PATCH] include: Handle rmxftmpl.x when needed by d3dx9 without the need to make all includes. (try 2)

by Rico Schüller

Please ignore this patch, it seems to break make crosstest. Cheers Rico Am 30.01.2012 09:00, schrieb Rico Schüller: > Hi, > > this is try 2 for fixing the build for d3dx9_36 without requiring to > make all includes. > > Improvements: > - don't use a generic rule, use a file specific one > > Cheers > Rico > > --- > Make.rules.in | 3 +++ > include/Makefile.in | 3 --- > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > >

Jan. 30, 2012

Re: kernel32: add a stub for LCMapStringEx (try 2)

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > On 01/29/2012 10:54 AM, Dmitry Timoshkov wrote: >> Austin English<austinenglish(a)gmail.com> wrote: >> >>> Forgot the include changes. >> >> Forwarding it to LCMapString would be much better. >> > > Also could we please stop adding stubs before the release? It seems > every new stub dll opens up another can of worms (or should I say > bugs). If we looking to stabilize Wine it's sure is the wrong way to > do it. New stub dlls are of course not accepted during code freeze. New functions may be accepted but they need a convincing argument, for instance if the stub is the only thing that prevents an app from working well. If it just makes the app stumble along a little further before dying it will have to wait. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2012

Re: [PATCH 4/5] ddraw/tests: Port the depth blit test to ddraw2

by Stefan Dösinger

Am Montag, 23. Januar 2012, 13:48:03 schrieb Henri Verbeet: > It probably makes sense to just skip this call and add a todo_wine for > the failing tests. Also, if all that's needed for this is setting > WINED3D_RS_LIGHTING in IDirect3DDeviceImpl_2_DrawPrimitive(), I think > that should be ok to go in before 1.4. I've sent the patch with todo_wine for now. A proper fix might be as simple as a SetRenderState call in the device2::draw* thunks, but I don't feel comfortable about it without some tests. I'm not sure if I'll have the time for that. Someone(Octavian? I lost the IRC logs) was working on a lot of tests for this. Maybe he wants to resume his work.

Jan. 30, 2012

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 2)

by Dmitry Timoshkov

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > Fixes bug 26924. Please add the tests. -- Dmitry.

Jan. 30, 2012

Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > +/* Locale name special values */ > +#define LOCALE_NAME_INVARIANT L"" > +#define LOCALE_NAME_MAX_LENGTH 85 > +#define LOCALE_NAME_SYSTEM_DEFAULT L"!sys-default-locale" > +#define LOCALE_NAME_USER_DEFAULT NULL Have a look how unicode constants are defined in other header files, the above version can't work in Wine. Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data. -- Dmitry.

Jan. 30, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Dan Kegel

On Sun, Jan 29, 2012 at 3:58 PM, Scott Ritchie <scott(a)open-vote.org> wrote: >> - rely on the system's update manager to pull updated versions of the >> package from the repository > > This may not be a fast-enough option for some apps, such as online games > that need to keep everyone in version sync. Even in an ideal case where > the company was 100% behind the Ubuntu package and kept it in sync with > their release process, there is still no current way for the Windows app > to tell Apt to update its package. In those cases, you would make the files updated by the game's launcher be read/write instead of read only symlinks. > wouldn't a > unionfs-fuse overlay be simpler and cleaner than this since you wouldn't > have to worry about the app-specific stuff at all? Yes. My experiences were in the context of making a single portable (in the old sense of the word) binary to run on all sorts of distros, even old ones with no union filesystem support at all, so we had to use symlinks. And my impression is that filesystem unions aren't quite ready for prime time. LWN has had a lot of articles about that (most recently last June? http://lwn.net/Articles/447650/ ) But perhaps you are only targeting the most recent Ubuntu, and have found that it includes a usable union mount of some sort. When I try to script things that use fuse filesystems, I seem to need to add mystery "sleep 1" statements after issuing mount commands, which isn't exactly trust-inspiring. But maybe some other part of the system I was using was causing the delay. >> (Picasa also went further and bundled a snapshot of wine, too, and >> modified the app slightly to display unix paths, which required adding >> one little extension to wine. I'm sure the wine patch is around if >> someone wants it. > > This patch would be interesting if you could dig it up. I don't see it standalone anywhere, but the source tarball used is linked to from http://code.google.com/opensource/wine.html, and the extension was probably kernel32.wine_get_unix_real_name(). > I don't know if > Alexandre would accept it, but ideally it would be part of Wine and > turned on via an environment variable or command line switch. I doubt he would accept it. (Heck, he probably wrote it.) - Dan

Jan. 30, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Scott Ritchie

On 01/29/2012 02:38 PM, Dan Kegel wrote: > Hi Scott, > I agree with what Vrit said. > > Here's what I recall learning from helping package Picasa: > - don't package the installer Right, run the installer and use the contents of the result as the packaged files. > - rely on the system's update manager to pull updated versions of the > package from the repository This may not be a fast-enough option for some apps, such as online games that need to keep everyone in version sync. Even in an ideal case where the company was 100% behind the Ubuntu package and kept it in sync with their release process, there is still no current way for the Windows app to tell Apt to update its package. > - install everything read-only into /opt/companyname/appname > - start the app using a shell script that creates a wineprefix on 1st run > - The wineprefix should have real directories (so the app can create > files in Program Files, ugh), should symlink to all the readonly files > in /opt, and have real copies of any files that can't be read-only > As Vrit said, the script that creates the wineprefix is very > app-specific, but once you write one, it's probably easy to write the > next one. Perhaps I'm speaking from inexperience with either, but wouldn't a unionfs-fuse overlay be simpler and cleaner than this since you wouldn't have to worry about the app-specific stuff at all? > - If you are running your own repo, you should put exactly one app per > repo. Otherwise you run into trouble because Canonical would want to > review all the apps in the repo every time you update any one of them. > This is already how apps work in the App Store - commercial apps get their own repos, if they require payment then it's a private launchpad PPA, and the user gets a unique access key when they buy it. > So no overlay filesystem needed, symlinks should usually suffice. > > (Picasa also went further and bundled a snapshot of wine, too, and > modified the app slightly to display unix paths, which required adding > one little extension to wine. I'm sure the wine patch is around if > someone wants it. And since it was in a non-ubuntu repo, it had to do > a strange song and dance to avoid autoupdates being disabled when the > user upgraded to a new version of ubuntu. This was considered safe > because picasa was fairly well self-contained and maintained, and was > unlikely to break on system updates.) This patch would be interesting if you could dig it up. I don't know if Alexandre would accept it, but ideally it would be part of Wine and turned on via an environment variable or command line switch. > > In case you want to look at picasa's scripts, the download page seems > to be gone, but the repo seems to still be there: > > http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i3… > http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_am… > 4ecf30186ce76430a7791cee2608f47e07b015e6 picasa_3.0-current_amd64.deb > fe8e83b29a10b5d663e87861d85512faea036c06 picasa_3.0-current_i386.deb > > Still installs and runs ok on 11.10. Thanks! Thanks, Scott Ritchie

Jan. 29, 2012