June 2015 - Wine-Devel - list.winehq.org

Re: Wiki is down

by Austin English

On Jun 27, 2015 3:33 PM, "Rosanne DiMesio" <dimesio(a)earthlink.net> wrote: > > Http://wiki.winehq.org leads to a bluehost.com page that says "There is no website configured at this address" and links to specific wiki pages produce 404: File not found. > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> +Dimi

June 27, 2015

Wiki is down

by Rosanne DiMesio

Http://wiki.winehq.org leads to a bluehost.com page that says "There is no website configured at this address" and links to specific wiki pages produce 404: File not found. -- Rosanne DiMesio <dimesio(a)earthlink.net>

June 27, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Vincent Povirk

> Most likely you should not be sharing them. Why do you need this? Best I can tell, this is how MS designed it. The _HIDP_PREPARSED_DATA structure can be obtained through ioctl or passed to certain hid.dll functions to carry information about the device. However, the details of that structure are not documented, and MSDN makes it sound like it can change between Windows versions.

June 26, 2015

Re: user32: Limit number of hooks called recursively.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14749 Your paranoid android. === wvistau64 (64 bit msg) === msg.c:10595: Test failed: expected PeekMessage to return FALSE, got 1

June 26, 2015

Re: [PATCH] msvcp90: Implement time_get<char> ctors and dtors

by Piotr Caban

On 06/26/15 18:37, Daniel Lehman wrote: > the string c/dtors need a cast to non-const. would it be ok to do the cast in the macros at the top? > > something like: > #define locale_string_char_dtor(this) _Yarn_char_dtor((locale_string *)this) > > Then the casts are in one spot and don't need to be sprinkled about It's useful to be warned about trying to modify const data. It's why I don't think it's a good idea to do the cast in the macro. Mangled names shows that the casts are also done in native dll. As far as I can see there are only 4 functions that needs the casts.

June 26, 2015

RE: [PATCH] msvcp90: Implement time_get<char> ctors and dtors

by Daniel Lehman

> -----Original Message----- > From: Piotr Caban [mailto:piotr.caban(a)gmail.com] > Sent: Friday, June 26, 2015 8:44 AM > To: Daniel Lehman > Cc: wine-devel(a)winehq.org > Subject: Re: [PATCH] msvcp90: Implement time_get<char> ctors and dtors > > On 06/26/15 16:51, Daniel Lehman wrote: > > + days = _Locinfo__Getdays((_Locinfo *)locinfo); > Could you please change _Locinfo__Getdays header and make the cast > there? Thanks to it we will much _Locinfo__Getdays mangled name. Also > _Locinfo__W_Getmonths, _Locinfo__Getmonths and _Locinfo__W_Getdays > header needs to be fixed. This will make this cast not needed. > the string c/dtors need a cast to non-const. would it be ok to do the cast in the macros at the top? something like: #define locale_string_char_dtor(this) _Yarn_char_dtor((locale_string *)this) Then the casts are in one spot and don't need to be sprinkled about Thanks daniel

June 26, 2015

Re: [PATCH] msvcp90: Implement time_get<char> ctors and dtors

by Piotr Caban

On 06/26/15 16:51, Daniel Lehman wrote: > + days = _Locinfo__Getdays((_Locinfo *)locinfo); Could you please change _Locinfo__Getdays header and make the cast there? Thanks to it we will much _Locinfo__Getdays mangled name. Also _Locinfo__W_Getmonths, _Locinfo__Getmonths and _Locinfo__W_Getdays header needs to be fixed. This will make this cast not needed. > + len = strlen(days)+1; > + this->days = MSVCRT_operator_new(len); > + if(this->days) Please handle allocation failures as it's done in other locale classes. > time_get_char* __thiscall time_get_char_ctor_locinfo(time_get_char *this, > const _Locinfo *locinfo, unsigned int refs) > { > - FIXME("(%p %p %d) stub\n", this, locinfo, refs); > + TRACE("(%p %p %d)\n", this, locinfo, refs); > + locale_facet_ctor_refs(&this->facet, refs); > this->facet.vtable = &MSVCP_time_get_char_vtable; > + time_get_char__Init(this, locinfo); > return NULL; > } You forgot to return THIS here. Thanks, Piotr

June 26, 2015

Re: [PATCH 2/2] msvcp90: Copy name in _Getctype (Valgrind) (try2)

by Piotr Caban

On 06/26/15 16:37, Daniel Lehman wrote: > I updated the patch to check for NULL. But wouldn't the same be true for these calls? > - _Getdateorder -> GetLocaleInfoEx > - _Strcoll -> LocaleNameToLCID -> parse_locale_name This calls are correct because LOCALE_NAME_USER_DEFAULT equals NULL. In case of e.g. C locale default user LCID will be used. Thanks, Piotr

June 26, 2015

RE: [PATCH 2/2] msvcp90: Copy name in _Getctype (Valgrind) (try2)

by Daniel Lehman

> On 06/24/15 16:46, Daniel Lehman wrote: > > + name = ___lc_locale_name_func()[LC_COLLATE]; > > + size = wcslen(name)+1; > > + ret->name = malloc(size*sizeof(*name)); > > + if (!ret->name) throw_exception(EXCEPTION_BAD_ALLOC, NULL); > > + memcpy(ret->name, name, size*sizeof(*name)); > This will not work if ___lc_locale_name_func()[LC_COLLATE] is NULL. I updated the patch to check for NULL. But wouldn't the same be true for these calls? - _Getdateorder -> GetLocaleInfoEx - _Strcoll -> LocaleNameToLCID -> parse_locale_name Thanks daniel

June 26, 2015

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Aaryaman Vasishta

I was corrected by Henri about that behaviour. I shouldn't use that as a check. Regardless, the tests do by themselves amount to the fact that the depth surface remains attached even after we explictly release all our references to it (therefore the refcount is 1 after calling release on the last reference). So after destroying the root surface, the attached surface is also destroyed as it's refcount was 1, and ddraw implicitly calls DeleteAttachedSurface which decrements that refcount to 0, in turn destroying it. On Fri, Jun 26, 2015 at 6:26 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > About the refcount of the depth surface after render target is destroyed: > How about a simple NULL check for lpvtbl? > > On Fri, Jun 26, 2015 at 5:32 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> >> >> On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger < >> stefandoesinger(a)gmail.com> wrote: >> >>> Minor issue: I don't think there's a reason to destroy and recreate the >>> surface. >>> >> The other way afaik is to QI surface version >= 3 and then call >> SetSurfaceDesc. This seemed easier to do so. Is there some other way? >> >> > + IDirectDrawSurface_Release(d3drm_ds); >>> > + IDirectDrawSurface_Release(d3drm_surface); >>> > + IDirectDrawSurface_Release(ds); >>> What happens to the depth buffer here? Does it remain attached? >>> >> >> At this point (after releasing ds) the refcounts of both ds and render >> target (i.e. surface) become 1. >> > >

June 26, 2015

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Aaryaman Vasishta

About the refcount of the depth surface after render target is destroyed: How about a simple NULL check for lpvtbl? On Fri, Jun 26, 2015 at 5:32 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger < > stefandoesinger(a)gmail.com> wrote: > >> Minor issue: I don't think there's a reason to destroy and recreate the >> surface. >> > The other way afaik is to QI surface version >= 3 and then call > SetSurfaceDesc. This seemed easier to do so. Is there some other way? > > > + IDirectDrawSurface_Release(d3drm_ds); >> > + IDirectDrawSurface_Release(d3drm_surface); >> > + IDirectDrawSurface_Release(ds); >> What happens to the depth buffer here? Does it remain attached? >> > > At this point (after releasing ds) the refcounts of both ds and render > target (i.e. surface) become 1. >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? Most likely you should not be sharing them. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Nikolay Sivov

On 06/26/2015 03:22 PM, Aric Stewart wrote: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? So just to clarify, is this the only solution to have internal structures? I mean do you need them because of some undocumented interfaces or because the way hid/hidclass are used differs from native architecture? > > -aric > > On 6/26/15 1:32 AM, Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> --- /dev/null >>> +++ b/include/wine/hid.h >>> @@ -0,0 +1,80 @@ >>> +/* >>> + * Wine internal HID structures >>> + * >> >> You shouldn't need a global header for internal structures. >> > >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Michael Stefaniuc

Aric, On 06/26/2015 02:22 PM, Aric Stewart wrote: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? my crystal ball tells me that the answer will be to just have that internal header and copy it to hidclass.sys E.g. I have 8 copies of dmobject.[ch] atm bye michael > > -aric > > On 6/26/15 1:32 AM, Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> --- /dev/null >>> +++ b/include/wine/hid.h >>> @@ -0,0 +1,80 @@ >>> +/* >>> + * Wine internal HID structures >>> + * >> >> You shouldn't need a global header for internal structures. >> >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Aric Stewart

These internal structures are shared between hid.dll and the forthcoming hidclass.sys Should I define them internally at this point and have a patch later that moves them to the global header? -aric On 6/26/15 1:32 AM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> --- /dev/null >> +++ b/include/wine/hid.h >> @@ -0,0 +1,80 @@ >> +/* >> + * Wine internal HID structures >> + * > > You shouldn't need a global header for internal structures. >

June 26, 2015

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Aaryaman Vasishta

On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Minor issue: I don't think there's a reason to destroy and recreate the > surface. > The other way afaik is to QI surface version >= 3 and then call SetSurfaceDesc. This seemed easier to do so. Is there some other way? > + IDirectDrawSurface_Release(d3drm_ds); > > + IDirectDrawSurface_Release(d3drm_surface); > > + IDirectDrawSurface_Release(ds); > What happens to the depth buffer here? Does it remain attached? > At this point (after releasing ds) the refcounts of both ds and render target (i.e. surface) become 1.

June 26, 2015

Re: [PATCH 3/4] dmband: Remove the extraneous IUnknown from DMBandTrack

by Michael Stefaniuc

On 06/26/2015 12:39 PM, Jacek Caban wrote: > Hi Michael, > > On 06/26/15 00:18, Michael Stefaniuc wrote: >> @@ -97,22 +41,47 @@ static inline IDirectMusicBandTrack *impl_from_IDirectMusicTrack8(IDirectMusicTr >> } >> >> static HRESULT WINAPI IDirectMusicTrack8Impl_QueryInterface(IDirectMusicTrack8 *iface, REFIID riid, >> - void **ppobj) >> + void **ret_iface) >> { >> IDirectMusicBandTrack *This = impl_from_IDirectMusicTrack8(iface); >> - return IUnknown_QueryInterface ((LPUNKNOWN)&This->UnknownVtbl, riid, ppobj); >> + >> + if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IDirectMusicTrack) || >> + IsEqualIID(riid, &IID_IDirectMusicTrack8)) >> + *ret_iface = iface; >> + else if (IsEqualIID(riid, &IID_IPersistStream)) >> + *ret_iface = &This->PersistStreamVtbl; >> + else { >> + WARN("(%p, %s, %p): not found\n", This, debugstr_dmguid(riid), ret_iface); >> + return E_NOINTERFACE; >> + } > > The patch is obviously fine and the problem exists in current code, but > QI is supposed to set output interface on error and such assumption is > common for callers. It would be nice to fix that when you rewrite QI ;) Thanks Jacek, that was just a copy and paste fail on my site as I copied it from band.c and there I did it correctly. bye michael

June 26, 2015

Re: [PATCH 3/4] dmband: Remove the extraneous IUnknown from DMBandTrack

by Jacek Caban

Hi Michael, On 06/26/15 00:18, Michael Stefaniuc wrote: > @@ -97,22 +41,47 @@ static inline IDirectMusicBandTrack *impl_from_IDirectMusicTrack8(IDirectMusicTr > } > > static HRESULT WINAPI IDirectMusicTrack8Impl_QueryInterface(IDirectMusicTrack8 *iface, REFIID riid, > - void **ppobj) > + void **ret_iface) > { > IDirectMusicBandTrack *This = impl_from_IDirectMusicTrack8(iface); > - return IUnknown_QueryInterface ((LPUNKNOWN)&This->UnknownVtbl, riid, ppobj); > + > + if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IDirectMusicTrack) || > + IsEqualIID(riid, &IID_IDirectMusicTrack8)) > + *ret_iface = iface; > + else if (IsEqualIID(riid, &IID_IPersistStream)) > + *ret_iface = &This->PersistStreamVtbl; > + else { > + WARN("(%p, %s, %p): not found\n", This, debugstr_dmguid(riid), ret_iface); > + return E_NOINTERFACE; > + } The patch is obviously fine and the problem exists in current code, but QI is supposed to set output interface on error and such assumption is common for callers. It would be nice to fix that when you rewrite QI ;) Cheers, Jacek

June 26, 2015

Re: [PATCH 2/2] msvcp90: Copy name in _Getctype (Valgrind) (try2)

by Piotr Caban

On 06/24/15 16:46, Daniel Lehman wrote: > + name = ___lc_locale_name_func()[LC_COLLATE]; > + size = wcslen(name)+1; > + ret->name = malloc(size*sizeof(*name)); > + if (!ret->name) throw_exception(EXCEPTION_BAD_ALLOC, NULL); > + memcpy(ret->name, name, size*sizeof(*name)); This will not work if ___lc_locale_name_func()[LC_COLLATE] is NULL. Thanks, Piotr

June 26, 2015

Re: wine CPU usage and CreateWaitableTimer

by Nikolay Sivov

On 06/25/2015 10:47 PM, andrea wrote: > On 07/06/15 19:08, Sebastian Lackner wrote: >> Hello andrea, >> >> good catch, its actually a bug in SystemClockAdviseThread. A patch like: >> >> --- snip --- >> diff --git a/dlls/quartz/systemclock.c b/dlls/quartz/systemclock.c >> index 043299b..ac41a49 100644 >> --- a/dlls/quartz/systemclock.c >> +++ b/dlls/quartz/systemclock.c >> @@ -127,6 +127,7 @@ static DWORD WINAPI SystemClockAdviseThread(LPVOID >> lpParam) { >> it = nextit; >> } >> if (NULL != it) timeOut = (DWORD) ((it->rtBaseTime + >> it->rtIntervalTime) - curTime) / (REFERENCE_TIME)10000; >> + else timeOut = INFINITE; >> >> /** Now Periodics Advice: semi sorted list (sort cannot be used) */ >> for (it = This->pPeriodicAdvise; NULL != it; it = it->next) { >> --- snip --- >> >> Seems to be sufficient to fix it. I will review the code for other >> errors one more time, >> and then submit the patch. >> >> Regarding your second question, the best timer (when using for events) is >> CreateWaitableTimer in my opinion. All other timers need separate >> threads, and need an >> additional wineserver call for event handling. >> >> Regards, >> Sebastian > > Did you manage to check if the patch you proposed is the good one? > This particular patch is already in wine, http://source.winehq.org/git/wine.git/commit/b513e07c55504f623baf8d838d00ac….

June 26, 2015

Re: [2/14]hid: break HidD_ functions out into their own module

by Alexandre Julliard

Charles Davis <cdavis5x(a)gmail.com> writes: >> On Jun 25, 2015, at 9:15 AM, Aric Stewart <aric(a)codeweavers.com> wrote: >> --- a/dlls/hid/main.c >> +++ b/dlls/hid/main.c >> @@ -39,43 +35,9 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) >> { >> switch(fdwReason) >> { >> - case DLL_WINE_PREATTACH: >> - return FALSE; /* prefer native version */ > This is minor, but I don’t think we should prefer the builtin hid.dll until we’re done implementing it. There's no such thing as a dll being done ;-) It's OK to change it as soon as the dll starts doing something useful. It should be a separate patch though. -- Alexandre Julliard julliard(a)winehq.org

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- /dev/null > +++ b/include/wine/hid.h > @@ -0,0 +1,80 @@ > +/* > + * Wine internal HID structures > + * You shouldn't need a global header for internal structures. -- Alexandre Julliard julliard(a)winehq.org

June 26, 2015

Re: [2/14]hid: break HidD_ functions out into their own module

by Charles Davis

> On Jun 25, 2015, at 9:15 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > --- a/dlls/hid/main.c > +++ b/dlls/hid/main.c > @@ -39,43 +35,9 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) > { > switch(fdwReason) > { > - case DLL_WINE_PREATTACH: > - return FALSE; /* prefer native version */ This is minor, but I don’t think we should prefer the builtin hid.dll until we’re done implementing it. Chip

June 26, 2015

Re: [1/14]include: add ddk/hidclass.h

by Charles Davis

> On Jun 25, 2015, at 9:15 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > @@ -0,0 +1,63 @@ […] > +#ifndef __HIDCLASS_H > +#define __HIDCLASS_H […] > +DEFINE_GUID (GUID_DEVINTERFACE_HID, \ > + 0x4D1E55B2L, 0xF16F, 0x11CF, 0x88, 0xCB, 0x00, 0x11, 0x11, 0x00, 0x00, 0x30); Correct me if I’m wrong, but I think this should go outside the header guard. That way, you can usefully include this definition multiple times, and one of those times you can define INITGUID to get a real definition. Chip

June 26, 2015

Re: Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

by Vincent Povirk

> By adding a exe.mainfest with wine data or exe.winemainfest file marks the > application as clearly to be opened by wine. FWIW Mono currently uses .exe.config files. > Also just using MINE type does not tell you want WINEPREFIX the > application owns to. In any normal case, an exe file that "belongs to" a wineprefix will be located in its C drive. That shouldn't be hard to find by traversing parent directories. > Yes setting up binfmt-misc requires root. But binfmt-misc is where non native > Linux applications requiring Linux security permissions should start > their execution path. We shouldn't condone assigning security permissions to specific win32 exe files beyond what the user naturally has. Currently, we cannot protect the exe process from anything else the user does, so it's effectively the same as giving that permission to any user that can execute the file. Of course, giving special permissions to wineloader is ALSO the same as doing that, but the solution is to give the permissions to the target program in some way that actually works, rather than switch to a different way that doesn't. I would suggest running these programs in a dedicated account. > Really the MINE type usage by .desktop to run wine should disappear > for Linux other than to tell the system > to directly execute the exe. The use of wine.desktop to run executable files is intentional and necessary. This is because Windows runs executables differently depending on whether they are invoked from the command-line or from the GUI (windows explorer). There are several differences, but the most important is that running from the GUI sets the working directory to the parent directory of the executable. Many applications rely on this behavior and won't be able to find their own files if they are executed from a different directory. Use of wine.desktop runs executables the way explorer does, which is appropriate when a user double-clicks the file. We don't want to change the working directory when running an exe via the command line because windows doesn't do that, and because it can be important. It's not possible for binfmt to determine how it was invoked, and thus which behavior it should use. AFAIK binfmt is generally configured for the command-line mode and is not suitable for GUI applications. Binfmt can't tell us which interpreter to use with any more accuracy than the desktop environment, unless it's specifically configured by the user, and in fact binfmt has a harder problem to solve because it doesn't know whether to treat the exe as a GUI application (whereas we can assume anyone using wine.desktop to run a .exe file wants the GUI mode). At least with wine.desktop, this can be configured through the same GUI that will be used to run the file, which wouldn't be possible with binfmt. For most users, that one setting will be enough. For users that need to use something other than wine for only some .exe files, the sensible thing to do is create a shortcut (.desktop file, shell script, or whatever is most convenient) that does it in the right way. That has the advantages of being a generally useful skill that users are likely to already know or at least use again, and of not relying on the user to have binfmt configured in a specific way. > Even .desktop files to run programs under Linux should become super simple. > Path to executable as enough. All the extra complexity in the > .desktop files for Linux is a bug. Generally .desktop files correspond to .lnk files, not .exe files. Links to executables are just one specific case. And more importantly, putting some configuration file next to a .exe would require user intervention, while we can create .desktop files automatically.

June 26, 2015

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Stefan Dösinger

Hi, > + ok((desc.ddsCaps.dwCaps & DDSCAPS_ZBUFFER) == DDSCAPS_ZBUFFER, "Expected caps containing %x, got %x.\n", DDSCAPS_ZBUFFER, desc.ddsCaps.dwCaps); Style-only issue: You're just checking one flag here, so ok(dwCaps & ZBUFFER, "..."); is enough > + IDirectDrawSurface_Release(surface); > + > + memset(&desc, 0, sizeof(desc)); > + desc.dwSize = sizeof(desc); > + desc.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE; > + desc.dwWidth = rc.right; > + desc.dwHeight = rc.bottom; > + > + hr = IDirectDraw_CreateSurface(ddraw, &desc, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); Minor issue: I don't think there's a reason to destroy and recreate the surface. > + IDirectDrawSurface_Release(d3drm_ds); > + IDirectDrawSurface_Release(d3drm_surface); > + IDirectDrawSurface_Release(ds); What happens to the depth buffer here? Does it remain attached? Stefan

June 25, 2015

Re: [PATCH 1/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 6).

by Stefan Dösinger

Hi, This patch looks good to me. Stefan > Am 25.06.2015 um 22:42 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > --- > dlls/d3drm/tests/d3drm.c | 202 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 202 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 5dcfddc..666150f 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1947,6 +1947,207 @@ static void test_frame_qi(void) > IDirect3DRM_Release(d3drm1); > } > > +static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, DDSURFACEDESC *desc, void *context) > +{ > + IDirectDrawSurface **primary = context; > + > + if (desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) > + { > + *primary = surface; > + return DDENUMRET_CANCEL; > + } > + IDirectDrawSurface_Release(surface); > + > + return DDENUMRET_OK; > +} > + > +static void test_create_device_from_clipper(void) > +{ > + DDSCAPS caps = { DDSCAPS_ZBUFFER }; > + IDirect3DRM *d3drm1 = NULL; > + IDirect3DRM2 *d3drm2 = NULL; > + IDirectDraw *ddraw = NULL; > + IUnknown *unknown = NULL; > + IDirect3DRMDevice2 *device2 = NULL; > + IDirect3DDevice2 *d3ddevice2 = NULL; > + IDirectDrawClipper *clipper = NULL, *d3drm_clipper = NULL; > + IDirectDrawSurface *surface = NULL, *ds = NULL, *d3drm_primary = NULL; > + IDirectDrawSurface7 *surface7 = NULL; > + DDSURFACEDESC desc, surface_desc; > + DWORD expected_flags; > + HWND window; > + GUID driver = IID_IDirect3DRGBDevice; > + HRESULT hr; > + ULONG ref1, ref2, ref3, cref1, cref2; > + RECT rc; > + > + window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 0, 0, 500, 400, 0, 0, 0, 0); > + GetClientRect(window, &rc); > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface (hr = %x).\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper (hr = %x).\n", hr); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x).\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM2 interface (hr = %x).\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm2); > + > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, 0, 0, &device2); > + todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %x.\n", hr); > + > + /* If NULL is passed for clipper, CreateDeviceFromClipper returns D3DRMERR_BADVALUE */ > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, NULL, &driver, 0, 0, &device2); > + todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %x.\n", hr); > + > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, 300, 200, &device2); > + ok(hr == D3DRM_OK, "Cannot create IDirect3DRMDevice2 interface (hr = %x).\n", hr); > + ref3 = get_refcount((IUnknown *)d3drm1); > + todo_wine ok(ref3 > ref1, "expected ref3 > ref1, got ref1 = %u , ref3 = %u.\n", ref1, ref3); > + ref3 = get_refcount((IUnknown *)d3drm2); > + ok(ref3 == ref2, "expected ref3 == ref2, got ref2 = %u , ref3 = %u.\n", ref2, ref3); > + cref2 = get_refcount((IUnknown *)clipper); > + todo_wine ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %u , cref2 = %u.\n", cref1, cref2); > + > + /* Fetch immediate mode device in order to access render target */ > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + todo_wine ok(hr == D3DRM_OK, "Cannot get IDirect3DDevice2 interface (hr = %x).\n", hr); > + if (FAILED(hr)) > + goto cleanup; > + > + hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &surface); > + ok(hr == DD_OK, "Cannot get surface to the render target (hr = %x).\n", hr); > + > + hr = IDirectDrawSurface_GetClipper(surface, &d3drm_clipper); > + ok(hr == DDERR_NOCLIPPERATTACHED, "Expected hr == DDERR_NOCLIPPERATTACHED, got %x.\n", hr); > + > + /* Check if CreateDeviceFromClipper creates a primary surface and attaches the clipper to it */ > + hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface7, (void **)&surface7); > + ok(hr == DD_OK, "Cannot get IDirectDrawSurface7 interface (hr = %x).\n", hr); > + IDirectDrawSurface7_GetDDInterface(surface7, (void **)&unknown); > + hr = IUnknown_QueryInterface(unknown, &IID_IDirectDraw, (void **)&ddraw); > + ok(hr == DD_OK, "Cannot get IDirectDraw interface (hr = %x).\n", hr); > + IUnknown_Release(unknown); > + hr = IDirectDraw_EnumSurfaces(ddraw, DDENUMSURFACES_ALL | DDENUMSURFACES_DOESEXIST, > + NULL, &d3drm_primary, surface_callback); > + ok(hr == DD_OK, "Failed to enumerate surfaces (hr = %x).\n", hr); > + ok(d3drm_primary != NULL, "No primary surface was enumerated.\n"); > + hr = IDirectDrawSurface_GetClipper(d3drm_primary, &d3drm_clipper); > + ok(hr == DD_OK, "Cannot get attached clipper from primary surface (hr = %x).\n", hr); > + if (SUCCEEDED(hr)) > + { > + ok(d3drm_clipper == clipper, "Expected clipper returned == %p, got %p.\n", clipper , d3drm_clipper); > + IDirectDrawClipper_Release(d3drm_clipper); > + } > + if (d3drm_primary) > + IDirectDrawSurface_Release(d3drm_primary); > + IDirectDrawSurface7_Release(surface7); > + IDirectDraw_Release(ddraw); > + > + /* Check properties of render target and depth surface */ > + surface_desc.dwSize = sizeof(surface_desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &surface_desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x).\n", hr); > + > + ok((surface_desc.dwWidth == 300) && (surface_desc.dwHeight == 200), "Expected surface dimentions = 300, 200, got %u, %u.\n", > + surface_desc.dwWidth, surface_desc.dwHeight); > + ok((surface_desc.ddsCaps.dwCaps & (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE)) == (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE), > + "Expected caps containing %x, got %x.\n", DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE, surface_desc.ddsCaps.dwCaps); > + expected_flags = DDSD_PIXELFORMAT | DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH; > + ok(surface_desc.dwFlags == expected_flags, "Expected %x for flags, got %x.\n", expected_flags, surface_desc.dwFlags); > + > + hr = DirectDrawCreate(NULL, &ddraw, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDraw interface (hr = %x).\n", hr); > + desc.dwSize = sizeof(desc); > + hr = IDirectDraw_GetDisplayMode(ddraw, &desc); > + ok(hr == DD_OK, "Cannot get IDirectDraw display mode (hr = %x)\n", hr); > + ok(desc.ddpfPixelFormat.dwRGBBitCount == surface_desc.ddpfPixelFormat.dwRGBBitCount, "Expected %u bpp, got %u bpp.\n", > + surface_desc.ddpfPixelFormat.dwRGBBitCount, desc.ddpfPixelFormat.dwRGBBitCount); > + > + hr = IDirectDrawSurface_GetAttachedSurface(surface, &caps, &ds); > + ok(hr == DD_OK, "Cannot get attached depth surface (hr = %x).\n", hr); > + > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(ds, &desc); > + ok(hr == DD_OK, "Cannot get z surface desc structure (hr = %x).\n", hr); > + > + ok((desc.dwWidth == 300) && (desc.dwHeight == 200), "Expected surface dimentions = 300, 200, got %u, %u.\n", > + desc.dwWidth, desc.dwHeight); > + ok((desc.ddsCaps.dwCaps & DDSCAPS_ZBUFFER) == DDSCAPS_ZBUFFER, "Expected caps containing %x, got %x.\n", DDSCAPS_ZBUFFER, desc.ddsCaps.dwCaps); > + expected_flags = DDSD_ZBUFFERBITDEPTH | DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH; > + ok(desc.dwFlags == expected_flags, "Expected %x for flags, got %x.\n", expected_flags, desc.dwFlags); > + ok(desc.dwZBufferBitDepth == 16, "Expected 16 for Z buffer bit depth, got %u.\n", desc.dwZBufferBitDepth); > + ok(desc.ddpfPixelFormat.dwStencilBitMask == 0, "Expected 0 stencil bits, got %x.\n", desc.ddpfPixelFormat.dwStencilBitMask); > + > + /* Release old objects and check refcount of device and clipper */ > + IDirectDrawSurface_Release(ds); > + ds = NULL; > + IDirectDrawSurface_Release(surface); > + surface = NULL; > + IDirect3DDevice2_Release(d3ddevice2); > + d3ddevice2 = NULL; > + IDirect3DRMDevice2_Release(device2); > + ref3 = get_refcount((IUnknown *)d3drm1); > + ok(ref1 == ref3, "expected ref1 == ref3, got ref1 = %u, ref3 = %u.\n", ref1, ref3); > + ref3 = get_refcount((IUnknown *)d3drm2); > + ok(ref3 == ref2, "expected ref3 == ref2, got ref2 = %u , ref3 = %u.\n", ref2, ref3); > + cref2 = get_refcount((IUnknown *)clipper); > + todo_wine ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %u, cref2 = %u.\n", cref1, cref2); > + > + /* Test if render target format follows the screen format */ > + hr = IDirectDraw_GetDisplayMode(ddraw, &desc); > + ok(hr == DD_OK, "Cannot get IDirectDraw display mode (hr = %x)\n", hr); > + hr = IDirectDraw_SetDisplayMode(ddraw, desc.dwWidth, desc.dwHeight, 16); > + ok(hr == DD_OK, "Cannot set display mode to 16bpp (hr = %x).\n", hr); > + > + hr = IDirectDraw_GetDisplayMode(ddraw, &desc); > + ok(hr == DD_OK, "Cannot get IDirectDraw display mode (hr = %x)\n", hr); > + ok(desc.ddpfPixelFormat.dwRGBBitCount == 16, "Expected 16 bpp, got %u.\n", desc.ddpfPixelFormat.dwRGBBitCount); > + > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot create IDirect3DRMDevice2 interface (hr = %x).\n", hr); > + > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + todo_wine ok(hr == D3DRM_OK, "Cannot get IDirect3DDevice2 interface (hr = %x).\n", hr); > + if (FAILED(hr)) > + goto cleanup; > + > + hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &surface); > + ok(hr == DD_OK, "Cannot get surface to the render target (hr = %x).\n", hr); > + > + surface_desc.dwSize = sizeof(surface_desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &surface_desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x).\n", hr); > + todo_wine ok(surface_desc.ddpfPixelFormat.dwRGBBitCount == 16, "Expected 16bpp, got %ubpp.\n", > + surface_desc.ddpfPixelFormat.dwRGBBitCount); > + > + hr = IDirectDraw2_RestoreDisplayMode(ddraw); > + ok(SUCCEEDED(hr), "RestoreDisplayMode failed, hr %#x.\n", hr); > + > +cleanup: > + if (ds) > + IDirectDrawSurface_Release(ds); > + if (surface) > + IDirectDrawSurface_Release(surface); > + if (d3ddevice2) > + IDirect3DDevice2_Release(d3ddevice2); > + if (device2) > + IDirect3DRMDevice2_Release(device2); > + if (d3drm2) > + IDirect3DRM2_Release(d3drm2); > + if (d3drm1) > + IDirect3DRM_Release(d3drm1); > + if (clipper) > + IDirectDrawClipper_Release(clipper); > + if (ddraw) > + IDirectDraw_Release(ddraw); > + DestroyWindow(window); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -1964,4 +2165,5 @@ START_TEST(d3drm) > test_frame_mesh_materials(); > test_d3drm_qi(); > test_frame_qi(); > + test_create_device_from_clipper(); > } > -- > 1.9.3 (Apple Git-50) > > >

June 25, 2015

Re: [PATCH 1/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 5).

by Aaryaman Vasishta

That d3drm_clipper variable is pointless, but please let me know if the rest of it is fine. Thank you! Jam On Fri, Jun 26, 2015 at 1:41 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > This is by no means a full review, just a couple of obvious things I noticed. >> >> On 24 June 2015 at 17:02, Aaryaman Vasishta <jem456.vasishta at gmail.com <https://www.winehq.org/mailman/listinfo/wine-devel>> wrote: >> >* +static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, DDSURFACEDESC *desc, void *context) >> *>* +{ >> *>* + IDirectDrawClipper *d3drm_clipper = NULL; >> *Initializing this to NULL is pointless, you initialize it before all >> uses with the IDirectDrawSurface_GetClipper() call below. >> >> >* + if (context) >> *>* + { >> *"context" should always be non-NULL here. >> >> >* + hr = IDirectDrawSurface_GetClipper(surface, &d3drm_clipper); >> *>* + ok(hr == DD_OK, "Cannot get attached clipper from primary surface (hr = %x).\n", hr); >> *>* + if (SUCCEEDED(hr)) >> *You have an ok() one line above that states "hr == DD_OK" at this >> point. If the GetClipper() call failed you'd get a test failure. >> >> Once you've found the primary you can of course return DDENUMRET_CANCEL. >> >> I think you're making things too complicated though. I'd just call >> EnumSurfaces() with "&primary" as context pointer, set it in the >> callback, and then just do the rest of the tests after EnumSurfaces() >> returns, instead of trying to fit those into the callback. >> >> Thank you for the suggestions! I have decided to return the primary > surface directly, and set it to NULL if it doesn't exist via the context, > something like this, which seems to run fine on my windows machine: > >> static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, >> DDSURFACEDESC *desc, void **context) >> { >> IDirectDrawClipper *d3drm_clipper; >> HRESULT hr; >> >> if (desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) >> { >> *context = surface; >> return DDENUMRET_CANCEL; >> } >> IDirectDrawSurface_Release(surface); >> >> return DDENUMRET_OK; >> } >> > Then in the tests, simply check if the context returned is NULL, if yes > then perform related tests on it inside the test. > > > Thank you! >

June 25, 2015

RE: [PATCH 1/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 5).

by Aaryaman Vasishta

> > This is by no means a full review, just a couple of obvious things I noticed. > > On 24 June 2015 at 17:02, Aaryaman Vasishta <jem456.vasishta at gmail.com <https://www.winehq.org/mailman/listinfo/wine-devel>> wrote: > >* +static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, DDSURFACEDESC *desc, void *context) > *>* +{ > *>* + IDirectDrawClipper *d3drm_clipper = NULL; > *Initializing this to NULL is pointless, you initialize it before all > uses with the IDirectDrawSurface_GetClipper() call below. > > >* + if (context) > *>* + { > *"context" should always be non-NULL here. > > >* + hr = IDirectDrawSurface_GetClipper(surface, &d3drm_clipper); > *>* + ok(hr == DD_OK, "Cannot get attached clipper from primary surface (hr = %x).\n", hr); > *>* + if (SUCCEEDED(hr)) > *You have an ok() one line above that states "hr == DD_OK" at this > point. If the GetClipper() call failed you'd get a test failure. > > Once you've found the primary you can of course return DDENUMRET_CANCEL. > > I think you're making things too complicated though. I'd just call > EnumSurfaces() with "&primary" as context pointer, set it in the > callback, and then just do the rest of the tests after EnumSurfaces() > returns, instead of trying to fit those into the callback. > > Thank you for the suggestions! I have decided to return the primary surface directly, and set it to NULL if it doesn't exist via the context, something like this, which seems to run fine on my windows machine: > static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, > DDSURFACEDESC *desc, void **context) > { > IDirectDrawClipper *d3drm_clipper; > HRESULT hr; > > if (desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) > { > *context = surface; > return DDENUMRET_CANCEL; > } > IDirectDrawSurface_Release(surface); > > return DDENUMRET_OK; > } > Then in the tests, simply check if the context returned is NULL, if yes then perform related tests on it inside the test. Thank you!

June 25, 2015

Re: wine CPU usage and CreateWaitableTimer

by andrea

On 07/06/15 19:08, Sebastian Lackner wrote: > Hello andrea, > > good catch, its actually a bug in SystemClockAdviseThread. A patch like: > > --- snip --- > diff --git a/dlls/quartz/systemclock.c b/dlls/quartz/systemclock.c > index 043299b..ac41a49 100644 > --- a/dlls/quartz/systemclock.c > +++ b/dlls/quartz/systemclock.c > @@ -127,6 +127,7 @@ static DWORD WINAPI SystemClockAdviseThread(LPVOID lpParam) { > it = nextit; > } > if (NULL != it) timeOut = (DWORD) ((it->rtBaseTime + it->rtIntervalTime) - curTime) / (REFERENCE_TIME)10000; > + else timeOut = INFINITE; > > /** Now Periodics Advice: semi sorted list (sort cannot be used) */ > for (it = This->pPeriodicAdvise; NULL != it; it = it->next) { > --- snip --- > > Seems to be sufficient to fix it. I will review the code for other errors one more time, > and then submit the patch. > > Regarding your second question, the best timer (when using for events) is > CreateWaitableTimer in my opinion. All other timers need separate threads, and need an > additional wineserver call for event handling. > > Regards, > Sebastian Did you manage to check if the patch you proposed is the good one?

June 25, 2015

Re: [3/14]hid: translated HidD_ functions to their IOCTLs

by Nikolay Sivov

On 25.06.2015 18:15, Aric Stewart wrote: > BOOLEAN WINAPI HidD_SetFeature(HANDLE HidDeviceObject, PVOID ReportBuffer, ULONG ReportBufferLength) > { > - FIXME("(%p %p %u) stub\n", HidDeviceObject, ReportBuffer, ReportBufferLength); > - return FALSE; > + TRACE("(%p %p %u)\n", HidDeviceObject, ReportBuffer, ReportBufferLength); > + return DeviceIoControl(HidDeviceObject, IOCTL_HID_SET_OUTPUT_REPORT, ReportBuffer, ReportBufferLength, NULL, 0, NULL, NULL); > } I can't say I know anything about that, but this looks like a typo, maybe it should use IOCTL_HID_SET_FEATURE?

June 25, 2015

Re: d3dx9-36: Save multiplications to improve performance

by Matteo Bruni

2015-06-25 4:07 GMT+02:00 David Adam <david.adam.cnrs(a)gmail.com>: > Hello, > > with my dual-core, for sides=65000 the gain is about 40%. It probably has more to do with avoiding the division than the multiplication. Can you add a test for a polygon with that many faces and see if the result matches native better with the simplification or without?

June 25, 2015

Re: [1/3] d3dcompiler: Share the source with d3dcompiler_46 (try 2)

by Matteo Bruni

2015-06-25 12:30 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Rename define to D3D_COMPILER_VERSION > > Changelog: > d3dcompiler: Share the source with d3dcompiler_46 > > > Best Regards > Alistair Leslie-Hughes Series looks good to me, thanks!

June 25, 2015

Re: [PATCH 1/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 5).

by Henri Verbeet

This is by no means a full review, just a couple of obvious things I noticed. On 24 June 2015 at 17:02, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > +static HRESULT CALLBACK surface_callback(IDirectDrawSurface *surface, DDSURFACEDESC *desc, void *context) > +{ > + IDirectDrawClipper *d3drm_clipper = NULL; Initializing this to NULL is pointless, you initialize it before all uses with the IDirectDrawSurface_GetClipper() call below. > + if (context) > + { "context" should always be non-NULL here. > + hr = IDirectDrawSurface_GetClipper(surface, &d3drm_clipper); > + ok(hr == DD_OK, "Cannot get attached clipper from primary surface (hr = %x).\n", hr); > + if (SUCCEEDED(hr)) You have an ok() one line above that states "hr == DD_OK" at this point. If the GetClipper() call failed you'd get a test failure. Once you've found the primary you can of course return DDENUMRET_CANCEL. I think you're making things too complicated though. I'd just call EnumSurfaces() with "&primary" as context pointer, set it in the callback, and then just do the rest of the tests after EnumSurfaces() returns, instead of trying to fit those into the callback.

June 25, 2015

Re: wineboot: Create MachineGuid registry value.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > I'm not sure if its a good idea to remove the advapi32 code. The behaviour that > CryptAcquireContextW re-creates the MachineGuid key was even tested explicitly back then > (see http://source.winehq.org/git/wine.git/patch/4c984e089a892a49e234bc09a62a2fe… ), > maybe because a specific app was depending on this behaviour. The same test was later > removed because it caused test failures on wow64 machines, but non-wow64 machines behave > basically all identical: http://newtestbot.winehq.org/JobDetails.pl?Key=14628. Do you > think we should just ignore these tests, or should I add them back to justify why the > advapi32 code stays there? Also, does this change your opinion regarding where to create > the MachineGuid? Having code duplication in advapi32<->wineboot might be better than in > advapi32<->wintrust. I forgot that we had this test at some point. So yes, it can stay in advapi32, but then there's no reason to duplicate anything, you can simply call CryptAcquireContextW from wintrust dll registration. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2015

Re: [1/3] wininet/tests: Add tests for overriding host header.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14698 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing

June 25, 2015

Re: wineboot: Create MachineGuid registry value.

by Sebastian Lackner

On 11.06.2015 08:24, Alexandre Julliard wrote: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> The MachineGuid registry key should exist even without calling CryptAcquireContextW. >> Optionally we could remove the remove the corresponding code from advapi32 afterwards. > > This doesn't need to run at every boot, so you can probably stick it > into the registration of some crypto dll like wintrust. And please also > remove the advapi32 code. > I'm not sure if its a good idea to remove the advapi32 code. The behaviour that CryptAcquireContextW re-creates the MachineGuid key was even tested explicitly back then (see http://source.winehq.org/git/wine.git/patch/4c984e089a892a49e234bc09a62a2fe… ), maybe because a specific app was depending on this behaviour. The same test was later removed because it caused test failures on wow64 machines, but non-wow64 machines behave basically all identical: http://newtestbot.winehq.org/JobDetails.pl?Key=14628. Do you think we should just ignore these tests, or should I add them back to justify why the advapi32 code stays there? Also, does this change your opinion regarding where to create the MachineGuid? Having code duplication in advapi32<->wineboot might be better than in advapi32<->wintrust. Best regards, Sebastian

June 25, 2015

Re: [1/3] wininet/tests: Add tests for overriding host header.

by Sebastian Lackner

On 25.06.2015 12:27, Sebastian Lackner wrote: > From: Michael Müller <michael(a)fds-team.de> > > --- > dlls/wininet/tests/http.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 109 insertions(+) > The testbot already shows a test failure on Win7, but it seems to be random. It doesn't occur in a second run: https://newtestbot.winehq.org/JobDetails.pl?Key=14699.

June 25, 2015

Re: [PATCH (resend)] cmd: Consistently wrap lines to 75 characters.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 75 characters is the maximum length of a line before gettext breaks it, > so this convention will cause each translatable string to fit snugly > into the po files. It's also about what we were doing anyway, just not > consistently. > > The biggest advantage to consistent line wrapping is that translators > will no longer have to guess where they should insert line breaks. You'll need to also update the duplicate text in programs/start, and it would be nice if you could try to fix at least some of the translations so that we don't have to invalidate all of them. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2015

Re: d3drm: Mark DllCanUnloadNow and DllGetClassObject as private.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -19,5 +19,5 @@ > @ stdcall D3DRMVectorScale(ptr ptr float) > @ stdcall D3DRMVectorSubtract(ptr ptr ptr) > @ stdcall Direct3DRMCreate(ptr) > -@ stub DllCanUnloadNow > -@ stub DllGetClassObject > +@ stub -private DllCanUnloadNow > +@ stub -private DllGetClassObject Private is not useful on a stub. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2015

Fw: Re: [PATCH] cmd: fix invalid "else if" execution (try2)

by Thomas Faller

Hello, these test failures weren't triggered by my patch. - Thomas Am 24.06.2015 um 22:23 schrieb Marvin: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=14664 > > Your paranoid android. > > > === wxppro (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === w2003std (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1368 (got 'value2', wanted '2set1endvalue1') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1369 (got 'C:\Documents and Settings\Administrator\My Documents\foobar\foodir2', wanted '@drive@@path(a)foobar\foodir3') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1370 (got 'value1', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1371 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1372 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === wvistau64 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > > === w8 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--------'', wanted ''--a------'@or_broken@'%~ai'') > > === wvistau64 (64 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > >

June 25, 2015

Re: ntdll: Randomize security cookie when available (try 3)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + /* randomize security cookie */ > + > + if (IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG < nt->OptionalHeader.NumberOfRvaAndSizes && > + (pos = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG].VirtualAddress)) > + { > + IMAGE_LOAD_CONFIG_DIRECTORY *loadcfg = (IMAGE_LOAD_CONFIG_DIRECTORY *)(ptr + pos); > + ULONG_PTR *cookie = (ULONG_PTR *)loadcfg->SecurityCookie; > + > + srand( time( NULL ) ); > + *cookie = rand(); This won't be random at all. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2015

Re: When/how to build separate debug symbol files

by Marcus Meissner

On Wed, Jun 24, 2015 at 06:26:31PM -0500, Ken Thomases wrote: > Hi, > > I'm investigating how to best make Wine build and install debug symbol files on OS X. > > My understanding is that, on Linux, the distros usually provide a > separate package for a user to install Wine's debug symbols. From recent > work in dbghelp, I'm guessing such a package installs debug symbol files > next to the corresponding binary or in a .debug subdirectory next to it. > Is that correct? For SUSE we install the debuginfo in places like: /usr/lib/debug/usr/lib64/libusb-1.0.so.0.1.0.debug for e.g. the libusb 1.0 shared library. /usr/lib64/libusb-1.0.so.0.1.0 Other distros might do it differently. > How do packagers generate such separate debug symbol files? Is it > a special option (make target?) in Wine's build process? Or is it a > post-processing step after Wine is built and installed to a staging > directory? How does this interact with stripping during building for > the non-debug-symbol, normal Wine package? It is standard macro hidden in our RPM build process. It happens after the regular package "make install" is done. It extracts the debuginfo fully automatic, no packager attention required. Basically it does objcopy of the debug sections for all libraries and binaries, and afterwards it does "strip --strip-unneeded" The package build itself is not supposed to strip binaries. CIao, Marcus

June 25, 2015

Re: When/how to build separate debug symbol files

by Ken Thomases

On Jun 24, 2015, at 7:58 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> >> How do packagers generate such separate debug symbol files? > I think they either: > a) use split DWARF (-gsplit-dwarf option to GCC/Clang), which will give you *.dwo files; or > b) use objcopy(1) to extract the .debug_* sections from the final binaries into *.debug files. > > I suspect it’s the second one; split DWARF (aka DWARF Fission) is relatively new, so I don’t think it’s widely used yet. OK. Do they get any help in applying objcopy to Wine's binaries? That is, is there anything in Wine's build system into which they hook? Or do they just need to manually identify the binaries somehow? (Not saying it's necessarily hard, just wondering what the right way to do it is.) >> How does this interact with stripping during building for the non-debug-symbol, normal Wine package? > Wine doesn’t run strip(1) until install time. Yup. I was aware of that. > This gives packagers time to objcopy(1) the DWARF data before it’s stripped away. I was thinking that the "make install" step would both be the opportunity to apply objcopy and also be a way to identify the files on which to apply it. Basically, anything on which INSTALL_PROGRAM is used. They might even do it with a cleverly-specified STRIP command. >> The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. > First, I’ll tell you that, under certain circumstances, it’s possible to get GCC or Clang to invoke dsymutil(1) for you. I haven’t yet completely worked out what those circumstances are—so far, I know that it will do this if you compile and link in one step, but I don’t know how to get it to do this automatically when linking objects with a __DWARF segment. OK, interesting, but I don't think I want to rely on that. I think it's best to figure out when and how to call dsymutil and do that explicitly from Wine's build system. > The other thing I’ll tell you is that, since strip(1) isn’t run until install time (and, in fact, probably won’t be run at all on Mac OS since we often use BSD install(1) there), you should be able to run dsymutil(1) at any time up to ‘make install’. Yes, sure, I can do it manually (both deciding to do it and figuring out what to do it to). I'm hoping to find the right way to automate it. Regarding whether stripping is done on OS X, Wine seems to use GNU install (if I've properly understood). Wine ships tools/install-sh and uses that. However, it seems that one must specify INSTALL_PROGRAM_FLAGS=-s in order to make it actually try to strip. A simple "make install" doesn't by default. And, then, OS X's strip throws errors when used without options, so you have to specify STRIP="strip -x". >> A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. > It’s actually possible to read the DWARF data out of the object files (if they’re still around). Both GDB and LLDB do this in the absence of a dSYM companion bundle/file. This is easier said than done, though. If you go this route, you’ll need to relocate the object files’ DWARF data (basically, doing what dsymutil(1) does) before making them available to clients. Yes, that's what I meant by "isn't easily accessible". ;) Not impossible, just not easy. Thanks for your input, Ken

June 25, 2015

Re: When/how to build separate debug symbol files

by Charles Davis

> On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > Hi, > > I'm investigating how to best make Wine build and install debug symbol files on OS X. > > My understanding is that, on Linux, the distros usually provide a separate package for a user to install Wine's debug symbols. From recent work in dbghelp, I'm guessing such a package installs debug symbol files next to the corresponding binary or in a .debug subdirectory next to it. Is that correct? > > How do packagers generate such separate debug symbol files? I think they either: a) use split DWARF (-gsplit-dwarf option to GCC/Clang), which will give you *.dwo files; or b) use objcopy(1) to extract the .debug_* sections from the final binaries into *.debug files. I suspect it’s the second one; split DWARF (aka DWARF Fission) is relatively new, so I don’t think it’s widely used yet. > How does this interact with stripping during building for the non-debug-symbol, normal Wine package? Wine doesn’t run strip(1) until install time. That’s why we set the STRIPPROG environment variable: if install(1) is GNU install, it’ll pick that up and run the specified strip(1) program on the installed copies of any binaries. This gives packagers time to objcopy(1) the DWARF data before it’s stripped away. > > The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. First, I’ll tell you that, under certain circumstances, it’s possible to get GCC or Clang to invoke dsymutil(1) for you. I haven’t yet completely worked out what those circumstances are—so far, I know that it will do this if you compile and link in one step, but I don’t know how to get it to do this automatically when linking objects with a __DWARF segment. The other thing I’ll tell you is that, since strip(1) isn’t run until install time (and, in fact, probably won’t be run at all on Mac OS since we often use BSD install(1) there), you should be able to run dsymutil(1) at any time up to ‘make install’. > A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. It’s actually possible to read the DWARF data out of the object files (if they’re still around). Both GDB and LLDB do this in the absence of a dSYM companion bundle/file. This is easier said than done, though. If you go this route, you’ll need to relocate the object files’ DWARF data (basically, doing what dsymutil(1) does) before making them available to clients. Chip

June 25, 2015

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)

by Kyle Auble

On 06/24/2015 08:18 AM, Austin English wrote: > > On Jun 21, 2015 2:58 AM, "Kyle Auble" <kyle.auble(a)zoho.com > <mailto:kyle.auble(a)zoho.com>> wrote: > > In the end though, beyond just adding more comments to the bottom of > > the page, I couldn't figure out how anyone earns the rights necessary > > to fix tags or recategorize bugs. I even tried emailing the Bugzilla > > admin to ask but never heard back. Honestly, beyond some of the > > developers and site admins, whom I assume have elevated rights across > > WineHQ, I still don't know who processes the bug reports. > > I didn't realize there was a Bugzilla admin email alias, I've asked > Jeremy Newman to add me, so now someone active is watching it :) > Cool, and I just realized that it was Jeremy Newman I had been talking to when I was working on the webpage (it's been a while). Either way, to both Jeremy-s and everyone else, keep up the good work. > > For future reference though, if in doubt, email wine-devel or ask on > #winehackers. > Will do, and to be fair, unless it's a critical life goal, I'm not the most persistent person so I probably should have asked around more. Quick question about #winehackers etiquette: if I can't be on all the time and want to use an IRC bouncer, is it ok to spread out conversations over time? Or is that seen as rude; should I only keep conversations going so long as they're relatively active? > > (If you still need permission to triage, send me an email, though I > won't have a chance to do so for a few days, currently traveling.) > I'm going through a move right now, but when things are more stable, I might email you then. I also just realized that even without triage permissions, maybe I could have still emailed to check in with reporters about abandoned bugs (I don't remember if standard rights let you email other users). First though, I might try to get a good grip on building and linking multiarch wine, then see if I can streamline it at all (I know I complained about that in particular, but I can get things done if I focus so I should code, not kvetch). - Kyle

June 25, 2015

Re: Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

by Peter Dolding

On Wed, Jun 24, 2015 at 9:42 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > In addition to being the popular Win32/Win64 PE executable format, > .exe files can also be DOS 16 bit ME or NE executables, OS/2 32 bit LE > executables, Win16 NE executables, as well as contain .NET code in the > PE format. It's thus not even clear that Wine should open .exe files, > as at least Mono and DOSBOX are better candidates for some of them. This is a reason todo why I am suggesting. By adding a exe.mainfest with wine data or exe.winemainfest file marks the application as clearly to be opened by wine. Technically Win32/Win64, Win16 NE Dos ME or NE or .Net code could have to be opened with wine. Now out of these list Dos ME or NE and .Net at times should not be run as wine and some must be run in wine or you break programs. There is no marker. Yes part of the wine data in a manifest will have to include flag this is not wine. Also just using MINE type does not tell you want WINEPREFIX the application owns to. > Additionally on the desktop we can use wine.desktop to open .exe files > via MIME type match without needing root permissions to set this up, > so I am not sure why binfmt-misc is necessary. > The reason why binfmt-misc format is failing is it is only a MIME match. So the wine.desktop has all the same issues as binfmt-misc and a extra weakness. Part of the reason why binfmt-misc requires root to set it up is the fact it can assign permissions like file capabilities and LSM attributes from what is recorded on the .exe file. The.desktop solution cannot do this. The result of using wine.desktop and .desktop files instead of being operational with binfmt-misc is the use of CAP_NET_RAW and CAP_NET_BIND_SERVICE on the wineloader program instead of on the .exe files themselves. Yes setting up binfmt-misc requires root. But binfmt-misc is where non native Linux applications requiring Linux security permissions should start their execution path. I do not have windows to test with and I need someone to test is I can place non Microsoft schema in a .mainfest file without risking major trouble. Or someone suggest another way I can tag the executable so the executable can in fact be run the correct solution every single time. Really the MINE type usage by .desktop to run wine should disappear for Linux other than to tell the system to directly execute the exe. Even .desktop files to run programs under Linux should become super simple. Path to executable as enough. All the extra complexity in the .desktop files for Linux is a bug. Peter Dolding > > On Tue, Jun 23, 2015 at 8:44 AM, Peter Dolding <oiaohm(a)gmail.com> wrote: >> For binfmt-misc to be workable a few things need to be known. >> >> 1) What version of wine >> 2) What wineprefix >> 3) What setting overrides. >> >> None of these can be done by environmental vars because binfmt-misc >> might be directly executing the file. >> >> Windows compadiblity mode does not use the registry like wine does. >> Instead it done in two horible halves. >> >> Half 1. The application manifest file. The mainfest file may be >> embedded in the .exe file or be .exe.mainfest >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85… >> Yes this is where you set what version of Windows application was >> designed to run with. So running XP mode on Windows 7 is here. >> >> Half 2. Application Compatilibity Database >> This is where it gets horible using shims on particular executables to >> make broken executables work. Also when this gets too large starts >> slowing windows down as it searching the database to make applications >> work. Yes reason some old applications don't work with Windows 10 >> that worked with 7 is that their entries were deleted from this >> database. >> >> To solve the problem I think we could get away with just Half the >> manifest can include library overrides and some windows configuration >> tweaks. But we have problems the include library information wine >> needs because of native and built-in libraries. Due to the fact wine >> is running on Linux and other OS's some of the configuration tweaks >> are going to be wine dependant. So we need another schema. >> >> >> http://wiki.winehq.org/UsefulRegistryKeys >> Because if Microsoft manifest would tolerate alien schema really >> everything under software\wine\appdefaults could be moved from the >> registry to the manifest. Advantage 1 this can be write protected >> per application and second advantage possibility of embedding in the >> exe itself. >> >> >> Also for binfmt-misc support have in the schema the means to record >> wineprefix and wine to use. So the program starting wine >> applications by binfmt-misc looks for either a mainfest or a >> winemainfest file in the same directory as the exe to see what wine >> environment the application should be running with. If there is no >> configured environment possibly ask user what wineprefix they do what >> to run the application with. >> >> What I do not know is if Microsoft application manifest file will >> tolerate an alien schema. Don't have different versions of Windows >> to test if Microsoft application manifest with a alien schema parts >> works or just causes windows to throw error or just results in the >> manifest being complete ignored. >> >> Now if Microsoft application manifest will not tolerate alien I have >> to ask would creating own own like exe.winemainfest be acceptable. >> >> I do hope Microsoft application manifest will tolerate alien because >> it would be really useful to have applications with a manifest a >> values saying what versions of wine they were tested with by the >> maker. Currently there is no way for a application vendor to record >> in the application they tested with wine. >> >> A lot of ways putting what shim modifications the application need in >> the manifest would also remove having to look up a huge database. >> >> Getting binfmt-misc working also will remove having to use setcap on >> wineloader instead of the .exe. Also would make if someone set a >> capicapity limitation by logind not break every wine application just >> because a few application where needing privileged operation.. >> >> So this alteration would be getting closer to how Windows does stuff >> and in the process making Linux integration better. >> >> Peter Dolding >> >>

June 25, 2015

When/how to build separate debug symbol files

by Ken Thomases

Hi, I'm investigating how to best make Wine build and install debug symbol files on OS X. My understanding is that, on Linux, the distros usually provide a separate package for a user to install Wine's debug symbols. From recent work in dbghelp, I'm guessing such a package installs debug symbol files next to the corresponding binary or in a .debug subdirectory next to it. Is that correct? How do packagers generate such separate debug symbol files? Is it a special option (make target?) in Wine's build process? Or is it a post-processing step after Wine is built and installed to a staging directory? How does this interact with stripping during building for the non-debug-symbol, normal Wine package? For what it's worth, I'm working on make dbghelp support DWARF-2 debug info on OS X <https://bugs.winehq.org/show_bug.cgi?id=22384>. On OS X, the normal link step does not transfer the DWARF-2 debug info from the object files to the file binary. Rather, you have to execute a separate command, dsymutil, to "link" the debug info, but that ends up in a separate file, not the binary. So, the first part is figuring out when to invoke dsymutil and where to put the debug symbol file. The second part is having dbghelp find that debug symbol file. I think I have a handle on the second part. The first part is what I'm trying to figure out. The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. Thanks, Ken

June 24, 2015

Re: d3dcompiler: Share the source with d3dcompiler_46

by Matteo Bruni

2015-06-24 12:15 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > diff --git a/dlls/d3dcompiler_46/Makefile.in b/dlls/d3dcompiler_46/Makefile.in > index 08c5145..41c98f7 100644 > --- a/dlls/d3dcompiler_46/Makefile.in > +++ b/dlls/d3dcompiler_46/Makefile.in > @@ -1,6 +1,24 @@ > MODULE = d3dcompiler_46.dll > +IMPORTS = dxguid uuid > +EXTRALIBS = $(LIBWPP) > +EXTRADEFS = -D_D3DCOMPILER_VER=46 That define isn't used yet, right? I guess you can keep it around but maybe call it D3D_COMPILER_VERSION since there is such a define in recent d3dcompiler.h from the SDK. Or just drop it for the time being and reintroduce it when there will be a need to distinguish the version we're compiling for from the shared code. Otherwise it looks fine to me. Maybe rename d3dcompiler_43_main.c to just main.c? That change can be a separate patch.

June 24, 2015

Re: [PATCH] cmd: fix invalid "else if" execution (try2)

by Thomas Faller

Hello, these test failures weren't triggered by my patch. - Thomas Am 24.06.2015 um 22:23 schrieb Marvin: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=14664 > > Your paranoid android. > > > === wxppro (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === w2003std (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1368 (got 'value2', wanted '2set1endvalue1') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1369 (got 'C:\Documents and Settings\Administrator\My Documents\foobar\foodir2', wanted '@drive@@path(a)foobar\foodir3') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1370 (got 'value1', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1371 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1372 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === wvistau64 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > > === w8 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--------'', wanted ''--a------'@or_broken@'%~ai'') > > === wvistau64 (64 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > >

June 24, 2015