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

Support for IDvdInfo2::GetDiscID
by James Courtier-Dutton March 25, 2005

March 25, 2005

The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. Cheers James

2 2

text edit box not painting text ( on form startup )
by Doug Herbert March 9, 2005

March 9, 2005

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Re: Wine on FreeBSD current
by Gerald Pfeifer Oct. 30, 2004

Oct. 30, 2004

>> I'm just wondering if it is supposed to work as well as FreeBSD stable. Right now, Wine doesn't work at all on FreeBSD -STABLE: wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory and before that I used to see deadlocks upon startup of non-trivial applications (such as Forte Agent, both 16bit and 32bit flavors). I believe there are also signficant threadings issues on -CURRENT, so overall Wine is hardly, if at all, usable on any version of FreeBSD I have access to, even though I'm still working to keep it at least compilable on FreeBSD 4.9 and 5.2/5.3. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

6 13

Don't crash on failing DRIVER_FindFromHDrvr
by Uwe Bonnes Sept. 6, 2004

Sept. 6, 2004

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

Wine bug with delphi Menus
by Robert van Herk Sept. 5, 2004

Sept. 5, 2004

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

2 1

Remote operations -- need for advice
by Alexander Yaworsky Aug. 27, 2004

Aug. 27, 2004

I'm thinking how to implement CreateRemoteThread and besides fix memory management functions. The complete (afaik) list includes: RtlCreateUserThread NtAllocateVirtualMemory NtFreeVirtualMemory NtProtectVirtualMemory NtQueryVirtualMemory NtLockVirtualMemory (do nothing?) NtUnlockVirtualMemory (do nothing?) NtFlushVirtualMemory NtMapViewOfSection NtUnmapViewOfSection Suggested implementation. Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx and remote_operation_xxxx_complete. remote_operation should do the following: 1) suspend_for_ptrace(); 2) inject a piece of code into required process and start its execution; 3) resume_after_ptrace(); 4) place calling thread into suspended state (or into some wait state?) remote_operation_complete should prepare reply and resume thread suspended by remote_operation. Injected code should call required function and then remote_operation_complete in context of required process. The question is: how to correctly get address of function? imho possible solutions are: 1) assume ntdll loaded at the same address for all processes -- unreliable; 2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?); 3) pass relative offsets and add them later to the ntdll's base address -- unreliable a bit: ntdll may be replaced, although, it is unlikely; 4) extend the struct process (server/process.h) and the request init_process with pointers to required functions -- most reliable and simple but looks ugly. What do you think?

6 11

Re: appdb dump
by Jeremy Newman Aug. 11, 2004

Aug. 11, 2004

This is getting to be a common request. I think what I am going to do is make a script that tars up the appdb every night and puts it up for download. The only table it will not dump will be the userdb, for privacy reasons. I'll email you all again when I have something whipped up. On Thu, 2004-06-24 at 18:12, Joel Konkle-Parker wrote: > I'm trying to set up a copy of appdb on localhost to play with (and > hopefully use as a base for patches for you guys). Do you think I could > get a dump of the apps tables so that I can have a good set to test with? -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon

2 2

Re: Scrollbars, an application bug or a wine regression ? (#2314)
by Dmitry Timoshkov July 26, 2004

July 26, 2004

"George Marshall" <g.marshall(a)nospam.com> wrote: > > Does reverting of the following patch help? > > Yes it does make the application work as it did before > the June Release :-) Do you have a small application I could test with? -- Dmitry.

4 16

Yard sale windows app fun: Lotus SmartSuite '96. 1-2-3 works, WordPro doesn't.
by Dan Kegel July 18, 2004

July 18, 2004

I went to a yard sale today, and that's always dangerous. Today I ended up buying a copy of Lotus SmartSuite '96. I then installed Wine-20040615.tar.gz and tried installing my new disc with $ wine d:\\install.exe It got all confused, started iterating through every file underneath my home directory, and printed out err:shell:SHGetFileInfoW pidl is null! for each one! On a hunch, I made my home directory look empty, $ mkdir .blort $ mv * .blort $ wine d:\\install.exe That seemed much better; Wine only printed out the SHGetFileInfoW error once, presumably for the lotustmp.000 directory it created in my home directory. The next problem was when a dialog box "Select a Program Group..." popped up. At about the same time, an error box with title "Setup Message" and body "Setup has encountered a problem. Please report File='COMMON\SYMTAB11.C',Line='618' to Microsoft Product Support Services." This looks a bit lot like http://support.microsoft.com/default.aspx?scid=kb;EN-US;113252 which happens when GetWindowsDirectory() returns a string with lowercase letters, but clicking OK let me past with no ill affects, and I was able to install. At least when all I installed was Word Pro. When I also tried installing 1-2-3 and ScreenCam, I got the error "Lotus Setup" : "Install encountered an error trying to start Regedit.exe." That popped up twice, after which install thought for a long time, then warned fixme:ole:CoCreateInstance no classfactory created for CLSID {00021401-0000-0000-c000-000000000046}, hres is 0x80040154 and seemed to get stuck. Still, things seemed to be more or less well installed, so I tried running two of the apps. $ cd c/lotus/123/programs $ wine 123w.exe worked quite nicely. (Well, it did say the date was 6/17/104, but nobody's perfect!) Next I tried Word Pro: $ cd ~/.wine/c/lotus/wordpro $ wine wordpro.exe That failed immediately, so quickly that WINEDEBUG=+all wine wordpro.exe was practical to run. Here's part of its output. It looks as if the very first instruction accesses a null pointer in a strange way. 0009:Starting process L"C:\\lotus\\wordpro\\wordpro.exe" (entryproc=0x7a6aee) 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x7a6aee 0009:trace:seh:EXC_RtlRaiseException info[0]=00000001 0009:trace:seh:EXC_RtlRaiseException info[1]=00000000 0009:trace:seh:EXC_RtlRaiseException eax=00000000 ebx=403f1668 ecx=400c0be8 edx=400c0c37 esi=400c1000 edi=007a6aee 0009:trace:seh:EXC_RtlRaiseException ebp=4070fff4 esp=4070ff30 cs=0023 ds=002b es=002b fs=003b gs=0033 flags=00010246 0009:trace:seh:EXC_CallHandler calling handler at 0x403e1708 code=c0000005 flags=0 0009:Call ntdll.NtQueryVirtualMemory(ffffffff,00000000,00000000,4070fac0,0000001c,4070fa84) ret=4037aeb8 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=4037aeb8 0009:Call ntdll.RtlImageDirectoryEntryToData(00000000,00000001,00000002,4070fabc) ret=4033fbbe 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40091368 0009:trace:seh:EXC_RtlRaiseException info[0]=00000000 0009:trace:seh:EXC_RtlRaiseException info[1]=00000000 0009:trace:seh:EXC_RtlRaiseException eax=00000000 ebx=400beec4 ecx=00000001 edx=00000000 esi=00000000 edi=00000002 0009:trace:seh:EXC_RtlRaiseException ebp=4070f9e4 esp=4070f928 cs=0023 ds=002b es=002b fs=003b gs=0033 flags=00010246 0009:trace:seh:EXC_CallHandler calling handler at 0x40089948 code=c0000005 flags=0 0009:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 0009:trace:seh:EXC_CallHandler calling handler at 0x40088fc0 code=c0000005 flags=2 0009:trace:seh:EXC_CallHandler handler returned 1 0009:Ret ntdll.RtlImageDirectoryEntryToData() retval=00000000 ret=4033fbbe 0009:Call ntdll.NtCreateEvent(4070fac0,001f0003,4070fac4,00000001,00000000) ret=4033f836 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=4033f836 wine: Unhandled exception (thread 0009), starting debugger... ... Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x007a6aee). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:007a6aee ESP:4070ff30 EBP:4070fff4 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:403f1668 ECX:400c0be8 EDX:400c0c37 ESI:400c1000 EDI:007a6aee Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060: Backtrace: =>1 0x007a6aee (0x4070fff4) 2 0x4002e83d (0x00000000) 0x007a6aee: addb %al,0x0(%eax) Modules: 0x40070000-400c2000 Deferred ntdll 0x40320000-403f3000 Deferred kernel32 0x00400000-00888000 --none-- wordpro 0x402f0000-403f3000 Deferred kernel32<elf> 0x40019000-40025000 Deferred libnss_files.so.2 0x401b5000-401d7000 Deferred libm.so.6 0x400c2000-401b5000 Deferred libwine_unicode.so.1 0x40053000-400c2000 Deferred ntdll<elf> 0x40000000-40016000 Deferred ld-linux.so.2 0x4004f000-40052000 Deferred libdl.so.2 0x420155f0-841485f0 Deferred libc.so.6 0x40042000-4004f000 Deferred libpthread.so.0 0x4002a000-40042000 Sym libwine.so.1 0x420155f0-841485f0 Deferred libc.so.6 Module Address Debug info Name (14 modules) PE 0x00400000-00888000 --none-- wordpro ELF 0x40000000-40016000 Deferred ld-linux.so.2 ELF 0x40019000-40025000 Deferred libnss_files.so.2 ELF 0x4002a000-40042000 Sym libwine.so.1 ELF 0x40042000-4004f000 Deferred libpthread.so.0 ELF 0x4004f000-40052000 Deferred libdl.so.2 ELF 0x40053000-400c2000 Deferred ntdll<elf> \-PE 0x40070000-400c2000 Deferred ntdll ELF 0x400c2000-401b5000 Deferred libwine_unicode.so.1 ELF 0x401b5000-401d7000 Deferred libm.so.6 ELF 0x402f0000-403f3000 Deferred kernel32<elf> \-PE 0x40320000-403f3000 Deferred kernel32 ELF 0x420155f0-841485f0 Deferred libc.so.6 ELF 0x420155f0-841485f0 Deferred libc.so.6 Threads: process tid prio (all id:s are in hex) 0000000b (D) C:\lotus\wordpro\wordpro.exe 00000009 0 <== 00000010 00000011 0 WineDbg terminated on pid 0xb So I guess I got a couple hours worth of entertainment out of my $5, and I can now run Lotus 1-2-3 if I feel like it. Cool. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 8

ioctl(/dev/dsp, SNDCTL_DSP_SETDUPLEX) failed
by Saulius Krasuckas July 10, 2004

July 10, 2004

With thepatch [1] I am getting some this line from Wine: err:wave:OSS_RawOpenDevice ioctl(/dev/dsp, SNDCTL_DSP_SETDUPLEX) failed (Input/output error) Yes, my soundcard doesn't support full duplex, I believe (I have OPTi 82c931 chip with mad16 driver running here). But shouldn't the type of the message be WARN or TRACE instead of ERR then? [1] http://cvs.winehq.org/patch.py?id=12636

2 1

Precompiled headers?
by Shachar Shemesh July 5, 2004

July 5, 2004

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 July 3, 2004

July 3, 2004

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 July 2, 2004

July 2, 2004

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 July 2, 2004

July 2, 2004

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 July 1, 2004

July 1, 2004

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 June 30, 2004

June 30, 2004

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 June 30, 2004

June 30, 2004

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 June 30, 2004

June 30, 2004

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 June 30, 2004

June 30, 2004

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 June 30, 2004

June 30, 2004

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

[RFC] Wine upgrade procedure (spec)
by Dimitrie O. Paun June 30, 2004

June 30, 2004

Hi folks, It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): -- native vs. builtin DLLs handling -- multiple Wine installations on a box -- updating only some DLLs -- integrating into the Unix environment -- dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: -- administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). -- the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a conprehensive view of the problem we are trying to solve. Thanks for reading this far! -- Dimi.

3 3

A wine magic trace key
by Andrei Barbu June 29, 2004

June 29, 2004

I'm about to implement a set of keys that lets me enable disable traces any time. Seems to me like it's a good idea, like that I can get traces for exactly what I need. Especially when I'm faced with weird debugger output that's 10 minutes into the game and I can't turn traces on to begin with. Is there another way, possibly existing, to do this? Is this a really bad idea? If people are interested I can post a patch later on today or tomorrow with it. It'll be implemented in the x11 driver and calling the existing wine_dbg_parse_options with a new options string. It can even be made a commandline option to enable and disable that key combination (and possibly the key combination could be set in wineconfig) but that's if enough people are interested in the idea. Thanks, Andrei

3 4

Temporary moderator needed
by Duane Clark June 29, 2004

June 29, 2004

Howdy, Someone is needed for the period June 30-July 5 to handle moderation of the Wine lists. If you are willing to do it, please email me off list. Thanks.

1 0

Re: Missing declaration for MSVCRT_div_t and MSVCRT_ldiv_t
by Dimitrie O. Paun June 29, 2004

June 29, 2004

On Tue, Jun 29, 2004 at 01:27:23PM +0200, Pierre d'Herbemont wrote: > Hi! > > On non-i386 we have to define MSVCRT_div_t and MSVCRT_ldiv_t. Please also add the appropriate tests to tests/headers.c. -- Dimi.

1 0

Re: parameter checking in CoMarshalInterface
by Uwe Bonnes June 29, 2004

June 29, 2004

>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: Aric> Changlog: return an error if the IUnknown pointer is NULL and dont Aric> crash tested with win2k and this is proper behavior Index: The test is welcome in the test suite... Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0