February 2009 - Wine-Devel - list.winehq.org

Re: [try2] gdiplus/tests: Dynamically load gdiplus.dll.

by Francois Gouget

On Sun, 22 Feb 2009, Nicolas Le Cam wrote: > This avoid a messagebox in regression tests on systems that don't have > GdiPlus. This seems wrong because winetest.exe is already supposed to check for missing dlls. If I remember correctly this was done explicitely so that individual tests would not have to dynamically link everywhere. Also I tested on a platform that does not have gdiplus, and I did not get a message box. In fact, on that platform, winetest did not extract gdiplus_test.exe, which also seems very wrong to me. So I think that if there's any issue, it's on the winetest.exe side. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Feb. 23, 2009

Re: faultrep:display useful information in ReportFault

by Jérôme Gardou

Mikołaj Zalewski a écrit : > > I've written a dialog about a crash some time ago to add to winedbg > (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html) > It's probably time to ask what is the status of this patch? > If this patch gets accepted (Alexandre seemed to like the previous > version, but pointed that it broke kernel32 tests because there had > been no way to disable it and he didn't have much time to review it), > maybe calling `winedbg --auto` from ReportFault would be the best way > - you would then have a dialog (the same as during a regular crash, > can be disabled from the registry), the full debugger output and an > option to run an interactive debugger. AFAIK this is the other way > round than Windows does (AFAIK drwatson loads faultrep.dll into the > process that crashed and calls ReportFault), but loading a DLL into a > process where everything could be corrupted seems a strange idea. > > Jérôme Gardou pisze: >> Most wine users, when their app crashes, open a bug report and attach >> the console log. If the log contains information got from >> ReportFault, developers will gain some time, and have the preceding >> context of the call. >> > I'm affraid this is what is done by the 1% best users ;). I'd expect > that a typical user to complain that Linux is broken because on Linux, > from time to time, apps just disappear from the screen while on > Windows they don't. Already knowing that there is such a thing like > Wine requires some knowledge :). > > Mikołaj Zalewski > > Instead of reinventing the wheel, why not call kernel32 which does it for us.... What do you think about this patch? >From 8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= <jerome.gardou(a)laposte.net> Date: Mon, 23 Feb 2009 09:35:13 +0100 Subject: [PATCH] faultrep: Make ReportFault do something useful MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1.6.0.6" This is a multi-part message in MIME format. --------------1.6.0.6 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit --- dlls/faultrep/faultrep.c | 7 ++++++- dlls/kernel32/except.c | 2 +- dlls/kernel32/kernel32.spec | 3 +++ 3 files changed, 10 insertions(+), 2 deletions(-) --------------1.6.0.6 Content-Type: text/x-patch; name="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff" diff --git a/dlls/faultrep/faultrep.c b/dlls/faultrep/faultrep.c index d4bd713..bb896f9 100644 --- a/dlls/faultrep/faultrep.c +++ b/dlls/faultrep/faultrep.c @@ -37,6 +37,7 @@ static const WCHAR SZ_EXCLUSIONLIST_KEY[] = { 'E','r','r','o','r','R','e','p','o','r','t','i','n','g','\\', 'E','x','c','l','u','s','i','o','n','L','i','s','t', 0}; + /************************************************************************* * AddERExcludedApplicationW [FAULTREP.@] * @@ -107,7 +108,11 @@ BOOL WINAPI AddERExcludedApplicationA(LPCSTR lpAppFileName) */ EFaultRepRetVal WINAPI ReportFault(LPEXCEPTION_POINTERS pep, DWORD dwOpt) { - FIXME("%p 0x%x stub\n", pep, dwOpt); + LONG ret ; + TRACE("%p 0x%x stub\n", pep, dwOpt); + + ret = wine_start_debugger_atomic(pep) ; + return frrvOk; } diff --git a/dlls/kernel32/except.c b/dlls/kernel32/except.c index 21d3584..f471e05 100644 --- a/dlls/kernel32/except.c +++ b/dlls/kernel32/except.c @@ -347,7 +347,7 @@ EXIT: * * returns TRUE for the two first conditions, FALSE for the last */ -static int start_debugger_atomic(PEXCEPTION_POINTERS epointers) +int CDECL start_debugger_atomic(PEXCEPTION_POINTERS epointers) { static HANDLE hRunOnce /* = 0 */; diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec index b0f4ee7..e5e79c3 100644 --- a/dlls/kernel32/kernel32.spec +++ b/dlls/kernel32/kernel32.spec @@ -1264,3 +1264,6 @@ # Init code @ cdecl __wine_kernel_init() + +#debugging +@ cdecl wine_start_debugger_atomic(ptr) start_debugger_atomic --------------1.6.0.6--

Feb. 23, 2009

Re: d3d8: some 64-bit fixes

by Henri Verbeet

FWIW, I think the right way to fix this would be to use a handle table like for shaders.

Feb. 23, 2009

Re: user32: change a pointer cast from DWORD to DWORD_PTR

by Austin English

2009/2/22 Austin English <austinenglish(a)gmail.com>: > -- > -Austin > Ignore this patch please. -- -Austin

Feb. 23, 2009

Re: d3d8: some 64-bit fixes

by Austin English

On Mon, Feb 23, 2009 at 1:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/2/23 Austin English <austinenglish(a)gmail.com>: >> + STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE; >> + STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE; >> + STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE; >> + STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR * pToken) PURE; > Which version of the DXSDK does this match? > You're right, looks like it's not in there. Ignore this patch please, sorry for the noise. -- -Austin

Feb. 23, 2009

Re: d3d8: some 64-bit fixes

by Henri Verbeet

2009/2/23 Austin English <austinenglish(a)gmail.com>: > + STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR * pToken) PURE; Which version of the DXSDK does this match?

Feb. 23, 2009

Re: [7/7] setupapi/tests: start dialog.c test file with a test for SetupPromptForDiskA

by Paul Vriens

Ricardo Filipe wrote: > > > ------------------------------------------------------------------------ > > Hi, Could you turn that skip() into a win_skip()? Usually it's a good idea to do a SetLastError(0xdeadbeef or something like that) before calling the function, especially because you are relying on that last error for the ok() test. -- Cheers, Paul.

Feb. 23, 2009

Re: faultrep:display useful information in ReportFault

by Ben Klein

2009/2/23 Erich Hoover <ehoover(a)mines.edu>: > On Sun, Feb 22, 2009 at 2:34 PM, Jérôme Gardou <jerome.gardou(a)gmail.com> > wrote: >> >> Chris Robinson a écrit : >>> >>> Having the information there of why it crashed would be nice too, >>> especially if it's hard to reproduce. Knowing what the fault was, and where >>> (with a backtrace if possible) can give the more development-inclined people >>> information of where to look for the issue, instead of needlessly trying to >>> make it crash again or go digging around in log files. >>> >>> >> >> Well, that was the intent of my patch : ReportFault is made to give >> windows developers information about why the application catched an >> exception. There is no reason why wine people could not use it. By the way, >> is there an easy way to know if wine was launched from console or not? > > Wine may have a macro or function to check for you, but I am not aware of > it. In any application you can check to see if getenv("TERM") is empty, if > it has a value then the application was launched from a console. #include <unistd.h> and use isatty() would be the correct way to do it. But is a dialog box that only appears when not being run from a terminal really such a good idea?

Feb. 23, 2009

Re: faultrep:display useful information in ReportFault

by Jérôme Gardou

Mikołaj Zalewski a écrit : > > I've written a dialog about a crash some time ago to add to winedbg > (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html) > It's probably time to ask what is the status of this patch? > If this patch gets accepted (Alexandre seemed to like the previous > version, but pointed that it broke kernel32 tests because there had > been no way to disable it and he didn't have much time to review it), > maybe calling `winedbg --auto` from ReportFault would be the best way > - you would then have a dialog (the same as during a regular crash, > can be disabled from the registry), the full debugger output and an > option to run an interactive debugger. AFAIK this is the other way > round than Windows does (AFAIK drwatson loads faultrep.dll into the > process that crashed and calls ReportFault), but loading a DLL into a > process where everything could be corrupted seems a strange idea. Launching winedbg sounds good, but I wonder if calling winedbg AFTER the exception has been catched by the application would be useful. It's time for me to document myself :-) > > Jérôme Gardou pisze: >> Most wine users, when their app crashes, open a bug report and attach >> the console log. If the log contains information got from >> ReportFault, developers will gain some time, and have the preceding >> context of the call. >> > I'm affraid this is what is done by the 1% best users ;). I'd expect > that a typical user to complain that Linux is broken because on Linux, > from time to time, apps just disappear from the screen while on > Windows they don't. Already knowing that there is such a thing like > Wine requires some knowledge :). > > Mikołaj Zalewski > > Let's rephrase it : most bug reporters expect the console log to be useful for developers willing to fix their problem :-)

Feb. 22, 2009

Re: faultrep:display useful information in ReportFault

by Mikołaj Zalewski

I've written a dialog about a crash some time ago to add to winedbg (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html) It's probably time to ask what is the status of this patch? If this patch gets accepted (Alexandre seemed to like the previous version, but pointed that it broke kernel32 tests because there had been no way to disable it and he didn't have much time to review it), maybe calling `winedbg --auto` from ReportFault would be the best way - you would then have a dialog (the same as during a regular crash, can be disabled from the registry), the full debugger output and an option to run an interactive debugger. AFAIK this is the other way round than Windows does (AFAIK drwatson loads faultrep.dll into the process that crashed and calls ReportFault), but loading a DLL into a process where everything could be corrupted seems a strange idea. Jérôme Gardou pisze: > Most wine users, when their app crashes, open a bug report and attach > the console log. If the log contains information got from ReportFault, > developers will gain some time, and have the preceding context of the call. > I'm affraid this is what is done by the 1% best users ;). I'd expect that a typical user to complain that Linux is broken because on Linux, from time to time, apps just disappear from the screen while on Windows they don't. Already knowing that there is such a thing like Wine requires some knowledge :). Mikołaj Zalewski

Feb. 22, 2009