January 2003 - Wine-Devel - list.winehq.org

Some ddraw / GDI palette problem

by Lionel Ulmer

Hi all, In 'old' D3D games, a lot of textures are created paletted... And each of these texture has its own DDraw palette object. And thus each has some GDI memory allocated. This means that after some time, we run out of GDI Heap space due to all these palettes created there : trace:ddraw:Main_DirectDraw_CreatePalette (0x4038ff48)->(00000044,0x406b1340,0x406b1978,(nil)) trace:palette:CreatePalette entries=256 err:local:LOCAL_GetBlock not enough space in GDI heap 01b7 for 1052 bytes Now that problem is fixed in one game (it was due to some bad reference counting is some D3D code fixed in patch 79), but if ever it happens in yet another game, is it possible to increase this space ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 4, 2003

Re: Windows Debugging Tools under Wine: "Could not inject logging thread into process"

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > Ah, but there I hit a roadblock; it gives the error "Could not inject > logging thread into process". Very likely that's due a stubbed CreateRemoteThread. > Shucks, shouldn't wine support > advanced windows debugging techniques? :-) Sure, when somebody implements all the missing functionality in Wine :-) P.S. Have you managed to run logger and logviewer under Windows? -- Dmitry.

Jan. 4, 2003

Windows Debugging Tools under Wine: "Could not inject logging thread into process"

by Dan Kegel

Dmitry Timoshkov recommended the MS Debugging Tools for Windows http://www.microsoft.com/ddk/debugging to log API calls. Foolish me, I tried them under Wine. Here's what I had to do to install them. They don't quite work under Wine, but only because of a fundamental problem; all the superficial ones were easily solved :-) 0. To fix the "This program may only be used with Microsoft Windows" problem, click "I Agree" on the license agreement. 1. To fix the "This program requires Windows NT or later" problem, edit ~/.wine/config to specify [Version] "Windows"="nt40" 2. to fix the "can't execute msiexec.exe" error, copy /dos/c/windows/system/msi* ~/c/windows/system 3. To fix the "Error 2352: Couldn't initialize cabinet file server. The required file 'cabinet.dll' may be missing." error, copy /dos/c/windows/system/cabinet.dll ~/c/windows/system and edit ~/.wine/config to specify [DLLOverrides] "cabinet" = "native,builtin" OK, now it installs. I then tried using it under Wine to log the system calls made by msvc4.0's installer, like this: wine 'c:\dtfw\logger.exe' d:setup 4. To fix the "can't load winexts.dll" problem (which is a strange one -- it is looking in windows/system, but only installed the dlls into c:\dtfw): cp ~/c/dtfw/exts/winexts.dll ~/c/windows/system 5. To fix the "can't open c:\windows\system\manifests\main.h" problem, cp -r ~/c/dtfw/manifests ~/c/windows/system/manifests/ (again, why weren't they installed there?) Ah, but there I hit a roadblock; it gives the error "Could not inject logging thread into process". Shucks, shouldn't wine support advanced windows debugging techniques? :-) - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: argv[0] needs to be an absolute path

by Dan Kegel

Uwe Bonnes wrote: >>>>>>"Dan" == Dan Kegel <dank(a)kegel.com> writes: > > Dan> The C program main(int argc, char **argv) { puts(argv[0]); } > Dan> outputs an absolute path on Windows, but sometimes outputs a > Dan> relative path on Wine. This causes the commandline $ wine d:setup > Dan> to fail to find its files properly if it uses the basename of > Dan> argv[0]. One example of this is msvc4.0 (although it only tries > Dan> this if an earlier method fails, so there's another bug lurking). .. > > Dan> The same problem exists for programs launched from other wine > Dan> programs, e.g. from inside wcmd. That's another code path, and I > Dan> couldn't find a one-line fix for that one. - Dan > > Did you check that it is CreateProcess that adds the absolute path? I would > guess the MS C Library will do it. Not quite sure how to check. Can you suggest a way? > Fiddling with CreateProcess needs good throught. I have not as yet fiddled with CreateProcess, only with the code that starts off the initial process when you run Wine, I think. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Make argv[0] an absolute path so 'wine d:setup' works (2nd try)

by Dan Kegel

My last version broke the existing regression tests. This one doesn't, and I've added a regression test to make sure argv[0] is an absolute path. This patch should be reviewed carefully, as I don't really understand Wine's internals yet. Changelog: * scheduler/process.c: make argv[0] absolute so 'wine d:setup' works * dlls/kernel/tests/process.c: verify that argv[0] is absolute and contains drive letter Copyright 2003, Dan Kegel. LGPL. -- Dan Kegel Linux User #78045 http://www.kegel.com Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.205 diff -d -u -r1.205 process.c --- scheduler/process.c 5 Dec 2002 19:56:15 -0000 1.205 +++ scheduler/process.c 4 Jan 2003 04:13:31 -0000 @@ -577,6 +577,7 @@ { char error[100], *p; DWORD stack_size = 0; + char main_exe_name_copy[MAX_PATH]; /* Initialize everything */ if (!process_init( argv )) exit(1); @@ -610,6 +611,10 @@ MESSAGE( "%s: cannot open builtin library for '%s': %s\n", argv0, main_exe_name, error ); ExitProcess(1); } + + /* absolutify argv[0] so 'wine d:setup' works */ + strcpy(main_exe_name_copy, main_exe_name); + argv[0] = main_exe_name_copy; switch( MODULE_GetBinaryType( main_exe_file )) { Index: dlls/kernel/tests/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/process.c,v retrieving revision 1.7 diff -d -u -r1.7 process.c --- dlls/kernel/tests/process.c 18 Dec 2002 20:51:33 -0000 1.7 +++ dlls/kernel/tests/process.c 4 Jan 2003 04:13:32 -0000 @@ -624,6 +624,7 @@ char buffer[MAX_PATH]; PROCESS_INFORMATION info; STARTUPINFOA startup; + const char *pstr; memset(&startup, 0, sizeof(startup)); startup.cb = sizeof(startup); @@ -640,6 +641,12 @@ WritePrivateProfileStringA(NULL, NULL, NULL, resfile); okChildInt("Arguments", "argcA", 4); + pstr = getChildString("Arguments", "argvA0"); + ok(pstr != NULL, "expected non-null argv[0]"); + if (pstr) { + ok(pstr[1] == ':', "expected drive letter in argv[0], got %s", pstr); + ok(pstr[2] == '\\', "expected absolute path in argv[0], got %s", pstr); + } okChildString("Arguments", "argvA3", "C:\\Program Files\\my nice app.exe"); okChildString("Arguments", "argvA4", NULL); okChildString("Arguments", "CommandLineA", buffer);

Jan. 4, 2003

Re: GlobalAlloc GlobalReAlloc problem

by Michael Stefaniuc

On Sat, Jan 04, 2003 at 02:54:12AM +0100, Michael Stefaniuc wrote: > Do we want to mimic the GlobalAlloc/GlobalReAlloc behaviour of Windows > (the DiMage Viewer dosn't corrupt the images at least on Win98 and it's > the same binary for Win2000 too)? Could be that some other broken, real > life programs are dependent of that behaviour). > At a quick glance i don't know how to fix GlobalAlloc/GlobalReAlloc > without breaking it. I'll do a bugzilla report but want to save me the > work if it will get anyway a WONTFIX resolution. Well, it wasn't so hard to fix as I first thought. And the patch isn't too intrusive, it aligns only the storage needed for the HGLOBAL on an 8byte boundary. The only disatvantage is we waste 1 byte per memory region allocated with GMEM_MOVEABLE but this should be realy tolerable. Alexandre, i could replace the definition of HGLOBAL_STORAGE with something like: #define HGLOBAL_STORAGE ROUND_SIZE(sizeof(HGOBAL)) and use the ROUND_SIZE macro from dlls/ntdll/heap.c . The two magics "-2" in the patch could be also replaced by HGLOBAL_STORAGE/sizeof(HGOBAL) License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - the Minolta DiMAGE Image Viewer relies on Global{,Re}Alloc called with the GMEM_MOVEABLE flag set, to allocate the exact specified size and no byte more when size = 8*k, where k=1,2,3,4.... . To achieve this allign the storage needed for the HGLOBAL in the heap to 8byte boundary. bye michael P.S.: I'll redo the dlls/kernel/tests/alloc.c to have a test case -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 4, 2003

Re: [D3D 72] Various stuff to get Monkey4 working in D3D mode

by Tony Lambregts

Lionel Ulmer wrote: > >PS: I updated the d3d_status.html page (http://www.bbrox.org/d3d_status.html) > > > <nit>The links to the screenshots for Aliens vs predator demo are local ie: file:///home/ulmer/Wine/avp_1.png</nit> -- Tony Lambregts

Jan. 4, 2003

GlobalAlloc GlobalReAlloc problem

by Michael Stefaniuc

Hello, the Minolta "DiMAGE Image Viewer" (Minolta Dimage digicams use a wider gamut colorspace and to transform that to sRGB you need this tool) makes strange ASSumptions about Global{Alloc,ReAlloc,Size} in it's jpeg exporter (JPEG.GEX, a dll de facto) thus corrupting the output jpg if it's bigger then 1 MB. Deducing from the +relay,+global,+heap debug output it does basicaly this (in pseudo C code): LPVOID ptr; hGlobal = GlobalAlloc(GMEM_MOVEABLE | GMEM_ZEROINIT, 0); still_needed_space = size_of_output_jpeg; while (still_needed_space > 0) { old_size = GlobalSize(hGlobal); want = (still_needed_space / 0x100000) ? 0x100000 : still_needed_space; still_needed_space -= want; GlobalReAlloc(hGlobal, old_size + want, GMEM_ZEROINIT); ptr = GlobalLock(hGlobal) + old_size; GlobalUnlock(hGlobal) Do_the_work using ptr } WriteFile(output_jpg_h, GlobalLock(hGlobal), size_of_output_jpeg, ...) The problem is that msdn states for GlobalAlloc (i implicitly assume that it applies for GlobalReAlloc too) that the memory is alligned on an 8byte boundary and that it allocates "at least" the requested number of bytes. That means more memory can be allocate and even msdn recommends to check the actual allocated size with GlobalSize. With the above code wine allocates 0x100004 bytes for the first call to GlobalReAlloc thus inserting four 0 bytes at position 0x100000 and cutting 4 bytes from the end of the jpeg. And this leads to corrupted jpeg's. Here are some snippets from the debug log to demonstrate it: 082c5d08:Call kernel32.GlobalAlloc(00000042,00000000) ret=46bd004a trace:global:GlobalAlloc () flags=0042 trace:heap:RtlAllocateHeap (0x40240000,00000002,00000080): returning 402baec0 08076498:Ret ntdll.RtlAllocateHeap() retval=402baec0 ret=40731b96 08076498:Call ntdll.RtlFreeHeap(40240000,00000000,402baec0) ret=40731b69 trace:heap:RtlAllocateHeap (0x40240000,00000002,00000018): returning 402b64f8 082c5d08:Ret kernel32.GlobalAlloc() retval=402b64fa ret=46bd004a [snip] 082c5d08:Call kernel32.GlobalSize(402b64fa) ret=46bce386 082c5d08:Ret kernel32.GlobalSize() retval=00000000 ret=46bce386 082c5d08:Call kernel32.GlobalReAlloc(402b64fa,00100000,00000040) ret=46bce39b trace:heap:HEAP_FindFreeBlock created new sub-heap 475c0000 of 00100040 bytes for heap 40240000 trace:heap:RtlAllocateHeap (0x40240000,0000000a,00100008): returning 475c0020 082c5d08:Ret kernel32.GlobalReAlloc() retval=402b64fa ret=46bce39b 082c5d08:Call kernel32.GlobalLock(402b64fa) ret=46bce3bd 082c5d08:Ret kernel32.GlobalLock() retval=475c0024 ret=46bce3bd 082c5d08:Call kernel32.GlobalUnlock(402b64fa) ret=46bce3d3 082c5d08:Ret kernel32.GlobalUnlock() retval=00000000 ret=46bce3d3 [snip] 082c5d08:Call kernel32.GlobalSize(402b64fa) ret=46bce41d trace:heap:RtlSizeHeap (0x40240000,00000002,475c0020): returning 00100008 082c5d08:Ret kernel32.GlobalSize() retval=00100004 ret=46bce41d The first GlobalReAlloc adds 4 (sizeof(HGLOBAL)) to the size (0x100000) and calls RtlAllocateHeap where ROUND_SIZE() increases the size to 0x100008. What makes me wonder is the different behaviour of Global[Re]Alloc regarding the allocated size when it's called without GMEM_MOVEABLE: with whithout GMEM_MOVEABLE GlobalAlloc(size=0) 0 0x18 GlobalAlloc(size=1MB) 0x100004 0x100000 GlobalReAlloc(size=1MB) 0x100004 0x100000 To demonstrate this i did a small patch to dlls/kernel/tests/alloc.c (Still need to install mingw to test it on Windows). Do we want to mimic the GlobalAlloc/GlobalReAlloc behaviour of Windows (the DiMage Viewer dosn't corrupt the images at least on Win98 and it's the same binary for Win2000 too)? Could be that some other broken, real life programs are dependent of that behaviour). At a quick glance i don't know how to fix GlobalAlloc/GlobalReAlloc without breaking it. I'll do a bugzilla report but want to save me the work if it will get anyway a WONTFIX resolution. The version of DiMage Viewer tested is 1.1 and it's not free. Minolta offers only a free upgrade from 2.0 -> 2.1 so I can't test it on a newer version (but i suspect it will still have the bug because the jpeg lib is bought from somebody else and has copyright 1999 whereas the rest is copyright 2001). bye michael P.S.: Not fixing this "bug" wont keep the linux users from enjoying their Minolta DiMage cams without windows because there is a Gimp plugin that can do the color space transformations (and Murphy sei Dank i found this AFTER debugging and finding the problem). -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 4, 2003

Re: Francois's winsock.h patch

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Are you going to apply Francois's winsock.h patch that fixes the > Winelib problems that I encountered on wxWindows? My impression was that it was not ready yet. Francois? -- Alexandre Julliard julliard(a)winehq.com

Jan. 4, 2003

Re: NT4 SP 6a entries

by Greg Turner

On Friday 03 January 2003 12:26 am, Sylvain Petreolle wrote: > On Dec 19, you made a patch to add the SP6a registry key to > winedefault.reg. > > Today, I made a cvs update and imported winedefault.reg into my > registry. > > Trying to install the .NET Framework Package, with nt40 as windows > version, > it says to install SP6a ot higher. > > Are you sure its the right hotfix/is there an another way to check > if SP6a is installed ? I don't know... of course, ultimately, the answer will always be: yes there is another way to find out if it's SP6a :( Anyone able to check my work, however, by comparing against their SP6a box? It's an interesting result. If .net framework is a free download (that doesn't require me to sacrifice my first born to Steve Balmer), then I'll check it out... -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 4, 2003