- wine-devel - winehq.org

Re: cabinet: Fix overrun of static array (Coverity)
by Alexandre Julliard 25 Jan '07

25 Jan '07

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > This patch is aimed at fixing Coverity CID-297. The existing code writes > 52 values to a 51-value array. The patch code only writes the first 51. > > Please let me know what is wrong with this patch. It may well be correct, but I think both the old and the new code are very confusing. Initializing this from a static constant would be a lot cleaner. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [try 4] slist support (2/2) slist declarations and functions
by Mike McCormack 25 Jan '07

25 Jan '07

Damjan Jovanovic wrote: > diff -ur a/include/winbase.h b/include/winbase.h > --- a/include/winbase.h 2007-01-12 20:59:52.000000000 +0200 > +++ b/include/winbase.h 2007-01-24 20:42:35.000000000 +0200 I would recommend you at least split the modifications to winbase into a separate patch, as they are not dependent on your implementation. Mike

1 0

Re: [kernel32][tests][locale] Add test for CompareStringA for non latin symbols
by Mike McCormack 25 Jan '07

25 Jan '07

Anatoly Lyutin wrote: > Changelog: Add test for CompareStringA for non latin symbols. Hmm. > + if (0) test_sorting_non_latin(); Adding a test that won't run... > +/* If you want to get the source code of the program generating a file, > + * please write to me on vostok(a)etersoft.ru. > + * Automatically generated file; DO NOT EDIT!! > + */ without the source code to generate the test data... Seems like it's unlikely this patch will be accepted. What exactly are you trying to show? Mike

1 0

Re: winex11.drv: Copy the GL extensions string because it may be freed.
by Chris Robinson 25 Jan '07

25 Jan '07

On Wednesday 24 January 2007 21:51, Ken Thomases wrote: > + WineGLInfo.glExtensions = strdup((const char *) pglGetString(GL_EXTENSIONS)); Shouldn't this be free'd somewhere? What about the other strings?

2 1

Re: Tests for NtCreateMailslotFile
by Vitaliy Margolen 25 Jan '07

25 Jan '07

Jeff Latimer wrote: > This is the first of some tests for NtCreateMailslotFile. I have > included them in kernel32/tests as I thought it better that the Mailslot > tests be collocated. Why do you need to test NtCreateMailslotFile directly? Why can't you use CreateMailslot instead? Vitaliy.

2 1

Re: cmdlg32: update Russian translation
by Dmitry Timoshkov 25 Jan '07

25 Jan '07

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > Changes: > Done Russian translation PD32_NO_DEVICES translation is missing a comma after 'Проверьте'. IDS_COLOR_MAROON translation has a spelling error. -- Dmitry.

1 0

Re: riched20: Don't create undos in ME_StreamIn
by Alexandre Julliard 24 Jan '07

24 Jan '07

"Matt Finnicum" <mattfinn(a)gmail.com> writes: > This fixes bug 7148 - a regression caused by one of my older patches. > This restores the old code that prevented ME_StreamIn from erroneously > creating undos. > > Changelog: > riched20: Don't create undos in ME_StreamIn It breaks the tests: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so editor.c && touch editor.ok editor.c:862: Test failed: EM_SETUNDOLIMIT didn't allow the first undo with UNDOLIMIT set to 2 editor.c:865: Test failed: EM_SETUNDOLIMIT didn't allow a second undo with UNDOLIMIT set to 2 editor.c:1447: Test failed: test paste: strcmp = -1 make[2]: *** [editor.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: add support for slists
by Dmitry Timoshkov 24 Jan '07

24 Jan '07

And one more... "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > +__int64 interlocked_cmpxchg64( __int64 **dest, __int64 *xchg, __int64 *compare ) > +{ > + _lwp_mutex_lock( &interlocked_mutex ); > + if (memcmp(*dest, compare, 8) == 0) > + memcpy(*dest, xchg, 8); > + else > + memcpy(compare, *dest); > + _lwp_mutex_unlock( &interlocked_mutex ); > + return compare; > +} Is there any particular reason that you use memcmp/memcpy instead of directly manipulating 64-bit values? -- Dmitry.

2 1

Re: add support for slists
by Dmitry Timoshkov 24 Jan '07

24 Jan '07

And some other problems with the patch: "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > --- a/include/winbase.h 2007-01-09 17:42:47.000000000 +0200 > +++ b/include/winbase.h 2007-01-24 09:50:04.000000000 +0200 > @@ -2343,6 +2343,14 @@ > > #endif /* __i386__ && __GNUC__ && __WINESRC__ && !_NTSYSTEM_ */ > > +#if (_WIN32_WINNT >= 0x0501) > +VOID WINAPI InitializeSListHead(PSLIST_HEADER); > +USHORT WINAPI QueryDepthSList(PSLIST_HEADER); > +PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); > +PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); > +PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); > +#endif Usually Wine doesn't use and doesn't need the checks for _WIN32_WINNT and similar macros. There are a couple of violations to that rule, but they need to be fixed. libs/port/interlocked.c changes should be sent separately, please remove c++ comments from them first. -- Dmitry.

1 0

Re: add support for slists
by Dmitry Timoshkov 24 Jan '07

24 Jan '07

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > + kernel32 = LoadLibraryA("KERNEL32.DLL"); All the kernel32 tests are already implicitly linked to kernel32.dll, therefore GetModuleHandle("kernel32.dll") is perfectly enough and is guaranteed to succeed. > + if (kernel32 == NULL) > + { > + trace("couldn't open KERNEL32.DLL, skipping slist tests\n"); > + return; > + } There was a new Wine test function introduced to mark the skipped tests - skip(), please use it when a test is going to be skipped for whatever reason. > + pInitializeSListHead = (void*) GetProcAddress(kernel32, "InitializeSListHead"); > + pQueryDepthSList = (void*) GetProcAddress(kernel32, "QueryDepthSList"); > + pInterlockedFlushSList = (void*) GetProcAddress(kernel32, "InterlockedFlushSList"); > + pInterlockedPopEntrySList = (void*) GetProcAddress(kernel32, "InterlockedPopEntrySList"); > + pInterlockedPushEntrySList = (void*) GetProcAddress(kernel32, "InterlockedPushEntrySList"); > + if (pInitializeSListHead == NULL || > + pQueryDepthSList == NULL || > + pInterlockedFlushSList == NULL || > + pInterlockedPopEntrySList == NULL || > + pInterlockedPushEntrySList == NULL) > + { > + trace("some required slist entrypoints were not found, skipping tests\n"); > + FreeLibrary(kernel32); > + } A 'return;' is missing here, as well as a skip() call. -- Dmitry.

1 0

Re: doc: Add info about where to get the Windows DDK
by Detlef Riekenberg 24 Jan '07

24 Jan '07

On Mi, 2007-01-24 at 13:31 +1100, Jeff Latimer wrote: Thanks for your update. Just a small typo (Device => Driver): DDK is the Windows Driver Development Kit -- By by ... Detlef

1 0

gecko download busted?
by Dan Kegel 23 Jan '07

23 Jan '07

Wine-0.9.27's iexplore.exe isn't downloading gecko for me. It tries, but then gives up, and says html rendering is disabled. +wininet shows that it did connect to winehq.org and got a redirect to sourceforge: trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302 Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 (Debian GNU/Linux)\r\nLocation: http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConne…: close\r\nContent-Type: text/html\r\n\r\n" but no connection request to that new URL, and the cabextract failed. I guess I'll try with a newer wine once I get to the office... - Dan

4 4

Directplay Sevice Provider
by Alessandro Pignotti 23 Jan '07

23 Jan '07

Hi everyone, i'm taking a look at wine's directplay implementation. From the the wiki i've seen that there are efforts to understand the directplay protocol. But it seems to be be quite a difficult task. Would not be a better idea to implement a wine directplay service provider with our own protocol, not compatible with microsoft tcp/ip service provider, but portable and usable on both windows and linux? Bye Pignotti Alessandro -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe

4 3

Re: user32: WM_SETFONT on button shouldn't repaint directly
by Dmitry Timoshkov 23 Jan '07

23 Jan '07

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > - if (lParam) paint_button( hWnd, btn_type, ODA_DRAWENTIRE ); > + if (LOWORD(lParam)) InvalidateRect(hWnd, NULL, TRUE); Your test doesn't show that the usage of LOWORD(lParam) is justified. -- Dmitry.

1 0

Howdy! Newbie with keyboard patches.
by seebs＠plethora.net 23 Jan '07

23 Jan '07

Hi! I'm new to Wine, but not a total newbie at C. I have a very specific interest: I would like Wine to support more keys. Background: Windows has support for no fewer than 24 function keys; in fact, possibly, as many as 32. However, right now, Wine only supports 16 of them. It is insanely trivial to patch Wine to support 24 function keys by plugging new values into nonchar_key_vkey and nonchar_key_scan. It is not much harder to support 32 at least partially; some sites claim that vkey values 0x88-0x8F are intended to be used as F25-F32, but there are no corresponding codes. Well, okay; it's not unheard of for a key to have a vkey value but no corresponding scan code. I have diffs for this. It works. There's just one TINY little problem. Many Windows games have no support for these keys! NOOOOO! I have implemented and tested a patch which is almost certainly unsuitable for production, but which is very convenient to me; it is this patch I enclose. This patch replaces F13-F24 with "control-alt-F1" through "control-alt-F12", and F25-F32 control-alt-shift-F1 through F8. Now, this is great for me, but it is obviously unsuitable as the only behavior; it deprives people of functioning keys. (My implementation my also be utter crap, but "it works in Warcraft", and that's my real interest.) I have no clue how to do Wine configuration settings. I think that this behavior is likely to be useful to a lot of people; X systems are easy to configure to generate extra keysyms, and many people have interesting keyboards which generate a broad range of additional values. Binding them to function keys is useful, and this patch would allow people to use such things in Windows games. Insofar as I have any possible copyright claim on this patch, I hereby release it into the public domain. Also, not in patch form, the winuser.h change: #define VK_F25 0x88 #define VK_F26 0x89 #define VK_F27 0x8A #define VK_F28 0x8B #define VK_F29 0x8C #define VK_F30 0x8D #define VK_F31 0x8E #define VK_F32 0x8F --- *** keyboard.c.orig Mon Jan 22 11:10:15 2007 --- keyboard.c Mon Jan 22 13:59:38 2007 *************** *** 1020,1027 **** /* function keys */ VK_F1, VK_F2, VK_F3, VK_F4, VK_F5, VK_F6, VK_F7, VK_F8, VK_F9, VK_F10, /* FFC0 */ ! VK_F11, VK_F12, VK_F13, VK_F14, VK_F15, VK_F16, 0, 0, /* FFC8 */ ! 0, 0, 0, 0, 0, 0, 0, 0, /* FFD0 */ 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ /* modifier keys */ 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ --- 1020,1027 ---- /* function keys */ VK_F1, VK_F2, VK_F3, VK_F4, VK_F5, VK_F6, VK_F7, VK_F8, VK_F9, VK_F10, /* FFC0 */ ! VK_F11, VK_F12, VK_F13, VK_F14, VK_F15, VK_F16, VK_F17, VK_F18, /* FFC8 */ ! VK_F19, VK_F20, VK_F21, VK_F22, VK_F23, VK_F24, 0, 0, /* FFD0 */ 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ /* modifier keys */ 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ *************** *** 1066,1073 **** /* function keys */ 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x40, 0x41, 0x42, 0x43, 0x44, /* FFC0 */ ! 0x57, 0x58, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFC8 */ ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFD0 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFD8 */ /* modifier keys */ 0x00, 0x2A, 0x36, 0x1D, 0x11D, 0x3A, 0x00, 0x38, /* FFE0 */ --- 1066,1073 ---- /* function keys */ 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x40, 0x41, 0x42, 0x43, 0x44, /* FFC0 */ ! 0x57, 0x58, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, /* FFC8 */ ! 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x76, 0x00, 0x00, /* FFD0 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFD8 */ /* modifier keys */ 0x00, 0x2A, 0x36, 0x1D, 0x11D, 0x3A, 0x00, 0x38, /* FFE0 */ *************** *** 1465,1471 **** if ( event->type == KeyRelease ) dwFlags |= KEYEVENTF_KEYUP; if ( vkey & 0x100 ) dwFlags |= KEYEVENTF_EXTENDEDKEY; ! X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); } } } --- 1465,1499 ---- if ( event->type == KeyRelease ) dwFlags |= KEYEVENTF_KEYUP; if ( vkey & 0x100 ) dwFlags |= KEYEVENTF_EXTENDEDKEY; ! if ((vkey & 0xFF) >= VK_F13 && (vkey & 0xFF) <= VK_F24) { ! /* translate to control-alt-F(N-12) */ ! vkey = vkey - 12; ! if (event->type != KeyRelease) { ! X11DRV_send_keyboard_input(VK_MENU, 0, 0, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_CONTROL, 0, 0, event_time, 0, 0 ); ! } ! X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); ! if (event->type != KeyRelease) { ! X11DRV_send_keyboard_input(VK_CONTROL, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_MENU, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); ! } ! } else if ((vkey & 0xFF) >= VK_F25 && (vkey & 0xFF) <= VK_F32) { ! /* translate to control-alt-F(N-12) */ ! vkey = vkey - 24; ! if (event->type != KeyRelease) { ! X11DRV_send_keyboard_input(VK_MENU, 0, 0, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_CONTROL, 0, 0, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_SHIFT, 0, 0, event_time, 0, 0 ); ! } ! X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); ! if (event->type != KeyRelease) { ! X11DRV_send_keyboard_input(VK_SHIFT, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_CONTROL, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); ! X11DRV_send_keyboard_input(VK_MENU, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); ! } ! } else { ! X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); ! } } } } *************** *** 2253,2260 **** function keys. Soooo.. We will leave the table alone and fudge the lookup here till the other part is found and fixed!!! */ ! if ( ((scanCode >= 0x13b) && (scanCode <= 0x144)) || ! (scanCode == 0x157) || (scanCode == 0x158)) scanCode &= 0xff; /* remove "extended-key" flag for Fx keys */ /* let's do scancode -> keycode -> keysym -> String */ --- 2281,2290 ---- function keys. Soooo.. We will leave the table alone and fudge the lookup here till the other part is found and fixed!!! */ ! if (((scanCode >= 0x13b) && (scanCode <= 0x144)) || ! ((scanCode >= 0x164) && (scanCode <= 0x16e)) || ! (scanCode == 0x157) || (scanCode == 0x158) || ! (scanCode == 0x176)) scanCode &= 0xff; /* remove "extended-key" flag for Fx keys */ /* let's do scancode -> keycode -> keysym -> String */

4 9

Re: [try3]: user32/tests: add tests for WM_SETICON - what's wrong?
by Kirill K. Smirnov 23 Jan '07

23 Jan '07

Anything wrong with them again? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Thanks, Kirill

1 0

Re: Alexandre Julliard : oleaut32/tests: Add tmarshal test.
by Alexandre Julliard 23 Jan '07

23 Jan '07

Alexandre Julliard <julliard(a)wine.codeweavers.com> writes: > Module: wine > Branch: master > Commit: aa9dcb42019e0ebc0913d1a56b150684212099ea > URL: http://source.winehq.org/git/wine.git/?a=commit;h=aa9dcb42019e0ebc0913d1a56… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Jan 22 23:18:45 2007 +0100 > > oleaut32/tests: Add tmarshal test. Sorry, that one should of course have been credited to Rob Shearman, not sure why my name got in there instead... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: WM_SETFONT on button shouldn't repaint directly
by Clinton Stimpson 23 Jan '07

23 Jan '07

Anything wrong with this patch? It hasn't been accepted. Thanks, Clint Clinton Stimpson wrote: > This patch includes a couple improvements over the patch submitted > yesterday. > > Fix WM_SETFONT on a button to invalidate the rect instead of painting it > directly. > Test included. > > Thanks, > Clinton Stimpson > > ChangeLog: > user32: don't repaint button directly when setting font > > > ------------------------------------------------------------------------ > > Index: dlls/user32/button.c > =================================================================== > RCS file: /home/wine/wine/dlls/user32/button.c,v > retrieving revision 1.1 > diff -u -r1.1 button.c > --- dlls/user32/button.c 16 Nov 2006 14:02:17 -0000 1.1 > +++ dlls/user32/button.c 19 Jan 2007 06:03:45 -0000 > @@ -410,7 +410,7 @@ > > case WM_SETFONT: > set_button_font( hWnd, (HFONT)wParam ); > - if (lParam) paint_button( hWnd, btn_type, ODA_DRAWENTIRE ); > + if (LOWORD(lParam)) InvalidateRect(hWnd, NULL, TRUE); > break; > > case WM_GETFONT: > Index: dlls/user32/tests/msg.c > =================================================================== > RCS file: /home/wine/wine/dlls/user32/tests/msg.c,v > retrieving revision 1.15 > diff -u -r1.15 msg.c > --- dlls/user32/tests/msg.c 9 Jan 2007 12:11:42 -0000 1.15 > +++ dlls/user32/tests/msg.c 19 Jan 2007 06:03:45 -0000 > @@ -4159,6 +4159,14 @@ > { WM_CAPTURECHANGED, sent|wparam|defwinproc, 0 }, > { 0 } > }; > +static const struct message WmSetFontButtonSeq[] = > +{ > + { WM_SETFONT, sent }, > + { WM_PAINT, sent }, > + { WM_ERASEBKGND, sent|defwinproc }, > + { WM_CTLCOLORBTN, sent|defwinproc }, > + { 0 } > +}; > > static WNDPROC old_button_proc; > > @@ -4239,6 +4247,9 @@ > unsigned int i; > HWND hwnd; > DWORD dlg_code; > + MSG msg; > + LOGFONTA lf; > + HFONT zfont; > > subclass_button(); > > @@ -4278,6 +4289,25 @@ > > SendMessageA(hwnd, WM_LBUTTONUP, 0, 0); > ok_sequence(WmLButtonUpSeq, "WM_LBUTTONUP on a button", FALSE); > + > + while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); > + flush_sequence(); > + > + lstrcpyA(lf.lfFaceName, "Symbol"); > + lf.lfHeight = 10; > + lf.lfItalic = 0; > + lf.lfEscapement = 0; > + lf.lfOrientation = 0; > + lf.lfUnderline = 0; > + lf.lfStrikeOut = 0; > + lf.lfWeight = 3; > + lf.lfWidth = 10; > + zfont = CreateFontIndirectA(&lf); > + SendMessageA(hwnd, WM_SETFONT, (WPARAM)zfont, TRUE); > + while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); > + ok_sequence(WmSetFontButtonSeq, "WM_SETFONT on a button", FALSE); > + DeleteObject(zfont); > + > DestroyWindow(hwnd); > } > > > > ------------------------------------------------------------------------ > >

2 1

Re: Howdy! Newbie with keyboard patches.
by seebs＠plethora.net 22 Jan '07

22 Jan '07

Someone asked for a copy in unified diff format. So, here's the version that also translates F25-F32 into control-alt-shift (F1-F8). I don't know my way around the rest of the tree to encode this cleanly as an option for winecfg. --- wine-0.9.29/dlls/winex11.drv/keyboard.c 2007-01-09 09:42:47.000000000 -0600 +++ wine-0.9.29.patch/dlls/winex11.drv/keyboard.c 2007-01-22 14:18:23.000000000 -0600 @@ -1020,9 +1020,9 @@ /* function keys */ VK_F1, VK_F2, VK_F3, VK_F4, VK_F5, VK_F6, VK_F7, VK_F8, VK_F9, VK_F10, /* FFC0 */ - VK_F11, VK_F12, VK_F13, VK_F14, VK_F15, VK_F16, 0, 0, /* FFC8 */ - 0, 0, 0, 0, 0, 0, 0, 0, /* FFD0 */ - 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ + VK_F11, VK_F12, VK_F13, VK_F14, VK_F15, VK_F16, VK_F17, VK_F18, /* FFC8 */ + VK_F19, VK_F20, VK_F21, VK_F22, VK_F23, VK_F24, VK_F25, VK_F26, /* FFD0 */ + VK_F27, VK_F28, VK_F29, VK_F30, VK_F31, VK_F32, 0, 0, /* FFD8 */ /* modifier keys */ 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ VK_CONTROL, VK_CAPITAL, 0, VK_MENU, @@ -1066,8 +1066,8 @@ /* function keys */ 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x40, 0x41, 0x42, 0x43, 0x44, /* FFC0 */ - 0x57, 0x58, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFC8 */ - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFD0 */ + 0x57, 0x58, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, /* FFC8 */ + 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x76, 0x00, 0x00, /* FFD0 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* FFD8 */ /* modifier keys */ 0x00, 0x2A, 0x36, 0x1D, 0x11D, 0x3A, 0x00, 0x38, /* FFE0 */ @@ -1465,7 +1465,35 @@ if ( event->type == KeyRelease ) dwFlags |= KEYEVENTF_KEYUP; if ( vkey & 0x100 ) dwFlags |= KEYEVENTF_EXTENDEDKEY; - X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); + if ((vkey & 0xFF) >= VK_F13 && (vkey & 0xFF) <= VK_F24) { + /* translate to control-alt-F(N-12) */ + vkey = vkey - 12; + if (event->type != KeyRelease) { + X11DRV_send_keyboard_input(VK_MENU, 0, 0, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_CONTROL, 0, 0, event_time, 0, 0 ); + } + X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); + if (event->type != KeyRelease) { + X11DRV_send_keyboard_input(VK_CONTROL, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_MENU, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); + } + } else if ((vkey & 0xFF) >= VK_F25 && (vkey & 0xFF) <= VK_F32) { + /* translate to control-alt-shift-F(N-24) */ + vkey = vkey - 24; + if (event->type != KeyRelease) { + X11DRV_send_keyboard_input(VK_MENU, 0, 0, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_CONTROL, 0, 0, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_SHIFT, 0, 0, event_time, 0, 0 ); + } + X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); + if (event->type != KeyRelease) { + X11DRV_send_keyboard_input(VK_SHIFT, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_CONTROL, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); + X11DRV_send_keyboard_input(VK_MENU, 0, KEYEVENTF_KEYUP, event_time, 0, 0 ); + } + } else { + X11DRV_send_keyboard_input( vkey & 0xff, bScan, dwFlags, event_time, 0, 0 ); + } } } } @@ -2253,8 +2281,10 @@ function keys. Soooo.. We will leave the table alone and fudge the lookup here till the other part is found and fixed!!! */ - if ( ((scanCode >= 0x13b) && (scanCode <= 0x144)) || - (scanCode == 0x157) || (scanCode == 0x158)) + if (((scanCode >= 0x13b) && (scanCode <= 0x144)) || + ((scanCode >= 0x164) && (scanCode <= 0x16e)) || + (scanCode == 0x157) || (scanCode == 0x158) || + (scanCode == 0x176)) scanCode &= 0xff; /* remove "extended-key" flag for Fx keys */ /* let's do scancode -> keycode -> keysym -> String */ --- wine-0.9.29/include/winuser.h 2007-01-09 09:42:47.000000000 -0600 +++ wine-0.9.29.patch/include/winuser.h 2007-01-22 13:56:34.000000000 -0600 @@ -3595,7 +3595,14 @@ #define VK_F22 0x85 #define VK_F23 0x86 #define VK_F24 0x87 -/* 0x88-0x8F Unassigned */ +#define VK_F25 0x88 +#define VK_F26 0x89 +#define VK_F27 0x8A +#define VK_F28 0x8B +#define VK_F29 0x8C +#define VK_F30 0x8D +#define VK_F31 0x8E +#define VK_F32 0x8F #define VK_NUMLOCK 0x90 #define VK_SCROLL 0x91 #define VK_OEM_NEC_EQUAL 0x92

1 0

Re: kernel32: Don't require full access to the newly created process and thread.
by Robert Shearman 22 Jan '07

22 Jan '07

Vitaliy Margolen wrote: > - req->process_access = PROCESS_ALL_ACCESS; > + req->process_access = MAXIMUM_ALLOWED | PROCESS_ALL_ACCESS; > req->process_attr = (psa && (psa->nLength >= sizeof(*psa)) && psa->bInheritHandle) ? OBJ_INHERIT : 0; > - req->thread_access = THREAD_ALL_ACCESS; > + req->thread_access = MAXIMUM_ALLOWED | THREAD_ALL_ACCESS; This looks wrong/confusing. I don't think MAXIMUM_ALLOWED does anything more when or'd with specific access rights. -- Rob Shearman

2 2

Re: comctl32: Fix the updown control test to pass under XP
by Lei Zhang 22 Jan '07

22 Jan '07

Hey, I was just about to send a similar patch in as well. I mentioned this in a different thread yesterday, but the updown ok_sequence_() function is not honoring the optional flag, you need this chunk of code as well: diff --git a/dlls/comctl32/tests/updown.c b/dlls/comctl32/tests/updown.c @@ -279,6 +280,8 @@ static void ok_sequence_(int sequence_in expected++; actual++; } + else if (expected->flags & optional) + expected++; else if (todo) { failcount++; On 1/20/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Hello, > > this patch makes the updown test pass cleanly under XP, and (inadvertently) > allows one more message sequence to pass under Wine. > > Changelog: > comctl32: Fix the updown control test to pass under XP. > > --- > dlls/comctl32/tests/updown.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/updown.c b/dlls/comctl32/tests/updown.c > index e0b8131..9a9c493 100644 > --- a/dlls/comctl32/tests/updown.c > +++ b/dlls/comctl32/tests/updown.c > @@ -109,6 +109,7 @@ static const struct message create_parent_wnd_seq[] = { > { WM_SETFOCUS, sent|wparam|defwinproc, 0 }, > /* Win9x adds SWP_NOZORDER below */ > { WM_WINDOWPOSCHANGED, sent, /*|wparam, SWP_SHOWWINDOW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE*/ }, > + { WM_NCCALCSIZE, sent|wparam|optional, 1 }, > { WM_SIZE, sent }, > { WM_MOVE, sent }, > { 0 } > @@ -123,7 +124,7 @@ static const struct message add_updown_with_edit_seq[] = { > { WM_WINDOWPOSCHANGING, sent }, > { WM_NCCALCSIZE, sent|wparam, TRUE }, > { WM_WINDOWPOSCHANGED, sent }, > - { WM_SIZE, sent|wparam|lparam|defwinproc, SIZE_RESTORED, MAKELONG(91, 75) }, > + { WM_SIZE, sent|wparam|defwinproc, SIZE_RESTORED /*, MAKELONG(91, 75) exact size depends on font */ }, > { 0 } > }; > > @@ -202,6 +203,8 @@ static void ok_sequence_(int sequence_index, const struct message *expected, > > while (expected->message && actual->message) > { > + trace_( file, line)("expected %04x - actual %04x\n", expected->message, actual->message); > + > if (expected->message == actual->message) > { > if (expected->flags & wparam) > @@ -356,6 +359,8 @@ static LRESULT WINAPI parent_wnd_proc(HWND hwnd, UINT message, WPARAM wParam, LP > message != WM_GETICON && > message != WM_DEVICECHANGE) > { > + trace("parent: %p, %04x, %08x, %08lx\n", hwnd, message, wParam, lParam); > + > msg.message = message; > msg.flags = sent|wparam|lparam; > if (defwndproc_counter) msg.flags |= defwinproc; > @@ -413,6 +418,8 @@ static LRESULT WINAPI edit_subclass_proc(HWND hwnd, UINT message, WPARAM wParam, > LRESULT ret; > struct message msg; > > + trace("edit: %p, %04x, %08x, %08lx\n", hwnd, message, wParam, lParam); > + > msg.message = message; > msg.flags = sent|wparam|lparam; > if (defwndproc_counter) msg.flags |= defwinproc; > @@ -459,6 +466,8 @@ static LRESULT WINAPI updown_subclass_proc(HWND hwnd, UINT message, WPARAM wPara > LRESULT ret; > struct message msg; > > + trace("updown: %p, %04x, %08x, %08lx\n", hwnd, message, wParam, lParam); > + > msg.message = message; > msg.flags = sent|wparam|lparam; > if (defwndproc_counter) msg.flags |= defwinproc; > @@ -519,7 +528,7 @@ static void test_create_updown_control(void) > updown = create_updown_control(); > ok(updown != NULL, "Failed to create updown control\n"); > ok_sequence(PARENT_SEQ_INDEX, add_updown_to_parent_seq, "add updown control to parent", TRUE); > - ok_sequence(EDIT_SEQ_INDEX, add_updown_with_edit_seq, "add updown control with edit", TRUE); > + ok_sequence(EDIT_SEQ_INDEX, add_updown_with_edit_seq, "add updown control with edit", FALSE); > > flush_sequences(); > > -- > 1.4.4.4 > > > > > >

1 0

Re: [4] snmpapi: Implement SnmpUtil{DbgPrint, IdsToA, OidToA, PrintAsnAny, PrintOid}.
by Alexandre Julliard 22 Jan '07

22 Jan '07

Hans Leidekker <hans(a)it.vu.nl> writes: > +/*********************************************************************** > + * SnmpUtilPrintOid (SNMPAPI.@) > + */ > +void WINAPI SnmpUtilPrintOid(AsnObjectIdentifier *oid) > +{ > + unsigned int i; > + > + TRACE("(%p)\n", oid); > + > + if (!oid) return; > + > + for (i = 0; i < oid->idLength; i++) > + { > + printf("%u", oid->ids[i]); > + if (i < oid->idLength - 1) printf("."); > + } > +} You don't want to use stdio functions in Wine. If apps really depend on these functions you'd have to use msvcrt, but otherwise you can simply use TRACE (or not implement them at all). -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [AppDB] Langauge fixes for the FAQ
by Francois Gouget 22 Jan '07

22 Jan '07

On Sat, 20 Jan 2007, Alexander Nicolaysen Sørnes wrote: > Langauge fixes for the FAQ. -Q: How can I submit How-to's? +Q: How can I submit how-to's? I tend to prefer 'howto' or 'how to' rather than 'how-to'. Also, plurals normally don't have a single quote. So I'd write 'howtos'. Alternately this could be rephrased as 'How can I submit a how to?'. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

5 4

Re: SHELL32: Implement the property sheet extension array functions (resend)
by Thomas Weidenmueller 22 Jan '07

22 Jan '07

Any feedback for why the patch hasn't been accepted? - Thomas

1 0

Re: [PATCH 1/14] winex11.drv: Make X11DRV_window_to_X_rect use hwnd instead of win_data
by Alexandre Julliard 22 Jan '07

22 Jan '07

Pierre d'Herbemont <pdherbemont(a)free.fr> writes: > -void X11DRV_window_to_X_rect( struct x11drv_win_data *data, RECT *rect ) > +void X11DRV_window_to_X_rect( HWND hwnd, RECT *rect ) > { > RECT rc; > > - if (!data->managed) return; > + if (!is_window_managed(hwnd)) return; > if (IsRectEmpty( rect )) return; This won't work, is_window_managed() will re-evaluate the managed flag so it will give wrong results if the window style has changed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 7/14] user32: Send the WM_NCCREATE message from user32's CreateWindow
by Robert Shearman 22 Jan '07

22 Jan '07

Pierre d'Herbemont wrote: > @@ -1031,18 +1032,6 @@ BOOL X11DRV_CreateWindow( HWND hwnd, CRE > /* get class or window DC if needed */ > alloc_window_dce( data ); > > - /* send WM_NCCREATE */ > - TRACE( "hwnd %p cs %d,%d %dx%d\n", hwnd, cs->x, cs->y, cs->cx, cs->cy ); > - if (unicode) > - ret = SendMessageW( hwnd, WM_NCCREATE, 0, (LPARAM)cs ); > - else > - ret = SendMessageA( hwnd, WM_NCCREATE, 0, (LPARAM)cs ); > - if (!ret) > - { > - WARN("aborted by WM_xxCREATE!\n"); > - return FALSE; > - } > - > I'm not an expert in this area by any means, but couldn't there now be a problem where calling GetDCEx on the window during WM_NCCREATE processing would fail? Maybe there should be a PreCreateWindow function? -- Rob Shearman

2 1

Re: [2/2] shell32: Add proper support for SHGetFileInfo(SHGFI_ICONLOCATION | SHGFI_USEFILEATTRIBUTES).
by Frank Richter 22 Jan '07

22 Jan '07

On 18.01.2007 16:23, Francois Gouget wrote: > + if (dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + { > + lstrcpyW(psfi->szDisplayName, swShell32Name); > + psfi->iIcon = -IDI_SHELL_FOLDER; > + } At least on Windows, folders have a file type, too - see HKCR\Folder. So maybe use 'HCR_GetDefaultIconW(L"Folder", ...)' when the directory attribute is set, and 'HCR_GetDefaultIconW(sTemp, ...)' otherwise? -f.r.

2 1

Re: server: Reverse return value and status in token_access_check to be consistent.
by Robert Shearman 22 Jan '07

22 Jan '07

Vitaliy Margolen wrote: > Change Log: > - server: Reverse return value and status in token_access_check to be consistent. > - server: Do not set successful status by default. Set it explicitly in each case. > - advapi32: Add few tests. > > It is some-what confusing to have token_access_check return 2 statuses. And > even more so, when it doesn't match with the native. Usually function returns > a status if call to it succeeded (all parameters are valid, caller allowed > to perform requested operation, etc). And extra parameters would indicate > if some check(s) succeeded or not. > I agree with the spirit of this patch, but it is not clear which part of this patch fixes the new tests. So please split this patch up into tests, cleanups and bug fixes. > @@ -866,24 +862,17 @@ static unsigned int token_access_check( > ace = ace_next( ace ); > } > > + done: > The indentation of this label is incorrect. -- Rob Shearman

1 0

Re: user32: Some apps pass a color bitmap as a mask to CreateIconIndirect, convert it to b/w
by Kirill K. Smirnov 22 Jan '07

22 Jan '07

Hi, these patches http://www.winehq.org/pipermail/wine-patches/2007-January/035014.html http://www.winehq.org/pipermail/wine-patches/2007-January/035052.html totally break qip IM icons. (www.qip.ru). I suspect the reason is hidden in GetDIBits(...) - resulting AND mask is not correct. XOR mask is correct. BTW, these patches heal systray taskmgr icon! -- Kirill

2 1

Re: [PATCH 1/2] ntdll: Implement RtlDecodePointer and RtlEncodePointer
by Alexandre Julliard 22 Jan '07

22 Jan '07

Mike McCormack <mike(a)codeweavers.com> writes: > + /* there's no ntdll.RtlInterlockedCompareExchangePointer() ... */ > + RtlEnterCriticalSection( &pointer_obfuscator_cs ); No, but we have interlocked_cmpxchg_ptr() in libwine... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/8] server: export few functions we will need for security descriptor checks.
by Dmitry Timoshkov 22 Jan '07

22 Jan '07

"Vitaliy Margolen" <wine-patches(a)kievinfo.com> wrote: > +++ b/server/security.h > @@ -41,10 +41,16 @@ extern const LUID SeCreateGlobalPrivileg > > extern const PSID security_interactive_sid; > > +extern void map_generic_mask(unsigned int *mask, const GENERIC_MAPPING *mapping); > +++ b/server/token.c > /* maps from generic rights to specific rights as given by a mapping */ > -static inline void map_generic_mask(unsigned int *mask, const GENERIC_MAPPING *mapping) > +inline void map_generic_mask(unsigned int *mask, const GENERIC_MAPPING *mapping) 'inline' above probably should be removed. -- Dmitry.

1 0

Re: user32: Restore old WM_SIZE handler in mdi child
by Peter Oberndorfer 22 Jan '07

22 Jan '07

On Monday 08 January 2007 11:31, Dmitry Timoshkov wrote: > Hello, Hi, this patch seems to cause http://bugs.winehq.org/show_bug.cgi?id=7190 Each time a MDI child window gets a WM_SIZE the left most menu entry disapperars. The problem is that MDI_RestoreFrameMenu is called for each WM_SIZE message, that does not maximize the window, instead of only beeing called when window goes from maximized to normal And MDI_RestoreFrameMenu removes the left most menu entry, in belief is the document icon of a maximized child. What is the reason for restoring the old code? Does the new code break some apps? The attached patch, which reverts a part of the revert "fixes" the problem for my test app(ollydbg) But i guess it is totally wrong :-) > > this patch restores (almost completely) an old WM_SIZE handler in mdi child, > including the comment /* do not change */. > > Changelog: > user32: Restore old WM_SIZE handler in mdi child. > Greetings Peter

2 1

Re: comctl32/tests/updown failures on xp?
by Dan Kegel 21 Jan '07

21 Jan '07

On 1/19/07, James Hawkins <truiken(a)gmail.com> wrote: > It sounds like your build environment isn't set up correctly. The > easiest way to work on and compile the tests is to run > wine/tools/winapi/msvcmaker under cygwin in Windows. This will create > several project files, one for each dll etc, and a winetest project > that can be opened with Visual C++ (and converted to a solution). Nah, I prefer bare metal commandline. I like knowing what's going on under the hood. > No matter which method you use to compile the tests, you should have the > latest Windows SDK installed (not the Platform SDK, which the Windows > SDK is replacing). OK, I'll try that... > If you run 'make test', you shouldn't see the errors > (because they're wrapped by todo_wine). Whoops, forgot about that! When running without 'make test', you have to set the environment variable WINETEST_PLATFORM=wine on wine for the todo_wine to work. Thanks! - Dan

2 1

WINSPOOL_EnumPrinters Found 0 printers on system with 1 parallel CUPS printer
by Michael [Plouj] Ploujnikov 21 Jan '07

21 Jan '07

Hi, I'm sending this message to both wine-users and wine-devel in hopes of getting help from someone with knowledge of Wine's internals. I've had this problem for a while, but only recently have I realized that I better fix it soon! I compile my own Wine out of git. Currently, I'm running wine-0.9.29-g5441536 but this issue appeared long before that. Moreover, I stopped being able to print between Wine updates, so I don't think it is anything to do with changes in Wine's code. The simplest way to reproduce my problem is try printing in notepad. First, I open notepad: $ WINEDEBUG=+winspool wine notepad trace:winspool:WINSPOOL_EnumPrinters Found 0 printers trace:winspool:WINSPOOL_EnumPrinters Found 0 printers Next, I type some text. Then I go to "File -> Printer Setup". Wine outputs this to the console: trace:winspool:WINSPOOL_EnumPrinters Found 0 printers fixme:winspool:WINSPOOL_EnumPrinters We don't handle PRINTER_ENUM_CONNECTIONS and I see a message box saying: "Before you can perform printer-related tasks such as page setup or printing a document, you need to install a printer. Please install one and retry." I've tried deleting and re-creating my ~/.wine multiple times. I know that wine is compiled with CUPS support $ ~/apps/wine-git/configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" --without-libcapi20 --without-libhal --without-libicu --without-libldap --without-libsane > /tmp/wine-config $ grep -i cups /tmp/wine-config checking cups/cups.h usability... yes checking cups/cups.h presence... yes checking for cups/cups.h... yes checking for -lcups soname... libcups.so I have a local CUPS printer installed on my system: $ lpstat -t scheduler is running system default destination: HPDeskjet710c device for HPDeskjet710c: parallel:/dev/lp0 HPDeskjet710c accepting requests since Thu Jan 18 20:26:33 2007 printer HPDeskjet710c is idle. enabled since Thu Jan 18 20:26:33 2007 and I am able to print to it from other Linux applications. I considered tracing the winespool code ot see where it fails to find my printer, but it looks way too cryptic for my uninitiated eyes. Any help would be appreciated. -- Libre Software: http://www.gnu.org/philosophy/free-sw.html

3 2

Re: dbghelp: fix debuglink crash, accessing memory after munmap
by Eric Pouech 21 Jan '07

21 Jan '07

Peter Oberndorfer a écrit : > Winedbg would crash on my system when trying to set a breakpoint (loading the debug info from a .debug file) > The problem is that hash_table_elt adds the symbols of the .debug file to the hashtable of the parent file. > But at the time elf_new_public_symbols is run, the sections of the .debug file are already unmapped. > In addition to that the symbols in .debug would be added 2 times (.so and .debug file) > > Changelog: > dbghelp: fix debuglink crash, accessing memory after munmap > I don't think it's the right fix IMO, we shouldn't call elf_new_public_symbols while processing the .gnu_link target, but in the parent call to elf_load_debug_from_map can you provide more information on the crash itself (which reference is lost to an unmapped section) A+

2 1

3DMark2000 regression
by Stefan Dösinger 21 Jan '07

21 Jan '07

Hi Dmitry, Your "Do not play with WS_VISIBLE" patch(5ddac44dc2a6637613407fa900d3fafac37e70d8) in wined3d causes a regression with 3DMark2000. The rendering in this game is not visible. Readding the SWP_SHOWWINDOW flag to the SetWindowPos calls fixes the problem. But I have the impression that the main point of your patch was removing this flag, so I don't want to just add it again. What were the reasons for removing the SWP_SHOWWINDOW flag? Stefan

2 3

Questions concering an application I maintain
by Jacob Alberty 20 Jan '07

20 Jan '07

I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).

5 8

re: regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
by Dan Kegel 20 Jan '07

20 Jan '07

On 1/18/07, Tom Lowe <tomlowe1 at earthlink.net> wrote: > Using ubuntu 6.10 and wine packages from > http://wine.budgetdedicated.com/apt edgy main > > TaxACT 2006 ( free download from http://www.taxact.com ) works > "out-of-the-box" with 0.9.28. Checking for program updates and > electronic filing "hang" with 0.9.29. > > When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was > able to connect and file my tax return. We had the same problem with Google Earth, and Rob Shearman kindly provided a fix: http://www.winehq.org/pipermail/wine-cvs/2007-January/029362.html Could be the same problem you hit. If so, it's already fixed in cvs. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

array out of bounds checking results
by Marcus Meissner 20 Jan '07

20 Jan '07

Hi, Yesterdays TRUNK gcc features array overflow checking... I have run it against WINE and found 3 index overflows. arb_program_shader.c:950: Warnung: array subscript is above array bounds This is the place in C: } else if(GL_SUPPORT(GL_VERTEX_PROGRAM_ARB)) { and in preprocessed: } else if(((*gl_info).supported[0x8620] != 0)) { The supported array is way smaller than that. Likely a typo. winaspi32.c:239: Warnung: array subscript is above array bounds winaspi32.c:239: Warnung: array subscript is above array bounds This is this part: if (rqbuf[15]&0x8) { TRACE("Pointer at %d, bit %d\n",rqbuf[16]*256+rqbuf[17],rqbuf[15]&0x7); } rqbuf points to SenseArea which is only 16 byte. I am unclear what exactly is meant to be done here. We only ever copy 16 Byte into this array anyway. Ciao, Marcus

3 2

java problem with builtin msvcrt.dll (need debugging help)
by Stefan Leichter 20 Jan '07

20 Jan '07

Hello, i found a problem with java (1.4.2_05) and builtin msvcrt.dll. The attached java code exhibits the problem. It produces an exception with builtin dll. As difference i identified the call to java._Java_java_io_WinNTFileSystem_getLength, what is basicaly a wrapper around msvcrt._(w)stati64. I have compared the result (dumped struct _stat) from _stati84 running with builtin and native version of msvcrt.dll. The result is the same. I tried winedbg, but i was not able to place a breakpoint neither in _Java_java_io_WinNTFileSystem_getLength nor msvcrt._stati64. Can someone please tell me either - how to place breakpoint in this functions or - suggest anopther way how to find the problem. The problem is independent of the emulated windows version. Thanks for help Stefan

2 1

Re: [Wine] www.winehq.com newsletter dead forever?
by Hiji 20 Jan '07

20 Jan '07

The developer's list was talking about this a couple of weeks back. Somebody was going to take over and continue the newsletter, but nothing yet. ----- Original Message ---- From: Michal Seliga <michal.seliga(a)visicom.sk> To: wine-users(a)winehq.org Sent: Tuesday, January 16, 2007 10:14:31 AM Subject: [Wine] www.winehq.com newsletter dead forever? I know its like this for a long time, but i have to ask... what happened with Wine newsletter? it was interesting reading and now its gone there is no update since last wineconf.... _______________________________________________ wine-users mailing list wine-users(a)winehq.org http://www.winehq.org/mailman/listinfo/wine-users ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121

6 7

Greenville Revisited, A new look at FontForge
by Wierd_w 19 Jan '07

19 Jan '07

OK, Due to the recent interest in Greenville, and the fact that enough time has passed that my original rage/disgust/contempt at freetype has faded, I decided to grab a recent Cygwin port of FontForge, and take a spin. FontForge is able to import the compiled glyphsets I produce with Fontlab(the expensive font tool) pretty neatly, and also seems to have fairly nice support for SBITs in outputted OTF and TTF files. This means I should be able (with hard work) to convert Greenville into a FontForge project file. However, the generated font will contain bitmaps of the glyphs for PPeM ranges 7-13, as the Type-1 hinting mechanisms inside FontForge are insufficient to cleanly hint the outlines for small point sizes. This will make the font files generated a tad bit 'large'. I will combat this as much as possible by using glyph composites as much as possible. (Basically aliasing to existant glyph outlines with new placement data- This not only improves consistancy of glyph shape, but also reduces the size of the outline glyphset. EG, one can make an "ü" by using the oderesis (The double dot accent) and the "u", and combining aliases of them into a new glyph. The same oderesis glyph can be used on any such accented glyph, and prevents it having to be drawn over and over again, reducing glyphset complexity, and thus filesize. So, pretty much all of Latin-A and Latin-B can be generated using a small set of diacriticals, and Latin-1, if you know what you are doing. :P It's like getting Latin-A and Latin-B for free.) I am comforted to read that FontForge's developer is also "unsatisfied" with the lack of 'quality' truetype instruction generation, and hope that he is able to someday include a real truetype hinter. In the meantime though, SBITs will have to do. (sigh) I still perfer FontLab for my typesetting needs, as it is more responsive on my host platform, and has better Unicode character reordering support (It understands the **FULL** Unicode range.), and a number of other features which I have grown fond of. However, the time I have available to work on it is very limited. I have to be available to assist students all day on Mondays and Wednesdays, and I take classes myself on Tuesdays, Thursdays, and Saturdays. This means that Fridays and Sundays are the only days I have available, and that time is difficult to budget. To try and improve my functional time on this hobby project, I need to get my laptop's battery serviced (as it is an old clunker, but still able to run both FontLab and FontForge+Cygwin) so I can work on it on my downtime at the NIAR building (which admittedly can be several hours a day. In fact, I am idling right now...), which will cost me around 90$. This will have to wait until my next bi-weekly pay deposit, as my disposable income is near 0$ right now, as a result of yet another tuition rate hike. (The university must think I am litterally made out of money....) I just wish there was a win32 native port of Fontforge, but I wont hold my breath. (I really, REALLY REALLY hate cygwin.) Status: I will have to begin re-examining the glyphs that the windows rasterizer returns for Tahoma at various point sizes in order to formulate suitable SBITs, but that will have to wait until after I have completed the glyphset to a degree that I consider at least serviceable. What unicode ranges, and or- codepages, would the WINEHQ community require of a Tahoma replacement? Ideally it would be all of them that MS Tahoma currently supports, but that would require me to draw characters that I have no functional knowledge of-- EG, Arabic, Cyrillic, Greek, and Hebrew characters. Arabic is the one that has me a bit worried, as if done wrong, the ligature substitution will be wonk, and I dont have the functional knowledge of how the language even works to produce such ligature substitution to begin with. Simmilar problem with Hebrew, but fewer glyphs to draw. I am currently shooting to have a full Latin-1, Latin-A, and Latin-B + Greek + Cyrillic glyphset before I start working on FontForge porting, and SBIT generation. I allready have Latin-1 and Latin-A complete (at least the glyphs that Tahoma supports), and am about 75% through Latin-B. I havent really touched Greek or Cyrillic yet. When completed though, it should support the US, Canada, and pretty much all of Europe. CJK ligatures, Arabic Ligatures, and Hebrew Ligatures would need to be done by people who are familiar with those glyphs, know what they mean, and how they are "Supposed" to look, as I consider myself unqualified to do them properly. I hope to have Greenville mostly functional (In North America and Europe) by that time, and to drop the fontforge project into WINEHQ custody, and see how it grows from there. Feedback would be greatly appreciated. ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

3 2

Re: Makefiles: Add a default BISONFLAGS variable for widl, wmc, wrc and wpp.
by Alexandre Julliard 19 Jan '07

19 Jan '07

Robert Shearman <rob(a)codeweavers.com> writes: > I disagree. I had a resource file that had an error because I forgot > to define "IDC_STATIC" to a number and all I got from wrc was an > unhelpful "syntax error" that seemed to point to the wrong line. I > ended up using the debugging option to find out what was causing this > error. If you can suggest a better solution, I'd go for it. Well, I don't know, but I have never had to resort to the parser debugging code for that sort of thing. In worst cases looking at the preprocessed file is normally enough to find the problem. It's true that line numbers are sometimes off in wrc errors, and that should clearly be fixed; but the parser debug stuff is not something that should be exposed to users. Do you still have the file that shows an unhelpful error? You should file a bug with it, and I'll have a look. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: COMCTL32: Fix InitCommonControlsEx prototype
by Mike McCormack 19 Jan '07

19 Jan '07

Thomas Weidenmueller wrote: > BOOL WINAPI > -InitCommonControlsEx (LPINITCOMMONCONTROLSEX lpInitCtrls) > +InitCommonControlsEx (const INITCOMMONCONTROLSEX *picce) The version of the Windows Platform SDK that I'm looking at agrees with Wine. There is also no reason to make a pointless change to the name of the argument, so this patch looks pointless and wrong to me. Mike

5 4

Re: [3/5] wined3d: Use SetupFullscreenWindow() to make the window fullscreen
by Stefan Dösinger 19 Jan '07

19 Jan '07

Am Donnerstag 18 Januar 2007 23:41 schrieb H. Verbeet: > Changelog: > - Use SetupFullscreenWindow() to make the window fullscreen I do not think that SetupFullscreenWindow should stay publically exported from wined3d. I think it would be better if IWineD3DDevice_SetFullscreen calls it, and it is made sure that SetFullscreen is called when needed with a true / false flag. DDraw calls it already, and I think Init3D() calls it too for d3d8 and d3d9. Not sure about IWineD3DDevice_Reset.

2 1

Winelib over Solaris/SPARC
by keyur＠elegantmicroweb.com 19 Jan '07

19 Jan '07

Thanks Eric and Mike for your in-sights. Your feedback has been helpful. Regards, Keyur

1 0

comctl32/tests/updown failures on xp?
by Dan Kegel 19 Jan '07

19 Jan '07

While getting ready for cs130 (thanks to Lei and James for all the help), I tried building and running comctl32/tests/updown.c standalone on winxp using Visual C++ Express 2005 (the freely downloadable one) and the Platform SDK (also freely downloadable, needed for e.g. user32.lib and .h files). First I tried building it by starting cmd with the visual studio environment vars defined (using the handy Start/Programs/Visual C++/Visual Studio Tools/Visual Studio Command Prompt start menu entry installed by visual C++): cl -DSTANDALONE -D_X86_ -I../../../include updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about redefinitions in rpc.h. I worked around that as suggested by Lei Zhang by avoiding letting cl see any of the Wine headers but wine/test.h, by doing mkdir wine copy ..\..\..\include\wine\test.h wine cl -DSTANDALONE -D_X86_ updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about WM_QUERYVISTATE being undefined. I worked around that as suggested by Lei Zhang by defining _WIN32_WINNT to the right value: cl -DSTANDALONE -D_X86_ -D_WIN32_WINNT=0x502 updown.c user32.lib gdi32.lib comctl32.lib That failed to link, complaining it couldn't find user32.lib. I worked around that by doing echo setenv LIB=%LIB% > setenv.bat editing that batch file to append ;C:\Program Files\Microsoft Platform SDK\Lib and running it. That worked (whew), but running the test found two failures: updown.c:509: Test failed: create parent window: the msg 0x0281 was expected, but got msg 0x0007 instead updown.c:522: Test failed: add updown control with edit: in msg 0x0005 expecting lParam 0x4b005b got 0x440065 updown: 133 tests executed (0 marked as todo, 2 failures), 0 skipped. I guess it needs a bit of tweaking. The system I tested it on is running Win XP Professional Version 2002 Service Pack 2. - Dan

2 2

user32/tests: Mysterious WinXP 0xae and 0xef messages.
by Kirill K. Smirnov 19 Jan '07

19 Jan '07

Hi! While improving rejected tests for WM_SETICON: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html I've noticed, that WinXP sends some mysterious message 0xae, that breaks tests. Googling it, I've found few notes indicating to WM_NCUAHDRAWCAPTION [0xae] message and WM_NCUAHDRAWFRAME[0xaf]. [http://www.werkema.com/ blog/index.php?op=Default&Date=200503&blogId=1] As I understood it, these messages are used to paint WINXP-specific fancy borders and captions. But MSDN shows absolutely absence of any knowledge concerning it. AFAIK wine does not support them too. Should these messages be implemented? Or at least add mnemonics to winuser.h? Anyway, how those tests should be modified to pass under XP and other versions? Thanks, Kirill

2 1

regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
by Tom Lowe 19 Jan '07

19 Jan '07

Using ubuntu 6.10 and wine packages from http://wine.budgetdedicated.com/apt edgy main TaxACT 2006 ( free download from http://www.taxact.com ) works "out-of-the-box" with 0.9.28. Checking for program updates and electronic filing "hang" with 0.9.29. When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was able to connect and file my tax return. It has been accepted by IRS. -- Tom Lowe

2 1

iphlpapi - MacOS / BSD support
by Juan Lang 18 Jan '07

18 Jan '07

Hi Gav, > As the iphlpapi DLL is LGPLed, our patches to it are necessarily under > the LGPL as well. In fact that's not true. I added the LGPL headers for inclusion into WineHQ, but I said my patches were MIT/X11 (unless I say otherwise, which I didn't say, but I suppose is implied): http://www.winehq.org/pipermail/wine-patches/2003-May/006174.html Thanks, --Juan ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html

2 1

File buffering
by Teemu Ikonen 18 Jan '07

18 Jan '07

Hi, I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows). The program does essentially this: opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows. To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help. Teemu

3 3

[1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Christoph Bumiller 18 Jan '07

18 Jan '07

This also (partially) fixes the issue with NFS:MW where nothing except the menus appears to be draw when setting the Visual Treatment option to high. The scene is now visible, but its scaled down in the y direction and only covers about the top 2/3 of the screen ...

1 0

Re: wined3d: Synchronize window style correcting code with ddraw
by H. Verbeet 18 Jan '07

18 Jan '07

On 18/01/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Hello, > > this patch should fix the regression reported on #wine-hackers. > > Changelog: > wined3d: Synchronize window style correcting code with ddraw. > Although afaik there's nothing wrong with this patch, I do have a patch myself that moves the ddraw code for doing this to wined3d so that both use the same code.

1 0

Re: [PATCH 1/4] ntdll: Implement RtlEncode/DecodePointer
by Alexandre Julliard 18 Jan '07

18 Jan '07

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 999687a..468e5b6 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2161,6 +2161,7 @@ void WINAPI LdrInitializeThunk( ULONG unknown1, ULONG unknown2, ULONG unknown3, > > RtlEnterCriticalSection( &loader_section ); > > + rtl_generate_pointer_obfuscator(); > load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer; > if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) goto error; > if ((status = alloc_process_tls()) != STATUS_SUCCESS) goto error; It would be cleaner to initialize this the first time it's needed, instead of having to export a global function and do more work at init time for a rarely used feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: invalidate button area instead of painting immediatly
by James Hawkins 18 Jan '07

18 Jan '07

On 1/17/07, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > WM_SETFONT on a button should invalidate the area so the system can send > a WM_PAINT event, instead of painting the button immediately. > This is a partial fix for bug# 6006. > The other part of the fix is for ShowWindow(button, SW_HIDE) to cause a > WM_PAINT event on the button's parent to paint in the newly exposed region. > > Thanks, > Clinton Stimpson > > ChangeLog: > user32: invalidate button area instead of painting button immediately. > Can you write a message test for this in dlls/user32/tests/msg.c to verify your fix? Thanks, James Hawkins

1 0

Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Mirek 18 Jan '07

18 Jan '07

Hi, this patch caused big performance regression in some D3D games (Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One). Mirek Slugen Stefan Dösinger napsal(a): > This time with a FIXME for unsupported filtering options. If we implement > them, it should be done in Blt and private blitting flags used. > > > ------------------------------------------------------------------------ > > From 95f4217d366770b9b05214ae68274ce4ab4b9fb6 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Thu, 11 Jan 2007 22:39:03 +0100 > Subject: [PATCH] D3D9: Implement IDirect3DDevice9::StretchRect > > --- > dlls/d3d9/device.c | 10 +++++++--- > dlls/d3d9/directx.c | 3 +++ > dlls/wined3d/device.c | 9 --------- > include/wine/wined3d_interface.h | 2 -- > 4 files changed, 10 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index aa788af..4c27853 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -356,9 +356,13 @@ static HRESULT WINAPI IDirect3DDevice9Impl_GetFrontBufferData(LPDIRECT3DDEVICE > } > > static HRESULT WINAPI IDirect3DDevice9Impl_StretchRect(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSourceSurface, CONST RECT* pSourceRect, IDirect3DSurface9* pDestSurface, CONST RECT* pDestRect, D3DTEXTUREFILTERTYPE Filter) { > - IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > - TRACE("(%p) Relay\n" , This); > - return IWineD3DDevice_StretchRect(This->WineD3DDevice, ((IDirect3DSurface9Impl *)pSourceSurface)->wineD3DSurface, pSourceRect, ((IDirect3DSurface9Impl *)pDestSurface)->wineD3DSurface, pDestRect, (WINED3DTEXTUREFILTERTYPE) Filter); > + IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > + IDirect3DSurface9Impl *src = (IDirect3DSurface9Impl *) pSourceSurface; > + IDirect3DSurface9Impl *dst = (IDirect3DSurface9Impl *) pDestSurface; > + > + TRACE("(%p)->(%p,%p,%p,%p,%d)\n" , This, src, pSourceRect, dst, pDestRect, Filter); > + if(Filter != D3DTEXF_NONE) ERR("Texture filters not supported yet\n"); > + return IWineD3DSurface_Blt(dst->wineD3DSurface, (RECT *) pDestRect, src->wineD3DSurface, (RECT *) pSourceRect, 0, NULL); > } > > static HRESULT WINAPI IDirect3DDevice9Impl_ColorFill(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSurface, CONST RECT* pRect, D3DCOLOR color) { > diff --git a/dlls/d3d9/directx.c b/dlls/d3d9/directx.c > index f360b4e..57062b2 100644 > --- a/dlls/d3d9/directx.c > +++ b/dlls/d3d9/directx.c > @@ -170,6 +170,9 @@ static HRESULT WINAPI IDirect3D9Impl_GetDeviceCaps(LPDIRECT3D9 iface, UINT Adapt > D3D9CAPSTOWINECAPS(pCaps, pWineCaps) > hrc = IWineD3D_GetDeviceCaps(This->WineD3D, Adapter, DeviceType, pWineCaps); > HeapFree(GetProcessHeap(), 0, pWineCaps); > + > + /* Some functionality is implemented in d3d9.dll, not wined3d.dll. Add the needed caps */ > + pCaps->Caps2 |= D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES; > TRACE("(%p) returning %p\n", This, pCaps); > return hrc; > } > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 7b81f0e..5f964fb 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4930,14 +4930,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl_UpdateTexture (IWineD3DDevice *iface, I > return hr; > } > > -static HRESULT WINAPI IWineD3DDeviceImpl_StretchRect(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface, > - CONST RECT* pSourceRect, IWineD3DSurface *pDestinationSurface, > - CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) { > - IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - > - TRACE("(%p) : stub\n", This); > - return WINED3D_OK; > -} > static HRESULT WINAPI IWineD3DDeviceImpl_GetRenderTargetData(IWineD3DDevice *iface, IWineD3DSurface *pRenderTarget, IWineD3DSurface *pSurface) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > /** TODO: remove remove casts to IWineD3DSurfaceImpl * > @@ -6776,7 +6768,6 @@ const IWineD3DDeviceVtbl IWineD3DDevice_Vtbl = > IWineD3DDeviceImpl_ColorFill, > IWineD3DDeviceImpl_UpdateTexture, > IWineD3DDeviceImpl_UpdateSurface, > - IWineD3DDeviceImpl_StretchRect, > IWineD3DDeviceImpl_GetRenderTargetData, > IWineD3DDeviceImpl_GetFrontBufferData, > /*** object tracking ***/ > diff --git a/include/wine/wined3d_interface.h b/include/wine/wined3d_interface.h > index 8a685f0..4a24636 100644 > --- a/include/wine/wined3d_interface.h > +++ b/include/wine/wined3d_interface.h > @@ -469,7 +469,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > STDMETHOD(ColorFill)(THIS_ struct IWineD3DSurface* pSurface, CONST WINED3DRECT* pRect, WINED3DCOLOR color) PURE; > STDMETHOD(UpdateTexture)(THIS_ struct IWineD3DBaseTexture *pSourceTexture, struct IWineD3DBaseTexture *pDestinationTexture) PURE; > STDMETHOD(UpdateSurface)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST POINT* pDestPoint) PURE; > - STDMETHOD(StretchRect)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) PURE; > STDMETHOD(GetRenderTargetData)(THIS_ struct IWineD3DSurface* pRenderTarget, struct IWineD3DSurface* pSurface) PURE; > STDMETHOD(GetFrontBufferData)(THIS_ UINT iSwapChain,struct IWineD3DSurface* pSurface) PURE; > /*** object tracking ***/ > @@ -608,7 +607,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > #define IWineD3DDevice_ColorFill(p,a,b,c) (p)->lpVtbl->ColorFill(p,a,b,c) > #define IWineD3DDevice_UpdateTexture(p,a,b) (p)->lpVtbl->UpdateTexture(p,a,b) > #define IWineD3DDevice_UpdateSurface(p,a,b,c,d) (p)->lpVtbl->UpdateSurface(p,a,b,c,d) > -#define IWineD3DDevice_StretchRect(p,a,b,c,d,e) (p)->lpVtbl->StretchRect(p,a,b,c,d,e) > #define IWineD3DDevice_GetRenderTargetData(p,a,b) (p)->lpVtbl->GetRenderTargetData(p,a,b) > #define IWineD3DDevice_GetFrontBufferData(p,a,b) (p)->lpVtbl->GetFrontBufferData(p,a,b) > #define IWineD3DDevice_ResourceReleased(p,a) (p)->lpVtbl->ResourceReleased(p,a) > > > ------------------------------------------------------------------------ > >

3 2

Using Wine headers on Mac OS X
by Mike 18 Jan '07

18 Jan '07

Hi. I know this is unsupported but I am trying to use the Wine windows headers to port some Windows code to Mac OS X. I'm not really trying to use the Wine functionality - I use the headers more to define and map the existing Win32 defines, and datatypes to Mac OS so that I can make as few changes to the Windows code I am porting as possible. My big question is: when I add the Wine headers to my project, it seems that every datatype in the wine headers is undefined. I noticed that most wine headers don't have any #includes in them. is there some precompiled or metaheader that I should be including in all of the wine files in order to get the compiler to see the data types? Thanks, Mike

3 5

Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
by Mirek 17 Jan '07

17 Jan '07

Hi, this patch caused regression in TES: Oblivion, some objects like peoples are broken. Mirek Slugen H. Verbeet napsal(a): > Changelog: > - Rewrite shader_glsl_mov() to properly take the write mask into account > - in case of writing to an address register round the source, rather > than just dropping the fractional part > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/glsl_shader.c | 33 ++++++++++++++++++++++++--------- > 1 files changed, 24 insertions(+), 9 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 60f74c0..6579e6d 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -963,17 +963,32 @@ void shader_glsl_arith(SHADER_OPCODE_ARG* arg) { > > /* Process the WINED3DSIO_MOV opcode using GLSL (dst = src) */ > void shader_glsl_mov(SHADER_OPCODE_ARG* arg) { > - > + IWineD3DBaseShaderImpl* shader = (IWineD3DBaseShaderImpl*) arg->shader; > SHADER_BUFFER* buffer = arg->buffer; > - char tmpLine[256]; > - char dst_str[100], src0_str[100]; > - char dst_reg[50], src0_reg[50]; > - char dst_mask[6], src0_mask[6]; > + char src0_str[100]; > + char src0_reg[50]; > + char src0_mask[6]; > + DWORD write_mask; > > - shader_glsl_add_dst_param(arg, arg->dst, 0, dst_reg, dst_mask, dst_str); > - shader_glsl_add_src_param_old(arg, arg->src[0], arg->src_addr[0], src0_reg, src0_mask, src0_str); > - shader_glsl_add_dst_old(arg->dst, dst_reg, dst_mask, tmpLine); > - shader_addline(buffer, "%s%s)%s;\n", tmpLine, src0_str, dst_mask); > + write_mask = shader_glsl_append_dst(buffer, arg); > + shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], write_mask, src0_reg, src0_mask, src0_str); > + > + /* In vs_1_1 WINED3DSIO_MOV can write to the adress register. In later > + * shader versions WINED3DSIO_MOVA is used for this. */ > + if ((WINED3DSHADER_VERSION_MAJOR(shader->baseShader.hex_version) == 1 && > + !shader_is_pshader_version(shader->baseShader.hex_version) && > + shader_get_regtype(arg->dst) == WINED3DSPR_ADDR) || > + arg->opcode->opcode == WINED3DSIO_MOVA) { > + /* We need to *round* to the nearest int here. */ > + size_t mask_size = shader_glsl_get_write_mask_size(write_mask); > + if (mask_size > 1) { > + shader_addline(buffer, "ivec%d(floor(%s + vec%d(0.5))));\n", mask_size, src0_str, mask_size); > + } else { > + shader_addline(buffer, "int(floor(%s + 0.5)));\n", src0_str); > + } > + } else { > + shader_addline(buffer, "%s);\n", src0_str); > + } > } > > /* Process the dot product operators DP3 and DP4 in GLSL (dst = dot(src0, src1)) */ > > > ------------------------------------------------------------------------ > >

2 10

Re: ntdll: Declare some functions static
by Marcus Meissner 17 Jan '07

17 Jan '07

On Wed, Jan 17, 2007 at 08:20:32PM +0000, Andrew Talbot wrote: > Changelog: > ntdll: Declare some functions static. > > diff -urN a/dlls/ntdll/exception.c b/dlls/ntdll/exception.c > --- a/dlls/ntdll/exception.c 2007-01-10 22:13:12.000000000 +0000 > +++ b/dlls/ntdll/exception.c 2007-01-17 20:11:06.000000000 +0000 > @@ -374,7 +374,7 @@ > /*********************************************************************** > * RtlRaiseException (NTDLL.@) > */ > -void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT *context ) > +static void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT *context ) > { > NTSTATUS status = raise_exception( rec, context, TRUE ); > if (status != STATUS_SUCCESS) > @@ -624,7 +624,7 @@ > * ntdll-specific implementation to avoid depending on kernel functions. > * Can be removed once ntdll.spec no longer contains stubs. > */ > -void __wine_spec_unimplemented_stub( const char *module, const char *function ) > +static void __wine_spec_unimplemented_stub( const char *module, const char *function ) > { > EXCEPTION_RECORD record; This is not a good idea, it will optimize those functions away, since gcc cannot look into the DEFINE_REGS_ENTRYPOINT() assembly. Ciao, Marcs

2 1

ntdll: Declare some functions static
by Andrew Talbot 17 Jan '07

17 Jan '07

Sorry. This patch breaks compilation. Please do not apply. -- Andy.

1 0

Re: [kernel32][console][try3] Adds comment for function
by Robert Shearman 17 Jan '07

17 Jan '07

Anatoly Lyutin wrote: > + * NOTES > + * Has appeared, since Windows 2000 Professional > */ > HWND WINAPI GetConsoleWindow(VOID) > { > We don't tend to add notes like this for functions as it is meaningless in the context of Wine. Also, when adding comments you must also add a disclaimer stating that you didn't copy it from MSDN. -- Rob Shearman

1 0

Anonymous structs/unions
by Joel Parker 17 Jan '07

17 Jan '07

As seen here <http://source.winehq.org/source/include/winnt.h#L152>, we seem to be going through a lot of trouble to enable anonymous structs and unions for those compilers that support it. Why do this, especially when we need to name them anyway for those that don't? My reason for asking is that I'm doing a casual ANSI sweep of the code, and anonymous unions are causing problems (they're not allowed). I could just put in a test for __STRICT_ANSI__ and disable them if found, but that feels like gaming the system, and it's not a standard macro anyway. The best way (other than just naming all the structs/unions) is to test for __STDC__, but GCC includes that one even when not using -ansi mode. Thoughts? -- Joel Parker

3 2

[try2] user32/tests: add tests for WM_SETICON - what's wrong?
by Kirill K. Smirnov 17 Jan '07

17 Jan '07

Hi, Traditional questions from rejected patch-sender: 1) What's wrong with the patch: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html 2) What can be done to improve it? -- Kirill

2 1

Re: [3/3] WineD3D: Implement per stream offsets
by Kovács András 17 Jan '07

17 Jan '07

Call of duty 2 uses steam offsets. 2007. január 17. 00.06 dátummal Stefan Dösinger ezt írta: > Stumbled uppon that while reading up instancing. This is a functionality > technically required for all d3d9 drivers. The new functionality is not > really tested because I have no app that really needs this, but it should > not cause issues with games not using stream offsets. -- ------------------ andras NetClub Lamarr csevego.net andras(a)csevego.net ------------------

3 2

Re: Make.rules.in: Add variables for BISONFLAGS and LEXFLAGS.
by Alexandre Julliard 17 Jan '07

17 Jan '07

Robert Shearman <rob(a)codeweavers.com> writes: > Make BISONFLAGS default to generating debug information so that parser > tracing works in the various tools. You should add this to the makefile of the tool you want to debug. There's no reason to force it for all parsers, and defining it in Make.rules prevents individual makefiles from having their own flags. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] WineD3D: Implement per stream offsets
by H. Verbeet 17 Jan '07

17 Jan '07

On 17/01/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > really tested because I have no app that really needs this, but it should not > cause issues with games not using stream offsets. > I think Serious Sam 2 required stream offsets. Perhaps I should give that game another try one of these days.

2 1

Re: [3/3] WineD3D: Implement per stream offsets
by Mirek 17 Jan '07

17 Jan '07

Hi, one or more nvidia sdk demos using instancing. Mirek Stefan Dösinger napsal(a): > Stumbled uppon that while reading up instancing. This is a functionality > technically required for all d3d9 drivers. The new functionality is not > really tested because I have no app that really needs this, but it should not > cause issues with games not using stream offsets. > > > ------------------------------------------------------------------------ > > From 6bd68813f3b05e525555ab2c28b331d838b50b92 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Sat, 13 Jan 2007 15:09:16 +0100 > Subject: [PATCH] WineD3D: Implement per stream offsets > > --- > dlls/wined3d/directx.c | 2 +- > dlls/wined3d/drawprim.c | 47 +++++++++++++++++++++++++++++++++++++---------- > dlls/wined3d/state.c | 22 ++++++++++++---------- > 3 files changed, 50 insertions(+), 21 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index cbcbdc2..0e6f4bc 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -2244,7 +2244,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > ------------------------------------------------ */ > if (This->dxVersion > 8) { > /* d3d9.dll sets D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES here because StretchRects is implemented in d3d9 */ > - *pCaps->DevCaps2 = 0; > + *pCaps->DevCaps2 = D3DDEVCAPS2_STREAMOFFSET; > /* TODO: VS3.0 needs at least D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET */ > *pCaps->MaxNpatchTessellationLevel = 0; > *pCaps->MasterAdapterOrdinal = 0; > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index 400ffb5..fdc9843 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -628,8 +628,12 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > DWORD diffuseColor = 0xFFFFFFFF; /* Diffuse Color */ > DWORD specularColor = 0; /* Specular Color */ > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > + UINT *streamOffset = This->stateBlock->streamOffset; > LONG SkipnStrides = startVertex + This->stateBlock->loadBaseVertexIndex; > > + BYTE *texCoords[WINED3DDP_MAXTEXCOORD]; > + BYTE *diffuse = NULL, *specular = NULL, *normal = NULL, *position = NULL; > + > TRACE("Using slow vertex array code\n"); > > /* Variable Initialization */ > @@ -638,6 +642,29 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > else pIdxBufL = (const long *) idxData; > } > > + /* Adding the stream offset once is cheaper than doing it every iteration. Do not modify the strided data, it is a pointer > + * to the strided Data in the device and might be needed intact on the next draw > + */ > + for (textureNo = 0, texture_idx = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) { > + if(sd->u.s.texCoords[textureNo].lpData) { > + texCoords[textureNo] = sd->u.s.texCoords[textureNo].lpData + streamOffset[sd->u.s.texCoords[textureNo].streamNo]; > + } else { > + texCoords[textureNo] = NULL; > + } > + } > + if(sd->u.s.diffuse.lpData) { > + diffuse = sd->u.s.diffuse.lpData + streamOffset[sd->u.s.diffuse.streamNo]; > + } > + if(sd->u.s.specular.lpData) { > + specular = sd->u.s.specular.lpData + streamOffset[sd->u.s.specular.streamNo]; > + } > + if(sd->u.s.normal.lpData) { > + normal = sd->u.s.normal.lpData + streamOffset[sd->u.s.normal.streamNo]; > + } > + if(sd->u.s.position.lpData) { > + position = sd->u.s.position.lpData + streamOffset[sd->u.s.position.streamNo]; > + } > + > /* Start drawing in GL */ > VTRACE(("glBegin(%x)\n", glPrimType)); > glBegin(glPrimType); > @@ -707,8 +734,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > continue; > } > > - ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > - if (sd->u.s.texCoords[coordIdx].lpData == NULL) { > + ptrToCoords = (float *)(texCoords[coordIdx] + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > + if (texCoords[coordIdx] == NULL) { > TRACE("tex: %d - Skipping tex coords, as no data supplied\n", textureNo); > ++texture_idx; > continue; > @@ -796,8 +823,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } /* End of textures */ > > /* Diffuse -------------------------------- */ > - if (sd->u.s.diffuse.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.diffuse.lpData + (SkipnStrides * sd->u.s.diffuse.dwStride)); > + if (diffuse) { > + DWORD *ptrToCoords = (DWORD *)(diffuse + (SkipnStrides * sd->u.s.diffuse.dwStride)); > diffuseColor = ptrToCoords[0]; > VTRACE(("diffuseColor=%lx\n", diffuseColor)); > > @@ -813,8 +840,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Specular ------------------------------- */ > - if (sd->u.s.specular.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.specular.lpData + (SkipnStrides * sd->u.s.specular.dwStride)); > + if (specular) { > + DWORD *ptrToCoords = (DWORD *)(specular + (SkipnStrides * sd->u.s.specular.dwStride)); > specularColor = ptrToCoords[0]; > VTRACE(("specularColor=%lx\n", specularColor)); > > @@ -850,16 +877,16 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Normal -------------------------------- */ > - if (sd->u.s.normal.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.normal.lpData + (SkipnStrides * sd->u.s.normal.dwStride)); > + if (normal != NULL) { > + float *ptrToCoords = (float *)(normal + (SkipnStrides * sd->u.s.normal.dwStride)); > > VTRACE(("glNormal:nx,ny,nz=%f,%f,%f\n", ptrToCoords[0], ptrToCoords[1], ptrToCoords[2])); > glNormal3f(ptrToCoords[0], ptrToCoords[1], ptrToCoords[2]); > } > > /* Position -------------------------------- */ > - if (sd->u.s.position.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.position.lpData + (SkipnStrides * sd->u.s.position.dwStride)); > + if (position) { > + float *ptrToCoords = (float *)(position + (SkipnStrides * sd->u.s.position.dwStride)); > x = ptrToCoords[0]; > y = ptrToCoords[1]; > z = ptrToCoords[2]; > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index bc2686f..8d74006 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -2112,6 +2112,7 @@ static inline void unloadNumberedArrays(IWineD3DStateBlockImpl *stateblock) { > static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *strided) { > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > int i; > + UINT *offset = stateblock->streamOffset; > > for (i = 0; i < MAX_ATTRIBS; i++) { > > @@ -2130,7 +2131,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > WINED3D_ATR_GLTYPE(strided->u.input[i].dwType), > WINED3D_ATR_NORMALIZED(strided->u.input[i].dwType), > strided->u.input[i].dwStride, > - strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride)); > + strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride + offset[strided->u.input[i].streamNo]) ); > GL_EXTCALL(glEnableVertexAttribArrayARB(i)); > } > } > @@ -2139,6 +2140,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *sd) { > unsigned int textureNo = 0; > unsigned int texture_idx = 0; > + UINT *offset = stateblock->streamOffset; > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > > TRACE("Using fast vertex array code\n"); > @@ -2155,7 +2157,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > #endif > > TRACE("Blend %d %p %d\n", WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > /* FIXME("TODO\n");*/ > /* Note dwType == float3 or float4 == 2 or 3 */ > > @@ -2170,7 +2172,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > VTRACE(("glWeightPointerARB(%d, GL_FLOAT, %d, %p)\n", > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType) , > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride)); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo])); > > if(curVBO != sd->u.s.blendWeights.VBO) { > GL_EXTCALL(glBindBufferARB(GL_ARRAY_BUFFER_ARB, sd->u.s.blendWeights.VBO)); > @@ -2182,7 +2184,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.blendWeights.dwType), > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > > checkGLcall("glWeightPointerARB"); > > @@ -2320,12 +2322,12 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > if(sd->u.s.position.VBO == 0) { > glVertexPointer(3 /* min(WINED3D_ATR_SIZE(sd->u.s.position.dwType),3) */, > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } else { > glVertexPointer( > WINED3D_ATR_SIZE(sd->u.s.position.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } > checkGLcall("glVertexPointer(...)"); > glEnableClientState(GL_VERTEX_ARRAY); > @@ -2350,7 +2352,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > glNormalPointer( > WINED3D_ATR_GLTYPE(sd->u.s.normal.dwType), > sd->u.s.normal.dwStride, > - sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride); > + sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride + offset[sd->u.s.normal.streamNo]); > checkGLcall("glNormalPointer(...)"); > glEnableClientState(GL_NORMAL_ARRAY); > checkGLcall("glEnableClientState(GL_NORMAL_ARRAY)"); > @@ -2384,7 +2386,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > glColorPointer(4, GL_UNSIGNED_BYTE, > sd->u.s.diffuse.dwStride, > - sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride); > + sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride + offset[sd->u.s.diffuse.streamNo]); > checkGLcall("glColorPointer(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_COLOR_ARRAY); > checkGLcall("glEnableClientState(GL_COLOR_ARRAY)"); > @@ -2411,7 +2413,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > GL_EXTCALL(glSecondaryColorPointerEXT)(4, GL_UNSIGNED_BYTE, > sd->u.s.specular.dwStride, > - sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride); > + sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride + offset[sd->u.s.specular.streamNo]); > vcheckGLcall("glSecondaryColorPointerEXT(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT); > vcheckGLcall("glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)"); > @@ -2476,7 +2478,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.texCoords[coordIdx].dwType), > WINED3D_ATR_GLTYPE(sd->u.s.texCoords[coordIdx].dwType), > sd->u.s.texCoords[coordIdx].dwStride, > - sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride); > + sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride + offset[sd->u.s.texCoords[coordIdx].streamNo]); > glEnableClientState(GL_TEXTURE_COORD_ARRAY); > } > } else if (!GL_SUPPORT(NV_REGISTER_COMBINERS)) { > > > ------------------------------------------------------------------------ > >

1 0

Re: comctl32: center calendar in monthcal
by Lei Zhang 17 Jan '07

17 Jan '07

Hi, Can we get this patch committed? It's a trivial fix to the calendar positioning, as seen here: http://linux.ucla.edu/~leiz/software/wine/screenshots/monthcal.png - Lei On 12/29/06, Lei Zhang <thestig(a)google.com> wrote: > The month calendar currently puts the calendar in the top-right corner > of the control window, it should be centered. > > --- > monthcal.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > >

1 0

The real DLL-Hell ("sfc.dll"), created by MS
by Detlef Riekenberg 16 Jan '07

16 Jan '07

I verify my work on winspool.drv and localspl.dll with the native versions of "localspl.dll" in wine. To my surprise, localspl.dll/XP needs a native "sfc_os.dll", while localspl.dll/W2K is happy with our buildin "sfc.dll" Please remember: - "sfc.dll" was not present before w2k. - The "System File Checker" API was introduced in win98 (with a different API in "sfcdll.dll") MS produced the ugliest case of the DLL-Hell on ther own! Two total different DLL's with a different API, but the same name: http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=sfc.dll&S=1&x… --- cut -- SFC.DLL (13.Nov.1998) in MS Office 2000 Prof (Starfighter Foundation Classes v1.0 DLL) http://support.microsoft.com/dllhelp/default.aspx?l=55&fid=115535 sfc.dll (07.Dec.1999) in Windows 2000 Prof (Windows File Protection) http://support.microsoft.com/dllhelp/?fid=72785&l=55&det=1 -- cut --- And to make the things even worse, the "sfc.dll" from office has the Version "1998.*" Congratulations -- By by ... Detlef

1 0

WineD3D: ProcessVertices
by Christoph Bumiller 16 Jan '07

16 Jan '07

Henri Verbeet wrote: > Well, you can't set a VBO as rendertarget directly, but you can copy > the FBO data into a PBO, which you can bind as a VBO. That's pretty > legitimate in OpenGL. But I was wondering how hard it would be to use > something like that for ProcessVertices. Well, you would get the rendered pixels' data written to the VBO then, right? To use this for ProcessVertices one would have to have a bijective relation between pixel's and processed vertices; p.e. pass the transformed vertex coordinates in varying variables and use'em as the color components and have the pixels stored in the order the vertices are so we can tell afterwards from what vertex they originate, in passing the vertex index as an attribute and so generate appropriate vertex coords ... theoretically. I don't think its easy or even possible to have exactly one pixel per vertex at sequential positions in the pixel buffer, or is it (using points and knowing the resolution etc.) ?

2 1

Time for wine-mono or wine-dotnet11 component in Bugzilla?
by Dan Kegel 16 Jan '07

16 Jan '07

While filing http://bugs.winehq.org/show_bug.cgi?id=7098 I realized that I'm starting to see lots of apps that require dot net, and there are two ways we could go to support them: 1) get msft's dotnetfx.exe to install (see http://bugs.winehq.org/show_bug.cgi?id=5358) and work 2) whip our mono integration into shape (see http://kegel.com/wine/fakedotnet.sh ) The question is, how should we tag bugs in bugzilla that fail because neither of these approaches really work yet? Should we make them depend on bug 5358, or should we create a new bug component, wine-dotnet11 or wine-mono, and put them in there? Filing these bugs as wine-misc seems wrong, so I'm leaning towards a new bugzilla component. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 8

Getting GTK/W32 applications to run
by Peter Gerwinski 16 Jan '07

16 Jan '07

Hello, WINE developers! While working on a cross-platform project, I tried to run some self-compiled GTK/W32 applications on a Debian GNU/Linux Sarge system using WINE 0.9.29, compiled from source. They crashed immediately. After some long, but unsuccessful Google sessions and some long, but successful RTFS/debugging sessions, I am now able to run and test my cross-compiled GTK/W32 applications in WINE. :-) Furthermore, I can start the W32 version of The GIMP up to the moment where it tries to load its plug-ins. (Without the plug-ins, the remaining parts of The GIMP even seem to work flawlessly.) Since Google told me that running GTK/W32 applications in WiNE - in particular: The GIMP - was an unsolved problem, I am hereby telling you what I observed and what I did. * Out of the box, pango (GTK's font renderer) does not find any suitable font. OTOH a non-GTK program, opening a MessageBox, works flawlessly, so the fonts are there. * When I tell pango to use a TrueType font *and* place the .ttf file in c:/windows/fonts/, I can start GTK's "Hello, world!" program, but the text is >300 pixels high, and thus unusable. (Real-world programs used to crash with a message similar to "memory exhausted", but trying to reproduce the exact message now results in *running* programs with a giant font. Sorry.) I conclude that (at least in my installation) pango does not find WINE's pixel fonts (even if I place them in c:/windows/fonts/), and sees the TTFs only with a wrong scaling factor. * When I tell pango to use the font "Sans 0.1", I get satisfying results. (In concrete, I got it working with the following gtkrc: style "wine-default-style" { font_name = "Sans 0.1" } widget "*" style "wine-default-style" ) I cannot fine-tune the font size. Using "Sans 0.2" or "Sans 0.01" yields exactly the same as "Sans 0.1". There seems to be one more intermediate size at "Sans 0.5"; after that the "normal" font sizes start with "Sans 1". Since both WINE and pango/GTK are free software, I am confident that these problems will be solved in the long run. I hope that you can use my observations. BTW, let me thank you for over 10 years of WINE by hacking Tom Payne's famous quote on Unix: Ten years ago mainstream users were choosing WABI over WINE. Now they are choosing $PROPRIETARY_FORK_OF_WINE over WINE. What part of that message aren't they getting? Keep on your excellent work! Cheers, Peter -- Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de German pages for GNU & free software - http://www.gnu.de G-N-U GmbH - EDV-Dienstleistungen - http://www.g-n-u.de Essener Linux User Group - http://www.elug.de

3 4

Re: Alexandre Julliard : ntdll: Implemented NtLockVirtualMemory and NtUnlockVirtualMemory.
by Robert Shearman 16 Jan '07

16 Jan '07

Alexandre Julliard wrote: > dlls/ntdll/virtual.c | 56 ++++++++++++++++++++++++++++++++++----- > include/wine/server_protocol.h | 32 +++++++++++++++++++++- > server/protocol.def | 30 ++++++++++++++++++++- > server/thread.c | 2 + > server/trace.c | 18 +++++++++++++ > 5 files changed, 127 insertions(+), 11 deletions(-) > It looks like the part of the commit to handle APC_VIRTUAL_LOCK/UNLOCK in call_apcs in dlls/ntdll/sync.c has been omitted. -- Rob Shearman

1 0

Re: iphlpapi - MacOS / BSD support
by Stefan Dösinger 16 Jan '07

16 Jan '07

Am Dienstag 16 Januar 2007 03:17 schrieb Gavriel State: > Author: Mark Adams <mark(a)transgaming.com> > > ChangeLog: > - Clarify interface counting > - Filter out no-ip addresses when building ip address table > - Add error messages when unimplemented functions are called on > non-linux platforms (ie: platforms without routing info in /proc) > - Implement retrieving the interface list on MacOS X (and other > platforms that use NET_RT_DUMP) I don't know the iphlpapi code, but the changelog suggests to me that the changes should be split up into seperate patches.

1 0

Re: iphlpapi - MacOS / BSD support
by Francois Gouget 16 Jan '07

16 Jan '07

--- iphlpapi/ifenum.c 21 Dec 2006 16:37:51 -0000 1.25 +++ iphlpapi/ifenum.c 15 Jan 2007 23:16:54 -0000 @@ -22,7 +22,7 @@ [...] - * - using the sysctl interface (FreeBSD and Mac OS X) + * - using the sysctl interface (FreeBSD and MacOS X) Just a small note; based on the Apple website I think the original spelling was correct. But don't worry about it, my 'typos' script should pick it up once your patch is committed and I will send a fix for it then. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

1 0

Re: [dinput 4/5] Add a config for the axes
by Vitaliy Margolen 16 Jan '07

16 Jan '07

Christoph Frick wrote: > Add a config for the axes like we do for the buttons > > This adds a mapping from the linux input id of the axis to the instance id > we assigned the axis. > --- > df->rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(axis++) | DIDFT_ABSAXIS; > } > - for (i = 0; i < 4; i++) > + > + idx = WINE_JOYSTICK_MAX_AXES; Why are you creating a gap? This is exactly the point here to skip all the objects that we do not have. And they all need to be sequential in godf - no gaps. Otherwise you braking EnumObjects. Vitaliy.

2 2

re: iphlpapi - MacOS / BSD support
by Dan Kegel 16 Jan '07

16 Jan '07

Hi Gav! You wrote: >Author: Mark Adams >... Cool... nice to see you on wine-patches again! For completeness, can you specify the license your patches are under? I assume MIT/X11...? - Dan

2 1

Re: user32/tests: add tests for WM_SETICON
by Dmitry Timoshkov 16 Jan '07

16 Jan '07

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > + /* Message sequences for WM_SETICON */ > + hwnd = CreateWindowExA(0, "TestWindowClass", NULL, > + WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, > + NULL, NULL, 0); > + flush_sequence(); > + SendMessage(hwnd, WM_SETICON, ICON_SMALL, (LPARAM)LoadIcon(0, IDI_APPLICATION)); > + ok_sequence(WmSetIcon, "WM_SETICON for window with caption", FALSE); This code doesn't show behaviour of a more interesting case - a visible window. -- Dmitry.

1 0

Re: appdb rating inflation
by Jesse Allen 15 Jan '07

15 Jan '07

Whoever it is that is wanting to update the HOWTO for the Diablo 2 appdb please email me. I don't have my email address on there for nothing. For whatever reason, I can't see who changes things nor does the appdb email me on changes anymore. Quote from new HOWTO note. "THIS IS A DUPLICATE ENTRY. I am making this simply because lots of the information in the original howto is either wrong, invalid or unnecessary. This is the new HOWTO. I'm leaving the old one in place so that the ones that wrote it can see the changes and voice anything before I remove the old one entirely. " I read it and you really did not change anything. But I will say that that YES the HOWTO is mostly unnessecary. However, when I tried going to a skeletal HOWTO, I got a bunch of odd complaints (especially on the CD-ROM info you removed). Also note, that the HOWTO duplicates the War3 one just because it's the same in almost every way. Jesse

1 0

Re: oleaut32: Remove unused items
by Michael Stefaniuc 15 Jan '07

15 Jan '07

Andrew Talbot wrote: > Changelog: > oleaut32: Remove unused items. > > diff -urN a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > --- a/dlls/oleaut32/vartype.c 2006-12-22 14:43:36.000000000 +0000 > +++ b/dlls/oleaut32/vartype.c 2007-01-13 20:13:23.000000000 +0000 > @@ -228,7 +228,6 @@ > SIMPLE(LONG64, SHORT, VarI8FromI2); > SIMPLE(LONG64, signed char, VarI8FromI1); > SIMPLE(LONG64, USHORT, VarI8FromUI2); > -SIMPLE(LONG64, LONG, VarI8FromI4); Are you removing a test here? > SIMPLE(LONG64, ULONG, VarI8FromUI4); > POSTST(LONG64, ULONG64, VarI8FromUI8, I8_MAX); bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Some stats (Was: Re: Alexandre Julliard : oleaut32/tests: Replace some macros by functions to reduce code size and compile time.)
by Michael Stefaniuc 15 Jan '07

15 Jan '07

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 25571d878960cd802aa31f291d473888dc01e035 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=25571d878960cd802aa31f291… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Jan 15 13:01:42 2007 +0100 > > oleaut32/tests: Replace some macros by functions to reduce code size and compile time. Some compile stats for vartest.c on my P4 3GHz HT, 2 GB RAM, FC6, gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) -O0 -O1 -O2 -O3 -Os size vartest.o with -O2 before 9s 38s 60s 870s 750s 1352256 after 3s 23s 35s 41s 42s 474300 I would say impressive, especially the -O3 and -Os changes. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

user32: the patches - what's wrong?
by Kirill K. Smirnov 15 Jan '07

15 Jan '07

Hi, Traditional questions from rejected patch-sender: 1) What's wrong with the following patches? http://www.winehq.org/pipermail/wine-patches/2007-January/034758.html http://www.winehq.org/pipermail/wine-patches/2007-January/034790.html 2) What can be done to improve them? Those patches let the window proc repaint NC area instead of calling NCPaint directly. And changes processing of WM_SETICON to be similar with WM_SETTEXT. -- Kirill

2 1

Re: [5] snmpapi: Implement SnmpUtilVarBindListCpy and SnmpUtilVarBindListFree.
by Robert Shearman 15 Jan '07

15 Jan '07

Hans Leidekker wrote: > + > +/*********************************************************************** > + * SnmpUtilVarBindListCpy (SNMPAPI.@) > + */ > +INT WINAPI SnmpUtilVarBindListCpy(SnmpVarBindList *dst, SnmpVarBindList *src) > +{ > + unsigned int i, size; > + SnmpVarBind *src_entry, *dst_entry; > + > + TRACE("(%p, %p)\n", dst, src); > + > + size = sizeof(SnmpVarBindList); > + if (!(dst = HeapAlloc(GetProcessHeap(), 0, size))) return SNMPAPI_ERROR; > Where do you return this memory to the caller? > + > + size = src->len * sizeof(SnmpVarBind *); > + if (!(dst->list = HeapAlloc(GetProcessHeap(), 0, size))) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return SNMPAPI_ERROR; > + } > + src_entry = src->list; > + dst_entry = dst->list; > + for (i = 0; i < src->len; i++) > + { > + if (SnmpUtilVarBindCpy(dst_entry, src_entry)) > + { > + src_entry++; > + dst_entry++; > + } > + else > + { > + for (--i; i > 0; i--) SnmpUtilVarBindFree(--dst_entry); > + HeapFree(GetProcessHeap(), 0, dst->list); > + HeapFree(GetProcessHeap(), 0, dst); > + return SNMPAPI_ERROR; > + } > + } > + dst->len = src->len; > + return SNMPAPI_NOERROR; > +} > > -- Rob Shearman

1 0

Re: dsound: fix tests for old versions of windows
by Francois Gouget 15 Jan '07

15 Jan '07

On Fri, 12 Jan 2007, Robert Reif wrote: > This patch fixes the tests to they can run without crashing on old versions of > windows that doesn't have dsound.dll. > + hDsound = LoadLibrary("dsound.dll"); + if (hDsound) { [...] + pDirectSoundCaptureEnumerateA=(void*)GetProcAddress(hDsound, + "DirectSoundCaptureEnumerateA"); + if (pDirectSoundCaptureCreate && pDirectSoundCaptureEnumerateA) + { [...] If all dsound.dll implementations are supposed to have these functions (which I believe is the case), then I would test that we found them with an ok() call. Also, if we fail to load dsound.dll, then we should indicate that we are skipping the tests with the new skip() function. This will make it clearer when analysing the logs that a big chunk of functionality was not tested (see the d3d8 tests for instance). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

1 0

(Cross)Compile failure for dsound/tests and shlwapi/tests
by Paul Vriens 15 Jan '07

15 Jan '07

Hi, three failures currently prevent winetest.exe from being build. The first one was ole32/tests/marshal.c (where Stefan Leichter sent a MinGW patch for): i386-mingw32-gcc clipboard.cross.o compobj.cross.o hglobalstream.cross.o marshal.cross.o moniker.cross.o ole2.cross.o propvariant.cross.o stg_prop.cross.o storage32.cross.o usrmarshal.cross.o testlist.cross.o -o ole32_crosstest.exe -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -luuid marshal.cross.o:marshal.c:(.text+0x7a61): undefined reference to `_IID_IChannelHook' collect2: ld returned 1 exit status make: *** [ole32_crosstest.exe] Error 1 The second one is for dsound/tests: i386-mingw32-gcc capture.cross.o ds3d.cross.o ds3d8.cross.o dsound.cross.o dsound8.cross.o duplex.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 capture.cross.o:capture.c:(.text+0xcf4): undefined reference to `_CLSID_DirectSoundPrivate' dsound.cross.o:dsound.c:(.text+0xbef): undefined reference to `_CLSID_DirectSoundPrivate' dsound.cross.o:dsound.c:(.text+0xc7a): undefined reference to `_CLSID_DirectSoundPrivate' dsound8.cross.o:dsound8.c:(.text+0xd39): undefined reference to `_CLSID_DirectSoundPrivate' dsound8.cross.o:dsound8.c:(.text+0xdc4): undefined reference to `_CLSID_DirectSoundPrivate' duplex.cross.o:duplex.c:(.text+0x794): more undefined references to `_CLSID_DirectSoundPrivate' follow propset.cross.o:propset.c:(.text+0x122f): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x1353): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x1477): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x159b): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x16bf): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x179e): more undefined references to `_DSPROPSETID_DirectSoundDevice' follow collect2: ld returned 1 exit status make: *** [dsound_crosstest.exe] Error 1 The third one is for shlwapi/tests: i386-mingw32-gcc clist.cross.o clsid.cross.o generated.cross.o ordinal.cross.o path.cross.o shreg.cross.o string.cross.o testlist.cross.o -o shlwapi_crosstest.exe -lshlwapi -ladvapi32 -lole32 -loleaut32 -lkernel32 -luuid clsid.cross.o:clsid.c:(.data+0x8): undefined reference to `_CATID_BrowsableShellExt' clsid.cross.o:clsid.c:(.data+0xc): undefined reference to `_CATID_BrowseInPlace' clsid.cross.o:clsid.c:(.data+0x10): undefined reference to `_CATID_DeskBand' clsid.cross.o:clsid.c:(.data+0x14): undefined reference to `_CATID_InfoBand' clsid.cross.o:clsid.c:(.data+0x18): undefined reference to `_CATID_CommBand' clsid.cross.o:clsid.c:(.data+0x30): undefined reference to `_CGID_ExplorerBarDoc' clsid.cross.o:clsid.c:(.data+0x50): undefined reference to `_IID_IShellDetails' clsid.cross.o:clsid.c:(.data+0x54): undefined reference to `_IID_IDelayedRelease' clsid.cross.o:clsid.c:(.data+0x94): undefined reference to `_IID_IRemoteComputer' clsid.cross.o:clsid.c:(.data+0x9c): undefined reference to `_IID_IDockingWindow' clsid.cross.o:clsid.c:(.data+0xa0): undefined reference to `_IID_IDockingWindowSite' clsid.cross.o:clsid.c:(.data+0xa8): undefined reference to `_CLSID_NetworkDomain' clsid.cross.o:clsid.c:(.data+0xac): undefined reference to `_CLSID_NetworkServer' clsid.cross.o:clsid.c:(.data+0xb0): undefined reference to `_CLSID_NetworkShare' clsid.cross.o:clsid.c:(.data+0xc8): undefined reference to `_CLSID_Printers' collect2: ld returned 1 exit status make: *** [shlwapi_crosstest.exe] Error 1 Volunteers ? Cheers, Paul.

3 4

vb6 ide getting close...
by Dan Kegel 15 Jan '07

15 Jan '07

OK, the vb6 IDE may not be the most popular app at the moment, but it's still a good test of Wine. It seems to be getting closer; http://bugs.winehq.org/show_bug.cgi?id=5181 and http://bugs.winehq.org/show_bug.cgi?id=4931 are both a fair bit happier. Still not really usable. There seems to be a regression since June: the "New Project" dialog that pops up at the start of vb6 doesn't get drawn properly, though if you arrow around, the icons in it do then get drawn. (See bug 4931.) - Dan

1 0

Feedback on "Wine users guide"
by Torsten Hammarstedt, X-Lin AB 14 Jan '07

14 Jan '07

Hi Perhaps the resason that you didn't receive a lot of feedback on the Wine Users Guide is that it is very well written. Nevertheless I have found a few details that might be better explained: 1.2.3 Wine capabilities ..... Notes [1] Today VMware server is free software and you can easily manage a Windows system on a VMware virtual machine. However this does not solve the problem with having to maintain/support two differnt operating systems (quite time consuming...). There is also the commercial software /2X application server/ and /2X application server client /(2X.com) with which windows applications can be run on Linux in single windows using Windows Terminal services. The above 2X software is free up to 5 server connections, for more you have to pay a license fee. So far it is quite beta-style but eventually it might be very good... Windows terminal services is available in Win XP prof, Win 2000 Server and Win 2003 Server (don't know about Vista). 2.2. Getting a Wine package I think you should mention Ubuntu - thera are packages for Ubuntu avaialable on sourceforge.net Wine download page. That was all for the first 4 chapters - perhaps I'll come back with more feedback later. -- B R Torsten Hammarstedt ~~~~~~~~~~~~~~~~~~~~~~ * * PC & Networks AB tel. 031 - 706 95 00 e-post: torsten(a)x-lin.se www.x-lin.se

2 1

[15/20] WineD3D: Clean up drawprim a bit
by Christoph Bumiller 14 Jan '07

14 Jan '07

Stefan Dösinger wrote: > We will need software shaders for a correct implementation of > IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I > don't really think OpenGL feedback mode is what we want here. > > Maybe we should remove it for now, but keep the code somewhere(in the > wiki maybe). If someone is extra-ambitious we can do something like > Softwire/SwiftShader does. But I think ProcessVertices is a good > oportunity to verify our vertex shader implementation. > Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.

3 4

Re: remove redundant semicolons for ANSI compat.
by Michael Stefaniuc 13 Jan '07

13 Jan '07

Joel Parker wrote: > Bug 4527 > > > > > ------------------------------------------------------------------------ > >>From 205f7fdd9a63409014a322318aba3fd77ec90f47 Mon Sep 17 00:00:00 2001 > From: Joel Parker <joeljkp(a)joel-laptop.(none)> > Date: Fri, 12 Jan 2007 17:26:47 -0600 > Subject: remove redundant semicolons for ANSI compat. > --- > @@ -636,17 +636,17 @@ #define DEFINE_SMapLS(n) \ > "movl " #n "(%ebp),%eax\n\t" \ > "call " __ASM_NAME("SMapLS") "\n\t" \ > "movl %edx," #n "(%ebp)\n\t" \ > - "ret" ); > + "ret" ) > > -DEFINE_SMapLS(8); > -DEFINE_SMapLS(12); > -DEFINE_SMapLS(16); > -DEFINE_SMapLS(20); > -DEFINE_SMapLS(24); > -DEFINE_SMapLS(28); > -DEFINE_SMapLS(32); > -DEFINE_SMapLS(36); > -DEFINE_SMapLS(40); > +DEFINE_SMapLS(8) > +DEFINE_SMapLS(12) > +DEFINE_SMapLS(16) > +DEFINE_SMapLS(20) > +DEFINE_SMapLS(24) > +DEFINE_SMapLS(28) > +DEFINE_SMapLS(32) > +DEFINE_SMapLS(36) > +DEFINE_SMapLS(40) Are you sure this compiles? You removed the semicolon in the macro definition and when it is used. And even if it compiles the code needs to look like C code. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Dapper, git, and version-stamp pain again
by Dan Kegel 13 Jan '07

13 Jan '07

On one of my dapper boxes (an old laptop), I got the error main.o: In function `check_command_line':/home/dank/wine-git/loader/main.c:89: undefined reference to `wine_version' today. Turns out the version-stamp rule in loader/Makefile is misbehaving; I had to hack that rule to not invoke git at all. Hmm. I remember having to do that before. Oh, yeah, it's coming back to me now: Dapper's "git --version" reports 1.1.3, and http://wiki.winehq.org/GitWine#head-f90aa63f963ccd6f1b34f59e4fdaafaecc72ad18 says that's too old. Grr. I guess I should submit a patch that checks git's version and doesn't break the build if it's only 1.1.3... it'd save me fifteen minutes next time I forget about this... - Dan

2 1

Re: Paul Vriens : mshtml/tests: Cast-qual warning fix.
by Michael Stefaniuc 13 Jan '07

13 Jan '07

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 6338caa9eda8eda98dad9a89a8e71c6ea37bd168 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=6338caa9eda8eda98dad9a89a… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 14:26:05 2007 +0100 > > mshtml/tests: Cast-qual warning fix. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/mshtml/tests/htmldoc.c: In function `test_Load': dlls/mshtml/tests/htmldoc.c:1806: invalid initializer make[2]: *** [htmldoc.o] Error 1 > > --- > > dlls/mshtml/tests/htmldoc.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c > index ac26ca8..0815c01 100644 > --- a/dlls/mshtml/tests/htmldoc.c > +++ b/dlls/mshtml/tests/htmldoc.c > @@ -1803,11 +1803,12 @@ static void test_Load(IPersistMoniker *p > { > IBindCtx *bind; > HRESULT hres; > + static WCHAR sz_html_clientsite_objectparam[] = SZ_HTML_CLIENTSITE_OBJECTPARAM; Making that 'static const WCHAR sz_html_clientsite_objectparam[]' fixes the compilation error but renders the exercise moot. > > test_readyState((IUnknown*)persist); > > CreateBindCtx(0, &bind); > - IBindCtx_RegisterObjectParam(bind, (LPOLESTR)SZ_HTML_CLIENTSITE_OBJECTPARAM, > + IBindCtx_RegisterObjectParam(bind, sz_html_clientsite_objectparam, > (IUnknown*)&ClientSite); > > SET_EXPECT(GetDisplayName); > > > bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

dlls/mshtml/tests/htmldoc.c breakage
by Gerald Pfeifer 13 Jan '07

13 Jan '07

The following change to dlls/mshtml/tests/htmldoc.c date: 2007-01-12 19:56:11 +0000; author: julliard; state: Exp; lines: +2 -1 Paul Vriens <paul.vriens.wine(a)gmail.com> mshtml/tests: Cast-qual warning fix. breaks the build with GCC 3.4: /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o htmldoc.o htmldoc.c htmldoc.c: In function `test_Load': htmldoc.c:1806: error: invalid initializer Would you mind having a look? Gerald

1 0

New dlls/crypt32/tests/cert.c breakage
by Gerald Pfeifer 13 Jan '07

13 Jan '07

The following change to dlls/crypt32/cert.c revision 1.36 date: 2007-01-12 20:56:12 +0100; author: julliard; state: Exp; lines: +56 -57 Paul Vriens <paul.vriens.wine(a)gmail.com> crypt32/tests: Cast-qual warning fixes. breaks the bootstrap on some of my systems. Specifically, it added a new variable static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; initialized with MS_DEF_PROV_W. However, in include/wincrypt.h we have the following: #if defined(__GNUC__) # define MS_DEF_PROV_W (const WCHAR []){ ... } #elif defined(_MSC_VER) # define MS_DEF_PROV_W L"Microsoft Base Cryptographic Provider v1.0" #else static const WCHAR MS_DEF_PROV_W[] = { 'M','i','c','r','o','s','o','f','t',' ', 'B','a','s','e',' ','C','r','y','p','t','o','g','r','a','p','h','i','c',' ', 'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 }; #endif In my case this breaks for GCC 3.4: /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o cert.o cert.c cert.c:312: error: invalid initializer Gerald PS: The patch below avoids this breakage on my test system, but is obviously not the real fix. Index: cert.c =================================================================== RCS file: /home/wine/wine/dlls/crypt32/tests/cert.c,v retrieving revision 1.36 diff -u -3 -p -r1.36 cert.c --- cert.c 12 Jan 2007 19:56:12 -0000 1.36 +++ cert.c 13 Jan 2007 17:08:00 -0000 @@ -309,7 +309,10 @@ static void checkHash(const BYTE *data, } static WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e','m','p',0 }; -static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; +static WCHAR ms_def_prov_w[] = { 'M','i','c','r','o','s','o','f','t',' ' , + 'B','a','s','e',' ','C','r','y','p','t','o','g','r','a','p','h','i','c', ' ', + 'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 }; + static void testCertProperties(void) {

1 0

re: New list subscriber - Question about gdi:widenpath
by Dan Kegel 13 Jan '07

13 Jan '07

Hi Laurent! You wrote: >I'm trying make a french software called Navigation, used by airplane >pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? >The point is this software needs gdi:widenpath to work. I'd just like to >know if this function is planned for the next release or if I will have >to wait a little more. It's not planned, as far as I know. If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 4

Re: Paul Vriens : crypt32/tests: Cast-qual warning fixes.
by Michael Stefaniuc 13 Jan '07

13 Jan '07

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 259c06ffc93d690fa5105b1451e519aa1c92b72e > URL: http://source.winehq.org/git/wine.git/?a=commit;h=259c06ffc93d690fa5105b145… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 15:51:02 2007 +0100 > > crypt32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/crypt32/tests/cert.c:312: invalid initializer make[2]: *** [cert.o] Error 1 > @@ -309,8 +308,8 @@ static void checkHash(const BYTE *data, > propID); > } > > -static const WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e', > - 'm','p',0 }; > +static WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e','m','p',0 }; > +static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation error but renders the exercise moot. > > static void testCertProperties(void) > { > > > --- > > dlls/crypt32/tests/cert.c | 113 ++++++++++++++++++++++----------------------- > 1 files changed, 56 insertions(+), 57 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=259c06ffc93d690fa5105… > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

GreenVille font, is it still available? I have a question about it.
by Wierd_w 13 Jan '07

13 Jan '07

Markus Amsler wrote: >I neither fully understood it, but here my opinion. It >looks like the >"only" problem he has is the TrueType hinting, which >affects small font >sizes. As long as the kerning (=width of a glyph) is >correct, and the >font looks somehow similar, it should be suitable for >wine's need. So it >should be possible to convert Larry's TTF version with >fontforge to SDF, >and you're done. Adding hinting is IMO a second step. This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.) http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(7%20… http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(11%2… http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(14%2… As you can see, there is a VERY LARGE discrepency between greenville (without TTF instructions) and MS Tahoma (Which does use TTF instructions). Type-1 hinting system does not have a mechanism to overcome this incongruity, because the glyphs have been arbitrarily resized using TTF instructions in MS Tahoma, and Type-1 hinting system does not have a mechanism for this. Depending on how far you want to go, you have 3 options as I see them: 1) (Best,but unlikely, due to the intense effort required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely." 2) Use the Type-1 font that is correct at sizes 15 and up, and use a bitmapped font for sizes below that and have WINE perform the substitution. 3) Adapt FontForge to inject SBIT record data (Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes. The last one seems the most workable, but I am unsure if .OTF files can support SBIT data records, although they are a part of the ".ttf wrapper" spec used by OTF files.--- More research would need to be performed to determine the viability of this option. Theoretically, the rasterizer should check for the existance of SBIT records, and if it finds one, simply pull the bitmap from the record, and pass it on through, totally skipping the rasterizer. I would check with Freetype's documentation to see if SBITs are supported with OTF under freetype. MS Typography has this to say concerning SBITs and OTF files: http://www.microsoft.com/typography/otspec/recom.htm <quote> Embedded Bitmaps Three tables are used to embed bitmaps in OpenType fonts. They are the 'EBLC' table for embedded bitmap locators, the 'EBDT' table for embedded bitmap data, and the 'EBSC' table for embedded bitmap scaling information. OpenType embedded bitmaps are also called 'sbits'. The behavior of sbits within an OpenType font is essentially transparent to the client. A client need not be aware whether the bitmap returned by the rasterizer comes from an sbit or from a scan-converted outline. The metrics in 'sbit' tables overrule the outline metrics at all sizes where sbits are defined. Fonts with 'hdmx' tables should correct those tables with 'sbit' values. 'Sbit only' fonts, that is fonts with embedded bitmaps but without outline data, are permitted. Care must be taken to ensure that all required OpenType tables except 'glyf' and 'loca' are present in such a font. Obviously, such fonts will only be able to return glyphs and sizes for which sbits are defined. 1. These metrics are returned as part of the logical font data structure by the GDI CreateLogFont() API. 2. These metrics are returned by the Apple Advanced Typography (AAT) GetFontInfo() API. </quote> ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

2 1

Re: Paul Vriens : secur32/tests: Cast-qual warning fixes.
by Michael Stefaniuc 13 Jan '07

13 Jan '07

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 6c3efd1c32b1f9054e82a684da6ab54a599f252d > URL: http://source.winehq.org/git/wine.git/?a=commit;h=6c3efd1c32b1f9054e82a684d… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 14:01:16 2007 +0100 > > secur32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/secur32/tests/schannel.c: In function `testAcquireSecurityContext': dlls/secur32/tests/schannel.c:119: invalid initializer make[2]: *** [schannel.o] Error 1 > > --- > > dlls/secur32/tests/schannel.c | 11 ++++++----- > 1 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/dlls/secur32/tests/schannel.c b/dlls/secur32/tests/schannel.c > index ca870f4..0bbd96b 100644 > --- a/dlls/secur32/tests/schannel.c > +++ b/dlls/secur32/tests/schannel.c > @@ -116,12 +116,13 @@ static void testAcquireSecurityContext(v > PCCERT_CONTEXT certs[2]; > HCRYPTPROV csp; > static CHAR unisp_name_a[] = UNISP_NAME_A; > + static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation error but renders the exercise moot. > BOOL ret; > HCRYPTKEY key; > CRYPT_KEY_PROV_INFO keyProvInfo; > > - keyProvInfo.pwszContainerName = (LPWSTR)cspNameW; > - keyProvInfo.pwszProvName = (LPWSTR)MS_DEF_PROV_W; > + keyProvInfo.pwszContainerName = cspNameW; > + keyProvInfo.pwszProvName = ms_def_prov_w; > keyProvInfo.dwProvType = PROV_RSA_FULL; > keyProvInfo.dwFlags = 0; > keyProvInfo.cProvParam = 0; bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

wine kills X
by Stefan Leichter 12 Jan '07

12 Jan '07

Hello, when i start wine, my X gets terminated. The logfile Xorg.0.log shows --------------------------------------------------------------------- Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4354] 1: [0xb7f48420] Fatal server error: Caught signal 11. Server aborting --------------------------------------------------------------------- Last line in wine's relay log is: X connection to :0.0 broken (explicit kill or server shutdown). The call stack is: 0009:Call PE DLL (proc=0x7e950b00,module=0x7e8f0000 L"winex11.drv",reason=PROCESS_ATTACH,res=(nil)) 0009:Call ntdll.LdrLoadDll(00160070 L"C:\\Programme\\camLine\\ECoFrame 1.8.0\\java\\jre\\bin;.;c:\\windows\\system32;c:\\windows\\system;c: \\windows;c:\\windows\\system32;c:\\windows;c: \\windows\\Microsoft.NET\\Framework\\v2.0.50727",00000000,0033f334,0033f308) ret=7ee745db 0009:Call kernel32.LoadLibraryA(0033f540 "winex11.drv") ret=7eaeb5e0 0009:Call gdi32.CreateDCW(7ec1492a L"DISPLAY",00000000,00000000,00000000) ret=7eb90a8f 0009:Call PE DLL (proc=0x7ec10330,module=0x7eb60000 L"user32.dll",reason=PROCESS_ATTACH,res=0x1) 0009:Call ntdll.LdrInitializeThunk(00000000,00000000,00000000,00000000) ret=7ee82bb5 My system is: Athlon XP 2700 NVIDIA GPU GeForce4 Ti 4200 (with NVIDIA driver version 1.0-9631) Debian Etch Last system modification was an update of the debian system with the availabe patches on 05.01.2007. This is most probably the root of the problem. Can someone please give me an idea how to fix this problem Thanks Stefan

4 5

Re: GreenVille font, is it still available? I have a question about it.
by Louis. Lenders 12 Jan '07

12 Jan '07

Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis Wierd_w <wierd_w(a)yahoo.com> wrote: --- "Louis. Lenders" wrote: > Hi, i got your email address from one of the Reactos > developers. AFAIK you have been working on a Tahoma > compatible font called Greenville. I was wondering > if you still have it, and if you were willing to > license this LGPL, so that it could be included in > Wine project. Sure I could. I would be happy to release the glyphset that I have started on, but the reason I never finished the project was because of "Differences" between the rasterizers in FreeType and MS Windows. These differences would have required me to learn native truetype assembler to resolve, because of (in my opinion) "overzealous" freetype developers attempting to take full advantage of the hint system's tolerances. (Better explanation: MS Windows' rasterizer only blends to 16 shades of grey, instead of the theoretical maximum of 256 shades. There is a REASON for doing this: Namely, it makes it possible for visual hinting systems, like the software that I used to work on Greenville, to produce a visually high-quality font, without using exact binary precision with the use of hinting instructions; It allows for a degree of "leniency" in the rasterizer's interperetation of a glyph outline. Because Freetype wants to use the full theoretical maximum to achieve more shades of grey, you must be "Spot on dead on the money" accurate with the use of hinting instructions, or else the font will have 'blurry' edges. Throw into that the fact that the "Delta" instruction is patented by Apple computer corporation, and refuses to sell Freetype a license, it makes it VERY VERY VERY difficult to get Freetype to even render the glyph even kind-of correctly to begin with. It is possible to 'patch' freetype to turn off some of this overzealousness, and even to turn on the native bytecode interpereter-- but even then the test case TTF files I generated (that look just fine in windows) look asthetically gut-wrenching in freetype.) After spending 6 months trying (and failing) to resolve these internal rendering troubles, (and even considering the implementation of Scalar Bitmaps (SBIT)data so that I wouldnt HAVE to mess with Freetype's CRAP, and ending up with a 600kb font file.) I decided that enough was enough. Since the software that I used was VERY expensive (over 300$ US for the STUDENT DISCOUNTED version), and uses a proprietary working format, I would instead be happy to send you the glyph metrics and kerning data in Adobe format, and the actual Glyph set in your choice of vector format. (Note, I spent 2 weeks looking for a suitable TTF editing suite from the freesoftware community (You know, one that would *gasp!* Run on windows, where I could quickly test the fonts!), and came up empty handed. this is why I shelled out the big bucks for FontLab. The Free Software community's gestalt predjudices have shot it in the foot this time.) The actual HINTING process would then be up to you, but be prepared to have your hair turn grey, and to develop ulcers. In order to achieve a strong level of clean resemblence to Tahoma, you *WILL* need to use Truetype, OR, a bitmapped font set. Adobe Type-1 fonts (God, so many tools for that in the FOSS community, but not a SINGLE ONE for TTF hints!...) will not be suitable, because they lack the necessary hinting control (Only stem and leaf, instead of Vector Node Deform, like TTF-- Means that round contours, like in the letter O or G, will NEVER be as clean in an adobe type-1, as they will be with TTF.) I am currently at the college, and dont have access to my software at the moment, but when I get home this evening I will begin cleaning up my old resources and packaging them. Any particular preference on a vector format? I CAN package the raw glyphs into an unhinted Adobe Type-1, but you will have to do a vector conversion to work on them as a TTF. That shouldnt be a problem though. Likewise, I could also send an unhinted TTF, with the kerning data allready merged. If one of these would be suitable, let me know, and if not-- please specify one. ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

2 1

Wine-cvs time-stamp timezone
by Andrew Talbot 12 Jan '07

12 Jan '07

Hi, I just thought I should mention that the timestamps for "Last message date:" and "Archived on:" at http://www.winehq.org/pipermail/wine-cvs/2007-January/ are currently given as CDT times, whereas those of the individual patches are correctly shown as CST. Thanks, -- Andy.

1 0

New list subscriber - Question about gdi:widenpath
by Laurent Vromman 12 Jan '07

12 Jan '07

Hi, My name is Laurent. I'm french, 23 year old, software designer for a huge european company. I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. I'd like to provide a patch for this particular function but unfortunatly, my development skills are far to low to do it without any help. Does anyone have informations about this function ? Thank you for your help. Laurent

1 0

Re: Implement SQLGetInstalledDrivers in odbccp32
by Detlef Riekenberg 12 Jan '07

12 Jan '07

At first: Congratulations for the commit of your Patches. On Do, 2007-01-11 at 09:29 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)shaw.ca) > Implement GetInstalledDrivers in odbccp32 > BOOL WINAPI SQLGetInstalledDriversW(LPWSTR lpszBuf, WORD cbBufMax, > WORD *pcbBufOut) > + else if ((reg_ret = RegOpenKeyExA (HKEY_LOCAL_MACHINE /* The drivers does not depend on the config mode */, > + "Software\\ODBC\\ODBCINST.INI\\ODBC Drivers", 0, KEY_READ /* Maybe overkill */, > + &hDrivers)) == ERROR_SUCCESS) We want to eleminate all CrossCalls: http://wiki.winehq.org/CrossCallsWtoA Please convert RegOpenKeyExA and the string to UNICODE. Thanks -- By by ... Detlef

3 2

Re: configure: add ncursesw detecting [try 2]
by Alexandre Julliard 12 Jan '07

12 Jan '07

Vitaly Lipatov <lav(a)etersoft.ru> writes: > Try 2, with ncursesw/ncurses detecting > In order to build wineconsole run properly in utf8 locale, we use ncursesw, > which can handle wchar strings. Why would you need wchar strings if you use utf-8? Have you configured your locale properly? -- Alexandre Julliard julliard(a)winehq.org

4 14

python-to-c++ compiler under wine
by Mark Dufour 12 Jan '07

12 Jan '07

hi there, while trying to get an experimental python-to-c++ compiler (http://mark.dufour.googlepages.com) to run under wine, I found a not-so complicated test case that crashes. it is a simple C++ program, converted from 57 lines of Python. it is quite self-contained, and only uses the Boehm GC, but it crashes early and consistently. I corresponded with mike hearn about this, but he is too busy atm to look at it further. here is a mail of me to him, with a link to an archive with an .exe that crashes (but works under windows), the .py and .?pp source code, and a crash log with debugging symbols. it would be great if any of you here would have a look at it. --- I tried to minimize the test program so it still crashes. the attachment (t37.py, 56 lines) very quickly and consistently crashes when trying to print out a list of integers: def propagate(lit, mods, failed_literal=0): .. print 'prop', lit print occurrence[3] this happens after calling just a few functions (solve_rec, lookahead, lookahead_variable, propagate) and no backtracking. in C++ terms, occurrence is a list<list<list<int> *> *> *. occurrence[3] is then a list<list<int> *> *. occurrence[3] is a list of 6 'clauses'. it always goes wrong on printing the 3rd clause (or list<int> *), at the line 'r->unit += repr.. ' below, in the file builtin.hpp: template<class T> str *list<T>::__repr__() { str *r = new str("["); for(int i = 0; i<this->__len__();i++) { r->unit += repr(units[i])->unit; if (i<this->__len__()-1) r->unit += ", "; } r->unit += "]"; return r; } now what happens in repr(..) is a bit complicated because of templatry and va_args stuff and all, but I would think that if the clause is not corrupt it should just work.. btw. a list<T> uses a vector<T> in it called 'units', as can be seen above. here's a bundle of files (crash log, t37.py, t37.?pp, t37.exe..): http://mark.dufour.googlepages.com/shedskin_crash.tgz --- thanks for any help! mark dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson

1 0

Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
by Vitaliy Margolen 12 Jan '07

12 Jan '07

Christoph Frick wrote: > with Vitaliy's patches i tried my games yesterday and everything seemed > ok (RBR works again). but my clutch on the wheel did not work and also That's a good news. I was hopping not to brake too many things while reorganizing the dinput. > @@ -128,11 +122,20 @@ struct JoystickImpl > /* The 'parent' DInput */ > IDirectInputImpl *dinput; > > + /* autodetecting ranges per axe by following movement */ > + LONG havemax[8]; > + LONG havemin[8]; I could never understood why we need these? In other joystick_linux the range assumed to be 0 - 0xffff. > /* joystick private */ > /* what range and deadzone the game wants */ > - LONG wantmin[ABS_MAX]; > - LONG wantmax[ABS_MAX]; > - LONG deadz[ABS_MAX]; > + LONG wantmin[8]; > + LONG wantmax[8]; > + LONG deadz[8]; Can we move these into separate struct like it's done in joystick_linux? It's much cleaner end eventually will allow a better integration of two. And can you use spaces instead of tabs please? > @@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid, const void *jvt, IDirectInputIm > /* Supported Axis & POVs should map 1-to-1 */ > for (i = 0; i < 8; i++) > { > - if (!test_bit(newDevice->joydev->absbits, i)) continue; > + if (!test_bit(newDevice->joydev->absbits, i)) { > + newDevice->axes[i] = -1; > + continue; > + } Can you please don't brake the good readable style? Please put that curly bracket into separate line, and use 4 space indentation. > + fake_current_js_state(newDevice); > + Can you explain what this suppose to do? Why do we need to "fake current state" everywhere? > + int axe = This->axes[ie.code]; It's an "axis" not an "axe" :) Vitaliy.

2 4

Re: [PATCH 1/1] msi: MsiGetPropertyA return wrong length when called from a custom action.
by Dmitry Timoshkov 12 Jan '07

12 Jan '07

"Mike McCormack" <mike(a)codeweavers.com> wrote: > This is a hack, however the correct way to achieve bug compatiblity is > complicated. > > MSI should run custom actions in a separate process and communicate with > the main installer process via COM. This is quite a lot of work which > needs to be done anyway, but this patch will make us bug compatible with > Microsoft's implementation in the mean time. > > Furthermore, writing a test case for this behavior requires adding a dll > contain custom action code to the dlls/msi/tests directory. I can > supply an MSVC project showing the problem. > > See bug 5768 (http://bugs.winehq.org/show_bug.cgi?id=5768) for more details. Does behaviour of MsiGetPropertyA and MsiGetPropertyW differ in that case? I'd be interested to have a look at the test case. > --- a/dlls/msi/custom.c > +++ b/dlls/msi/custom.c > @@ -439,6 +439,8 @@ static DWORD WINAPI ACTION_CallDllFunction(thread_struct *stuff) > TRACE("calling function (%s, %s)\n", debugstr_w(stuff->source), > debugstr_w(stuff->target)); > > + TlsSetValue( tls_slot, (void*) 1 ); Shouldn't this be reset to 0 once a custom action has finished? -- Dmitry.

2 1

[PATCH] fix tools/c2man.pl perl syntax
by Alexey Tourbin 12 Jan '07

12 Jan '07

Fellas, tools/c2man.pl have buggy pieca code which work only for accident reasons. The patch fixes perl syntax for upcoming perl-5.8.9 who ain't not gonna tolerate the buggy pieca coda. http://www.nntp.perl.org/group/perl.perl5.porters/119879 http://www.nntp.perl.org/group/perl.perl5.porters/119881 http://www.nntp.perl.org/group/perl.perl5.porters/119882 http://www.nntp.perl.org/group/perl.perl5.porters/119883 --- tools/c2man.pl- 2006-12-24 00:17:04 +0000 +++ tools/c2man.pl 2007-01-12 07:13:05 +0000 @@ -627,7 +627,7 @@ sub process_comment($) # When the function is exported twice we have the second name below the first # (you see this a lot in ntdll, but also in some other places). - my $first_line = ${@{$comment->{TEXT}}}[1]; + my $first_line = $comment->{TEXT}[1]; if ( $first_line =~ /^(@|[A-Za-z0-9_]+) +($|\[)([A-Za-z0-9_]+)\.(([0-9]+)|@)($|\])$/ ) { @@ -642,14 +642,14 @@ sub process_comment($) my $alt_export = @{$spec_details->{EXPORTS}}[$alt_index]; @$alt_export[4] |= $FLAG_DOCUMENTED; $spec_details->{NUM_DOCS}++; - ${@{$comment->{TEXT}}}[1] = ""; + $comment->{TEXT}[1] = ""; } } if (@{$spec_details->{CURRENT_EXTRA}}) { # We have an extra comment that might be related to this one - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; my $current_name = $current_comment->{COMMENT_NAME}; if ($comment->{COMMENT_NAME} =~ /^$current_name/ && $comment->{COMMENT_NAME} ne $current_name) { @@ -986,7 +986,7 @@ sub process_extra_comment($) if (@{$spec_details->{CURRENT_EXTRA}}) { - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; if ($opt_verbose > 0) { @@ -1072,7 +1072,7 @@ sub process_index_files() if (@{$spec_details->{CURRENT_EXTRA}}) { # We have an unwritten extra comment, write it - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; process_extra_comment($current_comment); @{$spec_details->{CURRENT_EXTRA}} = (); } @@ -1468,7 +1468,7 @@ sub output_api_synopsis($) my $biggest_length = 0; for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/) { my $length = length $1; @@ -1482,19 +1482,19 @@ sub output_api_synopsis($) # Now pad the string with blanks for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/) { my $pad_len = $biggest_length - length $1; my $padding = " " x ($pad_len); - ${@{$comment->{PROTOTYPE}}}[$i] = $1.$padding.$2; + $comment->{PROTOTYPE}[$i] = $1.$padding.$2; } } for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { # Format the parameter name - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; my $comma = ($i == @{$comment->{PROTOTYPE}}-1) ? "" : ","; $line =~ s/(.+?)([A-Za-z_][A-Za-z_0-9]*)$/ $fmt[0]$1$fmt[2]$2$fmt[3]$comma$fmt[1]/; print OUTPUT $line;

1 0

OpenGL in child windows
by Chris Robinson 12 Jan '07

12 Jan '07

Here's something I've been working on for about the past week. It's my attempt to get OpenGL to render into an X11 child window that overlays the Win32 window. These patches are more proof-of-concept than anything I'd attempt to get into Wine.. just to show that it seems to work. If the method is good enough, these would need to be rewritten. The biggest problem facing these patches that I ran into are threading issues. Since each window is basically tied to the thread that it was created in but can be used out of it, and each thread uses its own X11 display connection, there's quite a few hoops to jump through. The problem is that the OpenGL X11 window can be created at basically any time after the window was created, in any thread (it's currently done in the call to SetPixelFormat, the earliest it'll know which visual/pixel format is wanted, and can create a colormap to be able to use it in a child window, regardless of the visual of its parent). If that call is not done in the thread the win32 window was created in, it would have trouble getting some of the data structures it needs. Add on top of that, that the X11 window can be parented to yet another win32 window (the one that has the "whole" X11 window), which can be in yet another thread, it leaves a lot of problem trying to keep syncronization. Most of the placement syncronization is done by adding a couple fields to x11drv_win_data to hold info for the X11 child window's parent, that can be used to properly offset the X11 child in relation to the X11 parent, according to the Win32 window's placement. It also needed a couple driver-specific WM_ messages to be able to get the data it needs in case the creation is done in a seperate thread. Because the X11 window uses a thread-specific display connection, and the child window needs to share the display connection, I needed to add a Display* to the X11DRV_PDEVICE struct, which is used wherever a GLX call needs an explicit display connection. This works well most of the time, but has a problem when a GL context (tied to an HDC in Windows) is in use when the thread that created the Win32 window that the HDC came from is killed. When the thread is killed, it closes the connection which leaves GLX using an invalid Display. I have to ask, is there a reason each thread uses its own display connection (which are all different from gdi_display), and leaves the window data to only be available from the thread the window was created in? Besides the aforementioned problem with the GL context, I'd imagine it would be problematic even in current Wine.. for example, if something creates a window in one thread, passes it to another, then kills the thread it was originally created in while still using the window. I currently made it so each thread shares the same Display connection (which is different from gdi_display). This seems to cause no noticeable problems, and it fixes the GL context display issue. Beyond that, the only problem I can recall off-hand is that the OpenGL window will draw overtop of all Win32 windows that are sharing the same X11 parent window. However, considering that the current method with the scissors hack causes the whole X11 window to clear on a buffer flip, and also draws on top of anything in its window space anyway, this is still a nice step forward. And there are also a couple syslevel potential-deadlock warnings generated from the calls to create the window, however I have yet to see a problem arise from all the programs I've tested (the warnings can't stay obviously, but they can be figured out later). What these patches end up accomplishing is that it allows for the possibility to use alternate visuals, so the X11 driver would not need to force a specific double-buffered visual on initialization, and it allows programs to use program-specified color, stencil, depth, aux, multisampling, and single/double-buffer configurations without relying on the main window to have it too (this isn't done in these patches, but it does allow for it to work). Also, the scissors hack is no longer needed. All calls to the Wine-specific extension for it can be removed (they aren't removed here, instead just piped directly to the appropriate gl* function with no alteration, since that would require changes to opengl32). OpenGL in Win32 child windows is improved by being restrained to the Win32 windows' extents, as seen in the screen-grab here in VLC using the OpenGL output renderer: http://kcat.strangesoft.net/deskshot.jpg It uses proper color ordering (unlike the GDI renderer), is properly centered, can be scaled with no performance impact, and doesn't clear the whole window. Performance is good, and it is actually quite useable. Terragen (which has a real-time 3D window), Terragen 2 (which has two or three OpenGL child windows), Milkshape 3D, and GoogleEarth all work. Terragen 2 has some issues with its right-click menu that comes up from the OpenGL child window (the mouse doesn't interact with it), however I'm not sure if this is an issue with my patches since Milkshape3D also has a right-click menu from an OpenGL child and it works fine. In any case, there's no other input-related issues to speak of. Clicking and dragging the globe in GoogleEarth works, as does the keyboard controls in Terragen, and the other Win32 windows are properly receptive to all input as well. It also behaves properly with composite effects (such as the transparency, stretching, and warping effects from Beryl). All testing and comments on the patches are welcome. If the code is doing something it shouldn't be, I'm more than willing to figure out alternative methods if needed (hopefully with help). With luck, they can be gotten to a point soon where they can be rewritten properly to get into Wine.

4 4

Re: dsound/tests: The tests link with dsound.dll so use GetModuleHandle() instead of LoadLibrary().
by Felix Nawothnig 11 Jan '07

11 Jan '07

Francois Gouget wrote: > This is a NOP, it just seems a bit cleaner to me. > > - hDsound = LoadLibraryA("dsound.dll"); > - if (!hDsound) { > - trace("dsound.dll not found\n"); > - return; > - } > - > + hDsound = GetModuleHandleA("dsound.dll"); > + ok(hDsound != NULL, "dsound.dll not loaded!\n"); No it's not, that causes test failure on native when DirectX is not installed (NT4 out-of-the-box I believe?).

2 1

Looking for sound testers
by Maarten Lankhorst 11 Jan '07

11 Jan '07

Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten

6 5

Re: Stub fro GetRawInputDeviceList
by Marcelo Duarte 11 Jan '07

11 Jan '07

Michał Majchrowicz escreveu: > Hi. > I hope this time it is correct patch and will be accepted. > Regards Michael. I think the spec file is incorrect. > diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec > index f857105..0517ebc 100644 > --- a/dlls/user32/user32.spec > +++ b/dlls/user32/user32.spec > @@ -345,7 +345,7 @@ > # @ stub GetRawInputData > # @ stub GetRawInputDeviceInfoA > # @ stub GetRawInputDeviceInfoW > -# @ stub GetRawInputDeviceList > +@ stub GetRawInputDeviceList > maybe: @ stdcall GetRawInputDeviceList(ptr ptr long) > # @ stub GetReasonTitleFromReasonCode > # @ stub GetRegisteredRawInputDevices > @ stdcall GetScrollBarInfo(long long ptr) > diff --git a/include/winuser.h b/include/winuser.

1 0

WinZip regression
by martin pilka 11 Jan '07

11 Jan '07

Hello, automated CxTest testing shows WinZip regression: Jan 8 - WinZip ran 9 times (5 Francois + 4 Jozef), all succeeded Jan 9 - WinZip ran 1 time (Francois), failed with http://www.cxtest.org/triage/failures?dl=364121 (Out of resources error, unable to continue) Jan 10 - WinZip ran 2 times (1 Francois + 1 Jozef), both failed with same screenshot So there is a regression between Jan 8 and Jan 9 - unfortunately, I do not know GIT_ID. Should I create bug for this? If you want to join Wine automated testing process, go to http://www.cxtest.org/download and install CxTest. Martin

1 0

Re: WineD3D: Fix my name
by Alexandre Julliard 11 Jan '07

11 Jan '07

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Actually the encoding for source files is Latin-1 at the moment. This should probably be changed once we convert resources to utf-8, to make all files use the same encoding. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: Electron Microscope III (EMIII)
by Dmitry Timoshkov 11 Jan '07

11 Jan '07

"Seth Shelnutt" <shelnutt2(a)msn.com> wrote: > I am trying to get EMIII to run via wine. I'm perfectly willing to debug > this. I just don't know how. I think my issue is with MSVBVM60.DLL > (MSVBVM60.dbg)? I just sent a patch that should fix the crash. P.S. wineconf mailing list is not an appropriate place for a bug report. -- Dmitry.

1 0

dual displays
by James Hawkins 11 Jan '07

11 Jan '07

Hi, dlls/winex11.drv/opengl.c:820 if(!display || !display) { ERR("Invalid display or visual\n"); } My guess is that second 'display' is supposed to be 'visual'. -- James Hawkins

1 0

Re: D3D9: Implement IDirect3DDevice9::StretchRect
by Ivan Gyurdiev 11 Jan '07

11 Jan '07

Stefan Dösinger wrote: > This call can be handled fully by IWineD3DSurface::Blt. So where did the filter argument go.. there's 3 different filter types to support.

1 0

[ANN] Wine wiki
by Dimi Paun 11 Jan '07

11 Jan '07

Folks, As promised, the server that the wiki is on has been upgraded to a much better and faster box. Everything should work just fine, only faster :) Please let me know if you notice any problems or glitches. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: WineD3D: Fix my name
by Stefan Dösinger 11 Jan '07

11 Jan '07

Am Donnerstag 11 Januar 2007 02:07 schrieb Stefan Dösinger: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Ignore this patch, a code change slipped in accidentally. One that depends on my yesterday's [9] - ignore patch

1 0

Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
by Chetan Venkatesh 10 Jan '07

10 Jan '07

My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - chetan.venkatesh(a)gmail.com Regards Chetan

4 4

Re: [PATCH 2/10] dinput: [joystick_linux] Copy and modify default data format.
by Alexandre Julliard 10 Jan '07

10 Jan '07

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > @@ -610,6 +632,8 @@ static ULONG WINAPI JoystickAImpl_Releas > HeapFree(GetProcessHeap(), 0, This->props); > > /* release the data transform filter */ > + HeapFree(GetProcessHeap(), 0, (LPVOID)This->base.data_format.wine_df->rgodf); > + HeapFree(GetProcessHeap(), 0, (LPVOID)This->base.data_format.wine_df); Please don't add more cast-qual warnings, we are trying to get rid of them. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: rpcrt4: Give a proper name to some formerly reserved MIDL_STUB_MESSAGE fields.
by Francois Gouget 10 Jan '07

10 Jan '07

On Wed, 10 Jan 2007, Francois Gouget wrote: > Define NTDDI_WIN2K so we get definitions for the Reserved51_X fields with the PSDK. > This fixes compilation of the ndr_marshall.c with the PSDK. Ignore this one for now, it does not really solve the compilation problems with the PSDK so I will rework it a bit. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

1 0

Details: Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
by Chetan Venkatesh 10 Jan '07

10 Jan '07

I got a lot of people asking me to post details about our intended project. Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward. We're looking at contracting a development team to work on this with an estimated time to completion of 3 months, and are comfortable with an open source development model. The finished product will of course be released under the GPL. Feedback on this idea is welcome. Interested developers/organizations can contact me at chetan.venkatesh(a)gmail.com Chetan

1 0

Re: dinput, wheel/joystick and richard burns rally
by Vitaliy Margolen 09 Jan '07

09 Jan '07

Christoph Frick wrote: > On Mon, Jan 08, 2007 at 11:31:58AM -0700, Vitaliy Margolen wrote: > >> Well I've been looking at what will it take to fix it. Also made few >> patches for EnumObjects and GetObjectInfo. But I can't send those, >> because other parts using wrong indexes. And it will really brake >> things (but should fix the problem Tuomo was talking about). >> If you want to pick it up, I can move on to something else. > > well i had a look at it yesterday. what i have seen then next things > are to build the wine_df within the alloc_device. this can either be > done by copiing the const format or by really create what we have. this > would mean then to move the code from EnumObjects over and adapt it and > get rid of EnumObjects at all. > > is this right? > Correct. Sorry I got this already done and patches sent. After looking at it myself I realized that it would be easier to send everything as one set. The hard part was figuring out which index used where and why. I think that should do it for now. The only other big refactoring that I can think of would be using user provided data format as internal format. And of course merging two joystick files. There are much closer to each-other now. Vitaliy.

1 0

Re: Alexandre Julliard : Release 0.9.29.
by Lei Zhang 09 Jan '07

09 Jan '07

Bugzilla needs to be updated with the new version number. On 1/9/07, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: d8c3e7de692c785e1c7679d0521cf8b12469b0b8 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=d8c3e7de692c785e1c7679d05… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Jan 9 16:42:47 2007 +0100 > > Release 0.9.29. > > --- > > ANNOUNCE | 923 +++++++++++++++++------------ > ChangeLog | 1936 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > VERSION | 2 +- > configure | 18 +- > 4 files changed, 2484 insertions(+), 395 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=d8c3e7de692c785e1c767… > > >

1 0

Re: uninstaller: Add a Portuguese translation (contributed by Americo Jose Melo).
by Frank Richter 09 Jan '07

09 Jan '07

On 08.01.2007 11:49, Francois Gouget wrote: > +CAPTION "Desinstalador de AplicaÃ§Ãµes Wine" That's UTF-8... Is that correct? I though Portugese resources should be in cp1252. -f.r.

3 2

Re: uninstaller: Add a Portuguese translation (contributed by Americo Jose Melo).
by Michael Stefaniuc 09 Jan '07

09 Jan '07

Francois Gouget wrote: > --- > Resubmitting with the proper encoding this time, with thanks to Frank > Richter. I also switched SUBLANG_PORTUGUESE_PORTUGAL to the more > standard SUBLANG_PORTUGUESE to match all the other resource files. Actualy http://wiki.winehq.org/Developers-Hints#head-ef42a958e4f633dbd4a0ae42649fa0… says quite the opposite. Target is to change the SUBLANG_$whatever to SUBLANG_NEUTRAL if all the sublanguages use the same translation. And default in Windows for portugese is SUBLANG_PORTUGUESE_BRAZILIAN and not SUBLANG_PORTUGUESE_PORTUGAL. bye michael > > programs/uninstaller/Pt.rc | 21 +++++++++++++++++++-- > 1 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/programs/uninstaller/Pt.rc b/programs/uninstaller/Pt.rc > index 5797fb1..0f8ea11 100644 > --- a/programs/uninstaller/Pt.rc > +++ b/programs/uninstaller/Pt.rc > @@ -18,9 +18,26 @@ > * > */ > > -LANGUAGE LANG_PORTUGUESE, SUBLANG_NEUTRAL > +LANGUAGE LANG_PORTUGUESE, SUBLANG_PORTUGUESE > > +IDD_UNINSTALLER DIALOG DISCARDABLE 0, 0, 330, 160 > +STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU > +CAPTION "Desinstalador de Aplicações Wine" > +FONT 10, "MS Sans Serif" > +BEGIN > + LTEXT "Por favor seleccione a aplicação que deseja desinstalar:",IDC_PLEASESELECT,10,10,250,14 > + EDITTEXT IDC_FILTER,10,25,250,14,ES_AUTOHSCROLL > + LISTBOX IDC_LIST,10,43,250,106,LBS_NOINTEGRALHEIGHT | > + LBS_EXTENDEDSEL | WS_VSCROLL | WS_TABSTOP > + PUSHBUTTON "&Desinstalar",IDC_UNINSTALL,270,48,50,14 > + PUSHBUTTON "&Acerca",IDC_ABOUT,270,65,50,14 > + PUSHBUTTON "&Sair",IDC_EXIT,270,81,50,14 > +END > > STRINGTABLE DISCARDABLE { > - IDS_APPNAME, "Desinstalador" > + IDS_APPNAME, "Desinstalador de Aplicações Wine" > + IDS_ABOUT, "Desinstalador de Aplicações Wine (C) 2005 por Andreas Mohr, Hannu Valtonen e Jonathan Ernst." > + IDS_ABOUTTITLE, "Acerca do Desinstalador" > + IDS_REGISTRYKEYNOTAVAILABLE, "Chave de registo de desinstalação não disponível (ainda), nada a fazer !" > + IDS_UNINSTALLFAILED, "Execução do comando de desinstalação '%s' falhado, talvez devido a faltar o executável.\r\nDeseja remover a entrada de desinstalação do registo ?" > } > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: [try 3] systray patches
by Kirill K. Smirnov 09 Jan '07

09 Jan '07

> > Or I miss something really important? If so, just provide a use-case, > > please!! > > Well, for instance if the parent is a Wine window, which would be the > case when someone implements systray handling in desktop mode, it > would break since Wine windows are not painted with the background > pixmap. This case assumes absolutely other mechanism of embedding, not XEMBED. _Wine_ cannot be XEMBED-master for _wine_ application. (May it? Reasons?) My patches are to fix annoying background situation caused by _XEMBED_ usage. Only for xembed. Other way (as you supposed, native wine's tray in desktop mode) may be implemented (interesting idea, I though about it, but is there anybody who needs this?). Then XEMBED and the new mechanism MUST be mutually excluse. So, my patch does not hurt anything. > Anyway, I'm not necessarily opposed to doing pseudo-transparency, if > you can find a way to do it cleanly, i.e. without adding special cases > for systray windows all over the place. Heh, I intend to add cases as less as possible! BUT! For any "output-only-transparency, not input" mechanism for XEMBED I choose, I have to play around with background pixmap. When application changes icon, the window background must be repainted to remove previous junk. As you say, Wine windows are not painted with the background pixmap (I do not know details), so we must do it explicitly by calling XClearWindow. This is reason for at least one special case handling. And I add one special case in SetWindowIcon(a)winex11.drv/window.c!!! Other case I added in user32/defwnd.c looks like hack. You were right - I should investigate SetWindowPos problem. -- Kirill

1 0

Re: [try 3] systray patches
by Kirill K. Smirnov 09 Jan '07

09 Jan '07

> It's not transparent, Hm... Yes, it is not transparent. It is pseudo-transparent. Just for us. > it's painted with what you hope is the same > background as the parent, but there's no guarantee of that. Xlib thinks opposite. The window will be painted with the same background as the parent (not a copy of parent pixmap, but the same pixmap). It will be even correctly tiled to provide 'pseudo-transparency'! Xlib programming manual guarentee that: http://www.cptec.inpe.br/sx4/sx4man2/g1ae02e/chap3.html chapter 3.2.1. The main ideas I based upon: 1) the parent window does not paint anything under our window. If there will be smth, then pseudo-transparency will be broken. 2) Any sane systray implementation satisfies 1). 3) KDE/fluxbox/other systrays are sane. The link: http://www.nabble.com/-Gaim-gtk-bugs----gaim-gtk-bugs-1370422---Tray-icon-n… provides some information (KDE): [quote] "The code of those applications needs to be changed to perform XSetWindowBackgroundPixmap( dpy, window, ParentRelative ) on the X window that is used as the systray icon. There's nothing KDE can do about this, you need to ask the app developers to support this fake transparency." [/quote] Or I miss something really important? If so, just provide a use-case, please!! -- Kirill

2 1

Re: [try 3] systray patches + SetWindowPos in WM_SETICON
by Kirill K. Smirnov 09 Jan '07

09 Jan '07

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > Please, explain me, what is wrong with this serie of patches? > > What to do to improve them? > > As I said, making the background pixmap ParentRelative is just a hack, > it's not real transparency. Why is it not a real transparency? This is the easiest way to provide only output transparency, not input. Exactly what we need. > You don't know how the parent will paint > itself, so you can't rely on that. wine doesn't know that, but does not need to know too. That's why I use ParentRelative, because when I change KDE (e.g.) panel background it is handled correct. > Also, your patch adds special > handling for the tray window in user32, that's a violation of the > driver abstraction. Hm... The core problem here is to notify WM systray to be repainted when wine changes icon. To achieve this, I call XClearWindow in setwindowicon(a)winex11.drv/window.c. This is ideological correct (IMO) - perform X operation in setwindowicon function when application changes icon. But!!! defwndproc(a)user32.defwnd calls SetWindowPos. This breaks everything concerning wine tray. Tray window should not be reposed. It is done once (while docking) and forever. So, my patch for user32 is a 'bugfix' for a 'bug' caused by wine systray embedding idea. Maybe, there is other way to achieve this, but I cannot imagine. Any ideas? -- Kirill

2 1

Re: add tests to odbccp32
by Alexandre Julliard 09 Jan '07

09 Jan '07

Bill Medland <billmedland(a)shaw.ca> writes: > + /* MSDN states that the error number should be between 1 and 8. Passing 0 is an error */ > + sql_ret = SQLInstallerError(0, NULL, NULL, 0, NULL); > + todo_wine(sql_ret == SQL_ERROR, "SQLInstallerError(0...) failed with %d instead of SQL_ERROR\n", sql_ret); That's not how todo_wine is used, this won't do anything useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Humus Water demo vs FBOs
by Ivan Gyurdiev 09 Jan '07

09 Jan '07

Here's a demo that breaks FBOs: http://www.humus.ca/3D/Water.zip Also download: http://www.humus.ca/3D/Framework2.zip You'll notice all the glClear calls fail [ or at least a lot of them ]. That's because the framebuffer is incomplete at that point - checkFBOstatus() should be called before glClear, as well as drawprim to see that this is FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT (0x8cd9). I think the call that fails is the clear call in the drawFrame() function of the app - the others set a 0 depth stencil buffer immediately prior, while this one is probably using wined3d's initial depth fbo. I think the Framework sets EnableAutoDepthStencil, so that an fbo is created. It probably ends up being a different size from the color fbo, which breaks a framebuffer completeness requirement.

2 1

memory corruption in dlls/oleaut32/olepicture.c?
by Damjan Jovanovic 09 Jan '07

09 Jan '07

Hi In dlls/oleaut32/olepicture.c, there are several places where memory is allocated and then used immediately, without checking whether allocation succeeded. For example: 1479 xbuf = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, origsize); 1480 if (headerisdata) 1481 memcpy (xbuf, &header, 8); Is there something I'm missing, or does that sort of code lead to memory corruption / segmentation faults when allocating memory fails? >From what I see on http://people.redhat.com/mstefani/wine/smatch/bugs_all.html, smatch doesn't detect this as an error. What should we do? Damjan

2 1

RawInput
by Michał Majchrowicz 09 Jan '07

09 Jan '07

Hi. I am trying to write functions for RawInput in wine. If understand correctly GetRawInputDeviceList function gives us an array of rawinputdevice's registered with function RegisterRawInputDevices. So implementing it would be just geting and setting data in array. But I have two question: 1) Where should i put this array? In which file? 2) How can I get data to fill the begining of the array (according to my tests when Windows has only mouse and keyboard connected there are 4 input devices) Regards Michael.

2 1

Re: Proposed patch for "fonts.c"
by Marcus Meissner 09 Jan '07

09 Jan '07

On Mon, Jan 08, 2007 at 11:49:49PM +0100, Bernard Choppy wrote: > Good day, > > online(a)noteworthysoftware.com sent a patch covering bug 7040 I've initiated. > > The problem is that wine doesn't handle properly Symbol-encoded fonts, > which makes rendering of special fonts (in this case, music notation for > the NoteWorthy version 2 softwares) inaccurate. > > I suppose he will sent this patch too, but to make sure, please find it > here. > > 352c352 > < static LPWSTR FONT_mbtowc(LPCSTR str, INT count, INT *plenW) > --- > > static LPWSTR FONT_mbtowc(HDC hdc, LPCSTR str, INT count, INT *plenW) Please use "diff -u". Ciao, Marcus

1 0

Re: appdb/ ./account.php ./addcomment.php ./appbro ...
by Tony Lambregts 09 Jan '07

09 Jan '07

WineHQ wrote: > ChangeSet ID: 30851 > CVSROOT: /opt/cvs-commit > Module name: appdb > Changes by: wineowner(a)winehq.org 2007/01/03 20:35:02 > > Modified files: > . : account.php addcomment.php appbrowse.php > appimage.php appsubmit.php appview.php > browse_by_rating.php browse_newest_apps.php > commentview.php deletecomment.php > distributionView.php maintainerdelete.php > maintainersubmit.php preferences.php > screenshots.php search.php testResults.php > vendorview.php viewScreenshots.php viewbugs.php > votestats.php > admin : addAppNote.php addCategory.php > adminAppDataQueue.php adminAppQueue.php > adminBugs.php adminCommentView.php > adminMaintainerQueue.php adminMaintainers.php > adminScreenshots.php adminTestResults.php > adminUsers.php deleteAny.php editAppFamily.php > editAppNote.php editAppVersion.php > editBundle.php editDistribution.php > editVendor.php moveAppVersion.php > help : index.php > include : application.php bugs.php comment.php > distribution.php filter.php form_edit.php > form_login.php form_new.php incl.php note.php > screenshot.php sidebar.php testData.php url.php > util.php version.php vote.php > > Log message: > Chris Morgan <cmorgan(a)alum.wpi.edu> > Fix and enable input filtering through include/filter.php > > Patch: http://cvs.winehq.org/patch.py?id=30851 > > Old revision New revision Changes Path > 1.34 1.35 +0 -1 appdb/account.php > 1.33 1.34 +0 -1 appdb/addcomment.php > 1.22 1.23 +0 -1 appdb/appbrowse.php > 1.28 1.29 +0 -1 appdb/appimage.php > 1.57 1.58 +6 -20 appdb/appsubmit.php > 1.96 1.97 +0 -8 appdb/appview.php > 1.1 1.2 +0 -1 appdb/browse_by_rating.php > 1.2 1.3 +0 -1 appdb/browse_newest_apps.php > 1.15 1.16 +0 -1 appdb/commentview.php > 1.30 1.31 +0 -1 appdb/deletecomment.php > 1.22 1.23 +0 -1 appdb/distributionView.php > 1.24 1.25 +0 -7 appdb/maintainerdelete.php > 1.33 1.34 +0 -7 appdb/maintainersubmit.php > 1.33 1.34 +3 -25 appdb/preferences.php > 1.41 1.42 +0 -1 appdb/screenshots.php > 1.21 1.22 +0 -1 appdb/search.php > 1.22 1.23 +2 -10 appdb/testResults.php > 1.23 1.24 +0 -1 appdb/vendorview.php > 1.7 1.8 +0 -1 appdb/viewScreenshots.php > 1.10 1.11 +0 -1 appdb/viewbugs.php > 1.27 1.28 +0 -1 appdb/votestats.php > 1.30 1.31 +1 -8 appdb/admin/addAppNote.php > 1.15 1.16 +0 -8 appdb/admin/addCategory.php > 1.30 1.31 +0 -9 appdb/admin/adminAppDataQueue.php > 1.69 1.70 +6 -21 appdb/admin/adminAppQueue.php > 1.14 1.15 +0 -9 appdb/admin/adminBugs.php > 1.16 1.17 +0 -5 appdb/admin/adminCommentView.php > 1.35 1.36 +0 -8 appdb/admin/adminMaintainerQueue.php > 1.28 1.29 +0 -5 appdb/admin/adminMaintainers.php > 1.16 1.17 +0 -9 appdb/admin/adminScreenshots.php > 1.17 1.18 +1 -6 appdb/admin/adminTestResults.php > 1.13 1.14 +0 -9 appdb/admin/adminUsers.php > 1.22 1.23 +0 -8 appdb/admin/deleteAny.php > 1.43 1.44 +0 -5 appdb/admin/editAppFamily.php > 1.29 1.30 +2 -9 appdb/admin/editAppNote.php > 1.41 1.42 +0 -6 appdb/admin/editAppVersion.php > 1.15 1.16 +10 -10 appdb/admin/editBundle.php > 1.11 1.12 +1 -7 appdb/admin/editDistribution.php > 1.15 1.16 +0 -6 appdb/admin/editVendor.php > 1.11 1.12 +0 -6 appdb/admin/moveAppVersion.php > 1.10 1.11 +5 -5 appdb/help/index.php > 1.82 1.83 +5 -11 appdb/include/application.php > 1.19 1.20 +4 -6 appdb/include/bugs.php > 1.31 1.32 +1 -4 appdb/include/comment.php > 1.3 1.4 +2 -6 appdb/include/distribution.php > 1.8 1.9 +13 -8 appdb/include/filter.php > 1.10 1.11 +0 -3 appdb/include/form_edit.php > 1.8 1.9 +0 -4 appdb/include/form_login.php > 1.10 1.11 +0 -6 appdb/include/form_new.php > 1.38 1.39 +8 -1 appdb/include/incl.php > 1.20 1.21 +1 -7 appdb/include/note.php > 1.53 1.54 +1 -3 appdb/include/screenshot.php > 1.24 1.25 +3 -5 appdb/include/sidebar.php > 1.15 1.16 +6 -12 appdb/include/testData.php > 1.10 1.11 +2 -6 appdb/include/url.php > 1.77 1.78 +40 -38 appdb/include/util.php > 1.90 1.91 +5 -9 appdb/include/version.php > 1.23 1.24 +1 -5 appdb/include/vote.php > > This patch breaks xinha editing... -- Tony Lambregts

3 4

Re: comctl32: Rewrite the up-down control tests to add message checking
by Dmitry Timoshkov 09 Jan '07

09 Jan '07

"James Hawkins" <truiken(a)gmail.com> wrote: > + if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) > + { > + todo_wine > + { > + failcount++; > + ok_(file, line) (FALSE, > + "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > + context, expected->message, expected->lParam, actual->lParam); > + } > + } This is an old typo/misleading message that I've fixed in the original msg.c code. -- Dmitry.

1 0

Re: [user32][test] Add test for messageboxes
by Dmitry Timoshkov 09 Jan '07

09 Jan '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > + thread = CreateThread( NULL, 0, create_messagebox_thread, &info, 0, &tid ); > + while(info.hWndDlg == NULL) > + info.hWndDlg = FindWindowA(NULL,info.ch); This is too hackish IMO, if dialog creation fails for some reason the test will hang. > + > + PostMessageA(info.hWndDlg,WM_COMMAND,IDCANCEL,0); > + Sleep(nTimeOut); > + if(info.ret==-1) > + SendMessageA(info.hWndDlg,WM_COMMAND,Data[i].nExitMessage,(LPARAM)GetDlgItem( info.hWndDlg, > Data[i].nExitMessage )); Why don't you check whether 'info.ret==-1' is a legitimate response or not? > + Sleep(nTimeOut); > + ok(info.ret == Data[i].nReact,"This dialogue has incorrect reaction on IDCANCEL!\n"); > + CloseHandle( thread ); > + } > +} And these Sleep() calls are potential races. -- Dmitry.

1 0

Re: Add tests to odbccp32
by Detlef Riekenberg 08 Jan '07

08 Jan '07

On Mo, 2007-01-08 at 09:58 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)shaw.ca) > Add tests structure to odbccp32 > +START_TEST(error) > +{ > +} We really need more tests, but I do not think, that an empty testfile can go in the tree. And as another hint, you should use the same filename. You might want to look, how I add the tests for "localspl.dll": I use the testfile "dlls/localspl/tests/localmon.c" to test the implementation of "dlls/localspl/localmon.c" The History for the tests: http://source.winehq.org/git/wine.git/?a=history;f=dlls/localspl/tests My Patch for the initial test: http://www.winehq.org/pipermail/wine-patches/2006-September/031009.html -- By by ... Detlef

1 0

Compilation problem during regression testing
by L. Rahyen 08 Jan '07

08 Jan '07

I'm doing regression testing of Hogia software and have following compilation problem near wine-0.9.12: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ddraw.spec d3d_utils.o device_main.o device_opengl.o direct3d_main.o direct3d_opengl.o executebuffer.o light.o material.o opengl_utils.o texture.o vertexbuffer.o viewport.o clipper.o ddraw_hal.o ddraw_main.o ddraw_thunks.o ddraw_user.o ddraw_utils.o main.o palette_hal.o palette_main.o regsvr.o surface_dib.o surface_fakezbuffer.o surface_gamma.o surface_hal.o surface_main.o surface_thunks.o surface_user.o surface_wndproc.o version.res -Wl,--rpath, \$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/lib` -o ddraw.dll.so -L../../dlls -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L../../libs -lwine -ldxguid -luuid -lSM -lICE -lXxf86vm -lXext -lX11 -L../../libs/port -lwine_port surface_dib.o: In function `create_dib': /var/pkgs/wine/wine-git.experimental/dlls/ddraw/surface_dib.c:159: undefined reference to `DIB_CreateDIBSection' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ddraw.dll.so] Error 2 make[2]: Leaving directory `/var/pkgs/wine/wine-git.experimental/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/var/pkgs/wine/wine-git.experimental/dlls' make: *** [dlls] Error 2 Any idea how to resolve this? I tried to compile with 3.4.6 and 4.1.2 - same result.

1 0

Re: [try 3] systray patches
by Kirill K. Smirnov 08 Jan '07

08 Jan '07

Please, explain me, what is wrong with this serie of patches? What to do to improve them? http://www.winehq.org/pipermail/wine-patches/2007-January/034408.html http://www.winehq.org/pipermail/wine-patches/2007-January/034409.html http://www.winehq.org/pipermail/wine-patches/2007-January/034410.html http://www.winehq.org/pipermail/wine-patches/2007-January/034412.html http://www.winehq.org/pipermail/wine-patches/2007-January/034413.html Regards, Kirill K. Smirnov

2 1

Re: [Fwd: patch for bz 6855]
by James Hawkins 08 Jan '07

08 Jan '07

On 1/7/07, Neil Marko <nmarko(a)isyssoft.com> wrote: > Very sorry, I meant 0.9.28 and I forgot the patch!!! > > Hope this helps. > > Neil Marko > > -------- Original Message -------- > Subject: patch for bz 6855 > Date: Sun, 07 Jan 2007 17:42:56 -0500 > From: Neil Marko <nmarko(a)isyssoft.com> > To: wine-patches(a)winehq.org > > > > Hi all: > > Sorry that this is not in GIT format. I do not have the time to learn > this. I just wanted to get Off2K installed on 9.2.28. > > My determination of this bug is that around version 9.2.20 or so, > dlls/msi/files.c was rewritten. This bug seems to come from that. In > the routine ACTION_InstallFiles, there is a loop of all the file > objects. The first few steps of that loop attempt to detect a media > change. That ultimately causes a call to load_media_info. The select > statement in load_media_info has a where clause where table column > LastSequence is greater than the value of the current file. The problem > I detected is that what is selected in the first pass through the loop > is the media for the next sequence (COMCTL.OCX) and not the current > file. When a successful select occurs, the value of mi->last_sequence > is updated from the select row, which is obviously not correct. When we > loop eventually to the file structure where we should have a media > change (COMCTL.OCX), we do not do the media change and then we do not > extract the compressed file and the install fails. I solved this by > simply setting mi->last_sequence to file->Sequence in the loop in > ACTION_InstallFiles. > > It is possible that maybe changing the ">=" to a "=" in the select in > load_media_info might also solve this but I do not have enough knowledge > about msi to know if that could cause any other problems. I think we > would also have to change the error condition so that not reading rows > there would not cause a failure. That seemed like a lot more work! > > I eventually successfully installed Off2K on 9.2.28 with this. > (Eventually since I have only an "upgrade" version of Off2K and > therefore, some of the registry was not setup correctly. I made it work.) > It would be great if you could add a test for this case to dlls/msi/tests/install.c. That way we can verify that the fix is correct. Thanks, James Hawkins

1 0

Re: Add tests to odbccp32
by James Hawkins 08 Jan '07

08 Jan '07

On 1/8/07, Bill Medland <billmedland(a)shaw.ca> wrote: > Bill Medland (billmedland(a)shaw.ca) > Add tests structure to odbccp32 > You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests. -- James Hawkins

2 4

Re: dinput, wheel/joystick and richard burns rally
by Vitaliy Margolen 08 Jan '07

08 Jan '07

Christoph Frick wrote: > On Mon, Jan 08, 2007 at 10:28:22AM -0700, Vitaliy Margolen wrote: > >> That is correct. I already fixed mouse and keyboard the proper way. >> Now left to fix joysticks. It seems joysticks are in the worse shape >> that I thought. Number of places using wrong object indexes. > > does that mean, you are already working in this area? > Well I've been looking at what will it take to fix it. Also made few patches for EnumObjects and GetObjectInfo. But I can't send those, because other parts using wrong indexes. And it will really brake things (but should fix the problem Tuomo was talking about). If you want to pick it up, I can move on to something else. Vitaliy.

1 0

dinput, wheel/joystick and richard burns rally
by Tuomo Kohvakka 08 Jan '07

08 Jan '07

Hello, first, appdb entry: http://appdb.winehq.org/appview.php?iVersionId=5934&iTestingId=6382 As shown there, joystick (that ofcourse really means the wheel :) isn't detected by the game with current wine. I decided to take a look at that, figuring that it might be fixable. Well, I managed to "fix" it. Code follows, dlls/dinput/device.c, create_DataFormat() around line 387 says that && (/* Then check if it accepts any instance id, and if not, if it matches Wine's * instance id. */ ((asked_format->rgodf[j].dwType & DIDFT_INSTANCEMASK) == DIDFT_ANYINSTANCE) || (DIDFT_GETINSTANCE(asked_format->rgodf[j].dwType) == 0x00FF) || /* This is mentionned in no DX docs, but it works fine - tested on WinXP */ (DIDFT_GETINSTANCE(asked_format->rgodf[j].dwType) == DIDFT_GETINSTANCE(format->wine_df->rgodf[i].dwType))) && Now, adding || ((asked_format->rgodf[j].dwType&0xff) == (format->wine_df->rgodf[i]. =>dwType&0xff)) into middle of that fixes it. It works fine and doesn't seem to break anything (didn't try other applications thought). It took me a couple of hours to figure above ou, a few more comments more might have helped! :) (code itself is rather easy to follow) Now, my problem is that I don't really know anything about directx or much about windows anyhow. That means that I don't know if above "fix" is really proper way to fix anything. I figure that purpose of this function make a mapping from devices axes and buttons (wine datastructure) into applications preferred structure (which is used later on in fill_DataFormat). Mapping goes wrong without above, as application requests "3" in dwType and wine has something like 0x80ffff03. It's defined in c_dfDIJoystick2, data_formats.c as DIDFT_OPTIONAL|DIDFT_AXIS|DIDFT_ANYINSTANCE. If mapping goes wrong offset_in becomes -1 and that means that default values will be used (button not pressed etc). (If I would submit a patch containing only comments, some probably wrong guesses, would it be accepted?) Someone here on list probably has more insight on this. What is that dwType anyways? :) Is above fix correct, or should dwType be something else from the beginning with, or am I just completely lost? Bottom line ofcourse is that I would like to see a proper fix in wine .29 that would allow rbr and wheel co-operate :) Should I just try to submit this as a patch? -- Tuomo Kohvakka

3 2

Re: odbccp32 SQLGetInstalledDrivers etc
by Bill Medland 08 Jan '07

08 Jan '07

On Fri, 2007-05-01 at 16:14 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)shaw.ca) > Implement SQLGetInstalledDrivers > Implement a basic SQLInstallerError > Add test framework and some initial tests Would it help if this was split into three patches?

1 0

Missing tables in the AppDB dump
by Tony Lambregts 08 Jan '07

08 Jan '07

The dump of the AppDB is missing the following tables appMaintainers, buglinks, appHitStats, catHitStats Could someone please add them to the nightly dump. Thanks -- Tony Lambregts

2 1

Re: Stub for GetRawInputDeviceList
by L. Rahyen 08 Jan '07

08 Jan '07

Monday January 8 2007 14:35、Michał Majchrowicz さんは書きました: (from the attached file) > A modification of patch found on wine mailing list It checks whether Also, for more information you can mention my name if you wish as initial author of this patch. I know that my patch was silently rejected long time ago - I didn't asked why because I was too busy for some time and... my little patch was simply lost because of this (I wasn't very active because my patch is very small and simple). But some time ago I have received a message from unofficial wine-wiki that it "has a quote based upon your October mailing list post" (actually the patch).

1 1

Re: Stub for GetRawInputDeviceList
by Dmitry Timoshkov 08 Jan '07

08 Jan '07

Michal Majchrowicz mmajchrowicz(a)gmail.com wrote: > Everything is in the file :) > Regards. You are using tab == 4 spaces in your editor and that messes up formatting in 2 places in your patch. Also you should leave at least 1 empty line between function implementations like it is in the existing code. -- Dmitry.

1 0

Re: [15/20] WineD3D: Clean up drawprim a bit
by Ivan Gyurdiev 07 Jan '07

07 Jan '07

Stefan Dösinger wrote: > Now that almost everything is gone from drawPrimitiveDrawStrided we don't need > a subfunction for calling drawStridedSlow/Fast any longer > I think while we're cleaning up things, all of software shaders should be removed. There's tons of code in drawprim and *shader.c, which is disabled, doesn't work, and isn't on the right track if you ask me. None of the changes to make the shader parser 3.0 compliant are used in the disabled paths. There's even an "Emulation" value in winecfg which just confuses the user, since it doesn't work. I did have a working implementation of software shaders some time ago, which broke things up into functions, and shared the tracing and parser with hardware shaders - but in the end it was too slow, and I abandoned it as the wrong approach too. Unless we generate asm on the fly for the shader or something like that, I don't think software shaders will be made to work soon.

2 2

Re: make_makefiles: Ignore backups of edited files.
by Patrik Stridvall 07 Jan '07

07 Jan '07

On Sunday 07 January 2007 13:16, Robert Shearman wrote: > --- > tools/make_makefiles | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Since the "*~" files are not generated by the build process this is perhaps not the right place to do it. Rather each developer should ignore such files by editing the .git/info/exclude file. Works for me! Somebody probably should update the website to make other developers aware of this.

1 0

Re: fix a typo
by Detlef Riekenberg 06 Jan '07

06 Jan '07

On Sa, 2007-01-06 at 15:08 +0100, Jonathan Ernst wrote: > (I think) I decided to use "options", because native Ports have: COM*: Multiple options (BaudRate, DataBits, StopBits, Parity) LPT*: A single option (TransmissionRetryTimeout) FILE: No options Wine will add Redirection, what we can set in the registry at HKCU\Software\Wine\Printing\Spooler\<portname> -- By by ... Detlef

2 1

Re: [17/20] WineD3D: Vertex buffers can use the declaration from the device
by Ivan Gyurdiev 06 Jan '07

06 Jan '07

Stefan Dösinger wrote: > Now that the decoded vertex declaration is put into the device with > baseVertexIndex = 0, vertex buffers can just memcpy it instead of decoding it > Here's an issue I see - isn't introduced by your patch, but I am just confused. In the vertex buffer code: if(device->stateBlock->vertexShader != NULL && wined3d_settings.vs_mode != VS_NONE &&((IWineD3DVertexShaderImpl *)device->stateBlock->vertexShader)->baseShader.function != NULL && GL_SUPPORT(ARB_VERTEX_PROGRAM)) { /* Case 1: Vertex Shader: No conversion */ TRACE("Vertex Shader, no conversion needed\n"); } else if(device->stateBlock->vertexDecl || device->stateBlock->vertexShader) { 1) No code should be looking at wined3d_settings.vs_mode. This is the user spec from winecfg, which is taken into account as one of the things that determines shader mode. There are a number of other things involved - use device->shader_mode instead. 2) GL_SUPPORT(ARB_VERTEX_PROGRAM) has already been accounted for when selecting the shader mode in the device 3) This if statement looks kind of like the "useVertexShaderFunction" variable in drawprim 4) Why is the "device->stateblock->vertexShader" case included in the else statement? You cannot use this function with a vertex shader - it would not work at all, as the strided data is formatted differently (same issue as the trace function discussed earlier).

1 0

Re: French translation of localspl
by Detlef Riekenberg 06 Jan '07

06 Jan '07

On Sa, 2007-01-06 at 15:09 +0100, Jonathan Ernst wrote: > + IDS_NOTHINGTOCONFIG "Ce port n'a pas d'option Ã configurer" This is encoded as UFT-8 -- By by ... Detlef

1 0

appdb rating inflation
by Dan Kegel 06 Jan '07

06 Jan '07

The appdb says "Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list" But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - "with alsa, the sound lags ~ 1 second behind the game.... if i choose oss i got the 166 sound files missing error" And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

19 39

Re: listview: Remove over constrained restriction on creating subitems.
by Alexandre Julliard 06 Jan '07

06 Jan '07

Duane Clark <fpga(a)pacbell.net> writes: > Changelog: Remove over constrained restriction on creating subitems. > Subject: [PATCH] Remove over constrained restriction on creating subitems. This breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so listview.c && touch listview.ok listview.c:305: Test failed: ret 1 make[2]: *** [listview.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Problem with App Data screen
by Tony Lambregts 06 Jan '07

06 Jan '07

There is a problem with submitting/administrating screen shots. I cannot see any screenshots that were submitted recently. This is probably a problem with filtering but I cannot be sure. http://appdb.winehq.org/admin/adminAppDataQueue.php http://appdb.winehq.org/admin/adminAppDataQueue.php?iId=5572 -- Tony Lambregts

2 1

winebuild/DLLSPEC question
by Andrew Talbot 06 Jan '07

06 Jan '07

I was looking at Coverity bug report #CID294, and that has led me to ask about the "base" and "limit" values of the DLLSPEC structure. In winebuild/utils.c, we have: spec->base = MAX_ORDINALS; spec->limit = 0; Is that the correct way round? Thanks, -- Andy.

1 0

are trace timestamps possible?
by Robert Reif 06 Jan '07

06 Jan '07

Is there a way to get a time stamp in trace output kind of like we do now for thread id?

2 1

quartz help needed
by Robert Reif 06 Jan '07

06 Jan '07

I'm trying to get Windows Media Player 6.4 working again and am running into problems. At first it was crashing while trying to read wave files. I found 2 bugs that were preventing it from working: some minor memory corruption for questionable wave files and using a pointer before it was initialized. With these fixed (patch attached) you can now play files once but the program gets confused at the end of the file. There are a lot of fixmes and unimplemented stuff. This program was rated gold at one point so I'm not sure my fixes are completely correct. I have written dshow filters and programs in the past at work and it was an extremely frustrating experience so I would appreciate and help getting quarts working again. Index: dlls/quartz/waveparser.c =================================================================== RCS file: /home/wine/wine/dlls/quartz/waveparser.c,v retrieving revision 1.5 diff -p -u -r1.5 waveparser.c --- dlls/quartz/waveparser.c 13 Oct 2006 10:27:23 -0000 1.5 +++ dlls/quartz/waveparser.c 6 Jan 2007 13:09:25 -0000 @@ -63,6 +63,7 @@ static HRESULT WAVEParser_Sample(LPVOID long cbDstStream; long chunk_remaining_bytes = 0; long offset_src = 0; + TRACE("(%p)->(%p)\n", iface, pSample); hr = IMediaSample_GetPointer(pSample, &pbSrcStream); @@ -202,6 +203,8 @@ static HRESULT WAVEParser_Sample(LPVOID static HRESULT WAVEParser_QueryAccept(LPVOID iface, const AM_MEDIA_TYPE * pmt) { + TRACE("(%p)->(%p)\n", iface, pmt); + if (!IsEqualIID(&pmt->majortype, &MEDIATYPE_Stream)) return S_FALSE; if (IsEqualIID(&pmt->subtype, &MEDIASUBTYPE_WAVE)) @@ -220,17 +223,21 @@ static HRESULT WAVEParser_InputPin_PreCo LONGLONG pos = 0; /* in bytes */ PIN_INFO piOutput; ALLOCATOR_PROPERTIES props; - AM_MEDIA_TYPE amt; + AM_MEDIA_TYPE * pmt; float fSamplesPerSec = 0.0f; DWORD dwSampleSize = 0; DWORD dwLength = 0; WAVEParserImpl * pWAVEParser = (WAVEParserImpl *)This->pin.pinInfo.pFilter; + LPWAVEFORMATEX pwfx; + TRACE("(%p)->(%p)\n", iface, pConnectPin); piOutput.dir = PINDIR_OUTPUT; piOutput.pFilter = (IBaseFilter *)This; lstrcpynW(piOutput.achName, wcsOutputPinName, sizeof(piOutput.achName) / sizeof(piOutput.achName[0])); hr = IAsyncReader_SyncRead(This->pReader, pos, sizeof(list), (BYTE *)&list); + if (hr != S_OK) + return E_FAIL; pos += sizeof(list); if (list.fcc != ckidRIFF) @@ -250,6 +257,8 @@ static HRESULT WAVEParser_InputPin_PreCo } hr = IAsyncReader_SyncRead(This->pReader, pos, sizeof(chunk), (BYTE *)&chunk); + if (hr != S_OK) + return E_FAIL; pos += sizeof(chunk); if (chunk.fcc != mmioFOURCC('f','m','t',' ')) { @@ -257,52 +266,79 @@ static HRESULT WAVEParser_InputPin_PreCo return E_FAIL; } - memcpy(&amt.majortype, &MEDIATYPE_Audio, sizeof(GUID)); - memcpy(&amt.formattype, &FORMAT_WaveFormatEx, sizeof(GUID)); - amt.cbFormat = chunk.cb; - amt.pbFormat = CoTaskMemAlloc(amt.cbFormat); - amt.pUnk = NULL; - hr = IAsyncReader_SyncRead(This->pReader, pos, amt.cbFormat, amt.pbFormat); - memcpy(&amt.subtype, &MEDIATYPE_Audio, sizeof(GUID)); - amt.subtype.Data1 = ((WAVEFORMATEX*)amt.pbFormat)->wFormatTag; - /* CopyMediaType(&((OutputPin*)pWAVEParser->ppPins[1])->pin.mtCurrent, &amt); */ - ((Parser_OutputPin*)pWAVEParser->Parser.ppPins[1])->pmt = (AM_MEDIA_TYPE*) CoTaskMemAlloc(sizeof(AM_MEDIA_TYPE)); - - CopyMediaType(((Parser_OutputPin*)pWAVEParser->Parser.ppPins[1])->pmt, &amt); - - /* Update buffer alignment of media samples in output */ - ((Parser_OutputPin*)pWAVEParser->Parser.ppPins[1])->pin.allocProps.cbAlign = ((WAVEFORMATEX*)amt.pbFormat)->nBlockAlign; + pwfx = (LPWAVEFORMATEX)CoTaskMemAlloc(max(chunk.cb, sizeof(WAVEFORMATEX))); + if (!pwfx) + return E_FAIL; + hr = IAsyncReader_SyncRead(This->pReader, pos, chunk.cb, (BYTE *)pwfx); + if (hr != S_OK) { + CoTaskMemFree(pwfx); + return E_FAIL; + } pos += chunk.cb; + + if (pwfx->wFormatTag == WAVE_FORMAT_PCM) + pwfx->cbSize = 0; + + fSamplesPerSec = pwfx->nSamplesPerSec; + dwSampleSize = pwfx->nBlockAlign; + dwLength = 4096; + hr = IAsyncReader_SyncRead(This->pReader, pos, sizeof(chunk), (BYTE *)&chunk); + if (hr != S_OK) + { + CoTaskMemFree(pwfx); + return E_FAIL; + } if (chunk.fcc == mmioFOURCC('f','a','c','t')) { FIXME("'fact' chunk not supported yet\n"); pos += sizeof(chunk) + chunk.cb; hr = IAsyncReader_SyncRead(This->pReader, pos, sizeof(chunk), (BYTE *)&chunk); + if (hr != S_OK) + { + CoTaskMemFree(pwfx); + return E_FAIL; + } } if (chunk.fcc != mmioFOURCC('d','a','t','a')) { ERR("Expected 'data' chunk, but got %.04s\n", (LPSTR)&chunk.fcc); + CoTaskMemFree(pwfx); return E_FAIL; } - if (hr == S_OK) + pmt = CoTaskMemAlloc(sizeof(*pmt)); + if (!pmt) { - pWAVEParser->StartOfFile = MEDIATIME_FROM_BYTES(pos + sizeof(RIFFCHUNK)); - pWAVEParser->EndOfFile = MEDIATIME_FROM_BYTES(pos + chunk.cb + sizeof(RIFFCHUNK)); + CoTaskMemFree(pwfx); + return E_FAIL; } - if (hr != S_OK) - return E_FAIL; + memcpy(&pmt->majortype, &MEDIATYPE_Audio, sizeof(GUID)); + memcpy(&pmt->subtype, &MEDIATYPE_Audio, sizeof(GUID)); + pmt->subtype.Data1 = pwfx->wFormatTag; + pmt->bFixedSizeSamples = TRUE; + pmt->bTemporalCompression = FALSE; + pmt->lSampleSize = pwfx->nBlockAlign; + memcpy(&pmt->formattype, &FORMAT_WaveFormatEx, sizeof(GUID)); + pmt->pUnk = NULL; + pmt->cbFormat = sizeof(*pwfx) + pwfx->cbSize; + pmt->pbFormat = (BYTE *)pwfx; + + pWAVEParser->StartOfFile = MEDIATIME_FROM_BYTES(pos + sizeof(RIFFCHUNK)); + pWAVEParser->EndOfFile = MEDIATIME_FROM_BYTES(pos + chunk.cb + sizeof(RIFFCHUNK)); props.cbAlign = 1; props.cbPrefix = 0; props.cbBuffer = 4096; props.cBuffers = 2; - hr = Parser_AddPin(&(pWAVEParser->Parser), &piOutput, &props, &amt, fSamplesPerSec, dwSampleSize, dwLength); - + hr = Parser_AddPin(&(pWAVEParser->Parser), &piOutput, &props, pmt, fSamplesPerSec, dwSampleSize, dwLength); + + /* Update buffer alignment of media samples in output */ + ((Parser_OutputPin*)pWAVEParser->Parser.ppPins[1])->pin.allocProps.cbAlign = pwfx->nBlockAlign; + TRACE("WAVE File ok\n"); return hr;

2 1

Re: ole32: OLE clipboard functions should fail if OLE hasn't been initialised.
by Alexandre Julliard 06 Jan '07

06 Jan '07

Robert Shearman <rob(a)codeweavers.com> writes: > Add a field to the TLS data to determine whether OLE has been > initialised for the current thread and use it in the OLE clipboard > functions. This breaks the richedit tests: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so editor.c && touch editor.ok err:ole:OleSetClipboard OLE not initialised err:ole:OleSetClipboard OLE not initialised err:ole:OleSetClipboard OLE not initialised editor.c:860: Test failed: EM_SETUNDOLIMIT didn't allow the first undo with UNDOLIMIT set to 2 editor.c:863: Test failed: EM_SETUNDOLIMIT didn't allow a second undo with UNDOLIMIT set to 2 err:ole:OleSetClipboard OLE not initialised editor.c:1256: Test failed: EM_GETMODIFY returned zero, instead of non-zero when pasting identical text err:ole:OleSetClipboard OLE not initialised editor.c:1266: Test failed: EM_GETMODIFY returned zero, instead of non-zero when pasting different text err:ole:OleFlushClipboard OLE not initialised make: *** [editor.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

2 1

[2/8] WineD3D: Catch NOP vertex declaration changes
by Christoph Bumiller 06 Jan '07

06 Jan '07

Yet the application (NFS:MW) page faults right at startup at the address of pDecl + 4 so something's amiss ... maybe this will get fixed automatically in one of the next patches or is due to some other weird thing that affects my sources (eh?) ... as long as no one else complains, lets leave it at this. Just look again at the SetPixelShader function, this is how it looks in my current GIT (I didn't touch this one) : 3758 /* Handle recording of state blocks */ 3759 if (This->isRecordingState) { 3760 TRACE("Recording... not performing anything\n"); 3761 } 3762 3763 if (NULL != pShader) { 3764 IWineD3DPixelShader_AddRef(pShader); 3765 } 3766 if (NULL != oldShader) { 3767 IWineD3DPixelShader_Release(oldShader); 3768 } 3769 3770 if (This->isRecordingState) { 3771 TRACE("Recording... not performing anything\n"); 3772 return WINED3D_OK; 3773 } 3774 3775 if(pShader == oldShader) { 3776 TRACE("App is setting the old pixel shader over, nothing to do\n"); 3777 return WINED3D_OK; 3778 }

2 2

re: Instructions for creating the tests directory
by Dan Kegel 06 Jan '07

06 Jan '07

Bill wrote: > Is there any documentation on how to set up the tests directory for an > existing dll? Good question. Last time this came up, the answer was recorded here: http://kerneltraffic.osmirror.nl/wine/wn20021011_139.html#3 I don't know if that's correct still, but it's a start. Can you update the doc once you get it worked out? Thanks, Dan

4 3

Re: msacm32: Fix greater than vs. less than typo in comparison. (Coverity)
by Alex Villacís Lasso 06 Jan '07

06 Jan '07

Kai Blin escribió: > --- > dlls/msacm32/driver.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > ------------------------------------------------------------------------ > > diff --git a/dlls/msacm32/driver.c b/dlls/msacm32/driver.c > index d4ad644..06e6614 100644 > --- a/dlls/msacm32/driver.c > +++ b/dlls/msacm32/driver.c > @@ -430,7 +430,7 @@ LRESULT WINAPI acmDriverMessage(HACMDRIV > /* This verification is required because DRVCONFIGINFO is 12 bytes > long, yet native msacm reports a 16-byte structure to codecs. > */ > - if (iStructSize < sizeof(DRVCONFIGINFO)) iStructSize = sizeof(DRVCONFIGINFO); > + if (iStructSize > sizeof(DRVCONFIGINFO)) iStructSize = sizeof(DRVCONFIGINFO); > pConfigInfo = HeapAlloc(MSACM_hHeap, 0, iStructSize); > if (!pConfigInfo) { > ERR("OOM while supplying DRVCONFIGINFO for DRV_CONFIGURE, using NULL\n"); > > ------------------------------------------------------------------------ > > > This is not a typo, but rather an unnecessary verification, from when I didn't know the true size of a DRVCONFIGINFO. The struct size should be *exactly 16 bytes*, even though only the first 12 bytes are used. This patch might even introduce a bug, where the struct info assumed by the codec to be 16 bytes when only 12 are allocated, and some smart-ass codec tries to use the last 4 bytes of the struct for its own purposes, which with this patch are now past the end of the allocated array. A more correct patch would fix the comment to indicate that exactly 16 bytes are allocated for a 12-byte struct, and remove the conditional assignment altogether. Alex Villacís Lasso -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);'

2 1

Is Evolution the pile of .... it seems to be!
by Bill Medland 06 Jan '07

06 Jan '07

Does anyone doing OSS use evolution? I'm trying to submit a patch but can I get Evolution to not wrap it? No. I swapped from kmail to Evolution on the basis that it seemed to be being pushed as the 'real' linux mail program but I just keep being infuriated by the basic things it doesn't do and its refusal to let me have any control. Is it just me or is it the program? (and can anyone tell me how to stop it wrapping and if not then the patch will have to wait until monday :-( ) -- Bill Medland <billmedland(a)shaw.ca>

3 2

Re: appdb rating inflation
by Remco 05 Jan '07

05 Jan '07

What about a checklist of problems it doesn't have, and basing the rating on that. Something like: Installation: (_) Installs correctly. (_) No installation nessecary to run. (_) Preinstalled on Windows. (x) Doesn't install. [_] Works without an unofficially patched Wine. [_] Works without a compatibility mode different from XP. [_] Works without a registry setting. [_] Works without a crack. [_] Works without a setting in winecfg. (_) Works without glitches. (_) Has minor graphical glitches. (_) Minor Functional problems (_) Doesn't work as expected. Execution: [_] Works without an unofficially patched Wine. [_] Works without a compatibility mode different from XP. [_] Works without a registry setting. [_] Works without a crack. [_] Works without a setting in winecfg. (_) Works without glitches. (_) Has minor graphical glitches. (_) Minor Functional problems (x) Doesn't work as expected. If any isn't answered satisfactorily, it isn't Platina anymore. It is set up so that if you don't take the time to read it through, it will rate as Garbage. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Instructions for creating the tests directory
by Bill Medland 05 Jan '07

05 Jan '07

Is there any documentation on how to set up the tests directory for an existing dll? I couldn't see anything about the tests directory in the wiki and the stuff in the developer's guide presupposes that the test directory exists. I would rather follow instructions than have to reverse-engineer the process. -- Bill Medland <billmedland(a)shaw.ca>

3 2

mcicda: How can we get STATUS_XXX in GetLastError()?
by Francois Gouget 05 Jan '07

05 Jan '07

In dlls/mcicda/mcicda.c we have: if (!DeviceIoControl(wmcda->handle, IOCTL_CDROM_READ_Q_CHANNEL, &fmt, sizeof(fmt), &data, sizeof(data), &br, NULL)) { if (GetLastError() == STATUS_NO_MEDIA_IN_DEVICE) mode = MCI_MODE_OPEN; However DeviceIoControl() does the following: if (status) SetLastError( RtlNtStatusToDosError(status) ); return !status; } And RtlNtStatusToDosError() converts STATUS_NO_MEDIA_IN_DEVICE to ERROR_NOT_READY. So GetLastError() cannot return STATUS_NO_MEDIA_IN_DEVICE. Or did I miss something? Maybe the right thing would be to check the return value of DeviceIoControl() rather than GetLastError()? However, in MCICDA_GetError() we have a similar check: static int MCICDA_GetError(WINE_MCICDAUDIO* wmcda) { switch (GetLastError()) { case STATUS_NO_MEDIA_IN_DEVICE: return MCIERR_DEVICE_NOT_READY; case STATUS_IO_DEVICE_ERROR: return MCIERR_HARDWARE; default: FIXME("Unknown mode %x\n", GetLastError()); } Again, as far as I can see, GetLastError() cannot return these two STATUS_XXX values so this check seems wrong. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

3 2

rpc issues
by Matthew Edlefsen 05 Jan '07

05 Jan '07

Hi, I've been trying to get a program that uses rpc to work on wine and I've been having some problems (my understanding is that isn't surprising). The goal is to be able to run a rpc server that sits and waits for connections over tcp/ip (It's for doing distributed computing). My first problem was that I was using RpcServerUseProtseq which after looking at the code noticed will always fail with tcp/ip since it passes RpcServerUseProtseqEp NULL for the endpoint which eventually causes rpcrt4_protseq_ncacn_ip_tcp_open_endpoint to call getaddrinfo with NULL for both the ip and port which I guess isn't allowed. Anyways I altered my code to use a given endpoint instead and now it tells me: fixme:rpc:RpcMgmtWaitServerListen not waiting for server calls to finish Does this mean the function just doesn't work? Is there any way around it? I assume if it was easy to implement it would have already but just in case what exactly needs to be done to get it working? I was also confused by the differences between the online git tree and the LXR/what actually gets downloaded to my computer. To be honest I'm pretty new to wine and linux in general but it would be absolutely wonderful to get this working. Thanks in advance - Matt Edlefsen

3 6

Re: winegcc: Fix memory leaks (Coverity)
by Alexandre Julliard 05 Jan '07

05 Jan '07

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > winegcc: Fix memory leaks (Coverity). There is no reason to add a lot of complexity to fix leaks in short-lived apps like winegcc. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ole32: Remove redundant NULL check. (Coverity)
by Kai Blin 05 Jan '07

05 Jan '07

On Friday 05 January 2007 12:00, Kai Blin wrote: > --- > dlls/ole32/ole2.c | 10 +--------- > 1 files changed, 1 insertions(+), 9 deletions(-) Please ignore this one, winehq being down and git-format-patches played a trick on me. :) Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 1

IDropTarget code location
by Jeff L 05 Jan '07

05 Jan '07

Can anyone point me the location of the code that implements the IDropTarget class used by OLE2? Jeff

2 1

Winelib over Solaris/SPARC
by Keyur Pujara 05 Jan '07

05 Jan '07

Greetings! I am contemplating to port a complex windows application using winelib over Solaris/SPARC. In one of the emails in wine-devel list, I saw that there may be following issues in the process: * byte endianness * alignment issues * pointer size * must not use x86 assembly Could someone kindly advise on whether above issues *exists* in current version of wine? How do I identify and resolve them? Thanks in advance. Keyur __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

RFC: wininet: Inconsistent use of INTERNET_SetLastError()
by Francois Gouget 05 Jan '07

05 Jan '07

wininet has an INTERNET_SetLastError() which calls SetLastError() and does some extra tricks (see dlls/wininet/internet.c:3041). The problem is that while most functions use it, some call SetLastError() directly, seemingly without pattern or reason. Some functions even call one or the other depending on the error condition! So I propose the following patch to systematically call INTERNET_SetLastError(). However I have left the functions in cookie.c and urlcache.c unchanged as none of them calls INTERNET_SetLastError(). I have no idea if that's right or not. If I get no objection I will submit this patch to wine-patches in a few days. Otherwise I would be happy if someone could straighten this out the right way, and add explanatory comments in the places where SetLastError() should be called instead of INTERNET_SetLastError(). --- dlls/wininet/ftp.c | 2 +- dlls/wininet/http.c | 8 ++++---- dlls/wininet/internet.c | 40 ++++++++++++++++++++-------------------- 3 files changed, 25 insertions(+), 25 deletions(-) diff --git a/dlls/wininet/ftp.c b/dlls/wininet/ftp.c index 358c038..980687d 100644 --- a/dlls/wininet/ftp.c +++ b/dlls/wininet/ftp.c @@ -370,7 +370,7 @@ BOOL WINAPI FtpSetCurrentDirectoryW(HINTERNET hConnect, LPCWSTR lpszDirectory) if (!lpszDirectory) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); goto lend; } diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index ef19a27..650b824 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -1463,7 +1463,7 @@ static BOOL WINAPI HTTP_HttpQueryInfoW( LPWININETHTTPREQW lpwhr, DWORD dwInfoLev ((dwInfoLevel & HTTP_QUERY_FLAG_REQUEST_HEADERS) && (~lphttpHdr->wFlags & HDR_ISREQUEST))) { - SetLastError(ERROR_HTTP_HEADER_NOT_FOUND); + INTERNET_SetLastError(ERROR_HTTP_HEADER_NOT_FOUND); return bSuccess; } @@ -1753,7 +1753,7 @@ BOOL WINAPI HttpSendRequestExA(HINTERNET hRequest, header = HeapAlloc(GetProcessHeap(),0,headerlen*sizeof(WCHAR)); if (!(BuffersInW.lpcszHeader = header)) { - SetLastError(ERROR_OUTOFMEMORY); + INTERNET_SetLastError(ERROR_OUTOFMEMORY); return FALSE; } BuffersInW.dwHeadersLength = MultiByteToWideChar(CP_ACP, 0, @@ -1847,7 +1847,7 @@ BOOL WINAPI HttpSendRequestExW(HINTERNET hRequest, /* * This is from windows. */ - SetLastError(ERROR_IO_PENDING); + INTERNET_SetLastError(ERROR_IO_PENDING); ret = FALSE; } else @@ -1929,7 +1929,7 @@ BOOL WINAPI HttpSendRequestW(HINTERNET hHttpRequest, LPCWSTR lpszHeaders, /* * This is from windows. */ - SetLastError(ERROR_IO_PENDING); + INTERNET_SetLastError(ERROR_IO_PENDING); r = FALSE; } else diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c index de84c59..a4c3224 100644 --- a/dlls/wininet/internet.c +++ b/dlls/wininet/internet.c @@ -769,7 +769,7 @@ HINTERNET WINAPI InternetConnectW(HINTERNET hInternet, if (!lpszServerName) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return NULL; } @@ -778,7 +778,7 @@ HINTERNET WINAPI InternetConnectW(HINTERNET hInternet, hIC = (LPWININETAPPINFOW) WININET_GetObject( hInternet ); if ( (hIC == NULL) || (hIC->hdr.htype != WH_HINIT) ) { - SetLastError(ERROR_INVALID_HANDLE); + INTERNET_SetLastError(ERROR_INVALID_HANDLE); goto lend; } @@ -1219,7 +1219,7 @@ BOOL WINAPI InternetCrackUrlW(LPCWSTR lpszUrl_orig, DWORD dwUrlLength_orig, DWOR if (!lpszUrl_orig || !*lpszUrl_orig) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } @@ -1777,7 +1777,7 @@ BOOL WINAPI InternetReadFile(HINTERNET hFile, LPVOID lpBuffer, lpwh = WININET_GetObject( hFile ); if (!lpwh) { - SetLastError(ERROR_INVALID_HANDLE); + INTERNET_SetLastError(ERROR_INVALID_HANDLE); return FALSE; } @@ -1839,14 +1839,14 @@ BOOL WINAPI InternetReadFileExA(HINTERNET hFile, LPINTERNET_BUFFERSA lpBuffersOu if (lpBuffersOut->dwStructSize != sizeof(*lpBuffersOut)) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } lpwh = (LPWININETHANDLEHEADER) WININET_GetObject( hFile ); if (!lpwh) { - SetLastError(ERROR_INVALID_HANDLE); + INTERNET_SetLastError(ERROR_INVALID_HANDLE); return FALSE; } @@ -1868,7 +1868,7 @@ BOOL WINAPI InternetReadFileExA(HINTERNET hFile, LPINTERNET_BUFFERSA lpBuffersOu retval = INTERNET_AsyncCall(&workRequest); if (!retval) return FALSE; - SetLastError(ERROR_IO_PENDING); + INTERNET_SetLastError(ERROR_IO_PENDING); return FALSE; } @@ -1923,7 +1923,7 @@ static BOOL INET_QueryOptionHelper(BOOL bIsUnicode, HINTERNET hInternet, DWORD d lpwhh = (LPWININETHANDLEHEADER) WININET_GetObject( hInternet ); if (!lpwhh) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } @@ -1936,7 +1936,7 @@ static BOOL INET_QueryOptionHelper(BOOL bIsUnicode, HINTERNET hInternet, DWORD d if (!lpwhh) { WARN("Invalid hInternet handle\n"); - SetLastError(ERROR_INVALID_HANDLE); + INTERNET_SetLastError(ERROR_INVALID_HANDLE); return FALSE; } @@ -1976,7 +1976,7 @@ static BOOL INET_QueryOptionHelper(BOOL bIsUnicode, HINTERNET hInternet, DWORD d if (!lpwhh) { WARN("Invalid hInternet handle\n"); - SetLastError(ERROR_INVALID_HANDLE); + INTERNET_SetLastError(ERROR_INVALID_HANDLE); return FALSE; } if (lpwhh->htype == WH_HHTTPREQ) @@ -2519,7 +2519,7 @@ BOOL WINAPI InternetSetOptionExW(HINTERNET hInternet, DWORD dwOption, FIXME("Flags %08x ignored\n", dwFlags); if( dwFlags & ~ISO_VALID_FLAGS ) { - SetLastError( ERROR_INVALID_PARAMETER ); + INTERNET_SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } return InternetSetOptionW( hInternet, dwOption, lpBuffer, dwBufferLength ); @@ -2760,7 +2760,7 @@ End: HeapFree( GetProcessHeap(), 0, command ); if (rc == FALSE) - SetLastError(ERROR_NOT_CONNECTED); + INTERNET_SetLastError(ERROR_NOT_CONNECTED); return rc; } @@ -2919,7 +2919,7 @@ HINTERNET WINAPI InternetOpenUrlW(HINTERNET hInternet, LPCWSTR lpszUrl, if (!lpszUrl) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); goto lend; } @@ -2949,7 +2949,7 @@ HINTERNET WINAPI InternetOpenUrlW(HINTERNET hInternet, LPCWSTR lpszUrl, /* * This is from windows. */ - SetLastError(ERROR_IO_PENDING); + INTERNET_SetLastError(ERROR_IO_PENDING); } else { ret = INTERNET_InternetOpenUrlW(hIC, lpszUrl, lpszHeaders, dwHeadersLength, dwFlags, dwContext); } @@ -3227,7 +3227,7 @@ BOOL WINAPI InternetQueryDataAvailable( HINTERNET hFile, lpwhr = (LPWININETHTTPREQW) WININET_GetObject( hFile ); if (NULL == lpwhr) { - SetLastError(ERROR_NO_MORE_FILES); + INTERNET_SetLastError(ERROR_NO_MORE_FILES); return FALSE; } @@ -3240,7 +3240,7 @@ BOOL WINAPI InternetQueryDataAvailable( HINTERNET hFile, min(sizeof(buffer), lpwhr->dwContentLength - lpwhr->dwContentRead), MSG_PEEK, (int *)lpdwNumberOfBytesAvailble)) { - SetLastError(ERROR_NO_MORE_FILES); + INTERNET_SetLastError(ERROR_NO_MORE_FILES); retval = FALSE; } else @@ -3459,7 +3459,7 @@ static BOOL calc_url_length(LPURL_COMPONENTSW lpUrlComponents, { if (lpUrlComponents->lpszPassword) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } } @@ -3577,7 +3577,7 @@ BOOL WINAPI InternetCreateUrlA(LPURL_COMPONENTSA lpUrlComponents, DWORD dwFlags, if (lpUrlComponents->dwStructSize != sizeof(URL_COMPONENTSW) || !lpdwUrlLength) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } @@ -3647,7 +3647,7 @@ BOOL WINAPI InternetCreateUrlW(LPURL_COMPONENTSW lpUrlComponents, DWORD dwFlags, if (lpUrlComponents->dwStructSize != sizeof(URL_COMPONENTSW) || !lpdwUrlLength) { - SetLastError(ERROR_INVALID_PARAMETER); + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } @@ -3657,7 +3657,7 @@ BOOL WINAPI InternetCreateUrlW(LPURL_COMPONENTSW lpUrlComponents, DWORD dwFlags, if (!lpszUrl || *lpdwUrlLength < dwLen) { *lpdwUrlLength = (dwLen + 1) * sizeof(WCHAR); - SetLastError(ERROR_INSUFFICIENT_BUFFER); + INTERNET_SetLastError(ERROR_INSUFFICIENT_BUFFER); return FALSE; } -- 1.4.4.2

1 0

Winelib over Solaris/SPARC
by Keyur Pujara 05 Jan '07

05 Jan '07

Greetings! I am contemplating to port a complex windows application using winelib over Solaris/SPARC. In one of the emails in wine-devel list, I saw that there may be following issues in the process: * byte endianness * alignment issues * pointer size * must not use x86 assembly Could someone kindly advise on whether above issues *exists* in current version of wine? How do I identify and resolve them? Thanks in advance. Keyur __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

(Cross)Compile failure for ole32/tests/marshal.c
by Paul Vriens 05 Jan '07

05 Jan '07

Hi, when running the 'make crosstest' in ole32/tests, I get: [paul@penguin tests]$ make crosstest i386-mingw32-gcc clipboard.cross.o compobj.cross.o hglobalstream.cross.o marshal.cross.o moniker.cross.o ole2.cross.o propvariant.cross.o stg_prop.cross.o storage32.cross.o usrmarshal.cross.o testlist.cross.o -o ole32_crosstest.exe -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -luuid marshal.cross.o:marshal.c:(.text+0x7a97): undefined reference to `_IID_IChannelHook' collect2: ld returned 1 exit status make: *** [ole32_crosstest.exe] Error 1 When looking at our objidl.h, I see: DEFINE_GUID(IID_IChannelHook, 0x1008c4a0, 0x7613, 0x11cf, 0x9a,0xf1, 0x00,0x20,0xaf,0x6e,0x72,0xf4); whereas the objidl.h in the SDK shows: EXTERN_C const IID IID_IChannelHook; and the 'real' definition seems to be placed in comdef.h If I add the definition to marshal.c the cross-compile succeeds, but that's obviously not the solution. Can somebody more knowledgeable have a look? Cheers, Paul.

3 2

Re: wininet: Remove the custom thread pool implementation and use QueueUserWorkItem instead.
by Jacek Caban 04 Jan '07

04 Jan '07

Hi Rob, Robert Shearman wrote: > --- > dlls/wininet/internet.c | 184 > +++++------------------------------------------ > dlls/wininet/internet.h | 3 - > 2 files changed, 19 insertions(+), 168 deletions(-) > > This also fixes a bug in the old code where starting a new > asynchronous operation with more than 10 asynchronous operations in > progress would fail. ... > - LPWORKREQUEST lpRequest = NULL; > + LPWORKREQUEST lpRequest = lpvParam; > + WORKREQUEST workRequest; > > TRACE("\n"); > > - EnterCriticalSection(&csQueue); > + memcpy(&workRequest, lpRequest, sizeof(WORKREQUEST)); > + HeapFree(GetProcessHeap(), 0, lpRequest); > > - if (lpHeadWorkQueue) > - { > - lpRequest = lpHeadWorkQueue; > - lpHeadWorkQueue = lpHeadWorkQueue->prev; > - if (lpRequest == lpWorkQueueTail) > - lpWorkQueueTail = lpHeadWorkQueue; > - } > - > - LeaveCriticalSection(&csQueue); > - > - if (lpRequest) > - { > - memcpy(lpWorkRequest, lpRequest, sizeof(WORKREQUEST)); > - HeapFree(GetProcessHeap(), 0, lpRequest); > - bSuccess = TRUE; > - InterlockedDecrement(&dwNumJobs); > - } > + workRequest.asyncproc(&workRequest); > > - return bSuccess; > + WININET_Release( workRequest.hdr ); > + return TRUE; > } > Why do you copy lpRequest to workRequest? You could use lpRequest in asyncproc and WININET_Release and call HeapFree before return. Then workRequest may be removed. Thanks, Jacek

2 2

Application Database todo updated and open call for new developers
by Chris Morgan 04 Jan '07

04 Jan '07

I've updated the Application Database todo and sorted the list according to each item's difficulty. You can find the todo list at http://wiki.winehq.org/AppdbInfo This list is by no means complete so if you have an idea for a new entry feel free to email it to the AppDB mailing list at appdb(a)winehq.org or just update the wiki page. I also wanted ask that people interested in hacking on the AppDB take a look at the todo list if they might be interested in getting involved with AppDB development. The php code that runs the AppDB is available from the winehq cvs server and I'm available to mentor anyone interested in getting started hacking on the code. We've had some new developers and I wanted to thank Alexander Sørnes for his recent contributions to improve several areas of the AppDB that users see most. And of course thanks to all of the other contributors that have helped to develop the AppDB and the AppDB administrators that process all of the new submissions that come in each day. Chris

1 0

[2/8] WineD3D: Catch NOP vertex declaration changes
by Christoph Bumiller 04 Jan '07

04 Jan '07

Not performing the following: if (NULL != pDecl) { IWineD3DVertexDeclaration_AddRef(pDecl); } in IWineD3DDeviceImpl_SetVertexDeclaration(...) when state is being recorded (note the return that was added), seems to cause a page fault, at least in NFS: Most Wanted. Is it possible that not adding a reference here causes the declaration object to be deallocated to early, when it is still used by the application ?

3 2

Re: [PATCH] StgOpenStorage patch
by Mike McCormack 04 Jan '07

04 Jan '07

> This is the first time I've submitted a patch, so let me know if this > method of submission is incorrect. See description in the attachment. It's best to put the description in the body of the mail, and write a descriptive subject like "ole32: fix StgOpenStorage conformance test failure" or something like that. > This patch stops StgOpenStorage from creating a file when it does not > already exist. According to Microsoft's description, StgOpenStorage opens > an _existing_ root storage object... To create a new file, use the > StorageCreateStorageEx function. > > This fixes a bug in Orcad Capture (http://bugs.winehq.org/show_bug.cgi?id=7025) > > The conformance test file has also been modified to pass this test (before it > it was passing in Wine and failing in Windows). Your patch makes the conformance tests pass on Windows 2000 for me. The failing test was added some time ago: http://www.winehq.org/pipermail/wine-patches/2006-September/030808.html Maybe Andrey could comment on which version of Windows he was using? Mike

2 1

Re:dinput: Declare a function static
by Vitaliy Margolen 04 Jan '07

04 Jan '07

Andrew Talbot wrote: > Note: This is in addition to those submitted yesterday. > > -- Andy. > --- > Changelog: > dinput: Declare a function static. > > diff -urN a/dlls/dinput/device.c b/dlls/dinput/device.c > --- a/dlls/dinput/device.c 2007-01-04 11:22:23.000000000 +0000 > +++ b/dlls/dinput/device.c 2007-01-04 13:38:38.000000000 +0000 > @@ -294,7 +294,7 @@ > format->user_df = NULL; > } > > -inline LPDIOBJECTDATAFORMAT dataformat_to_odf(LPCDIDATAFORMAT df, int idx) > +static inline LPDIOBJECTDATAFORMAT dataformat_to_odf(LPCDIDATAFORMAT df, int idx) > { > if (idx < 0 || idx >= df->dwNumObjs) return NULL; > return (LPDIOBJECTDATAFORMAT)((LPBYTE)df->rgodf + idx * df->dwObjSize); > Please don't commit this one. It's a "work in progress" and I will need this function in other places. Vitaliy

1 0

iTunes installer success
by Dan Kegel 04 Jan '07

04 Jan '07

iTunes 6.5.2 seems to install ok now, so I marked http://bugs.winehq.org/show_bug.cgi?id=3335 as fixed. Yay Rob... iTunes 7 even seems to install, though its installer tries to run several vbscript custom actions, which of course don't work; wine cheerfully blows past those problems, no idea if they do anything important. ( Apple even has a help page for itunes vbscript install problems on windows, http://docs.info.apple.com/article.html?artnum=304405 ) I wonder if we can convince them to stop using vbscript for their next release... probably not, but it'd be nice if someone who knows them would ask. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Crash while starting Corel Draw 11
by Roland Kaeser 04 Jan '07

04 Jan '07

Hello I just trying to install (and run) Corel Draw 11 on wine 0.9.28 (self compiled) on SuSE 10.2. It requires some native dlls just to start. Can somebody give me a hint about it. It crashed with every windows version set (98-XP). Native Dlls I used: ole32*.dll msv*.dll(msvcrt.dll/msvcrt20,msvcrt40,msvcirt) Roland err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FEF9 (Pointer_EnableKeys) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=90,scanCode=45,keycode=4D,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E1,scanCode=60,keycode=71,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E1,scanCode=60,keycode=71,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E9,scanCode=64,keycode=7C,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E9,scanCode=64,keycode=7C,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=1) err:x11drv:X11DRV_CreateWindow invalid window height -25 err:x11drv:X11DRV_CreateWindow invalid window height -25 fixme:ole:CoRegisterMessageFilter message filter has been registered, but will not be used fixme:mmio:MMIO_InstallIOProc Global procedures not implemented fixme:wintab32:X11DRV_WTInfoA WTI_INTERFACE unhandled index 7 wine: Unhandled page fault on write access to 0x007d204e at address 0x253447a7 (thread 0058), starting debug ger... Unhandled exception: page fault on write access to 0x007d204e in 32-bit code (0x253447a7). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:253447a7 ESP:0033ef28 EBP:0033f4ac EFLAGS:00210206( - 00 - RIP1) EAX:00000c00 EBX:007d204e ECX:00000000 EDX:00000001 ESI:011d3848 EDI:00c348a0 Stack dump: 0x0033ef28: 00000001 011d3810 0000000d 7efb0aee 0x0033ef38: 00000064 7eb2dff4 0033ef60 7eb2dff4 0x0033ef48: fffffff4 b7e05ff4 0033ef98 00000001 0x0033ef58: 0033ef74 b7d04dbd 00000000 00000000 0x0033ef68: 0033efb4 7ee82ff4 0033f064 0033f044 0x0033ef78: 7ee5b338 0033ef98 00000001 4d430002 Backtrace: =>1 0x253447a7 in crlutl110 (+0x647a7) (0x0033f4ac) 2 0x20be7fe0 in coreldrw110 (+0x227fe0) (0x0033ff08) 3 0x7ee49198 start_process+0xe3() in kernel32 (0x0033ffe8) 4 0xb7e54e93 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x253447a7: movl %eax,0x0(%ebx) Modules: Module Address Debug info Name (221 modules) PE 350000-374000 Deferred fn3api PE 400000-411000 Deferred coreldrw PE 950000-9bd000 Deferred iuiintl PE ad0000-b18000 Deferred kodakcms PE 1180000-1191000 Deferred threeptcurvetool110 PE 4470000-4501000 Deferred dao350 PE 10000000-1015f000 Deferred cdrrip110 PE 209c0000-2138d000 Export coreldrw110 PE 214e0000-21d3a000 Deferred drawintl PE 22ac0000-22ee5000 Deferred cdrcore110 PE 23830000-23acb000 Deferred cdrprnintl110 PE 23af0000-23ced000 Deferred cdrprn110 PE 23d50000-23f23000 Deferred cdrtra110 PE 244d0000-24619000 Deferred drwbasetoolcore110 PE 24680000-247c3000 Deferred cdrtxt110 PE 24ab0000-24bb4000 Deferred crlfrmwk110 PE 24d30000-24e04000 Deferred crlfom110 PE 24f60000-25025000 Deferred crlcui110 PE 25120000-251c7000 Deferred drwextrudetool110 PE 25200000-252a5000 Deferred crlctl110 PE 252e0000-25388000 Export crlutl110 PE 25510000-25595000 Deferred crlfomui110 PE 25720000-257a2000 Deferred crlcuiintl110 PE 257d0000-25851000 Deferred cdrtxtui110 PE 25870000-258f0000 Deferred crliui110 PE 25920000-2599e000 Deferred crlfx110 PE 25cb0000-25d1c000 Deferred crlcmnres110 PE 25dd0000-25e32000 Deferred drwfilltool110 PE 25ec0000-25f20000 Deferred crlclr110 PE 25fb0000-26005000 Deferred drwblendtool110 PE 26090000-260e2000 Deferred cdrflt110 PE 26380000-263c9000 Deferred cdrfnt110 PE 26500000-26544000 Deferred drwcontourtool110 PE 265c0000-26602000 Deferred drwartisticmediatool110 PE 266d0000-2670d000 Deferred drwenvpersptool110 PE 26770000-267a9000 Deferred drwtransparencytool110 PE 267c0000-267f8000 Deferred crllshape110 PE 26900000-26933000 Deferred drwdropshadowtool110 PE 26950000-26984000 Deferred drwzoompantool110 PE 26a40000-26a72000 Deferred drwdimensiontool110 PE 26b00000-26b30000 Deferred crlfxcontrols110 PE 26bc0000-26bec000 Deferred cdrsty110 PE 26c00000-26c2c000 Deferred drwdistortiontool110 PE 26c40000-26c6a000 Deferred drwerasertool110 PE 26cc0000-26ce8000 Deferred drwbezierfreehandtoolcore110.dl PE 26d00000-26d29000 Deferred cdrpdfui110 PE 26d80000-26da7000 Deferred drwpicktool110 PE 26e00000-26e28000 Deferred crlfrmwkintl110 PE 26e40000-26e68000 Deferred crlfxintl PE 26e80000-26ea6000 Deferred drwliveshapetool110 PE 26fa0000-26fc4000 Deferred drwpolygontool110 PE 27000000-27022000 Deferred cdrcpr110 PE 27030000-27052000 Deferred cdrpdfintl110 PE 27060000-27081000 Deferred drwrectangletool110 PE 270c0000-270e1000 Deferred crlweb110 PE 27150000-27171000 Deferred smudgetool110 PE 271a0000-271c0000 Deferred symboltool110 PE 271d0000-271f0000 Deferred cdrcrv110 PE 27230000-2724f000 Deferred drwroughentool110 PE 27290000-272af000 Deferred drwmeshfilltool110 PE 272c0000-272de000 Deferred drwellipsetool110 PE 272f0000-2730f000 Deferred crlutlintl110 PE 27320000-2733e000 Deferred drwfilltoolcore110 PE 27380000-2739d000 Deferred drwspiraltool110 PE 273b0000-273cc000 Deferred drweyedroppertool110 PE 27410000-2742c000 Deferred drwoutlinetool110 PE 27440000-2745b000 Deferred drwconnectortool110 PE 27470000-2748a000 Deferred drwnodeedittool110 PE 274a0000-274ba000 Deferred drwartisticmediatoolcore110 PE 274d0000-274ea000 Deferred threeptellipsetool110 PE 27500000-2751a000 Deferred crlinet PE 27530000-27547000 Deferred drwblendtoolcore110 PE 27550000-27567000 Deferred drwnodeedittoolcore110 PE 27590000-275a7000 Deferred drwfhtransformtool110 PE 27610000-27624000 Deferred drwgraphpapertool110 PE 27630000-27643000 Deferred drwknifetool110 PE 27670000-27683000 Deferred drwbrushtoolcore110 PE 27690000-276a4000 Deferred cdrtxtintl110 PE 276b0000-276c2000 Deferred threeptrecttool110 PE 276f0000-27701000 Deferred drwfreehandtool110 PE 27730000-27742000 Deferred pentool110 PE 27770000-27782000 Deferred cdrpdfcmp110 PE 277d0000-277e1000 Deferred polylinetool110 PE 27860000-2786e000 Deferred crli18n110 PE 278c0000-278cd000 Deferred cdrautosense110 PE 278e0000-278ec000 Deferred drwbeziertool110 PE 27900000-2790d000 Deferred drwpicktoolcore110 PE 27940000-2794c000 Deferred drwconnectortoolcore110 PE 27950000-2795c000 Deferred crlppd110 PE 27970000-2797b000 Deferred drwtexttool110 PE 27980000-2798b000 Deferred drwtransparencytoolcore110 PE 279b0000-279ba000 Deferred drwpolygontoolcore110 PE 279c0000-279ca000 Deferred drwoutlinetoolcore110 PE 279d0000-279da000 Deferred cdrfntintl110 PE 279f0000-279fb000 Deferred crlctlintl110 PE 27a00000-27a0a000 Deferred drwdimensiontoolcore110 PE 27a30000-27a39000 Deferred drwmeshfilltoolcore110 PE 27a60000-27a69000 Deferred crltwain110 PE 27a70000-27a78000 Deferred drwspiraltoolcore110 PE 27aa0000-27aa8000 Deferred drweyedroppertoolcore110 PE 27ab0000-27ab8000 Deferred drwzoompantoolcore110 PE 27ac0000-27ac8000 Deferred crlclrintl110 PE 27ad0000-27ad7000 Deferred drwknifetoolcore110 PE 27ae0000-27ae7000 Deferred drwgraphpapertoolcore110 PE 27af0000-27af7000 Deferred drwrectangletoolcore110 PE 27b00000-27b07000 Deferred polylinetoolcore110 PE 27b10000-27b17000 Deferred drwliveshapetoolcore110 PE 27b20000-27b27000 Deferred drwerasertoolcore110 PE 27b30000-27b37000 Deferred drwellipsetoolcore110 PE 27b40000-27b47000 Deferred threepttoolcore110 PE 27b80000-27b86000 Deferred componentintl PE 27bc0000-27bc4000 Deferred crlfxcontrolsintl PE 61dc0000-61dce000 Deferred mfc42loc PE 73d30000-73e2e000 Deferred mfc42 PE 780a0000-780b6000 Deferred msvcirt PE 780c0000-78121000 Deferred msvcp60 ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7c150000-7c159000 Deferred libxi.so.6 ELF 7c159000-7c179000 Deferred wintab32<elf> \-PE 7c160000-7c179000 \ wintab32 ELF 7d5c3000-7d5ec000 Deferred msvcrt40<elf> \-PE 7d5d0000-7d5ec000 \ msvcrt40 ELF 7db41000-7db4a000 Deferred libkrb5support.so.0 ELF 7db4a000-7db4e000 Deferred libcom_err.so.2 ELF 7db4e000-7db74000 Deferred libk5crypto.so.3 ELF 7db74000-7dbf0000 Deferred libkrb5.so.3 ELF 7dbf0000-7dc08000 Deferred libsasl2.so.2 ELF 7dc08000-7dc31000 Deferred libgssapi_krb5.so.2 ELF 7dc31000-7dc3f000 Deferred liblber-2.3.so.0 ELF 7dc3f000-7dc77000 Deferred libldap-2.3.so.0 ELF 7dc77000-7dc96000 Deferred libnss_ldap.so.2 ELF 7dc96000-7dcac000 Deferred libnsl.so.1 ELF 7dcac000-7dcdf000 Deferred libcrypt.so.1 ELF 7dcdf000-7de12000 Deferred libcrypto.so.0.9.8 ELF 7de12000-7de4f000 Deferred libssl.so.0.9.8 ELF 7de4f000-7de7f000 Deferred libcups.so.2 ELF 7de91000-7dea9000 Deferred usp10<elf> \-PE 7dea0000-7dea9000 \ usp10 ELF 7deaa000-7dec1000 Deferred midimap<elf> \-PE 7deb0000-7dec1000 \ midimap ELF 7dee8000-7df01000 Deferred msacm32<elf> \-PE 7def0000-7df01000 \ msacm32 ELF 7df01000-7df41000 Deferred wineoss<elf> \-PE 7df10000-7df41000 \ wineoss ELF 7df61000-7df95000 Deferred uxtheme<elf> \-PE 7df70000-7df95000 \ uxtheme ELF 7e01c000-7e025000 Deferred libxrender.so.1 ELF 7e025000-7e142000 Deferred libx11.so.6 ELF 7e142000-7e151000 Deferred libxext.so.6 ELF 7e151000-7e16a000 Deferred libice.so.6 ELF 7e16a000-7e206000 Deferred winex11<elf> \-PE 7e180000-7e206000 \ winex11 ELF 7e310000-7e331000 Deferred libexpat.so.1 ELF 7e331000-7e35c000 Deferred libfontconfig.so.1 ELF 7e35c000-7e36f000 Deferred libz.so.1 ELF 7e36f000-7e3db000 Deferred libfreetype.so.6 ELF 7e3dc000-7e3e4000 Deferred libnss_compat.so.2 ELF 7e3e4000-7e3ee000 Deferred libnss_files.so.2 ELF 7e3f6000-7e3fc000 Deferred libxfixes.so.3 ELF 7e3fc000-7e406000 Deferred libxcursor.so.1 ELF 7e406000-7e41b000 Deferred olepro32<elf> \-PE 7e410000-7e41b000 \ olepro32 ELF 7e41b000-7e430000 Deferred lz32<elf> \-PE 7e420000-7e430000 \ lz32 ELF 7e430000-7e44a000 Deferred version<elf> \-PE 7e440000-7e44a000 \ version ELF 7e44a000-7e46c000 Deferred oledlg<elf> \-PE 7e450000-7e46c000 \ oledlg ELF 7e46c000-7e49b000 Deferred ws2_32<elf> \-PE 7e470000-7e49b000 \ ws2_32 ELF 7e49b000-7e4b6000 Deferred wsock32<elf> \-PE 7e4a0000-7e4b6000 \ wsock32 ELF 7e4b6000-7e4e9000 Deferred winspool<elf> \-PE 7e4c0000-7e4e9000 \ winspool ELF 7e4e9000-7e58a000 Deferred comdlg32<elf> \-PE 7e4f0000-7e58a000 \ comdlg32 ELF 7e58a000-7e629000 Deferred oleaut32<elf> \-PE 7e5a0000-7e629000 \ oleaut32 ELF 7e629000-7e649000 Deferred mpr<elf> \-PE 7e630000-7e649000 \ mpr ELF 7e649000-7e6d7000 Deferred winmm<elf> \-PE 7e650000-7e6d7000 \ winmm ELF 7e6d7000-7e7a9000 Deferred comctl32<elf> \-PE 7e6e0000-7e7a9000 \ comctl32 ELF 7e7a9000-7e802000 Deferred shlwapi<elf> \-PE 7e7c0000-7e802000 \ shlwapi ELF 7e802000-7e8f3000 Deferred shell32<elf> \-PE 7e810000-7e8f3000 \ shell32 ELF 7e8f3000-7e906000 Deferred libresolv.so.2 ELF 7e907000-7e90c000 Deferred libxrandr.so.2 ELF 7e90c000-7e910000 Deferred libxinerama.so.1 ELF 7e910000-7e914000 Deferred libxau.so.6 ELF 7e914000-7e931000 Deferred imm32<elf> \-PE 7e920000-7e931000 \ imm32 ELF 7e931000-7e950000 Deferred iphlpapi<elf> \-PE 7e940000-7e950000 \ iphlpapi ELF 7e950000-7e9a4000 Deferred rpcrt4<elf> \-PE 7e960000-7e9a4000 \ rpcrt4 ELF 7e9a4000-7ea40000 Deferred ole32<elf> \-PE 7e9b0000-7ea40000 \ ole32 ELF 7ea40000-7eb83000 Deferred user32<elf> \-PE 7ea60000-7eb83000 \ user32 ELF 7eb83000-7ebca000 Deferred advapi32<elf> \-PE 7eb90000-7ebca000 \ advapi32 ELF 7ebca000-7ec5e000 Deferred gdi32<elf> \-PE 7ebe0000-7ec5e000 \ gdi32 ELF 7ec5e000-7ecc5000 Deferred msvcrt<elf> \-PE 7ec70000-7ecc5000 \ msvcrt ELF 7edd7000-7eef4000 Export kernel32<elf> \-PE 7edf0000-7eef4000 \ kernel32 ELF 7ef29000-7ef4f000 Deferred libm.so.6 ELF 7ef51000-7ef5b000 Deferred libsm.so.6 ELF 7ef7a000-7f000000 Deferred ntdll<elf> \-PE 7ef90000-7f000000 \ ntdll ELF b7cd0000-b7cd6000 Deferred libxdmcp.so.6 ELF b7cd8000-b7cdc000 Deferred libdl.so.2 ELF b7cdc000-b7e0a000 Deferred libc.so.6 ELF b7e0a000-b7e22000 Deferred libpthread.so.0 ELF b7e25000-b7e2b000 Deferred libxxf86vm.so.1 ELF b7e4d000-b7f5f000 Export libwine.so.1 ELF b7f60000-b7f7d000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000057 (D) C:\Programme\Corel\Corel Graphics 11\Programs\CorelDrw.exe 0000004a 0 00000049 0 00000048 0 0000001c 0 0000001d 0 00000014 0 00000012 0 00000015 0 00000016 0 00000013 0 0000000f 0 0000000d 0 00000010 0 00000011 0 0000000e 0 0000000a 0 00000008 0 0000000b 0 0000000c 0 00000009 0 00000047 0 00000046 0 00000045 0 00000044 0 00000043 0 00000042 0 00000041 0 00000040 0 0000003f 0 0000003e 0 0000003d 0 0000003c 0 0000003b 0 0000003a 0 00000039 0 00000038 0 00000037 0 00000036 0 00000035 0 00000034 0 00000033 0 00000032 0 00000031 0 00000030 0 0000002f 0 0000002e 0 0000002d 0 0000002c 0 0000002b 0 0000002a 0 00000029 0 00000028 0 00000027 0 00000026 0 00000025 0 00000024 0 00000023 0 00000022 0 00000021 0 00000020 0 0000001f 0 00000067 0 00000066 0 00000065 0 00000064 0 00000063 0 00000062 0 00000061 0 00000060 0 0000005d 0 0000005e 0 0000001e 0 0000005b 0 0000005c 0 0000005a 0 00000059 0 00000058 0 <== 00000019 0000001b 0 0000001a 0 00000017 00000018 0 __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com

1 0

Re: [5/8] WineD3D: Readd the strided data trace
by Ivan Gyurdiev 04 Jan '07

04 Jan '07

Stefan Dösinger wrote: > I removed that call accidentally in one of my former patches, but I > think it is still a good idea to trace the final strided sources used > by drawprim > You removed it from a d3d8 fixed function FVF-only codepath, and are adding it back into a shared codepath. That function doesn't work properly with vertex declarations, it will only work with FVFs, which have different strided layout. FVFs use fixed semantic index [u.s.position], vdecl asks the shader for an index [u.s.input[idx]]. Furthermore, the trace isn't needed for declarations, because they have their own (better) traces.

2 1

Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
by Ivan Gyurdiev 04 Jan '07

04 Jan '07

> Regarding the concern of storing the decoded strided data after > finishing drawing: This is intentional, the decoded vertex declaration > will remain valid after the draw is finished and the arrays loaded. > Future draws can use it, if the state is not dirtified again. > This sounds like a good idea... > Wrt the upward references: When we have multithreading with multiple > contexts we will need a per-context tracking of most of the stuff we > have in the device now(last_was_rhw, ...). This structure does not > exist yet, and I do not see a point in passing the device impl to > every function when we can get it from the stateblock too. I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock. =========== Note: you just made drawPrimitiveTraceDataLocations into dead code. (previously called in d3d8 fixed function code path). I don't care much for this function, but please remove it if getting rid of its callers.

3 3

Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
by Francois Gouget 04 Jan '07

04 Jan '07

On Wed, 3 Jan 2007, Alexandre Julliard wrote: [...] > Commit: dff43b732b10e603f3aee38db2f684dc7404aa4e [...] > user32: Speed improvement for 16bit comm support. [...] > stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET; > COMM_MSRUpdate( ptr->handle, stol ); > > - if (lpStat) { > - lpStat->status = 0; > - > + if (lpStat) { > + lpStat->status = 0; > SleepEx(1,TRUE); > > lpStat->cbOutQue = comm_outbuf(ptr); As far as I can see this patch only contains whitespace changes (and I'm not sure they are correct). How can it improve performance? Probably something got lost in the way... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 2

So, what apps require BITS?
by Dan Kegel 04 Jan '07

04 Jan '07

Which apps require BITS? I'm collecting them as depending on bug http://bugs.winehq.org/show_bug.cgi?id=6194 So for I know of two, Visual C++ 2005, and Google Pack. There's also a third-party app which is just a file transfer front end on top of BITS; it's called WinBITS, and is at http://www.darvin.de/english/ I wonder if it's time to start implementing the parts of BITS that real apps use... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

automatic gecko download failing
by Bill Medland 04 Jan '07

04 Jan '07

Is it obvious to anyone where the error is in this? (trace ole, urlmon and mshtml) trace:ole:DllMain 0x60550000 0x8 (nil) trace:ole:DllMain (0x60750000,8,(nil)) trace:ole:DllMain 0x60550000 0x1 0x1 trace:ole:DllMain (0x60750000,1,0x1) trace:ole:OleInitialize ((nil)) trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize trace:ole:apartment_construct creating new apartment, model=2 trace:ole:apartment_construct Created apartment on OXID 800000009 trace:ole:apartment_get_or_create Created main-threaded apartment with OXID 800000009 trace:ole:OleInitialize () - Initializing the OLE libraries trace:ole:OLEClipbrd_Initialize () trace:ole:CoRegisterMessageFilter (0x16eb60, (nil)) trace:ole:CoLockObjectExternal pUnk=0x1898f2, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x1898f2 trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x18a6c0 for object with IUnknown 0x1898f2 trace:ole:stub_manager_ext_addref added 1 refs to 0x18a6c0 (oid 1), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x1002e,0x1898f2) trace:ole:CoLockObjectExternal pUnk=0x189388, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x189388 trace:ole:new_stub_manager Created new stub manager (oid=2) at 0x190138 for object with IUnknown 0x189388 trace:ole:stub_manager_ext_addref added 1 refs to 0x190138 (oid 2), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x10040,0x189388) trace:ole:CoLockObjectExternal pUnk=0x18941c, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x18941c trace:ole:new_stub_manager Created new stub manager (oid=3) at 0x191268 for object with IUnknown 0x18941c trace:ole:stub_manager_ext_addref added 1 refs to 0x191268 (oid 3), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x10044,0x18941c) trace:ole:CoCreateInstance (rclsid= {25336920-03f9-11cf-8fd0-00aa00686f13}, pUnkOuter=(nil), dwClsContext=00000005, riid={00000000-0000-0000-c000-000000000046}, ppv=0x33f6b4) trace:ole:CoGetClassObject CLSID: {25336920-03f9-11cf-8fd0-00aa00686f13}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x44bb30- >{25336920-03F9-11CF-8FD0-00AA00686F13} trace:urlmon:DllMain 0x60e00000 0x8 (nil) trace:urlmon:DllMain 0x60e00000 0x1 (nil) trace:urlmon:CoInternetGetSession (0 0x33ed20 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b9c {79eac9e7- baf9-11ce-8c82-00aa004ba90b} L"file" 0 (nil) 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b94 {79eac9e3- baf9-11ce-8c82-00aa004ba90b} L"ftp" 0 (nil) 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b8c {79eac9e2- baf9-11ce-8c82-00aa004ba90b} L"http" 0 (nil) 0) trace:urlmon:InternetSession_Release () trace:ole:COMPOBJ_DLLList_Add trace:mshtml:DllGetClassObject (CLSID_HTMLDocument {00000001-0000-0000- c000-000000000046} 0x33f680) trace:mshtml:ClassFactory_AddRef (0x1957c0) ref = 1 trace:mshtml:HTMLDocument_Create ((nil) {00000000-0000-0000- c000-000000000046} 0x33f6b4) trace:mshtml:HTMLDocument_QueryInterface (0x195db8)->(IID_IUnknown, 0x33f6b4) trace:mshtml:HTMLDocument_AddRef (0x195db8) ref = 1 trace:mshtml:load_gecko () trace:mshtml:check_version unknown version trace:mshtml:load_xpcom (L"c:\\Program Files\\wine_gecko") warn:mshtml:load_xpcom Could not load XPCOM: 126 trace:mshtml:load_mozctl Could not find Mozilla ActiveX Control trace:mshtml:load_mozilla Could not open key L"Software\\mozilla.org\ \GRE" trace:ole:DllMain 0x60550000 0x2 (nil) trace:urlmon:CreateURLMoniker ((nil), L"http://source.winehq.org/winegecko.php", 0x7ed40a4c) trace:urlmon:URLMonikerImpl_Construct (0x1984d0, (null),L"http://source.winehq.org/winegecko.php") trace:urlmon:parse_canonicalize_url (L"http://source.winehq.org/winegecko.php" 00010000 0x1a9a98 2084 0x7ed409f0) trace:urlmon:parse_schema (L"http://source.winehq.org/winegecko.php" 00000000 0x7ed408f0 64 0x7ed408ec) warn:urlmon:CF_QueryInterface (0x60e22b8c)->({79eac9ec- baf9-11ce-8c82-00aa004ba90b},0x7ed408e8),not found trace:urlmon:CF_CreateInstance (0x60e22b8c)->((nil),{79eac9ec- baf9-11ce-8c82-00aa004ba90b},0x7ed408e8) trace:urlmon:HttpProtocol_Construct ((nil) 0x7ed408a8) warn:urlmon:HttpProtocol_QueryInterface not supported interface {79eac9ec-baf9-11ce-8c82-00aa004ba90b} (*** IInternetProtocolInfo ***) *** HUH ??? *** trace:urlmon:HttpProtocol_Release (0x1983f0) ref=0 trace:ole:__CLSIDFromString L"{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}" -> 0x7ed40810 trace:ole:CoGetClassObject CLSID: {79eac9e2-baf9-11ce-8c82-00aa004ba90b}, IID: {00000000-0000-0000-c000-000000000046} err:ole:CoGetClassObject apartment not initialised *** HUH ??? *** TIA Bill Medland

1 0

Re: wined3d: Make CreateFakeGLContext thread safe. [try 2]
by Robert Shearman 04 Jan '07

04 Jan '07

Jan Zerebecki wrote: > > + LeaveCriticalSection(&wined3d_fake_gl_context_cs); > + LEAVE_GL(); > ... > LEAVE_GL(); > + LeaveCriticalSection(&wined3d_fake_gl_context_cs); > return FALSE; > } You can't lock or unlock in different orders as this will create subtle races that could result in deadlocks. -- Rob Shearman

1 0

compiling simple windows app
by xie jason 04 Jan '07

04 Jan '07

hi all, I was trying to compile a simple windows application using winelib. it crashs and returns: err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip 60169224 esp 00230ff4 stack 0x231000-0x340000 I first convert a .dll, which contains a simple add function (int add(int a, int b)) to be .dll.so. And then I compile a simple program which calls this function. I am able to compile it properly. but when i run it, it shows above error message. -----------------.h is ------------------------------ int __stdcall add(int a, int b); ----------------.c is---------------------------- HMODULE hDLL=0; /* DLL to call */ #ifdef __i386__ #define GET_THIS(t,p) t p;\ __asm__ __volatile__ ("movl %%ecx, %0" : "=m" (p)) #endif BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { TRACE("(0x%p, %ld, %p)\n",hinstDLL,fdwReason,lpvReserved); if (fdwReason == DLL_WINE_PREATTACH) return FALSE; /* prefer native version */ if (fdwReason == DLL_PROCESS_ATTACH) { hDLL = LoadLibraryA( "libjason.dll" ); printf("load dll\n"); TRACE(":Forwarding DLL (libJason.dll) loaded (%ld)\n",(LONG)hDLL); } else if (fdwReason == DLL_PROCESS_DETACH) { FreeLibrary( hDLL ); TRACE(":Forwarding DLL (libJason.dll) freed\n"); } return TRUE; } int add(int a, int b) { int (*pFunc)(int, int); int retVal; pFunc=(void*)GetProcAddress(hDLL,"vgMath"); TRACE("((int)%ld,(int)%ld): forward\n",(LONG)a,(LONG)b); retVal = pFunc(a,b); TRACE("Returned (%ld)\n",(LONG)retVal); return retVal; } ------------------------.spec is -------------------- 1 stdcall add( long long ) vgMath can any one help me? thanks Send instant messages to your online friends http://au.messenger.yahoo.com

2 1

Re: [2/2] WineD3D: Re-download dirty GL surfaces
by Stefan Dösinger 03 Jan '07

03 Jan '07

Am 03.01.2007 um 02:48 schrieb Phil Costin: > This patch enables the forced re-downloading of dirty GL surfaces. > > It requires [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface > Download and is the first step toward supporting gamma-corrected > (sRGB) > texture sampling support. > > Thanks to Stefan Dösinger for his advice in IRC during the > implementation of > these 2 patches. > <surfacedownload.diff> > You will have to bind the surface's texture to gl to be able to download the surface. If the texture name in glDescription is 0 you don't have to download. Select a proper texture unit(e.g. 0) before binding and mark that sampler dirty to force drawprim to restore it later.

2 1

Re: [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download
by Peter Oberndorfer 03 Jan '07

03 Jan '07

On Wednesday 03 January 2007 02:48, Phil Costin wrote: > This patch resets the SFLAG_GLDIRTY flag for a surface once the GL surface > data has been refreshed in surface_download_data(). > > Thanks to Stefan Dösinger for his advice in IRC during the implementation of > these 2 patches. > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 031d320..5cb9bf6 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -142,6 +142,8 @@ static void surface_download_data(IWineD > } > } > } > + /* No longer dirty */ > + This->Flags &= SFLAG_GLDIRTY; I think there is a ~ missing here, else everything but the dirty flag will be cleared. > } > } Greetings Peter

2 1

Re: crtdll: Declare some variables static
by Marcus Meissner 03 Jan '07

03 Jan '07

On Wed, Jan 03, 2007 at 03:45:28PM +0000, Andrew Talbot wrote: > Changelog: > crtdll: Declare some variables static. Err, why? They are clearly exported from the .spec file and you just killed the exports? They likely are used by Windows programs. Ciao, Marcus

3 3

Re: Oleview: correct representation of unions
by Francois Gouget 03 Jan '07

03 Jan '07

On Thu, 28 Dec 2006, Konstantin Kondratyuk wrote: > Hello, > > this patch corrects representation of unions for old compilers (gcc 2.95) > For example: > (union).field - is not supported by gcc 2.95 > union.field - is supported This is strange. I compile Wine with gcc 2.95 weekly but never encountered this problem. Also note that the U(x) macro would need to be fixed in other places too (include/wine/test.h for instance). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

Re: [PATCH] [DbgHelp]: implemented 64 bit versions of EnumerateLoadedModules
by Alexandre Julliard 03 Jan '07

03 Jan '07

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > +BOOL WINAPI EnumerateLoadedModulesW64(HANDLE hProcess, > + PENUMLOADED_MODULES_CALLBACKW64 E= > numLoadedModulesCallback, > + PVOID UserContext) > +{ > + struct enum_load_mod64_W64 x; > + > + x.cb =3D EnumLoadedModulesCallback; > + x.user =3D UserContext; > + > + return EnumerateLoadedModules64(hProcess, enum_load_mod64_W64, &x); You should make the A function call the W one, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
by Robert Shearman 03 Jan '07

03 Jan '07

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: dff43b732b10e603f3aee38db2f684dc7404aa4e > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dff43b732b10e603f3aee38db… > > Author: Reinhard Karcher <rkarcher(a)frey.de> > Date: Mon Jan 1 17:45:06 2007 +0100 > > user32: Speed improvement for 16bit comm support. > > --- > > dlls/user32/comm16.c | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/user32/comm16.c b/dlls/user32/comm16.c > index 9329c82..0164196 100644 > --- a/dlls/user32/comm16.c > +++ b/dlls/user32/comm16.c > @@ -719,9 +719,8 @@ INT16 WINAPI GetCommError16(INT16 cid,LP > stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET; > COMM_MSRUpdate( ptr->handle, stol ); > > - if (lpStat) { > - lpStat->status = 0; > - > + if (lpStat) { > + lpStat->status = 0; > SleepEx(1,TRUE); > > lpStat->cbOutQue = comm_outbuf(ptr); This patch doesn't seem to do what it says it does. -- Rob Shearman

2 1

Re: wined3d: state_pointsprite should apply to all texture units
by Tomas Carnecky 03 Jan '07

03 Jan '07

Chris Robinson wrote: > + for (i = 0; i < GL_LIMITS(texture_stages); i++) { > + /* Note the WINED3DRS value applies to all textures, but GL has one > + * per texture, so apply it now ready to be used! > + */ > + if (GL_SUPPORT(ARB_MULTITEXTURE)) { > + GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + i)); > + checkGLcall("glActiveTextureARB"); > + } else if (i>0) { > + FIXME("Program using multiple concurrent textures which this opengl implementation doesn't support\n"); > + } I'd do that '} else if (i == 1) {', otherwise you'll print a whole lot FIXME's, and maybe add a 'break', since it doesn't make sense to call glTexEnvi() over and over for the same texture. tom

2 1

Re: wined3d: state_pointsprite should apply to all texture units
by H. Verbeet 03 Jan '07

03 Jan '07

On 03/01/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > Updated with the change suggested by Tomas. > Does this work when there's no texture bound to the unit?

2 1

ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
by Andreas Mohr 03 Jan '07

03 Jan '07

Hi all, http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24… failed to install with some nice MSI failures when I tried it last week on a current Wine version (Ubuntu package 0.9.28, I think). Does that mean that I'm entitled to assemble a capable lynch mob for the guys who were supposed to fix any and all MSI installer issues at CodeWeavers? ;) IMHO ppviewer.exe is important since those people who receive some scripted PowerPoint file (yes, that's even some "games"!) won't have much luck with OpenOffice Impress, so they're fully dependant on getting ppviewer.exe to work. Andreas Mohr

4 4

Re: quartz: add implementations for AmpFactorToDB and DBToAmpFactor
by Roderick Colenbrander 03 Jan '07

03 Jan '07

Hi, Why are you using a lookup table and not just a log10(x) and 10^(x) for the gain <-> dB conversions? That's how it should be done I think like 10x corresponding to 20dB (assuming signal gain). In your tests it is just: 2000*log10(gain) - 9630 for going to that dB-like scale. Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

3 2

Re: Uniscribe improvements
by Hans Leidekker 03 Jan '07

03 Jan '07

On Tuesday 02 January 2007 19:42, * * wrote: > StringAnalysis should have a cache object, not save the HDC directly. I agree, although you shouldn't free the cache in ScriptStringFree, the caller is responsible for that. > One of the important things about the cache, which wine currently > doesn't do, is that the caller is free to select a different font into > the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to > use the right one. Yes, cache handling is still very basic. If the font changes the cache should be invalidated. It also needs to be ref counted and locked. -Hans

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel