June 2004 - Wine-devel - list.winehq.org

Precompiled headers?
by Shachar Shemesh 05 Jul '04

05 Jul '04

Hi, Is anyone considering putting precompiled headers support into the wine build system? http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20He… -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

2 1

Pango for BiDi
by Mike Hearn 03 Jul '04

03 Jul '04

Hi Shachar, I am reading your interview and a few words jumped out at me, mostly "BiDi", "shaping" and "unicode" - very vague I know, but if I understand correctly Pango is a library with advanced support for shaping and laying out all kinds of different scripts. Only stopper I can think of would be that it uses UTF-8 not UTF-16. Have you looked at this, or am I talking smack? thanks -mike

2 5

taskmgs hangs on edit debug channels
by Andrei Barbu 02 Jul '04

02 Jul '04

The taskmanager dies when trying to edit the debug channels of any programs with the newest CVS (checked out 2 days ago) It just sits there with this: 002e:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=409cd43c 002e:Call kernel32._ConfirmSysLevel(40a08ac0) ret=409a3f15 002e:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=409a3f15 002e:Call kernel32.GlobalLock16(0000116f) ret=40999b70 002e:Ret kernel32.GlobalLock16() retval=404326d0 ret=40999b70 002e:Call kernel32.ReleaseThunkLock(41625f7c) ret=409cd30f 002e:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409cd30f 002e:trace:msg:GetMessageW (116f) mask=0000007f, bits=00000000, changed=00000000, waiting 002e:Call kernel32.ReleaseThunkLock(41625fe4) ret=409cd684 002e:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409cd684 002e:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,404326d4,ffffffff,00000000,00000000) ret=409cd6c6 002e:Call ntdll.RtlEnterCriticalSection(40d76680) ret=40d54902 002e:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=40d54902 002e:Call ntdll.RtlLeaveCriticalSection(40d76680) ret=40d54932 002e:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40d54932 002e:Call ntdll.RtlEnterCriticalSection(40d76680) ret=40d54902 002e:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=40d54902 002e:Call ntdll.RtlLeaveCriticalSection(40d76680) ret=40d54932 002e:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40d54932 002e:Call kernel32.WaitForMultipleObjectsEx(00000002,41625dac,00000000,ffffffff,00000000) ret=40d383db 002e:Call ntdll.NtWaitForMultipleObjects(00000002,41625ba0,00000000,00000000,00000000) ret=40591c85 If I move the mouse it spits out the correct mouse messages which indicate that wine itself is running just fine. The taskmanager window doesn't get redrawn (the black backround around it does). The backtrace from that point is: =>1 0x400636a9 (0x41b2be48) 2 0x402335c2 NTDLL_wait_for_multiple_objects+0x122(count=0x1, handles=0x41b2bf38, flags=0x4, timeout=0x0) [sync.c:587] in ntdll (0x41b2beec) 3 0x40233636 NtWaitForMultipleObjects+0x66(count=0x1, handles=0x41b2bf38, wait_all=0x0, alertable=0x0, timeout=0x0) [sync.c:605] in ntdll (0x41b2bf14) 4 0x40591c85 WaitForMultipleObjectsEx+0xb5(count=0x1, handles=0x41b2c06c, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [sync.c:171] in kernel32 (0x41b2c044) 5 0x40591b1a WaitForSingleObject+0x3a(handle=0x6c, timeout=0xffffffff) [sync.c:99] in kernel32 (0x41b2c064) 6 0x40656867 ProcessPageRefreshThread+0x87(lpParameter=0x0) [procpage.c:511] in taskmgr (0x41b2c1a4) 7 0x40598fba THREAD_Start+0x11a(ptr=0x40450220) [thread.c:107] in kernel32 (0x41b2c27c) 8 0x40234fe9 start_thread+0x199(info=0x40450240) [thread.c:198] in ntdll (0x41b2cacc) 9 0x4005df70 (0x41b2cbcc) 10 0x4017e40a (0x00000000) Any ideas? I'm not quite versed enough in wine to know what's happening too well. I realise it's a thread waiting for another that apparently never finishes.. or I think it is, and I'm kind of lost from there. Thanks, Andrei

2 1

Delayed breakpoints in winedbg
by Adrian Rees 02 Jul '04

02 Jul '04

Hi all, Apologies in advance for what is probably a dumb question... I'm trying to debug a windows application by breaking on a call to a DLL function - in fact it's the NtCreateKey function within the ntdll library. I must be missing something fundamental because the debugger indicates that it has set a delayed breakpoint, but the breakpoint is never reached, although turning on debugging messages clearly indicates that the function is being called. Here's a typical attempt: $ WINDEBUG=reg winedbg MSMONEY.EXE ... (lots of startup calls to reg) ... In 32 bit mode. Wine-dbg>break NtCreateKey fixme:dbghelp:elf_new_wine_thunks Duplicate in midimap.drv<elf>: _edata<5b828a10 -00000000> completed.1<5b828a10-00000000> ... (snip) ... No symbols found for NtCreateKey Unable to add breakpoint, will check again when a new DLL is loaded Wine-dbg>info break No breakpoints No watchpoints Delayed breakpoints: 0: NtCreateKey Wine-dbg>cont trace:reg:NtCreateKey(0x28,L"Software\\Microsoft\\Windows\\CurrentVersion\\AppPaths\\MSMONEY.EXE",L"",1,1,0xb9fd04) trace:reg:NtCreateKey <- 0x50 trace:reg:RegQueryValueExA(0x50,"Path",(nil),0xb9fcf8,0xb9f318,0xb9fd00=260) ... (etc till program ends) ... I've spent a couple of hours searching for more information on how to use this capability of the debugger, but with no luck - can anyone tell me what I'm doing wrong? Thanks, Adrian

2 3

Cleaning up W->A calls
by James Hawkins 01 Jul '04

01 Jul '04

I recently decided to help with the development of Wine, and seeing as how I am new to the process, I have chosen menial tasks to take on. This way I can learn more about Wine while contributing. I am currently working on the janitorial task of getting rid of W->A calls and I have a few questions about how I should implement these changes. I'll start the question with an example: dlls/advapi32/crypt.c line 255, 482 BOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { ... complete implementation } BOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR pszContainer, LPCWSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { PSTR pProvider = NULL, pContainer = NULL; BOOL ret = FALSE; TRACE("(%p, %s, %s, %ld, %08lx)\n", phProv, debugstr_w(pszContainer), debugstr_w(pszProvider), dwProvType, dwFlags); if ( !CRYPT_UnicodeToANSI(pszContainer, &pContainer, -1) ) CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); if ( !CRYPT_UnicodeToANSI(pszProvider, &pProvider, -1) ) { CRYPT_Free(pContainer); CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); } ret = CryptAcquireContextA(phProv, pContainer, pProvider, dwProvType, dwFlags); if (pContainer) CRYPT_Free(pContainer); if (pProvider) CRYPT_Free(pProvider); return ret; } Initially CryptAcquireContextW converts all of its arguments to ansi then calls CryptAcquireContextA (which is intuitively not what we're wanting and thus the cleanup.) The question is, what exactly is the best way to clean this up? It seems to me that there are two main options as to what can be done: A) convert the W->A calls in the wide-char functions to A->W calls in the asci functions and implement the wide-char functions instead, or B) implement both asci and wide-char functions separately ie asci functions only call asci functions etc. If we are to choose plan A, I have seen several different methods of converting asci to wide-char, and I am wondering which method is best. for example: dlls/advapi32/crypt.c lines 133-141 wcount = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0); wcount = wcount < wstrsize/sizeof(WCHAR) ? wcount : wstrsize/sizeof(WCHAR); if (wstrsize == -1) *wstr = CRYPT_Alloc(wcount * sizeof(WCHAR)); if (*wstr) { MultiByteToWideChar(CP_ACP, 0, str, -1, *wstr, wcount); return TRUE; } and, dlls/advapi32/registry.c lines 1626-1636 LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, LPSECURITY_ATTRIBUTES sa ) { UNICODE_STRING *fileW = &NtCurrentTeb()->StaticUnicodeString; NTSTATUS status; STRING fileA; RtlInitAnsiString(&fileA, file); if ((status = RtlAnsiStringToUnicodeString(fileW, &fileA, FALSE))) return RtlNtStatusToDosError( status ); return RegSaveKeyW(hkey, fileW->Buffer, sa); } Which method is better/more efficient? I would have to argue that implementing both the asci functions and wide-char functions separately would be the most efficient way to solve the W->A problem. Throughout all the wine libs, many conversion calls are being made from W->A and A->W, when most of these calls could be left out. I think performance would improve without all of the conversion calls. Granted the size of the code would increase, but speed would also increase. There are a couple snags when it comes to implementing asci and wide-char functions independently, but that can be discussed later. If I'm totally off the mark, let me know, and if there are other jobs I could be doing, let me know as well because I would like to contribute, but I'm not exactly sure what to do yet. Thankyou for your time. James Hawkins truiken(a)comcast.net

4 4

Re: dlls/shell32 W->A cleanup of systray.c
by Marcelo Duarte 30 Jun '04

30 Jun '04

Danny Hawkins wrote: >Hi, > >Converted all wide-char->ansi calls to ansi->wide-char in systray.c > > > The TTM_UPDATETIPTEXTA should be converted to TTM_UPDATETIPTEXTW and TTM_ADDTOOLA -> TTM_ADDTOOLW >@@ -272,13 +272,13 @@ > ti.rect.bottom = ICON_SIZE+2*ICON_BORDER; > > if(modify) >- SendMessageA(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti); >+ SendMessageW(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti); > else >- SendMessageA(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti); >+ SendMessageW(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti); > } > > Here, you should'nt cast (WCHAR *)"". Please define: static const WCHAR emptyW[] = {0}; Or modify the function to accept NULL. >@@ -297,15 +297,15 @@ > (*ptrayItem)->notifyIcon.hWnd = pnid->hWnd; /* only needed for callback message */ > SYSTRAY_ItemSetIcon (*ptrayItem, (pnid->uFlags&NIF_ICON) ?pnid->hIcon :0); > SYSTRAY_ItemSetMessage(*ptrayItem, (pnid->uFlags&NIF_MESSAGE)?pnid->uCallbackMessage:0); >- SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :"", FALSE); >+ SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :(WCHAR *)"", FALSE); > > The old code should be eliminated, not commented: >+/*{ > BOOL flag=FALSE; > TRACE("enter %p %d %ld\n", pnid->hWnd, pnid->uID, dwMessage); > switch(dwMessage) { >@@ -377,13 +390,30 @@ > } > TRACE("leave %p %d %ld=%d\n", pnid->hWnd, pnid->uID, dwMessage, flag); > return flag; >-} >+}*/ > > > >+/*{ > BOOL ret; > > PNOTIFYICONDATAA p = HeapAlloc(GetProcessHeap(),0,sizeof(NOTIFYICONDATAA)); >@@ -395,4 +425,4 @@ > > HeapFree(GetProcessHeap(),0,p); > return ret; >-} >+}*/ > >

1 0

Scrollbars, an application bug or a wine regression ? (#2314)
by Gabriele Giorgetti 30 Jun '04

30 Jun '04

Hello, I've noticed a problem with scrollbars in the latest Wine's release (20040615). With wine version 20040505 everything was just fine. I've attacched a zip file with two screenshots (pls. see wine BUG #2314 @ bugs.winehq.org ) the first one is the correct behavior of the app using wine 20040505 the second one is wine 20040615 and the app in its wrong behavior. Trying to describe the problem: The application show up with a bottom scrollbar and a right scrollbar even if they are not needed. When executing the very same application, with the very same settings and size with wine 20040505 the scrollbars are not there. I hope you get it Thanks. NB: BUG #2314 at bugs.winehq.org

5 9

err:opengl:X11DRV_ChoosePixelFormat Flag not supported
by Tobias Burnus 30 Jun '04

30 Jun '04

Hello, I have the following problems with WINE, CVS version as of yesterday and Crystal Impact's Diamond http://www.crystalimpact.com/diamond/ http://www.crystalimpact.com/download/diamond/demo/dm2demo.exe, which installs flawlessly. a) I get a err:opengl:X11DRV_ChoosePixelFormat Flag not supported when I open e.g. ./Samples/Minerals/Copper.dsf and a dialogbox with the following text is shown: ChoosePixelFormat() returns 0 (last error = 0) SetPixelFormat() returns 1 (last error = 0) wglCreateContext() returns 0 (last error 2000) wglMakeCurrent() returns 1 (last error = 0) (Workaround: disable rendering) b) Some data is displayed as list, e.g. like http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png under WINE this is completely mangled: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list_wine.png Sometimes some spread numbers appear, but in this case one can only mark cells. Any ideas how to fix/debug this? (I have unfortunally no experience at all in programming in Wine/Windows.) Anyone volunteering to look at this? I'm willing to spend some $$ (but not $$$) on that (I know that this is not much, but some rewarding of volunteer work doesn't hurd either). Regards, Tobias

1 0

Re: Typo in winedbg
by Mike Hearn 30 Jun '04

30 Jun '04

On Mon, 28 Jun 2004 20:45:35 -0400, Andrei Barbu wrote: > This fixes debuggee to debugger. I think debuggee is the right word, it means "the one that is being debugged". Ctrl-C doesn't interrupt winedbg, it interrupts the process you are currently attached to.

2 1

Failed to compile on Sparc/Solaris 9
by John O'Donnell 29 Jun '04

29 Jun '04

make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/export/home/root/wine/wine/dlls/newdev' make[2]: Entering directory `/export/home/root/wine/wine/dlls/ntdll' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o error.o exception.o file.o heap.o large_int.o loader.o loadorder.o misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o wcstring.o relay32.o ntdll.dll.dbg.o -o ntdll.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lresolv -lsocket -lnsl ntdll.dll-IHmocZ.spec.c:20:1: warning: "__stdcall" redefined <command line>:17:1: warning: this is the location of the previous definition thread.o: In function `NtCurrentTeb': /export/home/root/wine/wine/dlls/ntdll/thread.c:582: undefined reference to `wine_pthread_get_current_teb' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ntdll.dll.so] Error 2 make[2]: Leaving directory `/export/home/root/wine/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/export/home/root/wine/wine/dlls' make: *** [dlls] Error 2 root(a)gold251:/root/wine/wine# This is CVS'ed a day ago. Any ideas? Any more info needed?

1 0