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

[WINETEST] How is a visible desktop detected
by Paul Vriens Jan. 28, 2005

Jan. 28, 2005

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 Jan. 28, 2005

Jan. 28, 2005

"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 Jan. 28, 2005

Jan. 28, 2005

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 Jan. 28, 2005

Jan. 28, 2005

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 Jan. 27, 2005

Jan. 27, 2005

"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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

--- 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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

> 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

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

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 27, 2005

Jan. 27, 2005

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 Jan. 26, 2005

Jan. 26, 2005

> 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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

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 Jan. 26, 2005

Jan. 26, 2005

> --- 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 Jan. 26, 2005

Jan. 26, 2005

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

Re: Oracle - unixODBC - wine - Win32 ODBC Apple [Virus checked]
by Bill Medland Jan. 25, 2005

Jan. 25, 2005

On January 25, 2005 08:03 am, Martin HEIN wrote: > Bill, > > I just upgraded to the most recent version of CrossOver Office 4.1 > Professional, a nightly build as of January 25th, 2005, and wine > reports version 20050111. (upgraded from Crossover Office 20040716) So do the "trace:odbc:....." messages display now? (Anyone at Codeweavers - Does Crossover disable the traces?) > > Furthermore I created a symbolic link from /usr/local/etc/odbcinst.ini > to /etc/odbcinst.ini, and from /usr/local/etc/odbc.ini to > /etc/odbc.ini. Shouldn't matter > > Then I added my DSN (KMPA) to the registry > HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.ini, just as statet at the > unixODBC home page, actually they are quoting you! :) My entries are: > > Driver REG_SZ "unixODBC" > User REG_SZ "" > Password REG_SZ "" > Did I mention the USer and Password? It was so long ago I don't remember. Currently there is now code in the builtin odbc32.dll that attempts to replicate the unixODBC DSN information into the registry, but it may not do enough. > But when running ODBCTE32.exe I still couldn't connect to my database. As I said, that was because that exe seems to require the new "Wide" functions. It isn't going to work until the patch submitted is accepted (or rejected and a different one accepted) > Another test was running Crystal Reports 8.0 which didn't result in a > successful connection either. >From your other email I understand that it managed to do quite a bit, just not everything. What error messages? > > - Martin > > -------------------------------------------------- > T-Mobile Austria GmbH > Ing.Martin HEIN > Information Technologies / Services > Knowledge Management & Process Automation / Senior Manager > > Rennweg 97-99 > A-1030 Vienna > Fon: +43-1-79585-6337 > Fax: +43-1-79585-6584 > Mobile: +43-676-82006337 > E-Mail: Martin.HEIN(a)T-Mobile.at > Web: http://www.T-Mobile.at > -------------------------------------------------- > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you have > received this email in error please notify the sender immediately and > delete this email from your system without copying or disseminating it > or placing any reliance upon its contents. > -------------------------------------------------- -- Bill Medland Programmer ACCPAC International, Inc. bill.medland(a)BestSoftware.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

3 2

Resend: [wined3d] more vertex declaration work
by Raphael Jan. 25, 2005

Jan. 25, 2005

Hi, I resend it (resync from current cvs) as i haven't been commited yet Regards, Raphael > > Changelog: > - VertexDeclaration device APIs > - D3D9 declarations parsing > - a little better APIs (trying to avoid compil problems) > > Todo: > - D3D8 declarations parsing (converting to d3d9 compatible using code in > d3d8) > - find a more cleaner prototype for CreateVertexDeclaration/GetDeclaration > APIs > - Use on drawing paths (implement StriddedFillFromDeclaration) > - use on d3d9 code > > Regards, > Raphael

4 6

Re: Oracle - unixODBC - wine - Win32 ODBC Apple [Virus checked]
by Bill Medland Jan. 25, 2005

Jan. 25, 2005

On January 25, 2005 06:40 am, you wrote: > Bill, > > To verify an ODBC connection from a Windows-based application I'm using > 'odbct32w.exe' and 'odbcte32.exe', both from the Microsoft MDAC 2.8 > SDK. The former crashes (see attached log), the latter runs fine except > it doesn't display my unixODBC DSNs, nor can't it connect to one of the > DSNs when entered manually. > > On 24. J� 2005, at 15:29, Bill Medland wrote: > > presume you are running a program called myprog.exe from the command > > line. > > You type, at the command line, > > export WINEDEBUG=odbc > > wine myprog.exe 2>odbc.log > > and when you are finished the file "odbc.log" is empty, or contains no > > information about odbc? In particular you have no > > trace:odbc:DllMain Initializing or Finalizing proxy ODBC > > odbct32w.exe generates: Aha (There is still no indication that you are doing the WINEDEBUG; what version of Wine are you running?) I see that the program, is calling SQLDataSourcesW, the "Wide" version of SQLDataSources. That is currently not implemented. I see a patch went in for it on 24 January but I don't know when or if it will be accepted. So it is quite possible that the actual program will work if it is based on the "standard" SQL functions. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

3 2

[Janitorial] Interlocked* cleanup completed
by Paul Vriens Jan. 25, 2005

Jan. 25, 2005

Hi, If there are not objections I'll send the attached patch to wine-patches. Changelog The Interlocked cleanup is completed. Cheers, Paul.

1 0

Re: PerformanceCounterFrequency fix.
by Mike Hearn Jan. 25, 2005

Jan. 25, 2005

On Tue, 25 Jan 2005 19:30:04 +0100, Andreas Mohr wrote: > and that thus the Windows function is equally highly optimized, > certainly much less slow than a gettimeofday() call. These days gettimeofday() is very fast because the kernel vDSO system is used to optimize the syscall overhead. thanks -mike

1 0

No new tests since 01/15/2005 ?
by Paul Vriens Jan. 25, 2005

Jan. 25, 2005

Hi, I have no idea if something is wrong but since 01/15/2005, no new tests (and more important, new output) appeared at http://test.winehq.org/data/ Cheers, Paul.

4 3

HKEY_USERS in our registry
by Paul Vriens Jan. 25, 2005

Jan. 25, 2005

Hi, just saw that our entry for the default user is .Default while on at least win98SE,Win2K and WinXP it's .DEFAULT. Not a big deal but should this be changed? The registry functions all seem to be case-insensitive. Cheers, Paul.

1 0

gdi32 test failing
by Jakob Eriksson Jan. 25, 2005

Jan. 25, 2005

http://test.winehq.org/data/200501151000/2000_JakobEriksson/gdi32:metafile.… This fails. It shouldn't, because I ran winetest manually. http://test.winehq.org/data/200501151000/2000_JakobEriksson/version.txt what's up with that? regards, Jakob

3 2

Trying to fix the shreg tests
by Paul Vriens Jan. 25, 2005

Jan. 25, 2005

Hi, now that the test results are current again :-) I can see why some of the shreg tests failed before. The error we are getting back for RegCreateKeyA is ERROR_CHILD_MUST_BE_VOLATILE on most of the XP boxes. We need to either: - Use a different key to write to (a non volatile parent) - Use RegCreateKeyEx instead of RegCreateKey and specify REG_OPTION_VOLATILE which one is preferred? Cheers, Paul Vriens.

1 0

Summary of MSRPC / DCE/RPC interoperability / Applicability of FreeDCE for Wine (DCOM)
by Luke Kenneth Casson Leighton Jan. 25, 2005

Jan. 25, 2005

hi, in case you looked at the number of emails exchanged on FreeDCE and freaked out, here's a summary. if you feel that there are any relevant points missing or incorrect, please _do_ speak up. [p.s. this message not sent to samba mailing lists due to censorship decision by samba team in effect since 15th dec 2004. if anyone believes this message to be relevant to samba development please kindly forward it to the samba lists, checking first to see if you are the first person to do that. or simply feel free to add cc on any comments to any samba lists you feel are appropriate. please _do_ remember to remove my email address from any cc's to samba lists because it is likely to trigger the samba team censorship filters. thank you] 1) initial query raised: "freedce suitable for wine, esp. dcom!" 2) comments made (corrections from mark, rob and wez): "freedce doesn't have anything _like_ the capability required for DCOM - freedce's DCOM code is 'stubs'" 3) confusion resulted, clarification process began (rob, luke). conclusion: a) "freedce is almost identical to MSRPC, and is the back-end to rpcrt4.dll" b) "MSRPC as implemented in rpcrt4.dll has NOTHING to do with DCOM: DCOM compiles to code that ***UTILISES*** rpcrt4.dll" (this requires further explanation, see below). c) Porting of / Plugging in FreeDCE to rpcrt4.dll could be done "a la Apache Runtime (APR)", i.e. wrapper functions - maybe even just macros in most cases. d) extending FreeDCE to support rpcrt4.dll is easy and almost boring - even RpcImpersonateClient would be trivial to add (trivial from a Wine perspective - but see below for implications) e) lkcl suggested porting FreeDCE to use Wine's threads because dcethreads (posix draft 4 threads) have to diiiieeee. this can be done independently of Wine and there is an incentive _outside_ of Wine to _get_ it done because the dependency on posix draft 4 threads is so "last decade". f) modifying and utilising FreeDCE to understand Win32 "type string format" tables is, with the help of muddle (a program written by matthew chapman that understands exactly those tables in Win32 DLLs and EXEs) going to be a pretty trivial task. (see below for more details here) g) extension of DCE/RPC syntax to support MSRPC syntax is infinitely more straightforward than rewriting an IDL compiler from scratch. (see below) ... still with me so far? :) now here's the catch, and the catch to the catch :) the main counterargument raised to utilising freedce was not so much a technical argument, but was a resources-related and maintenance argument. 'why bother, when the approach presently being taken will "work"'? to answer that, i have to drop out of "summary" mode and into a mode of adding to and also reiterating [some of the] points raised last week. 1) it'll work - _eventually_ - and not fully [codeweavers present aims are for binary and type string interoperability only, and for only a subset of MSRPC to keep the time, development and maintenance costs down] 2) if you ever intend to aim for full interoperability with MSRPC, i recommend that you investigate how "full" pointers are implemented, because i know of a [proprietary] company that implemented that, after first only doing unique pointers, and adding "full" pointers QUADRUPLED the amount of code that they ended up with. 3) why aim to implement (from scratch) only 25% of the full solution (i.e. leaving out network interoperability by implementing your own non-NDR wire format, and not even implementing the full capabilities of the DCE/RPC IDL language) when a 95 to 98% feature-complete and free-software-license-compatible solution already exists? madness! madness, i say! 4) by utilising FreeDCE in Wine, you can kill two birds (actually three or maybe four) with one stone - two of which were aimed for with the initial DCOM work (DCOM binary interoperability at the Win32 and "type string" table levels) and two more are gained "by accident" - network interoperability and the ability to run MSRPC-based applications. 5) the effort expended so far is most certainly not "wasted" by adopting FreeDCE. if the time and effort expended so far had not been spent, how would it then be possible to appreciate the scope and scale of adapting and maintaining FreeDCE integrated to suit Wine? remember, i went through the same thing - i implemented from scratch HAND-CRAFTED marshalling and unmarshalling code in NT Domain interoperability code - almost 100,000 lines over three years - before deciding it was insane and seeking alternatives [and i found FreeDCE]. 6) if you understand the present Wine rpcrt4.dll code, FreeDCE is _so_ similar that the issue of "it's so different that codeweavers and the wine developers couldn't _possibly_ adapt to it" is just absolute nonsense and a complete non-issue: it _is_ the same code (OSF DCE 1.1 "reference" implementation) it's just that in rpcrt4.dll, DCE 1.1 has been "microsofted", and in FreeDCE, DCE 1.1 has been "gnu'd" and "autoconf'd". the question therefore, in my mind, turns on its head: "how _can_ you turn such an opportunity to save time (and money, and effort) down?" summary (well, sort of summary) ends here. the rest of this message is notes about the two. three points above. [noooobody expects the spanish inquisitionnn. the key element is surpriiise. surprise and ... the _twooo_ key elements .... ] DCOM is nothing to do with MSRPC regarding 3b) - this is where the initial confusion arose in 1). DCOM is, as rob kindly clarified, an object-orientated "thing" that uses MSRPC for its transport. it is a programming concept, not a networking API. in microsoft's c++ implementation of DCOM, once the c++ compiler has done its job, no evidence of the fact that it was DCOM remains: everything is compiled down onto MSRPC interfaces [including certain services that are required as part of DCOM]. therefore, it is both easy to confuse rpcrt4 as an implementation of "DCOM" (which it is not, it is an implementation of MSRPC) and also it is easy to forget that DCOM expects some interfaces (including the c++ APIs if you want your c++ applications to utilise DCOM) and services (e.g. the additional service in the endpoint mapper) to exist. and, according to documentation written by microsoft and available online at the open group's site, one of those services is a Win32 registry (yuk). oops :) for which there exists samba tng code that implements the MSRPC side of a Win32 registry, btw, which could easily be combined with Wine's registry to complete a full proper job. RpcImpersonateClient and ImpersonateNamedPipeClient these functions can be implemented such that FreeDCE will transfer security contexts about (to and from Win32 applications that ask for them). the process of adding the two above functions to Wine is very straightforward: pass a few blobs around, such that they can be passed to SeAccessCheck amongst other things. the _implications_ of adding them are that ReactOS must actually understand them, make use of them, etc. [otherwise, you needn't bother - just implement stubs] and _that_ means that the integration with and adoption of Samba or Samba TNG's architecture and NT Services needs to be accelerated. the Samba Team will need to be brought up to speed on how this is achieved. you may run into difficulties, there, however. their general ethos is to keep complete control over all projects that they are involved with or need to make use of (emphasis on _they_ need), and where this is not possible, they tend to reimplement from scratch any components that they require (kerberos servers, ldap servers, that sort of thing). recent developments, however, tend to suggest that this ethos is changing - but the proof of the pudding is always in the eating: their track record on cooperation with other projects is not good. you may therefore find it easier to work with the samba tng architecture for the initial implementation of these two functions, because samba tng is already split into easily manageable and understandable portions behind APIs that match or mirror the samba tng team's "best-guess" of the underlying (or unpublished) Win32 apis. and, as frequently happens, once a concept has been demonstrated as viable in samba tng, it is often adopted by the samba team - so you need not have any concerns about utilising the samba tng architecture. consider it a "proving ground". NDR "type string" interoperability - f) compared to writing an interpreter from scratch that understands these tables, adapting FreeDCE to understand MSRPC tables in DLLs and EXEs is most certainly trivial. NDR "type strings" - aka in DCE/RPC formats as "AST", is effectively a byte-code interpreted language, one in which the size of data structures and the type and offsets of members of structs is embedded, amongst almost a hundred or so other things. remember, binary-interoperability with _linux_ is totally irrelevant: you can just recompile the source code, link against static libraries, blah blah, sorted. so adapting FreeDCE for win32 "type string" interoperability it's a matter of: 1) changing some constants and alignments where necessary, to match those in MSRPC (analysing muddle and freedce) 2) improving muddle to correctly identify the data structures and their relative positions in the DLLs / EXEs - at present, muddle "guesses" some of the table's locations (eek!) and as an aside / prerequisite: 3) correctly duplicating any MSRPC extensions, including adding in support for "complex" expressioning. MSRPC interoperability - g) "interface" inheritance has already been added (by wez). "expressions" needed for size_is(complexthing) have already been added [needs more work and needs "outsourcing" to a function] range(n-n) needs to be added (trivial to do). -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

3 6

Re: [OLE #50] IRemUnknown Proxy/Stub Implementation
by Alexandre Julliard Jan. 25, 2005

Jan. 25, 2005

Robert Shearman <rob(a)codeweavers.com> writes: > + memcpy(&cIids, buf, sizeof(USHORT)); > + buf += sizeof(USHORT); > + ir = (REMINTERFACEREF*)buf; > + pResults = alloca(cIids * sizeof(HRESULT)); You shouldn't use alloca, it's not portable, plus the space may not be available since the app controls the stack size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Summary of MSRPC / DCE/RPC interoperability / Applicability of FreeDCE for Wine (DCOM)
by Dan Kegel Jan. 24, 2005

Jan. 24, 2005

Mike wrote: > Luke Kenneth Casson Leighton wrote: >> hi, in case you looked at the number of emails exchanged on FreeDCE >> and freaked out, here's a summary. if you feel that there are any >> relevant points missing or incorrect, please _do_ speak up. > > There's only one thing that counts for Wine, and that is patches that > improve Wine. A grand scheme is nice, but it means nothing without patches. Indeed. Luke, we're all excited about the possibilities, but intimidated by the prospect of learning FreeDCE etc. and figuring out how to plug it in to Wine. Perhaps you could figure out a plan of attack that yields a useful intermediate result with a minimum of changes to Wine? If you actually got something simple plugged into Wine and working, it would really get people to stand up and take notice. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Unexpected messages arriving while in RedrawWindow()
by Troy Rollo Jan. 24, 2005

Jan. 24, 2005

In RedrawWindow (dlls/user/painting.c:402) there is a call to MsgWaitForMultipleObjects: /* process pending events and messages before painting */ if (flags & RDW_UPDATENOW) MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); This call can result in messages arriving at an unrelated window, such as in the trace below. This will not happen under Windows - a single-threaded application will not receive a message in an unrelated window while RedrawWindow is on the stack (unless one of the windows that is supposed to be getting messages sends it or processes the message queue). In the trace, the creation of the Combo Box (at stack frame 60) is part of the initialisation sequence for a window. During the creation of that box, RedrawWindow is called, and while in the MsgWaitForMultipleObjects code, an event arrives that causes SetWindowPos() to be called on the frame window containing the parent of the combo box, resulting in a WM_SIZE. In this case, the WM_SIZE message triggers some operations in the parent of the combo box (at stack frames 0-4) that result in data used by an earlier stack frame (at frames 61-70) being changed unexpectedly. A quick fix in the present case might be to take the "RDW_UPDATENOW" flag off the call to RedrawWindow() from CBResetPos(), since it seems unlikely that the flag is necessary, but it seems that doing so just masks the real problem. The real fix would appear to be involve some queueing of events received other than those needed by RedrawWindow(). .... in application code.... #5 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #6 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:419 #7 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:3053 #8 0x406f893f in CallWindowProcW (func=0x407a2dde <winproc_array+734>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:3279 #9 0x40731071 in call_window_proc (hwnd=0x20046, msg=5, wparam=2, lparam=19858040, unicode=1, same_thread=1) at message.c:1473 #10 0x4073219f in SendMessageTimeoutW (hwnd=0x20046, msg=5, wparam=2, lparam=19858040, flags=0, timeout=4294967295, res_ptr=0x4067dbc4) at message.c:1936 #11 0x40732472 in SendMessageW (hwnd=0x20046, msg=5, wparam=2, lparam=19858040) at message.c:2017 #12 0x406cc9d6 in DEFWND_HandleWindowPosChanged (hwnd=0x20046, winpos=0x4067e054) at ../../windows/defwnd.c:75 #13 0x406cdc10 in DEFWND_DefWinProc (hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/defwnd.c:345 #14 0x406ce2dd in DefWindowProcA (hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/defwnd.c:851 #15 0x406d9319 in DefFrameProcA (hwnd=0x20046, hwndMDIClient=0x20044, message=71, wParam=0, lParam=1080549460) at ../../windows/mdi.c:1280 .... in application code .... #19 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #20 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:419 #21 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:3053 #22 0x406f893f in CallWindowProcW (func=0x407a2dde <winproc_array+734>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:3279 #23 0x40731071 in call_window_proc (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460, unicode=1, same_thread=1) at message.c:1473 #24 0x4073219f in SendMessageTimeoutW (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460, flags=0, timeout=4294967295, res_ptr=0x4067dfac) at message.c:1936 #25 0x40732472 in SendMessageW (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460) at message.c:2017 #26 0x40ebae77 in X11DRV_SetWindowPos (winpos=0x4067e054) at winpos.c:885 #27 0x406f09cc in SetWindowPos (hwnd=0x20046, hwndInsertAfter=0x20026, x=0, y=4, cx=640, cy=350, flags=2147483664) at ../../windows/winpos.c:1200 #28 0x40ebc3e5 in X11DRV_ConfigureNotify (hwnd=0x20046, event=0x4067e1ac) at winpos.c:1480 #29 0x40ea51d5 in EVENT_ProcessEvent (event=0x4067e1ac) at event.c:348 #30 0x40ea4d68 in process_events (data=0x4037ff40) at event.c:128 #31 0x40ea4e4c in X11DRV_MsgWaitForMultipleObjectsEx (count=1, handles=0x4067e3ec, timeout=0, mask=255, flags=0) at event.c:162 #32 0x406db6e4 in MsgWaitForMultipleObjectsEx (count=0, pHandles=0x0, timeout=0, mask=255, flags=0) at ../../windows/message.c:596 #33 0x406db7a1 in MsgWaitForMultipleObjects (count=0, handles=0x0, wait_all=0, timeout=0, mask=255) at ../../windows/message.c:613 #34 0x40736d8c in RedrawWindow (hwnd=0x20040, rect=0x0, hrgn=0x0, flags=261) at painting.c:414 #35 0x406fe76a in CBResetPos (lphc=0x452a1e68, rectEdit=0x452a1e84, rectLB=0x452a1ea4, bRedraw=1) at combo.c:1599 #36 0x406fe7e6 in COMBO_Size (lphc=0x452a1e68) at combo.c:1616 #37 0x406fef84 in ComboWndProc_common (hwnd=0x20040, message=71, wParam=0, lParam=1080551548, unicode=0) at combo.c:1911 #38 0x40700425 in ComboWndProcA (hwnd=0x20040, message=71, wParam=0, lParam=1080551548) at combo.c:2281 #39 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #40 0x406f14fa in WINPROC_CallWndProc (proc=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:419 #41 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:3053 #42 0x406f893f in CallWindowProcW (func=0x407a2b4a <winproc_array+74>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:3279 #43 0x40731071 in call_window_proc (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548, unicode=1, same_thread=1) at message.c:1473 #44 0x4073219f in SendMessageTimeoutW (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548, flags=0, timeout=4294967295, res_ptr=0x4067e7d4) at message.c:1936 #45 0x40732472 in SendMessageW (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548) at message.c:2017 #46 0x40ebae77 in X11DRV_SetWindowPos (winpos=0x4067e87c) at winpos.c:885 #47 0x406f09cc in SetWindowPos (hwnd=0x20040, hwndInsertAfter=0x0, x=0, y=0, cx=223, cy=26, flags=22) at ../../windows/winpos.c:1200 #48 0x406fc21c in CBForceDummyResize (lphc=0x452a1e68) at combo.c:332 #49 0x406fc85a in COMBO_Create (hwnd=0x20040, lphc=0x452a1e68, hwndParent=0x2003e, style=1352728579, unicode=0) at combo.c:666 #50 0x406feee1 in ComboWndProc_common (hwnd=0x20040, message=1, wParam=0, lParam=1080552968, unicode=0) at combo.c:1875 #51 0x40700425 in ComboWndProcA (hwnd=0x20040, message=1, wParam=0, lParam=1080552968) at combo.c:2281 #52 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #53 0x406f14fa in WINPROC_CallWndProc (proc=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=1, wParam=0, lParam=1080552968) at ../../windows/winproc.c:419 #54 0x406f87cf in CallWindowProcA (func=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=1, wParam=0, lParam=1080552968) at ../../windows/winproc.c:3240 #55 0x40731108 in call_window_proc (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968, unicode=0, same_thread=1) at message.c:1478 #56 0x407323e0 in SendMessageTimeoutA (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968, flags=0, timeout=4294967295, res_ptr=0x4067eb18) at message.c:1984 #57 0x407324e2 in SendMessageA (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968) at message.c:2028 #58 0x40eb887f in X11DRV_CreateWindow (hwnd=0x20040, cs=0x4067ee08, unicode=0) at window.c:1124 #59 0x406e9ad3 in WIN_CreateWindowEx (cs=0x4067ee08, classAtom=49153, type=WIN_PROC_32A) at ../../windows/win.c:1172 #60 0x406ea3b7 in CreateWindowExA (exStyle=0, className=0xb47d1a "COMBOBOX", windowName=0xb47d23 "", style=1352728579, x=3, y=3, width=223, height=314, parent=0x2003e, menu=0xce6, instance=0x400000, data=0x0) at ../../windows/win.c:1327 .... in application code .... #71 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #72 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=256, wParam=13, lParam=0) at ../../windows/winproc.c:419 #73 0x406f87cf in CallWindowProcA (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=256, wParam=13, lParam=0) at ../../windows/winproc.c:3240 #74 0x40731108 in call_window_proc (hwnd=0x10022, msg=256, wparam=13, lparam=0, unicode=0, same_thread=1) at message.c:1478 #75 0x407323e0 in SendMessageTimeoutA (hwnd=0x10022, msg=256, wparam=13, lparam=0, flags=0, timeout=4294967295, res_ptr=0x4067f564) at message.c:1984 #76 0x407324e2 in SendMessageA (hwnd=0x10022, msg=256, wparam=13, lparam=0) at message.c:2028 .... in application code .... #79 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #80 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=273, wParam=101, lParam=34) at ../../windows/winproc.c:419 #81 0x406f87cf in CallWindowProcA (func=0x407a2dd0 <winproc_array+720>, hwnd=0x10022, msg=273, wParam=101, lParam=34) at ../../windows/winproc.c:3240 #82 0x406dbe02 in DispatchMessageA (msg=0x4067f96c) at ../../windows/message.c:793 .... in application code .... #85 0x00b1390b in _startup () #86 0x00000000 in ?? ()

1 0

some notes: ADVAPI32: convert services to use pipes for RPC instead of shared memory
by Alexander Yaworsky Jan. 24, 2005

Jan. 24, 2005

Hello, there should be only one dispatcher thread per process that accepts control requests. For shared services it starts another service threads on demand and the amount of them is not limited with MAXIMUM_WAIT_OBJECTS. Thanks.

2 1

compiling MFC...Advil required? ;-)
by Adam Boyle Jan. 24, 2005

Jan. 24, 2005

Hi All, First, thanks to all for the excellent work on Wine. I'm a Crossover Office user, and I anxiously await each week's Wine Weekly Newsletter as well to keep myself up with happenings in the Wine world. You guys truly rock. But I digress. Here's the real reason for my e-mail: I need to port one of my company's MFC-based application to Linux. My first thought was to use Winelib. I understand from everything that I've read that I need to recompile MFC using Wine. Easier said than done, though. I've spent several hours just trying to get everything setup correctly, and things are still not compiling correctly. First, some questions: - My initial attempt at compiling MFC was on the MFC source code from VS.NET 2003. After not being able to get a satisfactory Makefile configuration for compling that version of MFC, I figured that perhaps VS98's version of MFC was more commonly recompiled by Wine developers, so I'm currently trying to compile VC98's MFC. Is there a preferred version of MFC that I should be compiling, or are they all equally difficult? ;-) - I have the following RPM packages installed on my Mandrake 10.1 OS: libwine1-20040813-2mdk, winelib-0.3-1mdk, libwine1-devel-20040813-2mdk, wine-20040813-2mdk. I have also downloaded the latest wine source code from 20050111. As mentioned before, I also have Crossover Office installed. In your opinion, is there a more compatible or better set of libraries to use when compiling? Anybody compiled MFC using the Mandrake packages before? (FYI, wineg++ --version and winegcc --version both report that they are g++/gcc (GCC) 3.4.1. - Also, should I be using an older version of Wine's source code, instead of the very recent 20050111 version that I've currently got on my system? I've read the Winelib documentation on compiling MFC and have combed through the mailing list archives as much as possible to get to where I'm currently at. After running winemaker on the VC98 source code directories and tweaking the resulting VC98/MFC/src/Makefile quite a bit, I also put the following #defines at the top of VC98/MFC/src/stdafx.h: #define _AFX_PORTABLE #define _FORCENAMELESSUNION #define _AFX_NO_DAO_SUPPORT #define _AFX_NO_DHTML_SUPPORT #define _AFX_NO_OLEDB_SUPPORT #define _AFX_NO_RICHEDIT_SUPPORT #define _AFX_NO_ATL_SUPPORT (That seems to be basically what the Winelib docs tell me to do.) Anyway, here's the current output when I run 'make -f Makefile' in the VC98/MFC/src directory: wineg++ -c -mno-cygwin -isystem -fpermissive -fms-extensions -fshort- wchar -DWINE_UNICODE_NATIVE -DICOM_USE_COM_INTERFACE_ATTRIBUTE -I. - I/home/ajboyle/wine-20050111/include/msvcrt - I/home/ajboyle/wine-20050111/include -I../Include -o afxabort.o afxabort.cpp In file included from stdafx.h:96, from afxabort.cpp:11: ../Include/afxcom_.h: In constructor `CIP<_Interface, _IID>::CIP (IUnknown*)': ../Include/afxcom_.h:357: error: there are no arguments to `GetIID' that depend on a template parameter, so a declaration of `GetIID' must be available ../Include/afxcom_.h:357: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) ../Include/afxcom_.h: In member function `CIP<_Interface, _IID>& CIP<_Interface, _IID>::operator=(IUnknown*)': ../Include/afxcom_.h:379: error: there are no arguments to `QueryInterface' that depend on a template parameter, so a declaration of `QueryInterface' must be available ../Include/afxcom_.h: At global scope: ../Include/afxcom_.h:403: error: an explicit specialization must be preceded by 'template <>' In file included from stdafx.h:110, from afxabort.cpp:11: ../Include/afxctl.h: In constructor `COleControl::XEventConnPt::XEventConnPt()': ../Include/afxctl.h:1303: warning: invalid access to non-static data member `COleControl::m_xEventConnPt' of NULL object ../Include/afxctl.h:1303: warning: (perhaps the `offsetof' macro was used incorrectly) ../Include/afxctl.h: In constructor `COleControl::XPropConnPt::XPropConnPt()': ../Include/afxctl.h:1310: warning: invalid access to non-static data member `COleControl::m_xPropConnPt' of NULL object ../Include/afxctl.h:1310: warning: (perhaps the `offsetof' macro was used incorrectly) In file included from ../Include/afxpriv.h:758, from stdafx.h:123, from afxabort.cpp:11: ../Include/afxconv.h:62:21: atlconv.h: No such file or directory In file included from stdafx.h:127, from afxabort.cpp:11: oleimpl2.h: At global scope: oleimpl2.h:94: error: a class-key must be used when declaring a friend In file included from /usr/lib/gcc/i586-mandrake-linux- gnu/3.4.1/../../../../include/c++/3.4.1/backward/new.h:33, from stdafx.h:161, from afxabort.cpp:11: /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/../../../../include/c+ +/3.4.1/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated. winegcc: g++ failed. make: *** [afxabort.o] Error 2 Funny how gcc is telling me to use -fpermissive, when I'm already using it. Anyway, that's probably a red herring. If I can gain a clear understanding of the current steps needed to successfully compile MFC, I'd be more than happy to contribute updated 'Compiling MFC' docs to the Winelib docs to help out future developers that may be in a similar predicament as me. Thanks in advance for any help you can give me. Adam Boyle

1 0

Petzold Programming Windows Fifth Edition Section 1 Regression Tests
by Ira Krakow Jan. 24, 2005

Jan. 24, 2005

I'm going through the examples in Petzold's Programming Windows Fifth Edition, to familiarize myself with Winelib and to test against Wine 20050111. I am also comparing the output against Visual C++ 6.0 compilation on Windows XP. I finished Section 1 (Chapters 1-12) and found the following differences. (I didn't want to report these as bugs until others verified them, as well as my approach.) I have the source and can narrow down the code if you think this is necessary. I will proceed to Section 2 and report when I'm finished. Ira -------------------------------------------- Chapter 3: HelloWin.c Could not compile because PlaySoundA was not found. Chapter 5: SineWave.c at runtime, after sine wave displays OK and window is dismissed, get messages: err:dc:DCE_FreeWindowDCE [0x50030] GetDC() without ReleaseDC! I rerun and get a variable number of the messages, and the address inside the brackets [] changes. Clover.c Draws the clover regions initially OK, but does not redraw when the user resizes the window. Note: The resizing works in Windows XP when compiled with Visual C++ 6.0. Chapter 8: WhatClr.c Compiles and runs, but doesn't display the correct colors all the time. For example, if the cursor is under the black letters, doesn't display FF FF FF but pulsates. ALso displays FF FF FF when on a white pixel, when it should be 00 00 00. Chapter 9: PopPad1.c Compiles and runs and works for the most part. However, if you start typing on line 1 and keep typing to beyond the end of the line, the text redisplays at the bottom. In Windows, it keeps displaying on the same line and scrolls. Head.c Compiler warning on passing NULLto ReadFile: head.c:179 warning: passing arg 4 of 'ReadFile' from incompatible pointer type. But runs OK. Chapter 10: IconDemo.c Resource compiler warning: In non MFC projects, winemaker replaces the MFC specific header 'afxres.h' with 'winres.h'. Icon resource compiles OK and program runs OK. PoePoem.c Compiles OK. Exception raised dialog: "Unhandled page fault on write access to 0x7637f17a at address 0x7637e592. Do you wish to debug it?" Goes into Winedbg if you click Yes. PoorMenu.c Compiles and runs. However, it doesn't add the additional menu choices to the System Menu. NoPopup.c Compiles and runs. However, does not display all the menu choices if you double click the File.. choice. Should have New, Open, Save, Save As, and Main. The choices are there but hidden - need to click on each choice. The Main item, when clicked, should restore the MAIN menu but does not do so. Compare with Windows version. Chapter 11: About3.c OK, except that the custom icon (III) does not replace the down arrow in the upper left corner of the window, which it does in the Windows version. HexCalc.c Compiles and calculates OK. The button display is rectangular (long and narrow). On Windows the buttons display square. PopAd3.c OK. Produces message: fixme:commdlg:GetFileName95 Flags 0x00002000 not yet implemented when invoking the File Open dialog but otherwise works fine. Chapter 12: ClipView.c Compiles and runs but does not update the clipboard when the clipboard contents changes. Run ClipText under Wine, copy or cut the text to the clipboard, ClipView does not see the clipboard contents. -----------------------------------------------------

3 5

RE: D3D9 Changes
by Ann and Jason Edmeades Jan. 24, 2005

Jan. 24, 2005

Hi Oliver, I said I'd give this a review, and there's some great work here. I've had a chance to go through these changes, and some mostly trivial comments. Apologies if some of these are inaccurate, because some of the diffs look complex and I was purely reviewing the patch files! There seems a lot here, but most are simple... 1. D3DLOCK_ values, D3DUSAGE_ values --> You might as well put these in order. 2. Any of the d3drs_ (or similar) changes where you remove a value which is in d3d8 but not d3d9 - Can you please define a wined3d_ version in the wined3d private header. The problem here is wined3d is compiled with the d3d9 includes but needs to understand the d3d8 specifics. I think there's only one or two of these (d3dorder? Some d3drs_ values) 3. Stick your name in the copyright of files you do significant changes to - Theres a couple I think you missed. 4. Changes to cubetexture.c I mentioned before - You cant change - return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface); + return IWineD3DResource_GetType((IWineD3DResource *)iface); As this is recursive. You must leave the Impl version in there 5. You cant do this as the size isn't a member of the surface desc in d3d9 (it is in 8) - object->currentDesc_size = ((max(Width,4) * object->bytesPerPixel) * max(Height,4)) / 2; /* DXT1 is half byte per pixel */ + object->currentDesc.Size = ((max(Width,4) * object->bytesPerPixel) * max(Height,4)) / 2; /* DXT1 is half byte per pixel */ 6. There's a number of places where whitespace have increased the patch size, or indenting is changed where it didn't need to be. Its really trivial and I wont care if it goes in, its just something I noticed Examples include - case D3DZB_FALSE: + case D3DZB_FALSE: - - TRACE("(%p) : freeing StateBlock %p\n", This, pSB); + + TRACE("(%p) : freeing StateBlock %p\n", This , pSB); and /* glDrawPixels transforms the raster position as though it was a vertex - - we want to draw at screen position 0,0 - Set up ortho (rhw) mode as - per drawprim (and leave set - it will sort itself out due to last_was_rhw */ + we want to draw at screen position 0,0 - Set up ortho (rhw) mode as + per drawprim (and leave set - it will sort itself out due to last_was_rhw */ or -DWORD WINAPI IWineD3DTextureImpl_GetPriority(IWineD3DTexture *iface) { +DWORD WINAPI IWineD3DTextureImpl_GetPriority(IWineD3DTexture *iface) { (I was trying to remove such spaces as I went along!) 7. You cant comment out d3d8 functionality - We can check the version if we have to, but we must maintain the support. This relates to (2) + +#if 0 /*FIXME: d3d8 support*/ case D3DRS_SOFTWAREVERTEXPROCESSING : There's a number of these places mostly relating to texture states, render states and stateblocks - We MUST maintain d3d8 support. 8. Be careful adding in new GL calls with new gl constants, without updating the winegl_core header - We frequently break old compiles with out of date opengl headers, and this was one attempt to avoid the issue. + glTexEnvf( GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, GL_TRUE); Similarly please use the d3dcore header for + #ifndef GL_MAX_DRAW_BUFFERS_ATI + #define GL_MAX_DRAW_BUFFERS_ATI 0x00008824 + #endif 9. I'm not sure on this but does d3d9 really support 16 concurrent textures in non-shader drawing modes? (ie do we really need to reapply all the states for them?). I really haven't checked, I was just surprised by it! 10. Following on from 9, don't the changes to the sampler support break d3d8 settexturestagestate for d3d8 applications for the values like D3DTSS_MAXMIPLEVEL? 11. Can you explain the problem with the following addition please, just interested! + || (dataLocations.u.s.pSize.lpData == NULL /*My ATI9600 doesn't like this combination of nothing!*/ 12. You cant use C++ style comments +// PLIGHTINFOEL *src; 13. There is a section of code "Experemental memory management that releases the allocated memory from a surface when the texture is loaded until a lock is requested on the surface.". This needs to be a separate patch and needs confirming the memory benefits are not outweighed by the performance hit. I thought the problem was that reading the contents returned an upside down texture? 14. Again, why lines like + + +#include <math.h> +#include <stdarg.h> + +#define NONAMELESSUNION +#define NONAMELESSSTRUCT +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "wingdi.h" +#include "wine/debug.h" + + These are already #included in d3d9_private.h and are not required here (I had removed them in earlier patches) ---------------------------------------------------------------------------- To sum up I think there is some fabulous work in there, and we definitely need to get it into cvs. Please do not take the above as criticism, as there is so much there I wanted to give useful feedback. I would, however, suggest you split functionality into smaller patches rather than put lots of new code in at the same time. (And yes, I was guilty of that but only when it was pure cut and paste from d3d8 and no new function) If I read the patches correctly you have the following which probably could be split into separate patches - Removing the d3d9 code taking it down to stubs where there was initial dummy functionality when the skeleton was originally set up - Correcting the public d3d9* headers, and making the utils functions format out the data correctly - Using a single surface call back function (Neat, btw) - Adding point support - Adding some memory management - Support for texture sampler states - Other minor changes Jason

1 0

user32/tests/sysparams.c question
by Paul Vriens Jan. 24, 2005

Jan. 24, 2005

Hi, just installed winrash on my win98 box and saw some output from the test on the web. I just had a look at the sysparams.c test for test_SPI_SETICONTITLEWRAP. On my standard Win98 SE box this registry key is not available and the tests complains about that. The bad thing though is that the registry key is created and second time the test runs it succeeds of course. Shouldn't every call: rc=SystemParametersInfoA( SPI_FOO, 0, &old_b, 0 ); be followed by a: if (rc==0 && (GetLastError()==0 || GetLastError()==ERROR_CALL_NOT_IMPLEMENTED)) instead of: ok(rc!=0,"SystemParametersInfoA: rc=%d err=%ld\n",rc,GetLastError()); The 'big problem' right now will be that every volunteer will have some registry keys created if the key didn't exist before and we don't know what default installations have. Not good for documentation purposes. I will send a patch for ICONTITLEWRAP. Cheers, Paul.

1 0

Re: Disable antialiasing in palette mode
by Alexandre Julliard Jan. 24, 2005

Jan. 24, 2005

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > --- dlls/x11drv/xrender.c 30 Nov 2004 21:38:58 -0000 1.52 > +++ dlls/x11drv/xrender.c 6 Dec 2004 00:02:20 -0000 > @@ -1013,6 +1013,29 @@ > 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 { > + BITMAPOBJ *bmp; > + HBITMAP hBitmap; > + > + hBitmap = GetCurrentObject( physDev->hdc, OBJ_BITMAP ); > + bmp = (BITMAPOBJ *)GDI_GetObjPtr( hBitmap, BITMAP_MAGIC ); You should use GetObjectW here instead of GDI_GetObjPtr. -- Alexandre Julliard julliard(a)winehq.org

1 0

Refcounting in dsound
by Paul Vriens Jan. 24, 2005

Jan. 24, 2005

Hi, while going through some leftover TRACE's of the Interlocked cleanup, I found the following refcounting in dsound/buffer.c and dsound.c: dsound/buffer.c: This->buffer->ref--; dsound/buffer.c: This->buffer->ref--; dsound/dsound.c: dsb->buffer->ref++; Is there a need to clean (i.e. use Interlocked*) this up? Cheers, Paul.

4 4

Regression in update region handling
by Maxime Bellengé Jan. 24, 2005

Jan. 24, 2005

Hello, This patch introduced regressions : Moved update region handling to the server http://cvs.winehq.org/patch.py?id=14725 Since this patch has been applied, I have an application with acts like a christmas tree :) The application has owner drawn objects everywhere. What I see is that every object is painted but once a first object is painted (button or whatever) when the next one is painted all the rest of the dialog box is erased and so on. So I can only see the last painted component although every button is still usable. This patch is a real nightmare to understand. I tried comparing traces with +win before and after the patch but with no luck. I would appreciate if someone can give me an hint on how to find this bug. thanks Max

5 7

Re: Use NtLoadDriver and NtUnloadDriver in StartService and ControlService
by Uwe Bonnes Jan. 24, 2005

Jan. 24, 2005

>>>>> "Ivan" == Ivan Leo Puoti <ivanleo(a)gmail.com> writes: Ivan> Note that as NtLoadDriver is a stub, no program will ever get to Ivan> call NtUnloadDriver ATM. ... Remember when Bill Gates said that 512 kByte is enough for everybody? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

Re: rsaenh: Implemented TLS1 algorithms and tests
by Alexandre Julliard Jan. 24, 2005

Jan. 24, 2005

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Changelog: > Support for TLS1 pseudo random function > Some helper functions for DATA_BLOB's > Computing TLS1 master secret from the pre-master secret > Deriving the master hash from the master secret > Deriving TLS1 MAC and encryption keys from the master hash > Tests for most of the above The test is failing for me: rsaenh.c:1209: Test failed: 80090016 make: *** [rsaenh.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSI: indentation and style cleanup
by Alexandre Julliard Jan. 24, 2005

Jan. 24, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > - if(szFilePath) { > + if( szFilePath ) > + { > len = MultiByteToWideChar( CP_ACP, 0, szFilePath, -1, NULL, 0 ); > szwFilePath = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); > - if( !szwFilePath) > - return ERROR_OUTOFMEMORY; > MultiByteToWideChar( CP_ACP, 0, szFilePath, -1, szwFilePath, len ); > } Does your coding style also forbid proper error checking, or is there another reason for removing that check? <g> -- Alexandre Julliard julliard(a)winehq.org

6 9

Some general questions about test scripts
by Paul Vriens Jan. 24, 2005

Jan. 24, 2005

Hi, I'm currently working on the shlwapi tests and I already put something out on wine-devel for that. I tried a test on several operating systems with different dll's (out-of-the-box installation, servicepacks, Windows Update) so the end result is I have several different outputs of the test. I now more or less have the following (I'm exaggerating): ok( a < b | a == b | a > b, "Test failed\n"); So the question is how do we deal with the above? If the number of possible 'correct' output is huge, what's the benefit of testing? The second question is what should we implement in Wine? So much for the general questions. Now for the specific one: The test I'm referring to is SHQueryValueExA that I modified a bit for testing purposes: for (counter = 0; counter <= sExpLen2 ; counter++) { strcpy(buf, sEmptyBuffer); dwSize = counter; trace("Now trying with dwSize=(%lu)\n", counter); dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, buf, &dwSize); ok( ERROR_MORE_DATA == dwRet, "Expected ERROR_MORE_DATA, got (%lu)\n", dwRet); trace("comparing (%s) with (%s)\n", buf, sEmptyBuffer); ok( 0 == strcmp(sEmptyBuffer, buf) , "Comparing (%s) with (%s) failed\n", buf, sEmptyBuffer); ok( dwSize >= nUsedBuffer2, "Buffer size (%lu) should be >= (%lu)\n", dwSize, nUsedBuffer2); ok( REG_SZ == dwType , "Expected REG_SZ, got (%lu)\n", dwType); } I tested this on 3 different versions of win98, winxp-prof, winxp-home, winnt-server, w2k-prof and w2k-server and Wine of course. I can see that winxp/w2k and winnt act the same. Win98 and Wine do it differently (Wine doesn't do it as win98 does btw). Any thoughts? Paul Vriens.

3 2