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

CryptSetProviderExA fix

by James Hawkins

Hi, I'll start off by explaining how the Cryptographic Service Providers are stored in the registry. A lot of advapi32 CSP functions can accept a provider name sent in to use that provider, or advapi32 can use the default provider which is located in the registry at: HKLM\Software\Microsoft\Cryptography\Defaults\ Listed under the Provider\ key are the keys of the different providers available on the computer. Each provider has a non-unique provider type associated with it, and several providers may be of the same provider type. These types are listed under the 'Provider Types' key which is itself under 'Defaults\'. The keynames are of the form 'Type XXX' where XXX is the numeric value of the type. These keys under 'Provider Types\' assign the default provider that is to be used for each type. The 'Name' value associates each type with the corresponding provider default that is used with this type. It is essential that the 'TypeName' registry of each provider type remain in the registry, because it is only inserted once when the dll is registered. It is acceptable if the 'Name' value is removed, and this should happen when CryptSetProviderEx is called with the CRYPT_DELETEDEFAULT flag. This is the code that handles the CRYPT_DELETEFLAG in the current implementation of CryptSetProviderExA: if (dwFlags & CRYPT_DELETE_DEFAULT) { if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & CRYPT_USER_DEFAULT)) ) CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); RegDeleteKeyA( (dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE, keyname); CRYPT_Free(keyname); return TRUE; } The important line to look as is the RegDeleteKeyA call. This call removes the entire 'Type XXX' key from the registry. The next time a call is made to CryptSetProviderEx to set the default provider and not remove it, the call will fail because of the next line: if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & CRYPT_USER_DEFAULT)) ) CRYPT_GetTypeKeyName uses the dwProvType parameter to search the registry for the particular 'Type XXX' key that matches the provider type, but this call fails because when we last called CryptSetProviderExA with the CRYPT_DELETEDEFAULT flag, the entire 'Type XXX' key was removed. The proper fix for this, and the way windows handles it, is to just remove the 'Name' value from the 'Type XXX' key if the CRYPT_DELETEDEFAULT flag is sent in. This way the required 'TypeName' will never be removed, and the next call can set the default provider. If you would like to look at the already patched version, I'll attach it along with the patch. Thankyou for taking the time to look this over. If there are problems with the patch, please let me know so we can get this committed. -- James Hawkins

Aug. 25, 2004

Re: poll vs. epoll

by Shachar Shemesh

Dan Kegel wrote: > Shachar Shemesh wrote: > >> It doesn't compile (rn.c is not including <sys/epoll.h>). When I fix >> that, it checks whether epoll_create works. If it does, it sets all >> handlers to use sigio. I don't think this library is quite stable >> enough :-) > > > You're a tough customer :-) It's quite close; guess I should polish > it up a bit. > >> In any case, it seems that it's interface is not ideal for >> wineserver. Libevent, on the other hand...... > > > Now don't go and do level-triggered stuff just because it's easier :-) > That's not it at all, and edge vs. level is not part of my considerations. Libevent does support a wider variety of selection interfaces, and with wider platform support, than your library. > I don't think it's fair to say level-triggered is ideal for > wineserver. In fact, wineserver is an example of the kind > of program that is easier to convert to edge-triggering > than most programs, since it's small and self-contained. Can you give benchmarks for performance differences between the two? The more I think about it, the more I'm getting the impression that going edge trigger means we need to maintain our own cache of not-yet-useful data, as well as risking starvation. I'm sure there are cases where this is preferable, but can you explain why this is such a case? Also, can you show me how to do edge trigger via poll? > Sigh. I wish my wrists were in better shape; I'd convert it > myself. As it is, he who does the work gets to choose interfaces. > - Dan I'll qualify the starvation claim. Suppose we have five fds we are watching. Suppose one (let's call it "3") of them is really really intensive in it's request rate. Using the current interface (as used in the preliminary patch I sent), each time we call epoll we will see that 3 is active, but any time any other fd has anything to do, it will be handled. Suppose we go edge triggered now. We call epoll, and it's likely that 3 will be the only one active. We will call the 3 handling function, which will try to exhaust the requests arriving on 3 before returning. No it's a problem - requests potentially are never exhausted on 3. When do we exit the handler to do other stuff? We would need to write some mechanism to introduce this fairness ourselves. In short, if you are going edge trigger, your relative scheduling priority is your responsibility, as well as keeping all partial memory buffered. With level trigger, the kernel does that for you. Is there any reason to assume that we can do that better than the kernel? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 25, 2004

more debugger issues

by Chipzz

Hi all! As a saw a few updates to the debugger a couple of days ago, I decided to give the debugger another go. The problem with the stack trace is gone now, but now I get another problem when I attach to a running process, set a breakpoint and continue, the program crashes. When I in- stead don't set a breakpoint and continue, the program keeps running "fine": When setting the breakpoint: chipzz(a)Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000008 4 00000000 'H:\.wine-clean\win\dotnet.inst\install.exe' Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>bt Backtrace: =>1 0x40107b4b __read+0x4b in libc.so.6 (0x40307c54) 2 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x40307cf8) 3 0x401ca9dc vm86_return_end+0xc55 in ntdll (0x40307d1c) 4 0x40067678 (0x423bcc4c) 5 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x423bccf0) 6 0x401cc4e6 NtWaitForMultipleObjects+0x66 in ntdll (0x423bcd18) 7 0x404e25a5 WaitForMultipleObjectsEx+0xb5 in kernel32 (0x423bce48) 8 0x40cd54cc X11DRV_MsgWaitForMultipleObjectsEx+0x5c in x11drv (0x423bcf80) 9 0x408d9294 MsgWaitForMultipleObjectsEx+0x134 in user32 (0x423bd128) 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) 11 0x4163b91a (0x40915980) 12 0x7d8920ec (0x83e58955) fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) 13 0x8000:0x0000 (0x11b7:0x0800) 14 0x8000:0x0800 (0x11b7:0x0000) Wine-dbg>break MessageBoxA err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file ole32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file oleaut32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module msvcr80 fixme:dbghelp:symt_get_info Unsupported sym-tag SymTagPublicSymbol for get-type Many symbols with name 'MessageBoxA', choose the one you want (<cr> to abort): [1]: 0x408db030 MessageBoxA in user32 [2]: 0x40ad7760 MessageBoxA in shell32 [3]: 0x40107b00 __libc_read in libc.so.6 => 1 Breakpoint 1 at 0x408db030 MessageBoxA in user32 Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:11af GS:0000 EIP:4281009e ESP:423be038 EBP:423be0a4 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:77710800 EDX:00000000 ESI:00000000 EDI:000000a0 Stack dump: 0x423be038: 79655066 796fc52b 00000000 000000a0 0x423be048: 00000000 00000000 40340000 00000002 0x423be058: 00000034 404bec3f 00000007 423be084 0x423be068: 70a948ad 00000409 00000001 403b62f8 0x423be078: ffffffff 79670df4 ffffffff 423be0b8 0x423be088: 70a95755 00000001 354ae8a4 423be044 0235: sel=11af base=40306000 limit=00001fff 32-bit rw- Backtrace: =>1 0x4281009e (0x423be0a4) 2 0x796fc558 (0x423be0dc) 3 0x796fc705 (0x423be12c) 4 0x796fd494 (0x423be1d0) 5 0x00750073 (0x00690056) 6 0x00000000 (0x00000000) 0x4281009e: movl 0x40(%eax),%eax Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). ... etc. When not setting the breakpoint: chipzz(a)Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>c Also, ctrl-c doesn't work to stop the program being debugged. Wien version is wine CVS Aug 23. Any help is appreciated! kr, Chipzz AKA Jan Van Buggenhout PS: Please cc me as I'm not on the list. -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

Aug. 25, 2004

Re: poll vs. epoll

by Dan Kegel

Shachar Shemesh wrote: >> Now don't go and do level-triggered stuff just because it's easier :-) >> > That's not it at all, and edge vs. level is not part of my > considerations. Libevent does support a wider variety of selection > interfaces, and with wider platform support, than your library. Don't get me wrong. Libevent is good stuff. Niels is a very good guy. I don't think platform support is an issue (which platform do you need?) The one interface rn is missing, I think, is a timer. Buffered events would be a fine addition, too. But rn has the basic notification stuff; it was intended to focus on those. >> I don't think it's fair to say level-triggered is ideal for >> wineserver. In fact, wineserver is an example of the kind >> of program that is easier to convert to edge-triggering >> than most programs, since it's small and self-contained. > > Can you give benchmarks for performance differences between the two? The essential difference is that level-triggered means more notifications coming from kernel space, which always means higher overhead. The difference is going to be slight. I have also noticed that in some situations where the interest mask is hard to compute, using edge triggered is much easier, because you never have to compute it. > The more I think about it, the more I'm getting the impression that going > edge trigger means we need to maintain our own cache of not-yet-useful > data The same cache is maintained in the kernel for you if you use level triggering. > as well as risking starvation. There is no risk of starvation in a properly written program. > Also, can you show me how to do edge trigger via poll? There is no need for that, since Linux and *BSD all support some form of edge-triggered notification. However, if we want to support ancient operating systems, it wouldn't be too hard to add poll() support to rn under the covers, and present the edge-triggered interface to the user. > I'll qualify the starvation claim. > > Suppose we have five fds we are watching. Suppose one (let's call it > "3") of them is really really intensive in it's request rate. Using the > current interface (as used in the preliminary patch I sent), each time > we call epoll we will see that 3 is active, but any time any other fd > has anything to do, it will be handled. > > Suppose we go edge triggered now. We call epoll, and it's likely that 3 > will be the only one active. We will call the 3 handling function, which > will try to exhaust the requests arriving on 3 before returning. No it's > a problem - requests potentially are never exhausted on 3. When do we > exit the handler to do other stuff? We would need to write some > mechanism to introduce this fairness ourselves. Yes, but that's easy. It's about four lines of code. > In short, if you are going edge trigger, your relative scheduling > priority is your responsibility, as well as keeping all partial memory > buffered. With level trigger, the kernel does that for you. What's this about partial memory buffering? Sounds like you're inventing a difficulty here. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 25, 2004

Re: poll vs. epoll

by Dan Kegel

Shachar Shemesh wrote: > It doesn't compile (rn.c is not including <sys/epoll.h>). When I fix > that, it checks whether epoll_create works. If it does, it sets all > handlers to use sigio. I don't think this library is quite stable enough > :-) You're a tough customer :-) It's quite close; guess I should polish it up a bit. > In any case, it seems that it's interface is not ideal for wineserver. > Libevent, on the other hand...... Now don't go and do level-triggered stuff just because it's easier :-) I don't think it's fair to say level-triggered is ideal for wineserver. In fact, wineserver is an example of the kind of program that is easier to convert to edge-triggering than most programs, since it's small and self-contained. Sigh. I wish my wrists were in better shape; I'd convert it myself. As it is, he who does the work gets to choose interfaces. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 25, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Simon Kitching

On Fri, 2004-08-20 at 12:00, Simon Kitching wrote: > > > > Any suggestions on how to make progress on this issue are welcome. > > If a relay trace doesn't help, then the next thing would be to disas > > surrounding code at 0x004191fb and walk back the code flow to find out > > where the NULL %ecx was coming from. > > > I have some good news anyway. I still can't load the games I saved > earlier. But I tried starting a new game, and can load/save happily. So > the possibilities are: > (a) that the problem was caused by a corrupt save-file being *created* > when running with the debian wine release (Version: 0.0.20040615-1), and > that now I am running with wine CVS HEAD, games are being saved > properly. > (b) that there is a bug in HoI, and that the saved game wouldn't have > loaded on Windows anyway. I will test this theory soon by taking the > save-game to a friend with a Windows copy and see what happens. It would > be truly bad luck to strike an HoI bug the first time I try to run it > under Wine, but stranger things have happened. > (c) that the bug is wine-related, but only pops up sometimes. I can test > this by playing a lot more games, and seeing if it happens again. > > > So for now, I'm going to suspend the wine debugging, and do some more > playing instead :-) Just to end this thread, I have done some more "testing" :-) and the issue with being unable to load saved games has not reappeared. I still don't know which of the above theories was correct, but don't care now - it all "just works" (tm). Thanks for the cool software. Simon

Aug. 25, 2004

Hearts of Iron on Wine

by Simon Kitching

Hi All, I just wanted to let you all know that I have now given the game "Hearts of Iron" a good testing on Wine (no windows partition) and it works *extremely* well; only a few minor issues on startup, all with simple workarounds. I've submitted an entry to the app database for this. What is more interesting, though, is that the developer (Paradox Entertainment) and publisher (Strategy First) are releasing: (a) Hearts of Iron "Platinum Edition" in September 2004 (b) Hearts of Iron 2 in "Q4 2004/Q1 2005". As Wine runs HoI so very well, I thought it might be worth someone contacting Paradox to see if they would be willing to pay the Wine team for the final minor issues with HoI/wine to be resolved, and maybe to provide support for HoI 2 on Wine. Just a thought.... See: http://www.paradoxplaza.com/heartsofiron.asp http://www.paradoxplaza.com/heartsofiron2.asp http://www.gamespot.com/pc/strategy/heartsofiron/news_6103237.html Cheers, Simon

Aug. 25, 2004

Re: check box in group box regression

by Robert Reif

Zach Gorman wrote: >Does it matter whether the check box is before or after the group box in the >Z-order? Does the group box obscure any other controls? If you move the >check box so it is half-in and half-out of the group box, for example, does >only half of it get cut off? > >Zach > >-----Original Message----- >From: Robert Reif [mailto:reif(a)earthlink.net] >Sent: Tuesday, August 24, 2004 7:01 PM >To: Zach Gorman >Cc: wine-devel(a)winehq.org >Subject: Re: check box in group box regression > >Zach Gorman wrote: > > > >>Is this a general problem, or just in the hour.exe example? Is there source >>for hour.exe? >> >>Zach >> >>-----Original Message----- >>From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On >>Behalf Of Robert Reif >>Sent: Tuesday, August 24, 2004 8:02 AM >>To: Wine Develop >>Subject: check box in group box regression >> >>With current cvs, check boxes in group boxes are no longer displayed. >>See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html >> >> >> >> >> >> >> >It is a real problem that I was able to reproduce with a simple program. > >It's just a simple MFC program. I don't have the source with me now but >all it does is set the wait cursor in the check box callback, sleep for >5 seconds, >and then restore the cursor. The check box is inside a group box. I >can get it >tomorrow if needed. > > > > > > I just finished compiling cvs and the z order problem is fixed but the wait cursor doesn't change when you move it off the dialog.

Aug. 24, 2004

Re: check box in group box regression

by Robert Reif

Zach Gorman wrote: >Does it matter whether the check box is before or after the group box in the >Z-order? Does the group box obscure any other controls? If you move the >check box so it is half-in and half-out of the group box, for example, does >only half of it get cut off? > >Zach > >-----Original Message----- >From: Robert Reif [mailto:reif(a)earthlink.net] >Sent: Tuesday, August 24, 2004 7:01 PM >To: Zach Gorman >Cc: wine-devel(a)winehq.org >Subject: Re: check box in group box regression > >Zach Gorman wrote: > > > >>Is this a general problem, or just in the hour.exe example? Is there source >>for hour.exe? >> >>Zach >> >>-----Original Message----- >>From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On >>Behalf Of Robert Reif >>Sent: Tuesday, August 24, 2004 8:02 AM >>To: Wine Develop >>Subject: check box in group box regression >> >>With current cvs, check boxes in group boxes are no longer displayed. >>See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html >> >> >> >> >> >> >> >It is a real problem that I was able to reproduce with a simple program. > >It's just a simple MFC program. I don't have the source with me now but >all it does is set the wait cursor in the check box callback, sleep for >5 seconds, >and then restore the cursor. The check box is inside a group box. I >can get it >tomorrow if needed. > > > > The z order problem wasn't there 2 days ago.

Aug. 24, 2004

RE: check box in group box regression

by Zach Gorman

Does it matter whether the check box is before or after the group box in the Z-order? Does the group box obscure any other controls? If you move the check box so it is half-in and half-out of the group box, for example, does only half of it get cut off? Zach -----Original Message----- From: Robert Reif [mailto:reif(a)earthlink.net] Sent: Tuesday, August 24, 2004 7:01 PM To: Zach Gorman Cc: wine-devel(a)winehq.org Subject: Re: check box in group box regression Zach Gorman wrote: >Is this a general problem, or just in the hour.exe example? Is there source >for hour.exe? > >Zach > >-----Original Message----- >From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On >Behalf Of Robert Reif >Sent: Tuesday, August 24, 2004 8:02 AM >To: Wine Develop >Subject: check box in group box regression > >With current cvs, check boxes in group boxes are no longer displayed. >See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html > > > > > It is a real problem that I was able to reproduce with a simple program. It's just a simple MFC program. I don't have the source with me now but all it does is set the wait cursor in the check box callback, sleep for 5 seconds, and then restore the cursor. The check box is inside a group box. I can get it tomorrow if needed.

Aug. 24, 2004