Re: debugging help
On 6/18/07, Damjan Jovanovic <[EMAIL PROTECTED]> wrote: only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug. You can definitely use LoadLibrary() / GetProcAddress() inside of a builtin DLL manually to compare results against the native function. You'll have to change the name of the native DLL to avoid loading the builtin one by accident. Of course, none of that type of debugging code should be in the main git tree. Take a look at the tests/ folders for good examples of how to dynamically load the DLLs and functions.
debugging help
Hi I've been looking at bug 4437, where a game demo works perfectly with the native MSVCRT.DLL but dies on startup with the builtin due to a division by zero. The builtin doesn't have any fixmes, warnings or errors. Comparing builtin +relay and native +snoop traces shows the divide by zero doesn't happen with the native, everything else looks the same. A +msvcrt log is 20 lines long but there is nothing obviously wrong either, a +all,+relay log shows nothing useful before the crash - the last function called before the crash is a simple printf without any %'s, which produces the same results on native and builtin. Disassembling around the crash shows a long chain of calculations that dies on the fated idivl. So it looks like a nasty delayed-effect bug. I'd welcome any new ideas, and I also have a few questions. Does +relay catch all function calls? Because some functions like sscanf only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug. Thank you Damjan
Re: QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs
> --- wine-0.9.39-cvs/dlls/quartz/videorenderer.c 2007-05-17 10:25:02.0 -0500 > +++ wine-0.9.39-cvs-patch/dlls/quartz/videorenderer.c 2007-06-17 00:47:15.0 -0500 You should really use git. It may be some effort to learn, but it makes your life, and Alexandre's much easier in the long run.
Re: QUARTZ: Patch 2 - Move blitting operation to message thread and handle WM_PAINT
I have no direct comment on the patch (it's not really my area), but there's something I'd like to bring up. On Sunday 17 June 2007 01:51:56 pm [EMAIL PROTECTED] wrote: > This patch moves the blitting code into the message thread. This is a setup > patch for the DirectDraw rewrite, but can be applied on its own after the > first patch. I'm all for changing the video renderer away from GDI, however I think it'd be better to move it to Direct3D or WGL instead of DDraw. I'm quite sure native quartz uses Direct3D when available, given that DDraw has been deprecated ever since DX7. Also, using native quartz's video renderer causes wined3d debug output for me, and as Stefan says, DDraw currently defaults to GDI so it wouldn't have come from that.
Re: dinput: Handle multiple keyboard and mouse devices. Get rid of the message window. [resend]
Please don't apply this patch. I will need to change few more things that will affect parts of this patch. Vitaliy. Vitaliy Margolen wrote: Please use this one instead. The other patch had accidentally escaped debug statements. Fixes bug 7129. The whole idea here is to set/release hook only once for keyboard/mouse. Then if we have more then one device, just call their hook handlers from the single top level handler. Also, since we don't really check the return status from setting the hook itself get rid of the message window. Just notify the thread it needs to recheck device lists and set/remove hooks. --- dlls/dinput/dinput_main.c| 234 +- dlls/dinput/dinput_private.h |3 +- dlls/dinput/keyboard.c | 54 ++ dlls/dinput/mouse.c | 28 +- 4 files changed, 156 insertions(+), 163 deletions(-)
Re: vxd loading is broken last months
В сообщении от 17 июня 2007 Dan Kegel написал(a):
> Vitaly Lipatov wrote:
> > INT21_CreateMagicDeviceHandle in winedos/int21.c uses the same dummy file
> > magic with open file with unix path from wine_get_server_dir().
> > I guess we could use NtCreateFile on unix path before.
> > Now we need select correct place for such dummy files inside wine disk
> > tree...
>
> Yeah. Evan has been sitting on a patch to fix this for a week
> now. Evan, I'd say it's time to post your minimal test and
> the fix, even if things are broken.
> - Dan
JFYI: I have a patch to fix this via use temp dir, not server dir:
--- dlls/kernel32/vxd.c 9 Apr 2007 12:37:34 - 1.5
+++ dlls/kernel32/vxd.c 16 Jun 2007 14:29:49 -
@@ -91,7 +91,7 @@ static CRITICAL_SECTION vxd_section = {
/* create a file handle to represent a VxD, by opening a dummy file in the
wineserver directory */
static HANDLE open_vxd_handle( LPCWSTR name )
{
-const char *dir = wine_get_server_dir();
+WCHAR path[MAX_PATH];
int len;
HANDLE ret;
NTSTATUS status;
@@ -99,17 +99,16 @@ static HANDLE open_vxd_handle( LPCWSTR n
UNICODE_STRING nameW;
IO_STATUS_BLOCK io;
-len = MultiByteToWideChar( CP_UNIXCP, 0, dir, -1, NULL, 0 );
-nameW.Length = (len + 1 + strlenW( name )) * sizeof(WCHAR);
-nameW.MaximumLength = nameW.Length + sizeof(WCHAR);
-if (!(nameW.Buffer = HeapAlloc( GetProcessHeap(), 0, nameW.Length )))
+len = GetTempPathW(sizeof(path), path);
+path[len-1] = '\\';
+/* Lav: Possible stack overflow */
+strcpyW( path + len, name );
+
+if (!RtlDosPathNameToNtPathName_U( path, &nameW, NULL, NULL ))
{
-SetLastError( ERROR_NOT_ENOUGH_MEMORY );
-return 0;
+SetLastError( ERROR_PATH_NOT_FOUND );
+return INVALID_HANDLE_VALUE;
}
-MultiByteToWideChar( CP_UNIXCP, 0, dir, -1, nameW.Buffer, len );
-nameW.Buffer[len-1] = '/';
-strcpyW( nameW.Buffer + len, name );
attr.Length = sizeof(attr);
attr.RootDirectory = 0;
--
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!
