March 2013 - Wine-devel - list.winehq.org

Re: [3/3] Make mac driver the default on OS X
by Ken Thomases 06 Mar '13

06 Mar '13

On Mar 5, 2013, at 6:32 PM, Josh DuBois wrote: > diff --git a/dlls/winemac.drv/macdrv_main.c b/dlls/winemac.drv/macdrv_main.c > index cd1cc0c..1f16694 100644 > --- a/dlls/winemac.drv/macdrv_main.c > +++ b/dlls/winemac.drv/macdrv_main.c > @@ -85,7 +85,7 @@ static BOOL process_attach(void) > macdrv_err_on = ERR_ON(macdrv); > if (macdrv_start_cocoa_app(GetTickCount64())) > { > - ERR("Failed to start Cocoa app main loop\n"); > + TRACE("Failed to start Cocoa app main loop\n"); > return FALSE; > } > I would think that this should still be at least a WARN, although I'm not sure why it's being demoted from ERR in the first place. (In fact, I should probably have added a WARN in my patch for refusing to run in non-GUI sessions.) -Ken

1 0

Re: msxml3: Implement IXMLParser Get/Set Factory
by Nikolay Sivov 05 Mar '13

05 Mar '13

On 3/6/2013 09:11, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Implement IXMLParser Get/Set Factory You also need to release factory reference on parser release it seems. > > > Best Regards > Alistair Leslie-Hughes > >

1 0

Re: comctl32/imagelist: use proper color format for merged image lists (try 2)
by Alexandre Julliard 05 Mar '13

05 Mar '13

Daniel Jelinski <djelinski1(a)gmail.com> writes: > +static void test_merge_colors(void) > +{ > + HIMAGELIST himl[5], hmerge; > + int sizes[] = { ILC_COLOR4, ILC_COLOR8, ILC_COLOR16, ILC_COLOR24, ILC_COLOR32 }; You should also test COLORDDB, and probably the mask behavior too. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 2)
by Michael Stefaniuc 05 Mar '13

05 Mar '13

Hello Joerg, On 03/01/2013 10:22 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > The idea to replace X * numerator / denominator > by X / den * mul + remainder from euclidian division > came from > http://blog.airsource.co.uk/index.php/2010/03/15/quelle-heure-est-il/ > > M. Stefaniuc suggested an inline function. The MulDiv64 inline has the benefit > of ensuring unsigned arithmetic, matching GetPosition UINT64 output. My idea was to have the whole if else in an inline function. But I see that even the whole functionality can move to a helper. Something like this: static inline ULONGLONG get_qpctime(void) { LARGE_INTEGER stamp, freq; QueryPerformanceCounter(&stamp); QueryPerformanceFrequency(&freq); if(freq.QuadPart == 10000000) return stamp.QuadPart; else return stamp.QuadPart / freq.QuadPart * 10000000 + stamp.QuadPart % freq.QuadPart * 10000000 / freq.QuadPart; } bye michael

2 2

Re: [PATCH 2/2] winmm: MCI_BREAK_HWND handling now matches Wine's 1999 MCI_DefYieldProc.
by Alexandre Julliard 05 Mar '13

05 Mar '13

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > @@ -2063,9 +2063,10 @@ static DWORD MCI_Break(UINT wDevID, DWORD dwFlags, LPMCI_BREAK_PARMS lpParms) > switch (dwFlags & (MCI_BREAK_KEY | MCI_BREAK_OFF)) { > case MCI_BREAK_KEY: > wmd->lpfnYieldProc = MCI_DefYieldProc; > - wmd->dwYieldData = lpParms->nVirtKey; > - if (dwFlags & MCI_BREAK_HWND) > - FIXME("(%x) vkey %02X on window %p\n", dwFlags, lpParms->nVirtKey, lpParms->hwndBreak); > + /* Our MCI_DefYieldProc from 1999-04-11 expects this DWORD splitting, > + * yet tests on w2k-w7 prove wmd->dwYieldData = lpParms->nVirtKey; */ It doesn't make sense to add workarounds for Wine code, it should be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server/advapi32: Report administrator ownership by default for registry objects (try 5).
by Alexandre Julliard 05 Mar '13

05 Mar '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > +static struct security_descriptor *key_get_sd( struct object *obj ) > +{ > + struct security_descriptor *sd = default_get_sd( obj ); > + const SID *admins_sid = security_builtin_admins_sid; > + int admin_len; > + char *ptr; > + > + if (sd) return sd; > + admin_len = FIELD_OFFSET(SID, SubAuthority[admins_sid->SubAuthorityCount]); > + sd = mem_alloc( sizeof(struct security_descriptor) + 2*admin_len ); > + if (!sd) return sd; > + > + sd->control = 0; > + sd->owner_len = admin_len; > + sd->group_len = admin_len; > + sd->sacl_len = 0; > + sd->dacl_len = 0; > + > + ptr = (char *)(sd + 1); > + memcpy( ptr, security_builtin_admins_sid, sd->owner_len ); > + ptr += sd->owner_len; > + memcpy( ptr, security_builtin_admins_sid, sd->group_len ); > + ptr += sd->group_len; > + > + free( obj->sd ); > + obj->sd = sd; > + return sd; > +} It shouldn't be necessary to allocate one for every key. -- Alexandre Julliard julliard(a)winehq.org

1 0

Making wine default to the Mac Driver on OS X
by Josh DuBois 05 Mar '13

05 Mar '13

With Friday's release, I am interested in making the Mac Driver wine's default on OS X. My own immediate motivation is largely so we at CodeWeavers can start testing it as a default internally (which obviously we can do on our own, regardless, if needed), but I figured I'd ask the wider community to see whether it's time in winehq also. My question is how it should be configured from a user perspective. Right now one can set a registry key in HKCU/Software/Wine/Drivers/Graphics with a comma-separated list specifying the driver load order, and the first one successfully loaded will be used. Absent the key, there is a hardcoded load order in user32/driver.c. Right now that is just "x11." Discussing with Alexandre the other day I believe his thought is to make the hardcoded default "x11,mac" in all cases (including Linux). I believe (and I don't mean to put words in his mouth) that his thought is that a user should never have to edit the registry to switch between drivers. The thought would be that in order to switch between drivers, a user must instead create an environment in which all drivers which are ahead of the desired driver in the hardcoded load order will fail to load. I think that in the specific case of "x11,mac" on an OS X box, the thought was to unset DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and therefore getting the fallback. I just now realized, though, that OS X 10.8 ships with stub X11 libraries which behave badly. If you try to load X11 on a brand-new OS X 10.8 machine, the user sees a dialog box with directions on downloading XQuartz, and the process which tried to load X11 is killed. I hadn't thought of that earlier, but it seems to weigh against using a fallback mechanism where x11 is attempted first in all cases. It means that to get good behavior from the fall-through, a Mac user would be required to download and install real X libraries, then unset DISPLAY. It seems broadly incorrect to me to attempt to load X11 first everywhere and force the user to make sure loading that fails if they want a different driver. I think that if the Mac Driver is to be the default on a Mac, rather than assume the environment will be such that other drivers will fail, it should really just be the first thing wine tries to load. The case of OS X's bad X11 stub libraries is one where it seems fairly onerous for a user to ensure X11 won't load. Wayland isn't here now, but it seems like when it comes it may bring similar issues. I propose an environment variable, WINEDRIVERLOADORDER. I would think we would first use the registry value, then the value of WINEDRIVERLOADORDER, then the hardcoded fallback. I would also propose making the hardcoded fallback differ on OS X and linux, so that a user who does nothing on OS X can have the Mac Driver, but someone who wants X11 can set WINEDRIVERLOADORDER and switch to that without editing the registry. Is that an acceptable approach? Of course, Ken may abhor the idea of having the Mac Driver the default in winehq at this point, anyway. ;)

5 7

wanted: testbot w9x machines
by Joerg-Cyril.Hoehle＠t-systems.com 04 Mar '13

04 Mar '13

Hi, Francois Gouget wrote in another thread: >Not so long ago that machine was also running the tests on 5 additional >NT4 configurations, Windows 95, Windows 98 and Windows Millenium. It no >longer does, not because of lack of 'resources' or 'intention', but >because the Wine community is not interested in these. Huh? What? Please, PLEASE give me a (new)testbot with some w9x machines such that I can investigate the winmm&mci behavior that the apps written in that era encountered. It really slows down development on my side *not* to have an easily checked w9x system (nor a system for 16 bit tests, BTW). All that I can remember when that issue was raised last time was: 1. It's good not to test incoming patches against w9x behavior, because the time spent adding broken() for those is better invested adding code and more tests for w2k-w7 machines. Agreed. 1' test.winehq.org need no more display w9x test results. I don't care much. 2. Some technical aspects, such as not being able to find Greg's old w95 VM image, or producing a VM image with some soundcard not hanging randomly. But I can't remember an argument saying like "nobody was interested in those w95/w98/w98SE/wME machines, so we dumped them". Currently, (new)testbot doesn't even offer an option to run tests on w9x machines. I'm not asking for that option to be on by default, I'm just begging for it to be present! Thank you, Jörg Höhle

2 1

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.
by Dmitry Timoshkov 04 Mar '13

04 Mar '13

Francois Gouget <fgouget(a)codeweavers.com> wrote: > On Windows XP most versions of gdiplus (i.e. older than 5.2) do not support TIFF. I'd suggest to upgrade the VM instead. Ideally each VM should represent a Windows version with newest service pack installed it's supposed to run the tests on, otherwise that VM is useless. IMHO there is no point in changing the tests to workaround a broken VM state. -- Dmitry.

3 7

Re: [1/3] Revert "gdiplus: Add support for StringFormatFlagsNoClip."
by Vincent Povirk 04 Mar '13

04 Mar '13

Yay, thanks for fixing this. +1 :D

1 0