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

Re: MSVCP60.dll

by Bruno Jesus

On Fri, Jun 22, 2012 at 3:38 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: > If anyone thinks of any useful information I'll add it to the bug report. > ... > BACKTRACE FOLLOWS:- > Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 You could add a comment there instead of opening a new bug that could end up as being duplicate. I suggest you to get a new backtrace with wine debug symbols installed (if possible in wine 1.5.7). Best wishes, Bruno

June 22, 2012

Re: MSVCP60.dll

by John Emmas

On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote: > > On 06/15/2012 06:22 AM, John Emmas wrote: >> >> 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). > That is fairly trivial to figure out. Start your app with Wine on the > command line and it will crash with an exception: > Call from <address> to unimplemented function MSVCP60.<function> > > Once you have those please open a bug on http://bugs.winehq.org/ for > them. > Thanks Michael, That version number should have been 1.3.35 BTW, not 1.5.35. I'll file a bug report tomorrow but in the meantime it looks like the missing function is std::ios_base::Init() (it's probably the constructor for the Init class). I'm going from a backtrace that I got when I tried Crossover Linux (which exhibited the same problem). If anyone thinks of any useful information I'll add it to the bug report. John BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b83aed2 ESP:0033fcc8 EBP:0033fd2c EFLAGS:00000212( - -- I -A- - ) EAX:7b827985 EBX:7b8961e8 ECX:00000000 EDX:80000100 ESI:80000100 EDI:004e120c Stack dump: 0x0033fcc8: 0033fd4c 00000008 7bca774c 80000100 0x0033fcd8: 00000001 00000000 7b83aed2 00000002 0x0033fce8: 7e50f460 7e51415b 00110000 00000000 0x0033fcf8: 00000000 7ee6863c 7ee6863c 00431870 0x0033fd08: 0033fd58 7ee186e9 0000000d 004ef298 0x0033fd18: 7ee6863c 7e090000 7b83ae8a 7ee6863c Backtrace: =>0 0x7b83aed2 in kernel32 (+0x2aed2) (0x0033fd2c) 1 0x7e50f3f8 in msvcp60 (+0x2f3f7) (0x0033fd5c) 2 0x7e4f4065 in msvcp60 (+0x14064) (0x0033fdc0) 3 0x00433f55 in ardourxchange (+0x33f54) (0x0033fdc0) 4 0x004a9fde in ardourxchange (+0xa9fdd) (0x0033fe70) 5 0x7b85b23c call_process_entry+0xb() in kernel32 (0x0033fe88) 6 0x7b85c40f in kernel32 (+0x4c40e) (0x0033fec8) 7 0x7bc72a70 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 8 0x7bc7547d call_thread_func+0x7c() in ntdll (0x0033ffa8) 9 0x7bc72a4e RtlRaiseException+0x21() in ntdll (0x0033ffc8) 10 0x7bc4b8fe call_dll_entry_point+0x61d() in ntdll (0x0033ffe8) 0x7b83aed2: subl $4,%esp Modules: Module Address Debug info Name (73 modules) PE 340000- 352000 Deferred zlib1 PE 400000- 5e1000 Export ardourxchange PE 5f0000- 6c9000 Deferred iconv PE 10000000-100ee000 Deferred libxml2 PE 5f400000-5f4f2000 Deferred mfc42 PE 6f140000-6f198000 Deferred libsndfile-1 ELF 7b800000-7ba16000 Dwarf kernel32<elf> \-PE 7b810000-7ba16000 \ kernel32 ELF 7bc00000-7bcc4000 Dwarf ntdll<elf> \-PE 7bc10000-7bcc4000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7e086000-7e0b9000 Deferred uxtheme<elf> \-PE 7e090000-7e0b9000 \ uxtheme ELF 7e0fc000-7e102000 Deferred libxfixes.so.3 ELF 7e1d8000-7e1f9000 Deferred libexpat.so.1 ELF 7e1f9000-7e224000 Deferred libfontconfig.so.1 ELF 7e224000-7e22d000 Deferred libxi.so.6 ELF 7e22d000-7e232000 Deferred libxrandr.so.2 ELF 7e232000-7e23b000 Deferred libxrender.so.1 ELF 7e23b000-7e241000 Deferred libxxf86vm.so.1 ELF 7e241000-7e262000 Deferred imm32<elf> \-PE 7e250000-7e262000 \ imm32 ELF 7e262000-7e37f000 Deferred libx11.so.6 ELF 7e37f000-7e38e000 Deferred libxext.so.6 ELF 7e38e000-7e3a7000 Deferred libice.so.6 ELF 7e3a7000-7e3b1000 Deferred libsm.so.6 ELF 7e3b1000-7e446000 Deferred winex11<elf> \-PE 7e3c0000-7e446000 \ winex11 ELF 7e446000-7e4b2000 Deferred libfreetype.so.6 ELF 7e4b5000-7e4bf000 Deferred libxcursor.so.1 ELF 7e4d2000-7e569000 Dwarf msvcp60<elf> \-PE 7e4e0000-7e569000 \ msvcp60 ELF 7e569000-7e5df000 Deferred rpcrt4<elf> \-PE 7e570000-7e5df000 \ rpcrt4 ELF 7e5df000-7e6e6000 Deferred ole32<elf> \-PE 7e600000-7e6e6000 \ ole32 ELF 7e6e6000-7e7dd000 Deferred comctl32<elf> \-PE 7e6f0000-7e7dd000 \ comctl32 ELF 7e7dd000-7e9ee000 Deferred shell32<elf> \-PE 7e7f0000-7e9ee000 \ shell32 ELF 7e9ee000-7ea58000 Deferred shlwapi<elf> \-PE 7ea00000-7ea58000 \ shlwapi ELF 7ea58000-7eb17000 Deferred gdi32<elf> \-PE 7ea60000-7eb17000 \ gdi32 ELF 7eb17000-7ec57000 Deferred user32<elf> \-PE 7eb30000-7ec57000 \ user32 ELF 7ec57000-7ec7c000 Deferred mpr<elf> \-PE 7ec60000-7ec7c000 \ mpr ELF 7ec7c000-7ec8f000 Deferred libz.so.1 ELF 7ec8f000-7ecfe000 Deferred wininet<elf> \-PE 7eca0000-7ecfe000 \ wininet ELF 7ecfe000-7ed5f000 Deferred advapi32<elf> \-PE 7ed10000-7ed5f000 \ advapi32 ELF 7ed5f000-7ed72000 Deferred libresolv.so.2 ELF 7ed76000-7ed7a000 Deferred libxinerama.so.1 ELF 7ed7a000-7ed92000 Deferred version<elf> \-PE 7ed80000-7ed92000 \ version ELF 7ed92000-7edb3000 Deferred iphlpapi<elf> \-PE 7eda0000-7edb3000 \ iphlpapi ELF 7edb3000-7ede4000 Deferred ws2_32<elf> \-PE 7edc0000-7ede4000 \ ws2_32 ELF 7ede4000-7ee72000 Deferred msvcrt<elf> \-PE 7ee00000-7ee72000 \ msvcrt ELF 7efba000-7efe0000 Deferred libm.so.6 ELF 7efe2000-7efe6000 Deferred libxau.so.6 ELF 7efe6000-7f000000 Deferred wsock32<elf> \-PE 7eff0000-7f000000 \ wsock32 ELF b7c31000-b7c37000 Deferred libxdmcp.so.6 ELF b7c39000-b7c3d000 Deferred libdl.so.2 ELF b7c3d000-b7d6b000 Deferred libc.so.6 ELF b7d6b000-b7d83000 Deferred libpthread.so.0 ELF b7da3000-b7ee5000 Dwarf libwine.so.1 ELF b7ee6000-b7f03000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 winewrapper.exe 00000009 0 0000000c services.exe 0000001d 0 0000001c 0 00000016 0 00000015 0 00000013 0 0000000e 0 0000000d 0 00000010 winedevice.exe 0000001a 0 00000017 0 00000012 0 00000011 0 00000018 plugplay.exe 0000001e 0 0000001b 0 00000019 0 0000001f explorer.exe 00000020 0 00000021 (D) C:\Program Files\ArdourXchange\ArdourXchange.exe 00000022 0 <== System information: Wine build: wine-1.4-6831-gf832abc Platform: i386 Host system: Linux Host version: 2.6.19-4-rt

June 22, 2012

Re: [1/2] windowscodecs: Implement GetPreview and GetThumbnail in the TIFF decoder.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > 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. That was to make WICExplorer happy. After looking at its source I've found that it doesn't always check return values of GetThumbnail and GetPreview, but checks for returned interface pointer instead. I'll send a proper patch. Thanks. -- Dmitry.

June 22, 2012

Re: [1/2] windowscodecs: Implement GetPreview and GetThumbnail in the TIFF decoder.

by Vincent Povirk

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.

June 22, 2012

RE: Incompatibility in Kernel32

by robert.van.herk＠serioustoys.com

> > Is there any reason that you call DeleteFile() on a still being opened file? > > That's the whole point of this test. The observed behavior is that you can pass a > filename to MsiRecordSetStream, successfully delete the file, and keep on using the > stream. I think DeleteFile on a opened file is officially allowed in Windows. Although the MS documentation is vague: <QUOTE> The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. </QUOTE> These statements seem to be a bit contradictive to me, so that's why I though I'd write a test to see how Windows actually behaves, and then I found this incompatibility. Regards, Robert

June 22, 2012

Re: d3dx9_36: Implentation of D3DXSHDot

by Alexandre Julliard

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

June 22, 2012

Re: d3dx9_36 [patch 4 of 4, try 2]: Save multiplications

by Alexandre Julliard

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

June 22, 2012

Re: wintrust/tests: Fix build with MSVC.

by Thomas Faber

On 2012-06-21 23:47, David Laight wrote: > On Thu, Jun 21, 2012 at 12:56:43PM +0200, Thomas Faber wrote: >> On 2012-06-21 12:34, Dmitry Timoshkov wrote: >>> Thomas Faber <thfabba(a)gmx.de> wrote: >>>> FIELD_OFFSET isn't constant "enough". >>> >>> The problem is not with FIELD_OFFSET, but with applying shift and mask >>> operations to a constant. >> >> You're right, it's actually a combination of multiple factors. I'm not sure >> what exactly its problem is - the gist is, FIELD_OFFSET cannot reliably be >> assumed constant. >> >> E.g. the following code only complains about c4: >> >> struct a { >> char a; >> int b[5]; >> int c; >> }; >> int c1 = (int)&(((struct a *)0)->a) << 8; >> int c2 = (int)&(((struct a *)0)->b[0]); >> int c3 = (int)&(((struct a *)0)->b[0]) + 1; >> int c4 = (int)&(((struct a *)0)->b[0]) << 8; > > This is a bug in the microsoft C compiler. > It won't let you do multiply or divide offsetof(struct, array_member[index]) > by anything and still get a compile-time constant. > The C language requires offsetof() be a compile-time constant, so this > ought to be allowed. > I couldn't find anything that looked like 'offsetof' that would generate > a real compile-time constant. > > I can't remember whether it is 'constant enough' to let you do: > static char fubar[offsetof(struct a, b[3])]; Yeah, after some reading it seems clear that it's only with array[index] as a member designator. >From reading, it also seems that offsetof should indeed be constant enough for all of these purposes - but I won't consider myself qualified to nitpick on the contents of the standard in this regard. In conclusion, assuming working around MSVC bugs like this is worth the effort (which I do think it is), FIELD_OFFSET(struct, array) + index * sizeof(type) can be used as a compatible replacement. Seems a workable alternative to me. I've submitted a new patch accordingly. -Tom

June 22, 2012

Re: d3dx9_36 [patch 1 of 4, try 2]: Implemetation of D3DXSHDot

by Dmitry Timoshkov

Hello, Please follow http://wiki.winehq.org/SubmittingPatches instructions for naming patches when sending a patch series. Usually 'git format-patch -n' will do it for you. Otherwise testbot won't recognize the series. -- Dmitry.

June 22, 2012

Re: d3dx9_36 [patch 3 of 4, try 2]: Implemetation of D3DXSHMultiply2

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

June 22, 2012