February 2001 - Wine-Devel - list.winehq.org

Speeding up wineserver syncronization objects with shared memory
by Gavriel State Feb. 15, 2001

Feb. 15, 2001

Hi everyone, We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. After some more thinking, Ove and I have come up with a mechanism that should eliminate most of the wineserver overhead for mutexes and semaphores, without the need to resort to a kernel module. We're probably going to give this a try over the next few days, so any feedback will be very much appreciated. Here's what we've been discussing in private email: ============================================================================================ Ove writes: > Gav writes: > > > Alternatively, I wonder if there's some way to speed up synchronization stuff > > through the use of some kind of shared memory area that all wine processes know > > about. The shared memory area could be used to do mutexes with atomic test-and- > > set operations. > > Maybe. But we probably don't want extensive busy waits, so we'd need to > call the wineserver when we need to wait. And the wineserver isn't really > designed to do bus-locked atomic access to such shared areas itself. But > perhaps with some client cooperation... in win32, a mutex is just a > different (and slower) kind of a critical section, anyway (but since it's > handle-based it can work across address spaces). > > If each mutex had a wcount field shared among all clients, we could do... > > ReleaseMutex: > wc = InterlockedDecrement(&wcount) > if wc > 0 > call wineserver's ReleaseMutex > > WaitForSingleObject: > wc = InterlockedIncrement(&wcount) > if wc < 0 > return WAIT_OBJECT_0 > call wineserver's WaitForSingleObject > > which would at least do something about the > ReleaseMutex/WaitForSingleObject pairs in the same thread... That's exactly the kind of thing I was thinking about. We can probably do the same for the CriticalSection semaphores as well. I don't think that we can do anything to speed up Events though. So the next question is: what's the best way to manage the shared area for each mutex/semaphore? We could just expose the wineserver handle table directly in the shared memory area, expanding the handle_entry struct in the server with a DWORD to server as the count field. Theoretically it brings up security concerns, but I don't think that we care that much at this point. ============================================================================================ Thoughts, anyone? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

RE: Documentation fixes
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > * dlls/winedos/dosvm.c, > > dlls/winedos/module.c: > > - Added documentation > > - Reorganized the no-DOS support. > > I don't think adding a #ifdef around each function is a good > idea. It's much more readable with a single #ifdef around the whole > file IMO. More readable to a human, perhaps. I'm not sure that I agree, but I don't really care much either way. Let me explain why I did it insteed. Currently winapi_check tried to check whether API functions have the correct inline documentation and the future some other application will generate the .spec files from inline documentation and function prototype. In order to be able to easily do this, it is IMHO much better if all the compile time depend variants is groups together in some standardized way in order for the tool to easily understand that variants exist and under what cirumstances they exist. But sure, we could easily add a kludge in both winapi_check and any future tools what just ignore any multiple occurance of an already documented function. It will be more errorprone but since this is quite rare perhaps it will not matter so much. Anyway, I don't really very much, so just say how want it: 1. Some way similar to mine (easily parsable structure) 2. Just kludge over this rare case (ignore multiple) 3. Some other way.

1 0

Re: VerQueryValue[A|W]
by James Hatheway Feb. 15, 2001

Feb. 15, 2001

> > To convert an ASCII string to Unicode, you can use the > > function HEAP_strdupAtoW, as in: > Wrong ;-) Yeah, I know, Huw already set me straight on that. ^_^ > HEAP_str* is deprecated (the header file says so). > Use MultiByteToWideChar() or WideCharToMultiByte() instead. I'll admit I wrote the email when my brain wasn't quite working (by def'n anytime after 1am), thought to myself "what is that API again?", did a quick search in WINE, said to myself "oh HEAP_strdupAtoW" sent a quick email and went to bed. :) That teaches me to send email without thinking. But that gets me to my point. HEAP_strdupAtoW is used in this capacity 78 times in the WINE source tree (WtoA another 182 times). We should probably change it sometime, since a lot of people who are writing new code are sure to use the current code base as an example of "how to do things". Out of curiosity, why are we killing these macros? They seem quite convenient. If it is because they aren't in standard windows headers, can't we put them somewhere in include/wine? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: New EnumPrinterDataEx
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Ian Pilcher <pilcher(a)concentric.net> writes: > In theory, yes. But what about the case of a mistake on my part (or > the part of the person who implemented the underlying call)? We all > do everything possible to produce error-free code, but mistakes *do* > happen. IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant. Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason. -- Alexandre Julliard julliard(a)winehq.com

2 1

VersionInfo for built-in DLLs
by Dmitry Timoshkov Feb. 15, 2001

Feb. 15, 2001

Hello all. This patch adds version information to the built-in GDI32.DLL. Attached test program now able to retrieve and display version information for both 32-bit and 16-bit modules. For instance "about.exe notepad.exe" will show information about 16-bit notepad, "about.exe gdi32.dll" - about built-in gdi32.dll. To do: Add 16-bit version information. Before I'll send it to wine-patches I would like to hear your comments and suggestions.

1 0

Re: VerQueryValue[A|W]
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

lawson_whitney(a)juno.com writes: > AOL 5.0 does this, so I guess it is allowed by some flavors of windows. > > ChangeLog: > * dlls/version/info.c: > Lawson Whitney <lawson_whitney(a)juno.com> > If VerQueryValueA is called with a PE resource, cast the call > to VerQueryValueW. Shouldn't you convert the lpSubBlock string to Unicode first? -- Alexandre Julliard julliard(a)winehq.com

4 5

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall wrote: > > > > One fly in the legal ointment is that while the headers may not be > > > copyrighable, the shrinkwrap license may still be legal > as a contract. > > > There's a case where a court suggested that someone who > buys a copy > > > of a product that contains a shrinkwrap license agreement > and unwraps > > > it is legally bound to follow it, while the person who > later finds the > > > unwrapped CD 'on the street' with no such license is > allowed to copy > > > the portions that are unprotected by copyright. > > > > If that is so, wouldn't it mean that if you have a pirated > copy of the > > headers > > you can legally copy and distribute parts that are > unprotected by copyright. > > :-) > > > > Oh, the irony of it all. You don't need to use a pirated copy either just borrow a friends computer that has the headers legally installed and copy any part unprotected by copyright. Any "contract" can only bind him. :-)

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> One fly in the legal ointment is that while the headers may not be > copyrighable, the shrinkwrap license may still be legal as a contract. > There's a case where a court suggested that someone who buys a copy > of a product that contains a shrinkwrap license agreement and unwraps > it is legally bound to follow it, while the person who later finds the > unwrapped CD 'on the street' with no such license is allowed to copy > the portions that are unprotected by copyright. If that is so, wouldn't it mean that if you have a pirated copy of the headers you can legally copy and distribute parts that are unprotected by copyright. :-) Anyway, you don't need to go to such extremes, since the legal status of shrinkwrap licenses in Europe is much more doubtful, just have somebody in Europe do it. I can't see why something posted on wine-patches shouldn't be equal with found on the street, in the meaning that things that is unprotected by copyright can be legally incorperated in the main tree. This is probably true regardless of the legal status of shrinkwrap licenses in Europe, especially since it is IMHO entire reasonable, given existing European cases, to assume that they don't have an legally meaning. > It's unclear where > the anti-trust issue fits in there. I pass, not my area of expertize. :-) > Food for thought, anyhow... Yes.

3 2

Re: process.h patch
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > Until we have MS style headers, at least declare msvcrt functions extern "C" > so C++ Winelib programs will link. > > I didn't get any feedback to my headers patch. Alexandre, what do I need > to do to get some headers into CVS? Or is that not the plan? Well, I don't know, I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David. -- Alexandre Julliard julliard(a)winehq.com

6 7

Re: Re: recording sound?
by Eric Pouech Feb. 15, 2001

Feb. 15, 2001

>winmm wave recording is supposed to be supported, at least at the >low-level wave API level. Maybe less so at the MCI level, though, support at the MCI level should be more or less ok... (at least the Macadamiam folks did a great effort there) >and not >supported at all yet in the DirectSound layer. What kind of API does it >use to record these sounds? You don't say what kind of app it is... post the output of runnnig with the -debugmsg +wave,+mciwave,+dsound would help us pinpointing the issue A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

4 7