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

Re: wined3d updates
by Ann and Jason Edmeades 20 Jan '05

20 Jan '05

Hi Oliver, D3DRESOURCETYPE WINAPI IWineD3DCubeTextureImpl_GetType(IWineD3DCubeTexture *iface) { - return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface); + return IWineD3DResource_GetType((IWineD3DResource *)iface); } This is wrong (and others) - you'll end up in an infinite loop. You must calls the impl type if you are effectively casting the interface into one of the types it inherits from I haven't got chance to review the rest yet - I'm heading away for the weekend. I'll look at the rest on Mon if you want any comments. Jason

1 0

Font selection logic defective?
by Bill Medland 20 Jan '05

20 Jan '05

(Huw?) Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available? Note that my font knowledge is quite minimal Context When I installed our product on a clean Red Hat Enterprise Linux 3 test machine it looked relatively acceptable. However on my own development machine (again RHEL3) for several texts the font was too large and overflowed the area that had been allocated for it. Then when I installed on Mandrake 10.0 I noticed the same large fonts. So I dug. On my machine (and probably on the Mandrake too; I don't know since I've trashed it) OpenOffice.org is installed. It installs /usr/share/fonts/openoffice, containing Vera*.ttf. As an example the Splash screen asks for an Arial font. My development machine runs through the fonts it knows about and selects the Bitstream Vera Sans, which is not a good match. The test machine has no ttf files to work from and so it reverses the Helvetica-Arial substitution (Hm!!! poor registry setup, I reckon) and performs a match for a Helvetica font and finds a much more acceptable font. So it seems to me that merely because OpenOffice.org has installed a couple of ttf fonts my development machine will select from a small list of ttf fonts and ignore a large list of x11 fonts. Am I correct? What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 6

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros
by Juan Lang 20 Jan '05

20 Jan '05

Hi Luke, I don't know is this is useful, but the TRY/CATCH stuff in particular is declared here: http://source.winehq.org/source/include/wine/exception.h and the Wine exception handling code is implemented here: http://source.winehq.org/source/dlls/ntdll/exception.c As Mike said, the Wine threading stuff is pretty complicated. Native applications unfortunately rely on things being exactly in the right place in the TEB, and DCE threads are unlikely to give us this. Peruse if you like http://source.winehq.org/source/include/thread.h and http://source.winehq.org/source/dlls/ntdll/thread.c --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: RpcImpersonateClient (and ImpersonateNamedPipeClient)
by Juan Lang 20 Jan '05

20 Jan '05

Hi Luke, you said: > that's where you'd need the cooperation of samba / samba tng: > it's got "SIDs" behind it, and "SIDs" means a SAMR server > and a NETLOGON server and an LSARPC server (and in the > case of windows 2000 interoperability, access to an Active > Directory Server). Another possibility is that we implement our own version of a SAM. Right now we just return a fake Administrator SID every time we're asked for one. But if we absolutely needed to, we could implement a local version and it needn't even be a separate process. The NT SAM registry is pretty well reverse engineered here: http://neworder.box.sk/files/nullak_ntsecurity/index.php > you can always still implement RpcImpersonateClient as a stub. Yah. I think that's more likely than that we go whole-hog on it. From experience, it's often more important to get things like parameters and error codes just the way Windows programs expect than it is to make a function "really work." By implementing a stubbed or local-only version, we can figure out all this stuff, and maybe make a full-blown version later. and later, > it _does_ mean careful design because i doubt very much whether people > will be happy to have samba tng as a dependency on Wine. Agreed. The focus for the Wine folks is generally, does this get my app to work? Unless it's fixing an app, not too many folks are likely to get real excited by anything. Feel free to point out what we've been missing. Patches speak louder than anything here :) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

Re: Running dxdiag
by Juan Lang 20 Jan '05

20 Jan '05

Hi Mike, > Dumping the headers is necessary for stupid installers that map DLL files > manually and rummage around in the headers to figure out versions and > stuff ... simply having an empty file isn't enough for all of them I'm > afraid :( This isn't enough for new installers, either :( I have an MSI-based InstallShield installer that's looking for shdocvw.dll to see if IE6 is installed. (It isn't, but that's how it's looking for it.) Trouble is, how would this work with the native/builtin thing? Right now all our builtins don't live in the system directory, so we can always override whatever native dll happens to get dropped there. If we put a little stub PE header in there, what's to stop an installer from overwriting it? Or, would this cause a problem? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

3 2

Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros
by Luke Kenneth Casson Leighton 20 Jan '05

20 Jan '05

hi, as you may be aware, dce threads is posix draft 4 threads and FreeDCE has an emulation library kindly made up-to-date to successfully run even on NPTL on x86 and AMD64, courtesy of loic. http://cvs.sourceforge.net/viewcvs.py/freedce/dcethreads/ it is my understanding / guess that microsoft, in their adoption of DCE 1.0 some fifteen years ago for NT 3.1, ported DCE threads to Win32 [hence, you have all those lovely TRY CATCH RAISE macros in all the lovely MSVC++ programs, whoopeee] so i was wondering if someone could point me in the direction of some Wine source code - testing, implementation, macros etc. that would allow me to vaguely confirm whether my suspicions are correct. the first hypothesis i want to test is this: namely, that Wine applications would run _better_ [read, "more correctly"] by using dcethreads than by using its present implementation of Win32 threads. the _other_ hypothesis i want to test is this: namely, that FreeDCE applications would be more "palatable" in today's modern environment if compiled with Wine's threading code! according to loic, who is an expert on the different thread models, the thing is that certain syscalls are not interruptable / cancellable in Posix Draft 4 threads and in NPTL they are. this CHANGES the behaviour of any programs using the wrong threading library in subtle ways. thus, certain applications suddenly become unreliable where they were previously fine. etc. l. p.s. i don't claim to know all the answers, nor all the questions. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Re: Fwd: Re: Wine builtin mscms.dll
by Hans Leidekker 20 Jan '05

20 Jan '05

On Thursday 20 January 2005 08:04, you wrote: > I got your name from Mike. I was wondering if you could give me a pointer or a > hint on how to use wine's builtin mscms.dll. A simple DLL override in > .wine/config does not seem to do the job (using wine-20041210). Well, you have to realize that development on mscms in Wine has only been started a couple of months ago. My estimate is that it's now about 20% done and still missing basic functionality. And I have only weekends to spend time on it ;( So your best bet at this time is a native mscms. > (It works with a native mscms.dll file copied to the windows/system directory, > but with a specific application, makes it 5 times slower). The 5 times slow down you're seeing is not normal. Maybe you can investigate the problem a little more and report to the Wine development list at wine-devel(a)winehq.org? -Hans

1 0

Re: [LOSTWAGES] update the non-standard include files task (RESEND)
by Rémi Assailly 20 Jan '05

20 Jan '05

Selon "Dimitrie O. Paun" <dpaun(a)rogers.com>: > On Thu, Jan 20, 2005 at 02:58:22PM +0900, Mike McCormack wrote: > > > > So did you ;) Here's a merge of both. > > I don't do this on purpose, but you missed win.h again :) > Again, with feeling... > > -- > Dimi. > win.h still exists...

2 1

RpcImpersonateClient (and ImpersonateNamedPipeClient)
by Luke Kenneth Casson Leighton 20 Jan '05

20 Jan '05

1 0

Native comctl32.dll and native commctrl.dll
by Dripple 20 Jan '05

20 Jan '05

Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple

2 3