wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

[WINETEST] How is a visible desktop detected
by Paul Vriens 28 Jan '05

28 Jan '05

Hi, I was just wondering. I have a Win98/WNT/W2K (on VMWare) and a XP Home system. All are running the winrash service. All were started when I was logged in but only the W98 and WNT were considered running on a visible desktop. What's the criteria for 'running on a visible desktop'? Cheer,s Paul.

2 2

Re: X11DRV: Fix to incorrect detection and other bugs of keyboard driver in XKB presence
by Alexandre Julliard 28 Jan '05

28 Jan '05

"Oleh R. Nykyforchyn" <nick(a)pu.if.ua> writes: > Add alternative (alpha) code to keyboard driver in x11drv that can handle > correct detection and switching of keyboard layout both with and without > XKB extension. Add temporary --enable-xkb feature to configure script > to enable compilation with new code instead of existing one. You really need to get rid of these #ifdefs. If the patch is not working well enough to be enabled by default it won't go in at all. Most likely you need to split it in smaller parts that can be tested and applied separately. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: translate name to locate program
by Alexandre Julliard 28 Jan '05

28 Jan '05

Michael Wu <flamingice(a)sourmilk.net> writes: > if (args) > { > - ret = msvcrt_spawn(flags, fullname, args, envs); > + if (SearchPathA(NULL, name, exeA, MAX_PATH, fullname, NULL)) > + ret = msvcrt_spawn(flags, fullname, args, envs); That doesn't look right, spawnve is not supposed to search the path. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: Re: [winecfg] Show detected audio systems, and offer selection
by Paul van Schayck 28 Jan '05

28 Jan '05

So in the end we will just keep it all the same for now? Or did I lost you all. Or do we want to follow Chris suggestion by offering a frontend to the driver load order list? Thanks, Paul

1 0

Re: [x11/keyboard] numpad 5 key
by Dmitry Timoshkov 28 Jan '05

28 Jan '05

"Oliver Stieber" <oliver_stieber(a)yahoo.co.uk> wrote: > This little patch sends a scancode through for the 5 > key when numlock isn't on. > > This is needed to fire cannons in pirates. > > I hope this is ok, a quick test showed that the > keydown was already sending a scancode, but it may be > wrong, this just fixes keyup and should be correct. > - VK_END, 0, VK_INSERT, VK_DELETE, > + VK_END, 0x0c, VK_INSERT, VK_DELETE, Running spy++ under Windows confirms that your patch is correct, you just need to use symbolic name VK_CLEAR instead of 0x0c. -- Dmitry.

1 0

RE: [d3d9] VertexDeclaration support
by Ann and Jason Edmeades 27 Jan '05

27 Jan '05

Hi Raphael, Get/SetRenderTarget in d3d9 cant be right - if has to go through wined3d, as it's the only person who knows the front/back buffer etc. You don't want This->renderTarget at all at the d3d9 level The same issue later, + if (NULL == pDeviceImpl->backBuffer) { + pDeviceImpl->backBuffer = d3dSurface; + pDeviceImpl->renderTarget = d3dSurface; Note in the call to IWineD3DDevice_CreateVertexDeclaration you passed through 9, I assume for the dx level, but we store that in the device or directx impl already (cant remember which). In the wined3d version: Also, in the wined3d version please, please try to avoid using tabs, and use spaces instead - the rest of the file does (unless I missed some as I transferred them). Tabs are a real pain to work with if you ask me Jason

2 1

Re: [ddraw] more video memory
by Oliver Stieber 27 Jan '05

27 Jan '05

--- Raphael <fenix(a)club-internet.fr> wrote: There's a couple of other places that report the amount of video memory, GetAvaialbleVideoMemory in d3d, and static DDHALINFO hal_info in X11ddraw.c Is there somewhere where we can centralise the possibly tracking of video memory and read the initial setting from either a configuration file or the video cards i2c or registers if available instead of hard coding in three+ different places? I've got some agpgart code for detecting AGP memory usage and the DRI guys will probably have code for getting the 'real' video memory figures for some cards. > Hi, > > Changelog: > - set default video memory to 64Mb (was 16Mb) as > many d3d9 demos use d3d7 > code to get available video memory size (ex > ConfigSystem.exe on d3d9 sdk) > > Todo: > - autodetect this value (better than hardcoded) and > share it using wined3d > > Regards, > Raphael > > Index: main.c > =================================================================== > RCS file: /home/wine/wine/dlls/ddraw/ddraw/main.c,v > retrieving revision 1.58 > diff -u -r1.58 main.c > --- main.c 9 Jan 2005 17:35:44 -0000 1.58 > +++ main.c 27 Jan 2005 00:22:42 -0000 > @@ -118,7 +118,7 @@ > /* This is for the moment here... */ > This->free_memory = free_memory; > This->allocate_memory = allocate_memory; > - This->total_vidmem = 16 * 1024 * 1024; > + This->total_vidmem = 64 * 1024 * 1024; > This->available_vidmem = This->total_vidmem; > > return DD_OK; > > ATTACHMENT part 2 application/pgp-signature ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 5

Re: video4linux - wine
by Rick Romero 27 Jan '05

27 Jan '05

Looks like Webcamnow.com has a simple Win32 app now. They're setup quite simply - They merely grab a pic, and ftp it to their servers. After install, I assume I'm getting the same errors you were, as it enumerates the webcam devices: fixme:avicap:capGetDriverDescriptionA (0, 0x411f1050, 255, 0x411f2ef0, 255) stub! fixme:avicap:capGetDriverDescriptionA (1, 0x411f1050, 255, 0x411f2ef0, 255) stub! You can get the webcamnow Win32 app by going to their site with Firefox or Mozilla, and clicking "Broadcast", then you'll download the win32 app. Rick Jasper van Veghel wrote: > I've recently been looking into VFW with Wine, and though I certainly am no > expert at the Windows API concerning this (first time I really looked into DX), > nor Wine for that matter, I was able to get a bit further from where I started, > so allow me to share my experiences with you. > As an application to test this stuff with I went for MSN 6.2, though certainly > not the best application for this, it seemed neat to finally have Webcam support > on MSN - I eventually got some of it working with a load of native DLLs, some > hacking on the SSL stuff (I ended up simply setting useSSL = false, the applica- > tion was sending plain-text over an SSL socket, which wasn't working; this fixed > things, or at least for this application ;-)) and adding some undocumented flag > to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using some- > thing along the lines of the following webcam class I found using Google - > indeed, using a DirectShow filter: > http://www.jolash.com/projects/other_projects/webcam/WebCam.h > For things to start working under Wine I used the following native DLLs, which > I also registered with regsvr32 (for CLSIDs etc.) > COMCTL32.DLL > urlmon.dll > CRYPT32.DLL MSOSS.DLL > oleaut32.dll ole32.dll rpcrt4.dll > MSVCRT.DLL > shlwapi.dll shdocvw.dll > MLANG.DLL > qcap.dll amstream.dll > Though I'm not sure if amstream is needed. Don't know what qcap does as I only > managed to get to a point where something in qcap was called which was then > being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of stubs > and semi-stubs (filled in some bogus information for VIDEO_STREAM_CONFIG_CAPS, > VIDEOINFOHEADER and AM_MEDIA_TYPE) > It turned out that, at least MSN, and this webcam class too, uses devenum to > find the video input devices (CLSID_VideoInputDeviceCategory), for which I've > added the proper code to CreateSpecialCategories and hence CreateClassEnumerator > (it also seems that the windows DLL of devenum always recreates the dynamic > registery entries whereas Wine only seems to add them once and then never again, > that is, once they're in the registry they stay there (hence if a new audio card > gets added to the system ..)) The Windows DLL seemed to be using avicap32 to > collect information on the available video input devices, so I've simply had > capGetDriverDescription return some string with a fictional video driver (this > also makes it possible to use a native devenum.dll) Next up is Quartz, which > seemed to want IAMStreamConfig (collecting information on the video stream (res, > depth, sps, ..) for starters, but I never got around to implementing enough of > that for the program to accept it and move on, so that's where I got stuck. It > may also have had something to do with MSN wanting an IKsPin which isn't imple- > mented (which is why native quartz may have failed, when trying to approach the > kernel in some way) Here's a small scenario of what I observed working with both > native and hacked up DLLs ;-) > DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID) > DEVENUM - BindToObject() --> VfwCapture > QCAP - BindToClass --> Quartz(VideoRenderer) > QUARTZ - VideoRenderer_create > QUARTZ - [FAIL] InputPin_QueryInterface (IKsPin) > QUARTS - VideoRenderer_QueryInterface (IAMStreamConfig) > Anyway, the 'patches' I wrote are probably not worth much as the whole under- > taking was more of a little endeavor trying to see how far I go (MSN actually > managed to sign in, by the way, but kept crashing a few seconds after that (the > webcam stuff can be accessed without signing in though, there's a preview option > in one of the menus), but perhaps this brief explanation of my steps will prove > useful for someone wanting to implement this aspect of VFW :-) Perhaps someone > could build a control from the class I mentioned earlier which can then be used > for testing (through the webpage that refers to it says it's missing some code; > but at least it's a starting point) > Jasper

1 0

Re: NtQuerySystemInformation: cpu information
by Oliver Stieber 27 Jan '05

27 Jan '05

I'll see if darwinia runs ok now, it fails witht a cannot detect CPU error. http://www.darwinia.co.uk/downloads/ --- Rein Klazes <wijn(a)wanadoo.nl> wrote: > Hi, > > Changelog: > dlls/ntdll : nt.c > include : winternl.h > > In NtQuerySystemInformation, handle request for > information > class 1, now named SystemCpuInformation. Return > some dummy > data for now. > > Rein. > > --- wine/dlls/ntdll/nt.c 2005-01-27 > 08:32:17.000000000 +0100 > +++ mywine/dlls/ntdll/nt.c 2005-01-27 > 13:52:32.000000000 +0100 > @@ -546,6 +546,22 @@ NTSTATUS WINAPI > NtQuerySystemInformation > else ret = STATUS_INFO_LENGTH_MISMATCH; > } > break; > + case SystemCpuInformation: > + { > + SYSTEM_CPU_INFORMATION* sci; > + sci = (SYSTEM_CPU_INFORMATION *) > SystemInformation; > + if (Length >= sizeof(*sci)) > + { > + /* FIXME: move some code from > kernel/cpu.c to process this */ > + sci->Architecture = > PROCESSOR_ARCHITECTURE_INTEL; > + sci->Level = 6; /* 686, aka Pentium > II+ */ > + sci->Revision = 0; > + sci->Reserved = 0; > + sci->FeatureSet = 0x1fff; > + } > + else ret = STATUS_INFO_LENGTH_MISMATCH; > + } > + break; > case SystemPerformanceInformation: > { > SYSTEM_PERFORMANCE_INFORMATION* spi = > (SYSTEM_PERFORMANCE_INFORMATION*)SystemInformation; > --- wine/include/winternl.h 2005-01-27 > 08:32:53.000000000 +0100 > +++ mywine/include/winternl.h 2005-01-27 > 13:54:11.000000000 +0100 > @@ -521,7 +521,7 @@ typedef enum _SECTION_INHERIT { > > typedef enum _SYSTEM_INFORMATION_CLASS { > SystemBasicInformation = 0, > - Unknown1, > + SystemCpuInformation = 1, > SystemPerformanceInformation = 2, > SystemTimeOfDayInformation = 3, /* was > SystemTimeInformation */ > Unknown4, > @@ -908,6 +908,35 @@ typedef struct > _SYSTEM_BASIC_INFORMATION > #endif > } SYSTEM_BASIC_INFORMATION, > *PSYSTEM_BASIC_INFORMATION; > > +/* CPU Information Class 0x01 */ > +typedef struct { > + WORD Architecture; > + WORD Level; > + WORD Revision; /* combination of CPU > model and stepping */ > + WORD Reserved; /* always zero */ > + DWORD FeatureSet; /* see bit flags below */ > +} SYSTEM_CPU_INFORMATION; > + > +/* definitions of bits in the Feature set for the > x86 processors */ > +#define CPU_FEATURE_VME 0x00000005 /* Virtual > 86 Mode Extensions */ > +#define CPU_FEATURE_TSC 0x00000002 /* Time > Stamp Counter available */ > +#define CPU_FEATURE_CMOV 0x00000008 /* > Conditional Move instruction*/ > +#define CPU_FEATURE_PGE 0x00000014 /* Page > table Entry Global bit */ > +#define CPU_FEATURE_PSE 0x00000024 /* Page > Size Extension */ > +#define CPU_FEATURE_MTRR 0x00000040 /* Memory > Type Range Registers */ > +#define CPU_FEATURE_CX8 0x00000080 /* Compare > and eXchange 8 byte instr. */ > +#define CPU_FEATURE_MMX 0x00000100 /* Multi > Media eXtensions */ > +#define CPU_FEATURE_X86 0x00000200 /* seems to > be alway ON, on the '86 */ > +#define CPU_FEATURE_PAT 0x00000400 /* Page > Attribute Table */ > +#define CPU_FEATURE_FXSR 0x00000800 /* FXSAVE > and FXSTORE instructions */ > +#define CPU_FEATURE_SEP 0x00001000 /* SYSENTER > and SYSEXIT instructions */ > +#define CPU_FEATURE_SSE 0x00002000 /* SSE > extenstions (ext. MMX) */ > +#define CPU_FEATURE_3DNOW 0x00008000 /* 3DNOW > instructions available > + (FIXME: > needs to be confirmed) */ > +#define CPU_FEATURE_SSE2 0x00010000 /* SSE2 > extensions (XMMI64) */ > +#define CPU_FEATURE_DS 0x00020000 /* Debug > Store */ > +#define CPU_FEATURE_HTT 0x00040000 /* Hyper > Threading Technology */ > + > /* System Information Class 0x15 */ > typedef struct { > ULONG CurrentSize; > ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

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

27 Jan '05

> So just keep the Audio tab and remove the autodetect button. Or keep > it all the same. But that would bring us back to the original > question. How should we handle multiple detected audio systems? > I think removing the auto detect would the best solution. If we store a list of drivers to autodetect in the registry we can search this list on wine startup for the first working one. Maybe winecfg can provide an interface to this list? Its probably not very likely that users will run multiple high level audio systems at the same time but this should let those users work around wine detecting and using the wrong one. Although as long as we can output sound through a given interface it isn't really the wrong interface... Chris

2 1

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

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

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

Re: Disable antialiasing in palette mode (updated)
by Jakob Eriksson 26 Jan '05

26 Jan '05

I'm just a peon but wouldn't it be better for the ReactOS project if you put the code in gdi instead? They have to solve it someplace else anyway, since they don't have x11drv. Glenn Wurster wrote: >This is an updated patch based on Alexandre's comments. It uses >GetObjectW instead of GDI_GetObjPtr. > >Description: > >According to the docs for CreateFont: > >"Windows 95 with Plus!, Windows 98/Me: The display must greater than >8-bit color, it must be a single plane device, it cannot be a palette >display, and it cannot be in a multiple display monitor setup. In >addition, you must select a TrueType font into a screen DC prior to >using it in a DIBSection, otherwise antialiasing does not happen." > >Windows 2000 has been tested and it also does not antialias fonts when >writing into an 8 bit DIB. > >This patch disables antialiasing when a palette is involved. You've >seen this before in previous incarnations. The docs specify to >disable antialiasing and I've got an application which depends on >antialiasing being disabled. I've tried putting the change in the gdi >code, as well as in the x11drv code. I think it looks cleaner in the >x11drv code (no change to function prototypes) so that's where this >attempts to put it (with the caching split off into a different patch >this time). > >Author: > * Glenn Wurster (gwurster(a)scs.carleton.ca) > >Changelog: > * Disable antialiasing of fonts while working in a palette. > >Index: dlls/x11drv/xrender.c >=================================================================== >RCS file: /home/wine/wine/dlls/x11drv/xrender.c,v >retrieving revision 1.56 >diff -u -r1.56 xrender.c >--- dlls/x11drv/xrender.c 24 Jan 2005 19:32:54 -0000 1.56 >+++ dlls/x11drv/xrender.c 26 Jan 2005 04:15:27 -0000 >@@ -1013,6 +1013,25 @@ > INT *deltas = NULL, char_extra; > HRGN saved_region = 0; > UINT align = GetTextAlign( hdc ); >+ BOOL disable_antialias = FALSE; >+ AA_Type antialias = AA_None; >+ >+ /* Do we need to disable antialiasing because of palette mode? */ >+ do { >+ HBITMAP hBitmap; >+ DIBSECTION bmp; >+ >+ hBitmap = GetCurrentObject( physDev->hdc, OBJ_BITMAP ); >+ if( GetObjectW( hBitmap, sizeof(bmp), &bmp ) != sizeof(bmp) ) { >+ TRACE("bitmap is not a DIB\n"); >+ break; >+ } >+ >+ if (bmp.dsBmih.biBitCount <= 8) { >+ TRACE("Disabling antialiasing\n"); >+ disable_antialias = TRUE; >+ } >+ } while (0); > > TRACE("%p, %d, %d, %08x, %p, %s, %d, %p)\n", hdc, x, y, flags, > lprect, debugstr_wn(wstr, count), count, lpDx); >@@ -1307,14 +1326,16 @@ > > EnterCriticalSection(&xrender_cs); > entry = glyphsetCache + physDev->xrender->cache_index; >- formatEntry = entry->format[entry->aa_default]; >+ if( disable_antialias == FALSE ) >+ antialias = entry->aa_default; >+ formatEntry = entry->format[antialias]; > > for(idx = 0; idx < count; idx++) { > if( !formatEntry ) { >- UploadGlyph(physDev, glyphs[idx], entry->aa_default); >- formatEntry = entry->format[entry->aa_default]; >+ UploadGlyph(physDev, glyphs[idx], antialias); >+ formatEntry = entry->format[antialias]; > } else if( glyphs[idx] >= formatEntry->nrealized || formatEntry->realized[glyphs[idx]] == FALSE) { >- UploadGlyph(physDev, glyphs[idx], entry->aa_default); >+ UploadGlyph(physDev, glyphs[idx], antialias); > } > } > assert(formatEntry); >@@ -1354,7 +1375,7 @@ > wine_tsx11_lock(); > XSetForeground( gdi_display, physDev->gc, textPixel ); > >- if(entry->aa_default == AA_None) { >+ if(antialias == AA_None) { > for(idx = 0; idx < count; idx++) { > SharpGlyphMono(physDev, physDev->org.x + x + xoff, > physDev->org.y + y + yoff, > >

2 1

Re: [winecfg] Show detected audio systems, and offer selection
by Rob Shearman 26 Jan '05

26 Jan '05

Paul van Schayck wrote: >Hey, > >Never thought a simple popup with a few radio boxes would be this hard... > > Instead of generating the dialog box manually, why don't you store it in a resource? It will then be easier to localise and should be easier to use. You could also disable the radio boxes of drivers that cannot be used instead of hiding them and then you wouldn't have to do complicated rearranging. Rob

3 3

Q GUIDS
by Oliver Stieber 26 Jan '05

26 Jan '05

Hi, I've had to generate some GUIDs for wined3d is there a wine policy on internal GUIDs or should the ones I've generated be ok. secondly, nothing to do with GUIDS, what's the 'best' thread safe IUnknown enumerate to use for storing a heap of unique elements that will be searched for by the IUnknown pointer as well as emerated. It would be usefull if the enumerate didn't reference count because I may also need to use a call back or sorts so that when the ref count of the IUnknown gets to zero it's release can tell the enumerate to remove it from the list. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 1

Re: PerformanceCounterFrequency fix.
by Lionel Ulmer 26 Jan '05

26 Jan '05

> --- wine/dlls/kernel/cpu.c 2004-12-29 12:09:47.000000000 +0100 > +++ mywine/dlls/kernel/cpu.c 2005-01-19 12:39:15.000000000 +0100 > @@ -188,7 +188,8 @@ BOOL WINAPI QueryPerformanceCounter(PLAR > /* i586 optimized version */ > __asm__ __volatile__ ( "rdtsc" > : "=a" (counter->u.LowPart), "=d" (counter->u.HighPart) ); > - counter->QuadPart = counter->QuadPart / 1000; /* see below */ > + /* see below */ > + counter->QuadPart = counter->QuadPart / ( cpuHz / 1193182 ) ; > return TRUE; > } > #endif Don't we loose some precision here or are we sure that all PC clocks are exact multiples of '1193182' ? Moreover, anyone has any idea how to do this without using RDTSC (which is a bad idea on most laptops and may well be on modern CPUs too if any implement the laptop-like power saving features) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 6

Inconsistent test visualization
by Paul Vriens 26 Jan '05

26 Jan '05

Hi, I just had a look at http://test.winehq.org/data/200501251000/. When you look at the main overview it shows that shlwapi:path has a yellow box (144) under Win98. If you however jump to the Win98 overview, there is no shlwapi:path? The same is true for shlwapi:clsid, winmm:capture, winmm:wave and maybe more? Any ideas, Paul.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2005