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

Re: GetSecurityInfo stub replacement
by Steven Edwards 25 Aug '04

25 Aug '04

Hi, --- Evan Deaubl <wine(a)warpedview.com> wrote: > Well, this has been a humbling experience. :-S Let's see if these > patches finally come out right. > + FIXME("stub!\n"); > + return ERROR_BAD_PROVIDER; In the FIXME message you should print the values of the params being passed to the function. Look at how other stubs are implemented. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0

Get rid of W->A calls : help me help ?
by Joris Huizer 25 Aug '04

25 Aug '04

Hello, I'm thinking of trying to do some helpfull work on wine; I have the following problem, - I don't know where to start (I have never done stuff in wine or another open source project) ; but I hope you have patience to guide me into that (but I'm a informatica student, I like learning stuff like htis ;) ) - I don't know the details about Unicode functions; I think the W->A thing of the janitorial might be a great way to start working in wine code; as it doesn't require too much overview about the way wine does its work I think.. (and I don't yet have much of that overview..) About a month ago, I saw a thread, including an interesting patch, about the W->A calls; Could someone find that link? Are there tutorials/manuals/guides/... about Unicode funcitons you recommend ? Now, on to the work: if you can hand me that thread, how do I start? Are there unit tests? Where should I put tests ..? How do I run the tests? Thanks for any help -- I hope it's not too much trouble to answer these questions! Oh.. and if the W->A thing is already covered.. is there some other area where a starter like me could start? regards, Joris

4 5

Re: poll vs. epoll
by Dan Kegel 25 Aug '04

25 Aug '04

Shachar wrote: > I noticed that in server/fd.c, the wineserver is using "poll" to select > between file descriptors. The application is going through this code > over 2000 times a second, with over 380 file descriptors each time. I am > wondering whether this can be the cause of the slowdown. > > One of the possible solutions to this would be to use epoll instead. > This, of course, would have to be backed by a configure check, as not > all systems for which wine is intended support epoll. Another, arguably > better, solution would be to use libevent for this purpose. Libevent has > the distinct advantage that it automatically chooses the best tool for > the job (epoll, poll, /dev/poll, or if all else fails, select). By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. Compile time detection is insufficient. My code is at http://kegel.com/rn If you actually try to use it, let me know. I expect it might be useful mostly as a guide. It's edge-trigger oriented, but you can trivially add the flag (or remove the flag) needed to get level-triggered behavior again if you really need it. I highly recommend using edge-triggered behavior, though. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 10

USB?
by Alex Zeiger 25 Aug '04

25 Aug '04

I'm interested in possibly working on USB support for Wine. I'm not particularly familiar with USB programming, but I'm fluent in C and C++. Where do I start?

6 7

RE: iostream and msvcrt?
by Scott Snell 25 Aug '04

25 Aug '04

Hi Boaz, Have been off the case for a few days. Is it possible for you to post a copy of your stl_wine.h, stlcomp.h and makefile? I seem to be missing something as I cant get it to work. thanks, Scott. > -----Original Message----- > From: Boaz Harrosh [SMTP:boaz(a)hishome.net] > Sent: Sunday, 22 August 2004 22:18 > To: Scott Snell > Cc: Dimitrie O. Paun; Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > You need to have your stlport/config/stl_wine.h (I based mine on > stl_mycomp.h, not stl_gcc.h) and change /stlport/config/stlcomp.h to > include it (based on a WINE_GCC flag). You need to do that because of > the way STLPort works with headers. you must put a path that will > Definitely select wine/msvcrt as the source of stdc. I used ../msvcrt in > the header and than Just fixed up the -I list in makefiles (and the > WINE_GCC flag or is there a flag that is defined by wingcc). > > Free Life > Boaz >

1 0

CryptSetProviderExA fix
by James Hawkins 25 Aug '04

25 Aug '04

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

1 0

Info on debugging requested: trying to run "Hearts of Iron"
by Simon Kitching 24 Aug '04

24 Aug '04

Hi, I recently tried to run the MS-Windows WWII strategy game "Hearts of Iron" using Wine on Linux. And it *very nearly* works. In fact, it's so close I'm trying to debug the problem in the hope of getting it working. I hope that someone here can give me a few wine debugging tips. Actually, the game runs perfectly - absolutely "gold" standard. I gave it a 5-hour "stress test" ;-) and did not experience a single problem. There are some minor problems on startup, but there are reasonable workarounds for those. The problem, though, is that saved games cannot be loaded. Unfortunately, this is a show-stopper as a game of HoI typically takes several days to play! Fortunately the problem is 100% repeatable. FYI: I'm running Debian Sarge on x86, no native windows partition. I first tried the latest debian wine package, and then rebuilt from CVS HEAD code of Fri 13 August (possibly a bad day to choose :-). Exactly the same behaviour occurred. Info on the game can be found here: http://www.heartsofiron-game.com/. It's a WWII strategy game with pleasant but not intensive graphics. When running "wine HoI.exe" and trying to load a saved game, a message is output: wine: Unhandled exception (thread 0009), starting debugger.. Usage: winedbg [--auto] [--gdb] comdline There is then no response to the keyboard; no debugger prompt or anything. Is this meant to start a debugger interactive session here, or am I supposed to somehow start a debugger and point it at the wine process? If so, info on how to do so would be appreciated. I ran "winedbg HoI.exe" and got exactly the same behaviour, though with a bit more info: <output> First chance exception: page fault on read access to 0x00000006 in 32-bit code (0x004191fb). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 - RIP1) EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44 ESI:418736c0 EDI:45ae16e3 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 0x004191fb (0x406bfe94) 2 0x005af5b2 (0x406bff20) 3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x406bfff4) 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x004191fb: movl 0x6(%ecx),%ecx Wine-dbg> </output> Qn: is there any way of getting function names in that backtrace rather than just addresses? I've tried "CFLAGS=-g ./configure" when rebuilding wine, but haven't had time to test the resulting wine binaries. And then is there a way to step through at the source rather than assembly level? It's apparent here that %ecx is null when not expected to be, resulting in a bad access to memory address 0x00000006. I also tried the "WINEDEBUG=+relay" option as recommended in the wine docs. However after leaving the program running overnight, and having generated 3 gigabytes of log output, the point where the bug occurs hadn't been reached. I think that what's happening is that there is a thread (0011) which is driven by timer ticks [probably doing GUI or sound stuff], and that because HoI is running much more slowly under +relay, that the thread doing the load-game work (0009) isn't actually getting any CPU time at all. NB: the log was only 3GB because I used grep to discard output about RtlEnterCriticalSection and RtlLeaveCriticalSection. Without that, the log would be closer to 30GB! Any suggestions on how to make progress on this issue are welcome. Pointers to documentation on debugging this sort of thing are very welcome. By the way, I'm an experienced c/c++ developer on unix/linux, but know very little about Windows programming (and frankly would prefer to leave it that way :-). It's been a while since I've used gdb and friends, but can brush up on that if it's useful. Cheers, Simon PS: Congrats to the Wine team. I was most impressed how well HoI ran on wine.

4 6

Hearts of Iron on Wine
by Simon Kitching 24 Aug '04

24 Aug '04

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

1 0

check box in group box regression
by Robert Reif 24 Aug '04

24 Aug '04

With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html

2 5

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
by Alexander Yaworsky 24 Aug '04

24 Aug '04

Hello In fact, the existing implementation of service subsystem in advapi32 is very poor and is sufficient only for very simple services or test programs. I tried to launch oracle 7 database under wine and that trial has been failed. The main problem was inability of parameter passing. Not only oracle -- most services require that. I did some improvements. Although I still cannot start database, because its launcher, oradim, requires CreateRemoteThread, the listener service works well (although, it cannot be fully tested because no database instance exists, but there is nothing suspicious in trace logs). I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Also, maybe the diagram shown below will be useful. Thanks. This simplified diagram shows interaction between three main components of win32 service subsystem. Service Control | Service Control Manager | Service Program Program | | ----------------+-----------------------------+----------------------------- | | StartService-----> LockServiceDatabase | | IF OWN_PROCES or | | (SHARE_PROCESS and Service | Program is not running)| | THEN | | | | CreateProcess===============> ... | wait for call to | initialization | StartServiceCtrlDispatcher| must not be longer | timeout=30s | than 30 seconds | | ... | if wait timed out then | ... | TerminateProcess | ... failure <---- UnlockServiceDatabase | ... | | ... | wait satisfied <============= StartServiceCtrlDispatcher | | | END IF | | | | CreateThread ***************> ServiceMain | (or CreateRemoteThread | ... | for SHARE_PROCESS; | * | if SHARE_PROCESS then | * | find entry in service | ********************** | table by service name; | * | if OWN_PROCESS then use | * | first entry) | * success <---- UnlockServiceDatabase | * | | * | accept control requests | * | | * ControlService---> request accepted ===========> ServiceControlHandler * | | ... * status <----- return status <============== SetServiceStatus * | | * | | * | | ********************** | | * | | ... | | SetServiceStatus | ExitThread <***************** (STOPPED) | if Service Program has | | now only one thread | | return control from | | StartServiceCtrlDispatcher==> ... | | ExitProcess legend: --- Service Control Program's thread === Service Program's main thread (control thread) *** Service Program's service thread OWN_PROCESS == SERVICE_WIN32_OWN_PROCESS SHARE_PROCESS == SERVICE_WIN32_SHARE_PROCESS Implementation. completely win32-based Two basic things: a) The only time the service control manager requests ownership of the lock is when it is starting a service. (C) M$DN; b) When StartService creates a new service process, it must pass arguments, or at least argv[0] - the service name - for ServiceMain across process boundary. So, use the existence of shared memory object as lock indicator and the content of object for passing service name. Also we need a wait object for monitoring process startup. The call to StartServiceCtrlDispatcher will satisfy wait condition. A dedicated shared memory object is used for each service thread. It holds other arguments, control requests and status. Also we need mutex object for serialization of control requests and two wait objects for serialization of service control program thread and service control handler thread.

4 4