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

Re: [PATCH] Don't generate FIXME warnings for DllCanUnloadNow.
by Maarten Lankhorst Jan. 6, 2010

Jan. 6, 2010

Hi Reece, Reece Dunn schreef: > NOTE: Some of the DllCanUnloadNow functions always return S_OK. I > intend to address that in a separate patch once I have investigated > whether the DLLs implement COM objects or not. > When a dll is first implemented it probably returns S_OK since no interfaces were used yet, but some programs just depended on the dll being present. However the FIXME should not be removed then, since if it does implement interfaces and it gets freed while in use this can be a serious crash. I'd rather have that message then as a red flag for investigation. Returning nothing in case of S_FALSE is fine though, but a TRACE() would still be nice there just in case. Cheers, Maarten.

2 1

Fwd: The (Casual) Game Support Report in Wine (Jan 2009)
by David Gerard Jan. 6, 2010

Jan. 6, 2010

whoops, sending to list as well! ---------- Forwarded message ---------- From: David Gerard <dgerard(a)gmail.com> Date: 2010/1/6 Subject: Re: The (Casual) Game Support Report in Wine (Jan 2009) To: Reece Dunn <msclrhd(a)googlemail.com> 2010/1/5 Reece Dunn <msclrhd(a)googlemail.com>: > 2/ the major issues appear to be in the application launchers used > by different game providers (most of which are in the current wine > implementation of the IE browser ActiveX control); Curious question: you tested with IE6, how do things work if you install IE7? Any better? (I installed IE7 with winetricks to see if I could get the ActiveX control for our work VPN going. It didn't work, and I didn't expect it to - it uses ActiveX to completely take over and try to secure a Windows installation, and I think it just recoiled in horror when it found itself in Wine on Linux - but I routinely use it now to check website rendering. It's really horrible. But useful.) - d.

2 1

Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
by Alexandre Julliard Jan. 6, 2010

Jan. 6, 2010

Marcus Meissner <marcus(a)jet.franken.de> writes: > buffer and size need to be either 0 at the same time or not, > otherwise this breaks up. Windows is inconsistent (either crashes > or returns invalids), so we can just add checking. If Windows crashes we don't need extra checks. Just tell Coverity that crashing is allowed here. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
by Paul Vriens Jan. 6, 2010

Jan. 6, 2010

On 01/06/2010 01:26 PM, Marcus Meissner wrote: > + if (!RtlCreateUnicodeStringFromAsciiz(&filenameW, filename)) { > + SetLastError(ERROR_OUTOFMEMORY); > + return 0; > + } Aren't you leaking bufferW here? -- Cheers, Paul.

1 0

Re: [4/5] WineD3D: Implement manual fencing with GL_APPLE_flush_buffer_range
by Henri Verbeet Jan. 6, 2010

Jan. 6, 2010

2010/1/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + if(This->query.context) context_free_event_query(&This->query); > + This->query.context = NULL; context_free_event_query() already clears the context field. > + if(This->resource.device->adapter->gl_info.supported[APPLE_FENCE]) You already have a gl_info pointer in buffer_create_buffer_object(), you're using it a few lines up. I'm not sure you can test for APPLE_fence to determine if event queries are available. > +static inline void buffer_sync_apple(struct wined3d_buffer *This, struct wined3d_context *context, DWORD flags) Do you have a good reason for adding that inline? I think it mostly just causes the compiler to not notice when the function is unused. > + /* TODO: Test and implement D3DLOCK_DONOTWAIT */ > + GL_EXTCALL(glFinishFenceAPPLE(This->query.id)); > + checkGLcall("glFinishFenceAPPLE(This->query.id)"); The buffer code can't assume an event query is implemented with APPLE_fence. > + GL_EXTCALL(glSetFenceAPPLE(cur->query.id)); > + checkGLcall("glSetFenceAPPLE(cur->query.id)"); ...and neither can the draw code. The assumption is currently true of course, but that's just an accident of the code order in context_alloc_event_query(). Adding e.g. ARB_sync support to event queries will break that.

2 4

Re: gdi32: Use the LOGFONT charset field on OEM font creation
by Dmitry Timoshkov Jan. 6, 2010

Jan. 6, 2010

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > Some explanation for this patch: > > The fsCsb is bitfield that is used as boolean value. If this is false the > DEFAULT_CHARSET is using and the real charset is choosen through the current > ANSI codepage. But this is mistake in case of the OEM charset. A real fix would be to add "Terminal" font to Wine. -- Dmitry.

2 2

Re: ole32/tests: remove a test, as it fails or hangs on Vista+
by Paul Vriens Jan. 6, 2010

Jan. 6, 2010

On 01/05/2010 08:05 PM, André Hentschel wrote: > vista and 2k8: fails > w7: timeout > --- > dlls/ole32/tests/clipboard.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c > index 626d244..4a9e234 100644 > --- a/dlls/ole32/tests/clipboard.c > +++ b/dlls/ole32/tests/clipboard.c > @@ -1186,6 +1186,7 @@ static void test_flushed_getdata(void) > "got %08x\n", hr); > if(SUCCEEDED(hr)) ReleaseStgMedium(&med); > > +#if 0 /* broken on Vista+ */ > InitFormatEtc(fmt, cf_another, 0xffff); > memset(&dm, 0, sizeof(dm)); > dm.dmSize = sizeof(dm); > @@ -1204,6 +1205,7 @@ static void test_flushed_getdata(void) > ok(hr == S_OK, "got %08x\n", hr); > ok(med.tymed == TYMED_ISTORAGE, "got %x\n", med.tymed); > if(SUCCEEDED(hr)) ReleaseStgMedium(&med); > +#endif > > HeapFree(GetProcessHeap(), 0, fmt.ptd); > The test doesn't fail or hang on all Vista+ boxes though. There have been several attempts to fix these failures but I'm not sure just removing them is the best option. Apart from that I think "if (0)" is preferred over "#if 0". -- Cheers, Paul.

1 0

The (Casual) Game Support Report in Wine (Jan 2009)
by Reece Dunn Jan. 6, 2010

Jan. 6, 2010

Hi, With Dan reporting on the success of Visual C++ 2005, I thought I would post my findings of various casual (and other) games. In general, my observations are that: 1/ the games themselves tend to work very well (and have done for a long while now thanks to the great work CodeWeavers did in getting DirectDraw and Direct3D working); 2/ the major issues appear to be in the application launchers used by different game providers (most of which are in the current wine implementation of the IE browser ActiveX control); 3/ the success varies from provider to provider, but the same tricks usually work for a given provider; 4/ a game is usually distributed by more than one provider, so you should be able to find a provider that works with wine that distributes the game; 5/ the recent Xrender support has provided major improvements to games (to the point where Azgard Defense is actually playable :D). Oberon Media Oberon Media have two versions of their game launcher. The older one renders with the buttons drawn, but the text and links are not functional; installing IE6 causes the text to render and the links to work, but when registering the games, you cannot enter any text in the text fields and there is no visible cursor. The newer launcher (which has a different UI) causes an SEH exception; I suspect that this is due to tightened DRM in the launcher. In addition to this, entering the details directly into the registry doesn't appear to work any more (and in the newer versions of the launcher, a different mechanism is used). Verdict: Rubbish! PopCap Games The PopCap games launcher works without problems out of the box. I haven't tried registering/buying a game through their launcher interface, though. Verdict: Flawless Blizzard Entertainment I have successfully installed and registered Warcraft III (and the expansion), StarCraft and Diablo II using the installer/launcher from the download version. StarCraft and Diablo II work flawlessly; WarCraft III crashes at random points (usually when transitioning between parts of a scenario). Verdict: Almost-but-not-quite Flawless Big Fish Games These use a special downloader client that makes extensive use of IE to provide its functionality. Although this does not currently work with wine out of the box, it works flawlessly in IE6 (using winetricks to install) -- the games download (although the download animation button background does blink), launch and you can successfully register/purchase them from the Big Fish Games UI. NOTE: Using IE7 results in a crash when starting the Big Fish Games launcher, and I have not yet been able to get IE8 installing/working properly from winetricks (using the IE7 recipe). Verdict: Excellent Awem Studios The Awem Studios game launcher works flawlessly in a clean wine prefix (only gecko is needed). The games launch and you can even register/purchase the games from within the Awem game launcher. Verdict: Flawless YoudaGames The launcher used by YoudaGames does not work in wine out of the box, but requires IE6. I haven't tried registering/purchasing any of their games yet, so I don't know how well this works. Verdict: Excellent - Reece

2 3

visual c++ 2005 success
by Dan Kegel Jan. 5, 2010

Jan. 5, 2010

Well, golly. Now that Rob has fixed the /Zi bug, Visual C++ 2005 seems to be building small apps pretty well. There are three or so gotchas to be aware of: 1) apps like gyp's unit test won't be able to build until you've run the IDE once so it can register itself 2) you have to install winbind or /Zi will still be broken 3) the first run of a devenv /Zi build will hang after starting the pdb service; you have to kill it to recovert. Further runs (until reboot) will work fine. See http://bugs.winehq.org/show_bug.cgi?id=21259 for a nice script to demonstrate the latter problem. Oh, and you can't create projects; our ie implementation isn't good enough to run the wizard yet. But you can use projects that were created earlier.

1 0

valgrind progress: only 426 errors left?!
by Dan Kegel Jan. 5, 2010

Jan. 5, 2010

Rob Shearman's commit, http://source.winehq.org/git/wine.git/?a=commit;h=9dc584d0a2cae7cfb4816fe98… seems to have caused a spectacular improvement in jscript/tests/run.c's leakage: LEAK SUMMARY: - definitely lost: NNN bytes in 19,001 blocks + definitely lost: NNN bytes in 4 blocks woot! The stats are now 1 Invalid free/ delete / delete[] 1 Use of uninitialised value of size 4 2 Source and destination overlap in memcpy 3 Syscall param writev 6 Invalid write of size 4 7 Invalid read of size 2 8 Invalid write of size 1 22 Invalid read of size 4 41 Conditional jump or move depends on uninitialised value 335 XXX bytes in XXX blocks are definitely lost total: 426 Amazing progress for December. I'll be happy if in January we cut the error count by 10% down to 380... There were two runs today; http://kegel.com/wine/valgrind/logs/2010-01-04-06.56 covered last Thursday's git, http://kegel.com/wine/valgrind/logs/2010-01-04-10.14 was fresh. Also: I'm deleting really old valgrind logs to avoid going over quota.

1 1