wine-devel January 2012

wine-devel@winehq.org

83 participants
193 discussions

Best way to overlay a filesystem for a Wine app?
by Scott Ritchie 30 Jan '12

30 Jan '12

Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store. Ubuntu requires these commercial packages: 1) Install into a unique namespace in /opt (icons/.desktop excepted) 2) Store their user configuration in ~/.packagename or ~/.config/packagename I have already packaged a super-simple Wine application this way. This was a single binary file that could be run from anywhere - all I had to do was copy it into its own /opt folder and make a .desktop file that declared a unique WINEPREFIX for it. More complicated Windows applications, however, won't be doable with this basic approach. Specifically, Windows applications might: 1) Be distributed as installer files 2) Have self-updating mechanisms 3) Expect their own folder to be user-writable One ugly not-quite-solution would be to just have the package put the installer in opt, provide a link to it, and expect the user to install like he would a downloaded application (and then use a different .desktop file to actually run the program). Slightly better is to just copy an entire /opt prefix template into user space on first run, and then let it go on its own way after that. An app which didn't self-update, however, would then be unable to benefit from an updated version of the system package. A more complete solution would have a prefix in the user space, but files inside it would actually be those residing in /opt. A system of symlinks might work, but if a package update introduced new files those would not be available without complicated scripting to add the links. 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. Or have I missed something? Thanks, Scott Ritchie

4 5

winecoreaudio.drv: Improve underrun handling
by Joerg-Cyril.Hoehle＠t-systems.com 30 Jan '12

30 Jan '12

Andrew, The good news is that your underrun patch prevents mmdevapi from writing less and less frames in mmdevapi/tests/render:test_worst_case http://test.winehq.org/data/f0cfa7cf46d7c832fb84555529d1a1b7c49c46c0/mac_jc… >render.c:1631: Released 86436=98x882 -0 frames at 44100 worth 1960ms in 2035ms >render.c:1631: Released 71442=81x882 -0 frames at 44100 worth 1620ms in 2037ms >render.c:1631: Released 56448=64x882 -0 frames at 44100 worth 1280ms in 2039ms That is abnormal behavior. + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, + This->public_buffer, 0, NULL, 0, 0, 0, NULL, &req_time, &start_time); I advise against setting req_time. This can only fragilize the system. What if req_time is miscomputed or there's a delay? NULL=ASAP is exactly what we want. We don't want ALSA/dmix behavior, where it'll silently skip over late frames in order to catch up (dunno if MacOSX does this but in my eyes that doesn't matter). If you need to memorize a time, I believe it's best stored in our AQBuffer struct. >if(list_count(...) == 0) I once wrote a patch to turn such a pattern into if(list_empty(...)) Regards, Jörg

2 3

Re: winealsa: snd_card_get_name uses strdup (Valgrind). (2nd)
by Alexandre Julliard 30 Jan '12

30 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Perhaps that way, the relationship is obvious. > > Please choose whether to apply the original patch #82900 or this one. > It used instead "if(!err)" i.e. the 0 return code that ALSA documents. The previous one was better, but you need to get rid of that cast. -- Alexandre Julliard julliard(a)winehq.org

1 0

mmdevapi: Correctly convert UINT32 to INT64
by Joerg-Cyril.Hoehle＠t-systems.com 30 Jan '12

30 Jan '12

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

3 3

comctl32: fix MSVC build in imagelist.c
by carlo.bramix＠libero.it 30 Jan '12

30 Jan '12

If I can say my opinion, I disagree on the usage of HeapAlloc/HeapFree for that known amount of memory. Instead, for granting compatibility with MSVC, I would continue to use a structure in stack memory by simply using _alloca() and something like this: LPBITMAPINFO bmi = (LPBITMAPINFO) _alloca(FIELD_OFFSET(BITMAPINFO, bmiColors[256])); or this: LPBITMAPINFO bmi = (LPBITMAPINFO) _alloca(sizeof(BITMAPINFO)+sizeof(RGBQUAD)*256); and leaving all other lines of code unchanged. Sincerely, Carlo Bramini. > Thomas Faber <thfabba at gmx.de> writes: > >> This removes the use of a Variable-Length Array in ImageList_CreateImage >> and replaces it with HeapAlloc/HeapFree, as it is done in several >> other functions in this file. >> Alas, FIELD_OFFSET is "not const enough" for ANSI C. > >Using sizeof instead would be preferable. > >-- >Alexandre Julliard >julliard at winehq.org >

1 0

Rules for code freeze
by Alexandre Julliard 30 Jan '12

30 Jan '12

Folks, We are now in code freeze, so all patches that are not obviously harmless need to have a justification as to why the patch should be applied. In most cases, that simply means pointing to the corresponding bug that is fixed by the patch. Patches that seem risky will be marked pending or deferred. If you still think they should go in, you should convince me that they fix something important that is worth the risk. Patches that only change the tests can't break apps so they will be accepted freely, at least until we get closer to release. Patches that require translation updates will only be accepted for the next two weeks, to give translators time to catch up afterwards. I'm planning to make rc releases every week until we run out of bugs. The release schedule may be a bit more random than usual because of travel constraints (not to mention skiing constraints ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: fix MSVC build in imagelist.c
by Alexandre Julliard 30 Jan '12

30 Jan '12

Thomas Faber <thfabba(a)gmx.de> writes: > This removes the use of a Variable-Length Array in ImageList_CreateImage > and replaces it with HeapAlloc/HeapFree, as it is done in several > other functions in this file. > Alas, FIELD_OFFSET is "not const enough" for ANSI C. Using sizeof instead would be preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] include: Handle rmxftmpl.x when needed by d3dx9 without the need to make all includes. (try 2)
by Rico Schüller 30 Jan '12

30 Jan '12

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(-) > > > > >

1 0

Re: kernel32: add a stub for LCMapStringEx (try 2)
by Dmitry Timoshkov 30 Jan '12

30 Jan '12

Austin English <austinenglish(a)gmail.com> wrote: > Forgot the include changes. Forwarding it to LCMapString would be much better. -- Dmitry.

3 2

Re: [PATCH 4/5] ddraw/tests: Port the depth blit test to ddraw2
by Henri Verbeet 30 Jan '12

30 Jan '12

On 22 January 2012 16:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* FIXME: This is wrong, d3d2 does not have D3DRENDERSTATE_LIGHTING. D3DLVERTEX should > + * disable lighting. This needs more tests and fixes after Wine 1.4 */ > + hr = IDirect3DDevice2_SetRenderState(device, D3DRENDERSTATE_LIGHTING, FALSE); 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.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2012