September 2007 - Wine-Devel

Re: make_makefiles: ignore .DS_Store files
by Alexandre Julliard Sept. 11, 2007

Sept. 11, 2007

Emmanuel Maillard <mahanuu(a)free.fr> writes: > From b298a599f2b0eb5b8d7f2092573aba28755001d7 Mon Sep 17 00:00:00 2001 > From: Emmanuel Maillard <mahanuu(a)free.fr> > Date: Sun, 2 Sep 2007 12:42:16 +0200 > Subject: [PATCH] - ignore .DS_Store files You should put that in your global ignore file, the .DS_Store files are not created by the build process so they don't belong in .gitignore. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WineD3D: PBO support 2/2
by Stefan Dösinger Sept. 11, 2007

Sept. 11, 2007

Am Dienstag, 11. September 2007 10:25:28 schrieb Roderick Colenbrander: > Hi, > > This patch adds PBO support for dynamicly locked textures. It greatly > improves performance of games that use render target locking a lot. It looks good to me, here are some suggestions for further improvements in further patches(this patch is good for the start). The locking flag passed to LockRect could be forwarded to GL. D3DLOCK_DISCARD and D3DLOCK_WRITEONLY(ddraw only) would be GL_WRITE_ONLY, D3DLOCK_READONLY GL_READ_ONLY. However, we have to take care about the upside down swap for render target locking. D3DLOCK_DISCARD can be implemented(appart of the surface beeing writeonly) by calling glBufferData with a NULL pointer. This tells gl that the old data can be thrown away. This allows the driver to further optimize the map. e.g. if it is a texture that is still used for rendering in some pending calls, it can duplicate the buffer and doesn't have to wait for the rendering to finish. It will have to be tested if that really helps performance. I tried it for vbos, and it made things noticeably worse. Binding the pbo to 0 after each operation is a good idea for a start, but shouldn't be done in the long term in my opinion.

1 0

settlers 3 and dib engine
by Skrzynka Sept. 10, 2007

Sept. 10, 2007

Hi, I'm trying to get Settlers 3 to run on Wine. After fixing some race condition (seems like the thread calling WaitForXXXObject was giving up time-slice too early after the call) it seems that the only problem left is very slow text output. What I could understand from the forum archives is that with no DIB engine, the rendering into a DC causes copying of the bitmap to/from server (is that correct?). I'd like to contribute to the DIB engine if it's possible/needed, so I'd like to ask about a few things. There were some discussion recently about an implementation of DIB engine by Jesse Allen - what is the status of DIB engine? I compiled winedib.drv but ExtTextOut function is missing there and overall there are regressions visible when running Settlers 3 (wrong colors, no text at all). Which docs/urls/sources would you recommend to read to get some quick introduction to the DIB engine? Which particular functions are making current impl slow? Or, in general: where to start? Sorry for any silly questions... Thanks & regards Piotr -- ----- AlphaNet - najtaniej w sieci! -------- Odnowienia domen w rewelacyjnych cenach! .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl http://www.domeny.alpha.pl --------------------------------------------

4 8

Re: ntdll: Do not segfault with snoop for files with a broken exporttable
by Dmitry Timoshkov Sept. 10, 2007

Sept. 10, 2007

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > ntdll: Do not segfault with snoop for files with a broken export table > + /* Check for files with broken exports */ > + if (exports->Characteristics || > + exports->MajorVersion || > + HIWORD(exports->NumberOfFunctions) || > + HIWORD(exports->NumberOfNames)) { > + WARN_(snoop)("snoop disabled for bad module %p: 0x%x, %u, 0x%x, 0x%x\n", hmod, > + exports->Characteristics, exports->MajorVersion, > + exports->NumberOfFunctions, exports->NumberOfNames); > + return; > + } > + > TRACE_(snoop)("hmod=%p, name=%s\n", hmod, name); It's still helpful to see the line "hmod=%p, name=%s\n" in the log before an error message. -- Dmitry.

2 1

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (improved, fixes bug #5877)
by Dmitry Timoshkov Sept. 8, 2007

Sept. 8, 2007

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > As suggested by Dmitry the table id is now a symbolic constant. However > I didn't included the tttags.h but defined the constant myself as I see > that every freetype header is checked by configure and included only if > it is available. Thus in case it is not available we would either need > an #ifdef in AddFileToList (what IMHO wouldn't be nice) or in such a > case define the symbol ourselfs. But if we will need to define the > symbol then why to include the header? > +#define WINEENG_SFNTTAG_CFF 0x43464620 /* stores the outline for Type1 OTF fonts */ This is not what I suggested. Using a macro like FT_MAKE_TAG makes this much more readable. WINEENG_SFNTTAG_CFF doesn't follow any macro naming conventions in freetype.c, I'd suggest to use the same name as FreeType has (TTAG_CFF) instead, perhaps inside of #ifdef guard if including tttags.h is much hassle. Although including tttags.h and using #ifdef before defining TTAG_CFF is much more clean IMO. -- Dmitry.

1 0

[PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.
by Misha Koshelev Sept. 8, 2007

Sept. 8, 2007

Jacek Caban wrote: > Hi Misha, > > Misha Koshelev wrote: > > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > > Now we can just address them within the framework since we need that framework for closing handles > > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > > much sense to me to store the "parent" object handle in two different places. > > Sorry for late response. > > This patch reverses what I've done some time ago. There is no reason to > have parent object in header - you need only a child list to handle > closing handles. Also casts make the code much less readable. > > Thanks, > Jacek Ok, that sounds fair. I didn't really like the casts either, that was my biggest problem with this patchset. I am leaving the country tomorrow for 9 days but will change the patches/resubmit as you suggested after I come back. Thanks for your comments. Misha

1 0

Re: [PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.
by Jacek Caban Sept. 8, 2007

Sept. 8, 2007

Hi Misha, Misha Koshelev wrote: > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > Now we can just address them within the framework since we need that framework for closing handles > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > much sense to me to store the "parent" object handle in two different places. Sorry for late response. This patch reverses what I've done some time ago. There is no reason to have parent object in header - you need only a child list to handle closing handles. Also casts make the code much less readable. Thanks, Jacek

1 0

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (fixes bug #5877)
by Dmitry Timoshkov Sept. 7, 2007

Sept. 7, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > As I wrote in Bugzilla for Photoshop to work with Type1 fonts after > applying this patch one needs to reinstall Photoshop in a clean > wineprefix - it seems that Photoshop caches some font data. > + /* check for the presence of the 'CFF ' table to check if the font is Type1 */ > + tmp_size = 0; > + if (pFT_Load_Sfnt_Table && !pFT_Load_Sfnt_Table(ft_face, 0x43464620, 0, NULL, &tmp_size)) > + { > + TRACE("Font %s/%p is OTF Type1\n", wine_dbgstr_a(file), font_data_ptr); > + face->ntmFlags = NTM_PS_OPENTYPE; > + } Please use a symbolic name instead of 0x43464620. FreeType provides TTAG_CFF, or you can define it on your own using FT_MAKE_TAG. -- Dmitry.

1 0

Kudos - Fireworks 8 working better...
by Dan Kegel Sept. 7, 2007

Sept. 7, 2007

http://www.5thpercentile.com/devBlog/archives/2007/09/wine_just_got_t.html and http://appdb.winehq.org/appview.php?iVersionId=4149&iTestingId=15163 both say that wine-0.9.44 really improves Adobe Fireworks. Yay! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: wined3d: add WINED3DPRESENT_INTERVAL_ONE flag (fix bug 9584)
by Stefan Dösinger Sept. 7, 2007

Sept. 7, 2007

Am Freitag, 7. September 2007 18:29:02 schrieb Louis. Lenders: > I added this initially as a hack to get mame running, but what i understood > from discussion on IRC, there's no way we can check the graphics card's for > this capability now, and adding it as default (so without checking) would > be rather harmless. Short answer: Patch is ok with me Long answer: We can check if opengl supports vsync(which is what this flag does). WineD3D implements vsync using GLX_SGI_video_sync. So if this extension is supported, we should set the flag. If it is not supported, do not set it. Our WGL implementation does not forward the GLX extension yet, so we do not support vsync at the moment, so setting this flag means essentially lying to the app. However, I think it is safe to pretend vsync support. The worst that may happen is that the game renders with a higher framerate, and the hardware consumes more power instead of beeing idle. I think both cases are better then not running the game at all. There's one game which runs into internal race conditions if vsync does not work(need for speed 3), but that game doesn't even care to check that flag.

1 0

build problem on amd64
by Dave Phillips Sept. 7, 2007

Sept. 7, 2007

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 Sept. 7, 2007

Sept. 7, 2007

"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 Sept. 7, 2007

Sept. 7, 2007

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 Sept. 7, 2007

Sept. 7, 2007

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 Sept. 7, 2007

Sept. 7, 2007

"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 Sept. 6, 2007

Sept. 6, 2007

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 Sept. 6, 2007

Sept. 6, 2007

"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 Sept. 6, 2007

Sept. 6, 2007

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 Sept. 6, 2007

Sept. 6, 2007

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 Sept. 6, 2007

Sept. 6, 2007

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

Re: olethk32.dll
by Juan Lang Sept. 6, 2007

Sept. 6, 2007

Hi Stefan, + if (fdwReason == DLL_PROCESS_ATTACH) + DisableThreadLibraryCalls(hinstDLL); + + return TRUE; You should probably add a DLL_WINE_PREATTACH case that returns FALSE. --Juan

1 0

IDirect3DImpl_EnumDevices only enumerating IID_IDirect3DTnLHalDevice
by David Hedberg Sept. 6, 2007

Sept. 6, 2007

Hi, I've been tracking down the reason for bug 7993 ( http://bugs.winehq.org/show_bug.cgi?id=7993 , "Delta Force Land Warrior 1.31 -> Can't find 3D Video Card" ), and I think I've found it. It appears as if the EnumDevices callback in Delta Force for some reason discards all devices with a GUID of IID_IDirect3DTnLHalDevice, thus discarding the only device enumerated by wine. This is "easily" checked (and bypassed) by searching for and altering the IID_IDirect3DTnLHalDevice value used in the check (78 9E 04 F5 (..) ) in the delta force executable. While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine. Fixing this together with applying (or otherwise fixing the issue highlighted in) the patch at http://flodaby.ath.cx/~david/0001-ddraw-fix-cases-where-desc2.u2.dwMipMapCo… (also sent to wine-patches), would enable both Delta Force Land Warrior and Delta Force Task Force Dagger to run great with wine. David

2 4

Re: winhelp, Vector NTI, molecular biologists
by Misha Koshelev Sept. 5, 2007

Sept. 5, 2007

On 9/4/07, Alexander Sornes wrote: > Tirsdag 04 september 2007 03:17, skrev Misha Koshelev: > > On 9/3/07, Stefan Dosinger wrote: > > > Am Montag, 3. September 2007 13:30:57 schrieb Damjan Jovanovic: > > > > Somebody needs to make a do-nothing-useful app, intended for Windows, > > > > that also installs on wine and supplies each and every DLL that > > > > Windows applications need but we don't have in wine (like MFC42.DLL, > > > > the D3DX9_xx.DLL's, new MSVCRT's, etc.). That way we can legally use > > > > those DLLs without a Windows licence. > > > > > > This is not necessarily true. I don't know about MFC42.dll or the > > > msvcrts, but the directx eula does not allow that; It requires the > > > application to run only on the Microsoft Windows operating system, > > > targetting both Windows and Linux+Wine violates the contract. These are > > > the conditions for distributing the directx dlls. I've not found anything > > > against installing them on Wine, you just must not distribute the DLLs > > > with an app that targets both Windows and Wine. Thus I think it's legal > > > to write a script that downloads them from the original location > > > @microsoft.com and installs them, as long as that script isn't bundled > > > with the dlls. However, IANAL. > > > > > > What remains unanswered though is how this affects game vendors whose > > > games run on Wine without intention from the game vendor and ship the > > > dlls, e.g. Eve Online. > > > > Actually you all bring up rather interesting points with regards to Vector > > NTI as: > > > > (a) It pretty much ships with almost every Microsoft redistributable needed > > (e.g., MDAC, Windows Script, MFC71, etc.) and installs them on its > > installation _except_ MFC42 (not sure why this oversight and if this would > > break it on some native system, although I _believe_ it installed correctly > > on my plain vanilla Win98 VMWare installation, but I would have to double > > check for sure). > > > > I believe mfc42 is bundled with Windows XP. Actually, I just reinstalled Windows 98 in VMWare _without_ installing VMWare tools and even my version of Windows 98 is bundled with mfc42.dll, so wine really should provide it too... > > > (b) If the licenses for those DLLs/redistributables are the same as you > > suggest for DirectX, this would mean they couldn't ever say they support > > Wine (but I'm not sure whether or not the licenses are). Anyway, seeing it > > work "gold" on Wine still wouldn't be a bad thing in either case and > > certainly Vector NTI is not the only program that needs good winhelp > > support. > > > > Misha > Misha

1 1

Would also like to contribute to Wine
by Reece Dunn Sept. 5, 2007

Sept. 5, 2007

I am interested in the Wine project, and my manager at work has accepted my request to work on it. I work for a company that develops Windows software, so as I have access to Visual Studio, and thus the sources for ATL, MFC and the msvc runtime (provided with the full version of Visual Studio), I state that I will not participate in the development of these components. I have not seen, and do not intend on seeing, any of the Windows source code. I am interested in the following. 1. Writing tests for various parts of Wine, initially the RECT API. I know that this is a simple API, but even the simplest API needs tests. I will expand on this set as time permits. Is it possible for me to write tests for ATL and/or the msvc runtime, as this is not implementing those API? 2. Investigating the failing tests (e.g. the new, unknown message in the monthcal tests on Vista) and how to fix them properly. 3. Improve the user32/comctl32 controls. I would like to address the outstanding issues with these if I can. 4. Microsoft Active Accessibility (MSAA)/User Interface Automation (UIA). I would like to get this working with the various Linux accessibility API, so that more people will have access to Windows applications running on Linux+Wine. 5. Microsoft Text-To-Speech API (part of the sapi DLL). This is on my wishlist and is likely beyond my capabilities to get working. It is used by applications like Dragon Naturally Speaking and Cepstral SwiftTalker. Here, there is supporting voices installed on Windows that use the SAPI interface directly, and voices installed on Linux that implement different APIs. 6. Get theming working with the user32 controls and Window frames. Get the theming support working with GNOME themes as well. 7. Anything else I can think of. I would be interested in improving Wine to help get more applications running on Wine. Does anyone know if there are some common things that are holding Wine up, or is it more a per-application problem as each application is hitting different problems in Wine? - Reece

5 6

The Sims - some hacks
by Trent Waddington Sept. 5, 2007

Sept. 5, 2007

Attached is a patch for some hacks that will get The Sims to run and not crash (for a while). First, there's the easy problem of the cursors not working. This is because Sims.exe calls LoadCursorFromFile on a bunch of files that contain icons, not cursors. As the only difference between the two is that the cursor has a hotspot in front of it, I added some code to treat the icon as a cursor with no hotspot. Other programs may benefit from this patch, as it seems it is something you can get away with on Windows. Then there's the problem of the actual crash. This is caused by CreateSurface in ddraw returning an error and Sims.exe doesn't check for the error. It is returning an error because Sims.exe is trying to create a depth buffer without specifying a valid pixelformat. Note that it actually does pass a pixelformat, it's just all zeros, except for the dwSize member. Again, this appears to be something you can get away with on Windows.. the pixelformat defaults to the current screen format. Once these patches are applied there are significant problems with the game. Minor: the company logo flashes and won't go away without a mouse click. Minor: the scrolling text of pointless terms sometimes overlaps itself Annoyance: there seems to be some blitting error on the "neighborhood" screen that results in parts of the splash screen not being overwritten. Major: the characters in the game are not redrawn correctly, and eventually, it will crash. Overall result: not playable. If someone with a better understanding of wined3d code could have a look, I'd love to receive some hints on what could be causing these issues. Thanks, Trent

3 2