January 2005 - Wine-devel - list.winehq.org

Re: [winecfg] Show detected audio systems, and offer selection
by Mike Hearn 27 Jan '05

27 Jan '05

On Wed, 26 Jan 2005 15:21:28 +0100, Paul van Schayck wrote: > Never thought a simple popup with a few radio boxes would be this hard... Welcome to Win32 :( > Changelog: > Show the detected audio systems in a popup dialog and offer selection. I don't think we want to do this, to be honest. The idea for a while has been to just delete that tab entirely and have the driver detected at runtime automatically. An attempt was made before but Alexandre wasn't happy with it. That's what we need to do, rather ask the user questions they shouldn't need to care about. thanks -mike

4 8

configure warning report
by Jean Cardona 27 Jan '05

27 Jan '05

configure: WARNING: sys/sysctl.h: present but cannot be compiled configure: WARNING: sys/sysctl.h: check for missing prerequisite headers? configure: WARNING: sys/sysctl.h: see the Autoconf documentation configure: WARNING: sys/sysctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/sysctl.h: proceeding with the preprocessor's result configure: WARNING: sys/sysctl.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ##

1 0

MSRPC / FreeDCE interoperability of non-encapsulated onions.
by Luke Kenneth Casson Leighton 27 Jan '05

27 Jan '05

On Thu, Jan 27, 2005 at 10:38:41AM +0000, Luke Kenneth Casson Leighton wrote: > > Also, I don't believe your other comment about switch_is is correct. AFAIK > > MIDL does use the size of the member / parameter used in switch_is for > > the descriminant size (although I'm not sure how an expression within > > switch_is would affect the size). Perhaps switch_type was also used? > > DCE/RPC idl absolutely _must_ have a switch_type explicitly > specified and yes, a switch_type of "long" was used. > > ironically, MIDL truncates that to a short when INTERNALLY doing case > statements to determine what structure member is being decoded in the > non-encapsulated union. > > yet _more_ ironically, there is evidence that it STILL allows the > full 32-bits to be marshalled up to the caller - thus presenting > the users with a 32-bit switch_is parameter, the top 16-bits of which > is total garbage off of some uninitialised area of memory. > > oops! okay - it's confirmed. i'm cc'ing this to the wine-devel list because they too are implementing MSRPC, and whilst it may not appear to be relevant for on-wire interoperability (which they are _not_ working towards in their implementation of rpcrt4.dll) it _may_ turn out to be relevant for application interoperability. michael, if you're in contact with the samba team, perhaps you could relay this to them because they have set up some fascist censorship where i cannot post to any addresses at samba.org. okay. you're not going to believe it, or like it, but i can only guess it must be something to do with "default" behaviour that microsoft added to MIDL. *sigh*. what i am _guessing_ is that microsoft considered it silly to force people to specify switch_type on parameters, so i'm _guessing_ that they allowed a "default" of a 16-bit value (short). ... and then forgot to automatically "increase" that to 32-bit if the switch_is on a non-encapsulated union was actually a long. consequently, ha ha, there are circumstances under which the first 16 bits of a 32-bit switch value is placed on-wire just before the non-encapsulated union is, and the remaining 16 bits is filled with garbage due to alignment of the non-encapsulated union. _but_, the data structure _containing_ the item using the switch is of course marshalled correctly: the switch item receives the full 32-bits, 16 of which is garbage. consequently, applications may _expect_ that garbage to be there - certainly the application that i am exploring will fail if you don't notify it of the full 32-bits of the switch value - including the garbage - in further function calls (!) yet when i do pretty-printing of the data structures received off-of-wire, i must still typecast the 32-bits to 16 in order to do my switch statement!! there aren't any case statements of 0xffef001e _that's_ for sure, it's actually 0x1e which is a STRING. god, i love microsoft interoperability, it's such a hoot. l.

1 0

Re: PerformanceCounterFrequency fix
by Michael Ost 27 Jan '05

27 Jan '05

On Tue, 2005-01-25 at 14:05, wine-devel-request(a)winehq.org wrote: > Message: 1 > Date: Tue, 25 Jan 2005 19:30:04 +0100 > From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> > To: Rein Klazes <wijn(a)wanadoo.nl> > Cc: Lionel Ulmer <lionel.ulmer(a)free.fr>, wine-patches(a)winehq.com, > wine-devel(a)winehq.org > Subject: Re: PerformanceCounterFrequency fix. > > Hi, > > On Tue, Jan 25, 2005 at 06:44:04PM +0100, Rein Klazes wrote: > > On Mon, 24 Jan 2005 15:08:56 +0100, you wrote: > > > > > > How bad is it to use the gettimeofday() method? > > > > > > In my opinion, the RTDSC method should be suppressed from the code and we > > > should always use the 'gettimeofday' method (despite the penalty hit of a > > > syscall). > > > > I was more concerned about the accuracy of gettimeofday (not > > incrementing in usec's). So I did a small test and I find it behaves > > very nicely. > > > > That was the only reason I could see to justify the rdtsc method, so > > here it goes. As the cpuHz variable is not used anymore, we might as > > well move it to ntdll. > (sorry for not replying earlier - no time :-\) > I'm not sure why you'd want to base it on gettimeofday(). > This is a terrible idea IMHO. > I'm quite certain that many programs use that function for extremely time critical code > (games, anyone??), and that thus the Windows function is equally highly optimized, > certainly much less slow than a gettimeofday() call. > > This should remain based on rdtsc IMHO, or on equally suitable and fast methods > (ACPI counter, ...). > > Or did you actually test it with programs calling it a large number of times, > or test its performance behaviour on Windows? > > Andreas Mohr Our system uses the performance counter all the time in extremely time critical code. If the call is anything more than a few cycles with absolutely no chance of blocking, we are hosed! The application is an embedded audio plugin player. The audio is processed with SCHED_FIFO and needs to be as deterministic and fast as possible. I hope this fix/change doesn't jeopardize our product's use of Wine... mo =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

3 4

Re: shdocvw: properly implement DllCanUnloadNow
by jacek 26 Jan '05

26 Jan '05

> HRESULT WINAPI SHDOCVW_DllCanUnloadNow(void) > { > - FIXME("(void): stub\n"); > - > - return S_FALSE; > + return SHDOCVW_refCount != 0 ? S_FALSE : S_OK; > } I think you should try to call Mozilla's DllCanUnloadNow before returning S_OK. Your patch may cause unload of mozilla while some instances of IWebBrowser still exist.

1 0

NPTL and Wine threads
by Luke Kenneth Casson Leighton 26 Jan '05

26 Jan '05

it's come to my attention that NPTL cannot cope with jumping out of a cancellation handler. i thought you might like to be made aware of this in case you weren't already because this has been discovered to have an impact on the way that FreeDCE operates. there is some code in FreeDCE which expects to be able to jump out of a cancellation handler: i noticed in the "exception" comments that whilst it is not okay to do a "goto" from inside a TRY block, it says it's okay to do that in the EXCEPT block. you may wish to double-check this when running Wine under NPTL, and if it doesn't work please bitch like hell at the designers of NPTL for me because it's needed for FreeDCE as well. ta, l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

more d3d9
by Oliver Stieber 26 Jan '05

26 Jan '05

Hi, I've been tinkering for a week or so and D3d9 is almost their (well except for shaders) Along with Pirates I can now run Axis and Alies and Myst4 is looking promising Most of the demos from here http://www.codesampler.com/dx9src.htm Swap Chains only runs in one window, Shadow Volume is still a very flaky and some of the textures have strange offsets, but everything runs. Apart from the slightly bad texture offsets wine should be able to run more DirectX 9 applications than Cedega if only I could get them installed! I'm going to do some more debugging, cleaning up and post some screenshots on a web site and start sending patches against head (in smaller chunks that the last lot!) ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 1

Re: Does wine have a posix threads "emulation" with which TRY/EXCEPT/CATCH will work?
by Luke Kenneth Casson Leighton 26 Jan '05

26 Jan '05

thank you rob. i'm attaching some example code - it's from client/perf.c. after looking at these closely, i believe it would be straightforward to #define CATCH to __EXCEPT etc. and to rewrite the FreeDCE __EXCEPT argument as a function rather than a structure. dcethreads provides a CATCH macro - you are expected to provide a catcher for _one_ particular exception type. you're expected to roll these one after another: the macro expands to "} else if exc_matches(...) { " basically, i think the way that the Wine code does it, the CATCH possibilities are "rolled" into one EXCEPT - is that correct? or can you do more than one EXCEPT (even if the function says "i accept more than one type of exception - visa _or_ marstercaaard") so if the FreeDCE CATCH exceptions were turned into EXCEPT-style functions, on a "#ifdef / ./configure --with-wine-exceptions" basis, i think that'd work. this raises a further question, which i apologise for not being able to work out from looking at the macros. is it possible to do this: __TRY { /* do something horrible */ } __EXCEPT(exception_1) { printf("this is exception 1\n"); } __EXCEPT(exception_2) { printf("this is exception 1\n"); } ENDTRY secondary question: does Wine's exception handling cope with "stacked" exceptions and "fall-through"? if there are "nested" __TRY / __EXCEPT blocks, and an exception is not covered by the "inner" exception handlers, will it go through to the "outer" ones? ta rob. l. On Wed, Jan 26, 2005 at 03:11:36PM -0600, Robert Shearman wrote: > Luke Kenneth Casson Leighton wrote: > > >hi, > > > >i would like to check something which, if it is the case, > >may make porting FreeDCE to wine a no-brainer. > > > >i notice that there exists pthread emulation in Wine: it > >says so at the top of wine/dlls/kernel/pthread.c > > > >can i therefore expect the following things: > > > >1) the attached test program to compile and work under wine, > >with a few macros and/or simple wrapper functions e.g. redirect > >RAISE to RaiseException? > > > >2) a program that uses posix threads to also at the same time > >be able to use Wine Exception routines/macros, try/except/catch? > > > > > >... wouldn't it be ironic if Wine's pthreads emulation turned > >out to provide exactly the posix draft 4 threading semantics > >that FreeDCE programs expect? > > > >l. > > > > > > No, that program won't compile or run. > Windows exception handling (SEH) requires you to have an exception > filter function so that you don't get, say, a STATUS_ACCESS_VIOLATION > exception when you are expecting an RPC_E_DISCONNECT exception. > > You can see an example of Wine exception handling here: > http://cvs.winehq.org/cvsweb/wine/dlls/user/lstr.c?rev=1.31&content-type=te… > > Rob -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Does wine have a posix threads "emulation" with which TRY/EXCEPT/CATCH will work?
by Luke Kenneth Casson Leighton 26 Jan '05

26 Jan '05

hi, i would like to check something which, if it is the case, may make porting FreeDCE to wine a no-brainer. i notice that there exists pthread emulation in Wine: it says so at the top of wine/dlls/kernel/pthread.c can i therefore expect the following things: 1) the attached test program to compile and work under wine, with a few macros and/or simple wrapper functions e.g. redirect RAISE to RaiseException? 2) a program that uses posix threads to also at the same time be able to use Wine Exception routines/macros, try/except/catch? ... wouldn't it be ironic if Wine's pthreads emulation turned out to provide exactly the posix draft 4 threading semantics that FreeDCE programs expect? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Re: [OLE #50] IRemUnknown Proxy/Stub Implementation
by Vincent Béron 26 Jan '05

26 Jan '05

Le mar 25/01/2005 à 11:51, Robert Shearman a écrit : > Hi, > > This time without alloca. > > Rob > > Changelog: > Proxies/stubs for IRemUnknown methods, based on code written by Ove Kåven. > ---- > > diff -u -p -N -r -x '*~' -x '.#*' -x CVS -x Makefile -x '*.o' -x '*.spec.def' dlls/ole32_49/oleproxy.c dlls/ole32/oleproxy.c > --- dlls/ole32_49/oleproxy.c 2005-01-24 16:12:03.000000000 -0600 > +++ dlls/ole32/oleproxy.c 2005-01-25 10:47:23.011171080 -0600 > @@ -2,6 +2,7 @@ > * OLE32 proxy/stub handler > * > * Copyright 2002 Marcus Meissner > + * Copyright 2001 Ove KÃ¥ven, TransGaming Technologies Not sure we want UTF-8 in the source files... At least we don't have it (yet). Vincent

4 5