September 2007 - Wine-devel

build problem on amd64
by Dave Phillips 07 Sep '07

07 Sep '07

Greetings, I hope I have the right list. I'm trying to build Wine 0.9.44 under 64Studio, a Debian-based distribution. CPU is an AMD64, GCC is 4.1.2. Configure and make depend report no errors (btw, I ran a simple ./configure, no options), but when I run make I receive these errors : gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -D__i386__ -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:38: Error: suffix or operands invalid for `push' {standard input}:39: Error: suffix or operands invalid for `push' {standard input}:46: Error: suffix or operands invalid for `pop' {standard input}:47: Error: suffix or operands invalid for `pop' make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/dlphilp/src/wine-0.9.44/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/dlphilp/src/wine-0.9.44/libs' make: *** [libs] Error 2 Is there a fix for this problem ? Please advise, thanks. Best regards, Dave Phillips

1 0

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite
by Dmitry Timoshkov 07 Sep '07

07 Sep '07

"Vincent Povirk" <madewokherd(a)gmail.com> wrote: > fixes bug 9523, Knytt Stories installer fails > +/*********************************************************************** > + * SHPathPrepareForWriteA (SHELL32.@) > + */ > +HRESULT WINAPI SHPathPrepareForWriteA(HWND hwnd, IUnknown *modless, LPCSTR path, DWORD flags) > +{ > + WCHAR wpath[MAX_PATH]; > + MultiByteToWideChar( CP_ACP, 0, path, -1, wpath, MAX_PATH); > + return SHPathPrepareForWriteW(hwnd, modless, wpath, flags); You are still using a buffer of a fixed size. > + /* cut off filename if necessary */ > + if (flags & SHPPFW_IGNOREFILENAME) > + { > + last_slash = StrRChrW(path, NULL, '\\'); StrRChrW is a shlwapi export. Since shlwapi.dll is just mostly a wrapper/helper, and it imports shell32, that would create a circular dependency. I already suggested to use strrchrW here. > + temppath = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!temppath) > + return E_OUTOFMEMORY; > + StrCpyNW(temppath, path, len); Again StrCpyNW is a shlwapi export, and since you just allocated the buffer of correct length memcpy + adding an explicit '\0' terminator look more naturally here (if not kernel32.lstrcpynW). > + /* try to create the directory if asked to */ > + if (flags & (SHPPFW_DIRCREATE|SHPPFW_ASKDIRCREATE)) > + { > + if (flags & SHPPFW_ASKDIRCREATE) > + FIXME("treating SHPPFW_ASKDIRCREATE as SHPPFW_DIRCREATE\n"); > + > + SHCreateDirectoryExW(0, realpath, NULL); > + } You are still not checking SHCreateDirectoryExW return value. > + if (temppath) > + HeapFree(GetProcessHeap(), 0, temppath); There is no need to check temppath for NULL before HeapFree call. -- Dmitry.

3 3

re: nhelp, Vector NTI, molecular biologists
by Dan Kegel 07 Sep '07

07 Sep '07

Misha wrote: > and even my version of Windows 98 is bundled with mfc42.dll, so wine really should > provide it too... [our own version, not Microsoft's.] Well, sure. Same goes for a lot of things. But since mfc42.dll is a Visual C++ runtime file that has very liberal redistribution terms and is in fact bundled with many apps, we can get away without it for a long time. And it's not currently a showstopper as far as I can tell; I'm more interested in the bugs that keep e.g. Photoshop from running flawlessly. So one of these days it might become a priority. Until then, it's merely important but not urgent. - Dan

6 5

Re: ddraw/tests: Check deviceGUID of enumerated devices.
by Stefan Dösinger 07 Sep '07

07 Sep '07

Am Donnerstag, 6. September 2007 16:02:59 schrieb David Hedberg: > This patch adds tests to check the devices enumerated by > IDirect3D7_EnumDevices . At least two games rely on the behavior > tested by one of the test in this patch. If wine behaves incorrectly and your test fails on wine, you have to send a fix before or in the same patch as the test. Alexandre has some scripts that run the conformance tests after each patch and refuses all patches that cause in test failures. If you do not know how to fix the bug, or want to keep it unfixed for some other reason(e.g. the incorrect behavior is hard to fix and considered harmless), then you can mark the test as todo_wine. Then the tests script will ignore failures in the test. However, Alexandre will drop a note and ask for further explanation if a test marked todo_wine succeeds(e.g. we had a test that succeeded or failed for some time based on the features graphics driver). todo_wine test(2 + 2 == 3.99998, "This is my test marked as TODO\n"); /* Microsoft does something insane here */ Other things: + if(!memcmp(&lpdd7->deviceGUID, &IID_IDirect3DRGBDevice, sizeof(IID_IDirect3DRGBDevice))) You can use IsEqualGUID here. Sorry for not spotting this earlier. + IDirect3D7_EnumDevices(lpD3D, (LPD3DENUMDEVICESCALLBACK7) enumDevicesCallbackTest7, &d3d7et); To get more compiler checks, you shouldn't cast the function to the right type, but use void *d3d7et, and cast it to the right pointer in your function. Debugging a wrong function pointer is a nasty thing ;-)

2 2

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped asPE resources
by Dmitry Timoshkov 07 Sep '07

07 Sep '07

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > This is some overlap with freetype as freetype 2.3.5 can load fonts > from PE resources. But the code is so small (we have all the tools > needed) and helps many programs (including working around the > Photoshop Z-order problem during startup as now the dialogs doesn't > show) that I thought it is useful. Then there is no point in using FreeType for loading font files at all, (or adding support for new font file formats to FreeType) since FreeType can load fonts from memory. > + TRACE("WineEndAddFontResourceEx failed on PE file %s - trying to load resources manualy\n", > + wine_dbgstr_w(str)); > + if (EnumResourceNamesW(hModule, rt_font, load_enumed_resource, (LONG_PTR)&num_resources)) This code snippet causes a stack corruption since load_enumed_resource has wrong calling convention. I wonder whether gcc issued a warning here. -- Dmitry.

2 4

RE: problem with silly CreateBitmap call
by Rolf Kalbermatter 06 Sep '07

06 Sep '07

Deun wrote on Thursday, September 06, 2007 10:40 AM >trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 >1 bpp >X Error of failed request: BadAlloc (insufficient resources for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Serial number of failed request: 3155 > Current serial number in output stream: 3163 > >This occured after an attempt to load a bmp file that can't be found anywhere. > >The size of the bitmap seems crazy... So I've made a patch to fix this in >bitmap.c by setting 1x1 size in case of stupid input instead of failing with >BadAlloc. However, since it works fine on real windows, so I'm not sure about >the behaviour that the function should have. However this patch let me run >the game now : First your patch is not very useful as the diff was run from inside the directory where the two files where, instead of from the main wine directory. So the patch does not contain the necessary full project path for the patch maintainer to apply It without guessing, which he won't do without some very compelling reasons. But the more serious problem is that it is really just a hack and as such won't get into wine. Trapping on some arbitrary size is not an acceptable patch for Wine. Instead the root cause should be found. Since you say that this comes from trying to load a bitmap that can be nowhere found I wonder if this is the result of some unitialized structures that result in garbage but somehow the loading is not aborted with an error for whatever reasons but just passed further to X11DRV_CreateBitmap with whatever garbage happened to be in memory and here probably on the stack. I see two possibilities and they both are likely to be fixed in the actual caller of X11DRV_CreateBitmap instead of in this function itself: 1) Wine code has a bug and should not ever attempt to call X11DRV to create the bitmap after it couldn't find the according file on disk to initialize the bitmap members. Instead that function should just return to the caller with an error. 2) Windows allows to load a nonexisting bitmap file and returns in that case a default bitmap, brush or whatever without causing an error. In that case the structure should be either initialized to some meaningful values like a 0 * 0 or 1 * 1 bitmap before attempting to load the file from disk and when the load fails just fall through to create that default bitmap or on failure of the loading some special code needs to be executed to create whatever Windows returns here. So in any case I think you need to figure out from which function exactly X11DRV_CreateBitmap is called with these silly parameters and concentrate on fixing that one instead. Your patch is still very likely to crash on a 0x7e000000 * 0x7e000000 bitmap and therefore didn't adress the root cause of this problem. Not knowing anything about the stack trace it is completely impossible for anyone not running that application to look for the likely cause of this problem as there are quite a few functions in Wine that call X11DRV_CreateBitmap somewhere and somehow. Rolf Kalbermatter

3 2

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite
by Dmitry Timoshkov 06 Sep '07

06 Sep '07

"Vincent Povirk" <madewokherd(a)gmail.com> wrote: > HRESULT WINAPI SHPathPrepareForWriteA(HWND hwnd, IUnknown *modless, LPCSTR path, DWORD flags) > { > - FIXME("%p %p %s 0x%08x\n", hwnd, modless, debugstr_a(path), flags); > - return S_OK; > + WCHAR wpath[MAX_PATH]; > + MultiByteToWideChar( CP_ACP, 0, path, -1, wpath, MAX_PATH); > + return SHPathPrepareForWriteW(hwnd, modless, wpath, flags); It's better to not use fixed buffer sizes but allocate the buffer dynamically. > + /* make a copy of the path so we can cut off the filename */ > + for (i=0; i<MAX_PATH; i++) > + { > + realpath[i] = path[i]; > + if (path[i] == '\\') > + last_slash = i; > + else if (path[i] == 0) > + break; > + } > + realpath[MAX_PATH-1] = 0; > + > + if (flags & SHPPFW_IGNOREFILENAME) > + realpath[last_slash] = 0; If the job must be done only when SHPPFW_IGNOREFILENAME is specified then don't do it in all cases. And using strrchrW would simplify the code a bit. > + /* try to create the directory if asked to */ > + if (flags & (SHPPFW_DIRCREATE|SHPPFW_ASKDIRCREATE)) > + { > + if (flags & SHPPFW_ASKDIRCREATE) > + FIXME("treating SHPPFW_ASKDIRCREATE as SHPPFW_DIRCREATE\n"); > + > + SHCreateDirectoryExW(0, realpath, NULL); > + } Why there is no check for SHCreateDirectoryExW return value? > + > + /* check if we can access the directory */ > + res = GetFileAttributesW(realpath); > + > + if (res == INVALID_FILE_ATTRIBUTES) > + { > + err = GetLastError(); > + if (err == ERROR_FILE_NOT_FOUND) > + err = ERROR_PATH_NOT_FOUND; > + return HRESULT_FROM_WIN32(err); > + } > + else if (res & FILE_ATTRIBUTE_DIRECTORY) > + return S_OK; > + else > + return 0x8007010b; 0x10b == 267, therefore 0x8007010b is HRESULT_FROM_WIN32(ERROR_DIRECTORY) > --- a/dlls/shell32/tests/shpathprep.c > +++ b/dlls/shell32/tests/shpathprep.c > @@ -82,27 +82,27 @@ START_TEST(shpathprep) > ok(res == S_OK, "res == 0x%08x\n", res); > > res = SHPathPrepareForWriteA(0, 0, "c:\\testdir\\nonexistent", SHPPFW_NONE); > - todo_wine ok(res == 0x80070003, "res == 0x%08x\n", res); > + ok(res == 0x80070003, "res == 0x%08x\n", res); Please use above and in other places symbolic error names instead of hex, and print expected and received codes to make life easier for those who looks at the (failing) test results without looking at the source. For some reason your mailer attaches the patch in text and html formats, it would save some time/traffic by avoiding html in wine-patches. -- Dmitry.

2 6

WineHQ Upgrade Downtime
by Jeremy Newman 06 Sep '07

06 Sep '07

On Wednesday Sept 12 at 14:00 US Central Time, we will be taking all of WineHQ offline for maintenance and upgrades. The server itself will offline for about an hour. Some services will be offline longer than that as we adjust/fix them to the upgraded server.

1 0

Wine on 64bit system crashes (critical)
by Roderick Colenbrander 06 Sep '07

06 Sep '07

Hi, One of my development machines is a dualcore Athlon64 using a 64bit version of Debian. I have been using this system for months and it always worked fine. Since I hadn't used the system during the summer it contained an older Wine version. I have upgraded it to the latest GIT version and Wine doesn't work anymore. It doesn't just crash, but it locks up the whole system. I have no idea what causes it. I for instance ran Wine some time before as root (I really had to be root at that time) and for the root user it didn't lock up until I wanted to run a fresh .wine directory. I can't really test what caused it as testing this takes a lot of time and I can't use a bad filesystem or so on this system. On irc a ubuntu64 user said he had similar problems using Wine 0.9.44 but for him it 'only' segfaulted. Perhaps there is a connection between the problems. Has anyone recently seen problems like this? It prevents me from playing with Wine code at the moment. Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

2 3

Re: problem with silly CreateBitmap call
by Jesse Allen 06 Sep '07

06 Sep '07

On 9/6/07, Deun <deun76(a)yahoo.com> wrote: > Hi, > > I've tried the free-to-play MMORPG game called Perfect World ( > http://perfect-w.jp ) with wine 0.9.44 and it installs fine. > However, when running it often crashed with the following error > in the x11drv traces : > > trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 > 1 bpp > X Error of failed request: BadAlloc (insufficient resources > for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Serial number of failed request: 3155 > Current serial number in output stream: 3163 > > This occured after an attempt to load a bmp file that can't be > found anywhere. > > The size of the bitmap seems crazy... So I've made a patch to > fix this in bitmap.c by setting 1x1 size in case of stupid > input instead of failing with BadAlloc. However, since it works > fine on real windows, so I'm not sure about the behaviour that > the function should have. Look at the +bitmap debug channel, or others and trace to the original call's parameters. Figure out how the app is wanting to create the bitmap and write a test case for it and test on windows and wine. Jesse

1 0