June 2012 - Wine-devel - list.winehq.org

Building WoW64 packages
by Hilko Bengen 25 Jun '12

25 Jun '12

Hi, after the effort on the Debian wine packages has progressed to a point where it's likely that we'll release wheezy with a stable wine version that is not completely out of date, I'd like to take things a step further. I recently spent some time looking at ways how we could build Debian packages for a shared WoW64 setup similar to what is described in http://wiki.winehq.org/Wine64. We will have to use separate build environments because having 32-bit and 64-bit -dev packages installed at the same time is not possible. Installing a 64-bit package that contains the build tools into a 32-bit environment should be possible, though. >From looking at the build system, things happen in a different way when I run configure for the 32-bit components with --wine64=...: 1. Manpages are not installed (WOW64_DISABLE) 2. --disable-fonts is implied 3. --disable-server is implied, so wineserver is not built. (The 64-bit wineserver is used instead, right?) 4. --disable-tools is implied because the existing build tools are being used. Did I miss anything? Leaving parts out is easy to understand, but how do the build tools that have been built for the x86_64 architecture affect the 32-bit components that are being built with them? Are different paths encoded into libwine? Cheers, -Hilko

2 1

Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress
by Chris Robinson 25 Jun '12

25 Jun '12

On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: > @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) > /* Temporarily disable the context, so we can see that we can't > retrieve functions now. */ wglMakeCurrent(hdc, NULL); > func = wglGetProcAddress("glActiveTextureARB"); > - todo_wine ok(func == NULL, "Function lookup without a context passed, > expected a failure; last error %#x\n", GetLastError()); > + ok(func == NULL, "Function lookup without a context passed, expected a > failure; last error %#x\n", GetLastError()); > wglMakeCurrent(hdc, ctx); > } Does this apply to all functions, or just the ones MS's DLL doesn't implement? I could imagine wlgGetProcAddress still returning functions that are in opengl32.dll without worrying about the driver.

2 1

Re: [3/5] gdiplus: Implement GdipGetPropertyIdList.
by Nikolay Sivov 25 Jun '12

25 Jun '12

On 6/25/2012 14:30, Dmitry Timoshkov wrote: > + > + return hr == S_OK ? Ok : hresult_to_status(hr); > } > No need for special case for S_OK here.

1 0

Re: [3/3] d3drm: Implement IDirect3DRMMeshBuilderX_GetClassName
by Marvin 24 Jun '12

24 Jun '12

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 http://testbot.winehq.org/JobDetails.pl?Key=19493 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [2/3] d3drm: Implement IDirect3DRMLight_GetClassName
by Marvin 24 Jun '12

24 Jun '12

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 http://testbot.winehq.org/JobDetails.pl?Key=19492 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Incompatibility in Kernel32
by robert.van.herk＠serioustoys.com 23 Jun '12

23 Jun '12

Hi group, As I was trying write a fix for msi.dll, I stumbled upon an incompatibility in the kernel. If you open an existing file, FILE_SHARE_DELETE doesn't seem to work in Wine. In Windows, it does. Attached is a minimal test case. I feel hesitation towards starting to hack in kernel32 myself. Though this bug seems to be blocking me to implement msi.dll completely compatible with the MS implementation... Shall I file a bug report? Regards, Robert

4 6

MSVCP60.dll
by John Emmas 22 Jun '12

22 Jun '12

Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far. Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from where they were able to install an alternative version of MSVCP60.dll. My app now gets past the place where it previously crashed although it now crashes further on... :-( It looks as if the MSVC6 runtime module(s) that now come with Wine aren't the same as the ones from v0.9.58. Either they're different versions of the Microsoft DLLs or maybe they're now being implemented by somebody else, perhaps as part of Wine development? Either way, they don't work with my particular app any more. I still have Visual C++6 installed on an old computer, together with both the source code and the (InstallShield) packager for my original app. So is there anything I can do to make this work? For example, do I need to link against a particular version of the MSVC6 runtime? Or do I need to configure my packager so that it specifically distributes the runtime modules that my app linked to? I never did that in the past - because whichever runtime came with Wine seemed to work. Any advice? John

4 7

Re: [1/2] windowscodecs: Implement GetPreview and GetThumbnail in the TIFF decoder.
by Vincent Povirk 22 Jun '12

22 Jun '12

According to MSDN, GetPreview isn't supported on any decoder except WMPhoto, and if that's true it should probably be returning WINCODEC_ERR_UNSUPPORTEDOPERATION. And why bother with GetThumbnail if you're not going to do it properly? At least check whether a thumbnail exists in the image before returning something.

2 1

Re: d3dx9_36: Implentation of D3DXSHDot
by Alexandre Julliard 22 Jun '12

22 Jun '12

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > +static void test_D3DXSHDot(void) > +{ > + unsigned int i; > + FLOAT a[64], b[64], got; > + CONST FLOAT expected[] = > + { 0.0f, 0.0f, 17.0f, 222.0f, 1300.0f, 5050.0f, 15225.0f, 38612.0f, 86352.0f, }; > + > + for (i = 0; i < 64; i++) > + { > + a[i] = (FLOAT)i; > + b[i] = (FLOAT)i + 0.5f; > + } You should start with a non-zero value to tests orders 0 and 1 properly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx9_36 [patch 4 of 4, try 2]: Save multiplications
by Alexandre Julliard 22 Jun '12

22 Jun '12

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > @@ -1971,11 +1971,13 @@ FLOAT *WINAPI D3DXFloat16To32Array(FLOAT *pout, CONST D3DXFLOAT16 *pin, UINT n) > > FLOAT* WINAPI D3DXSHAdd(FLOAT *out, UINT order, const FLOAT *a, const FLOAT *b) > { > - UINT i; > + UINT i, sq_order; > > TRACE("out %p, order %u, a %p, b %p\n", out, order, a, b); > > - for (i = 0; i < order * order; i++) > + sq_order = order * order; > + > + for (i = 0; i < sq_order; i++) > out[i] = a[i] + b[i]; There's no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

1 0