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

shlwapi.dll: IUnknown_CPContainerInvokeParam

by Cihan Altinay

http://www.winehq.org/pipermail/wine-patches/2005-October/021101.html Is there are reason why this patch wasn't applied? G-Ware crashes when invoking help without it. Cheers, Cihan

Dec. 12, 2005

Re: MB_USEGLYPHCHARS glyph table

by Willie Sippel

Am Montag, 12. Dezember 2005 02:16 schrieb Mike McCormack: > Willie Sippel wrote: > > I just tried to find out why Poser won't display any fonts (no luck, > > BTW), when I noticed the obviously quite common "MB_USEGLYPHCHARS not > > supported" fixme. I don't know if it's related to the missing fonts > > thing, so I googled a little. In case someone wants to implement this > > (the unicode stuff is _way_ over my head), I found this description and a > > glyph table - there seems to be next to know useful info on > > MB_USEGLYPHCHARS on MSDN, so maybe it helps: > > > > http://blogs.msdn.com/michkap/archive/2005/02/26/381020.aspx > > Maybe you could write a test case for it? Seems like you'd just call > WideCharToMultiByte on a WCHAR string like { 1,2,3,4,5,6,7,8 }, then > check the output for the cases that MB_USEGLYPHCHARS is specified and > isn't. The output strings should be different. Perhaps try it on a few > different code pages? > I would, if I had the skills... :-/ Really, I only know PHP and a little C++/ Qt, that's about it. The only patch for Wine I've written so far added a few additional PCI IDs for wined3d, and that was also the first time I ever touched plain C. ;-) My mail was more about the link to the glyph table, as it seems to be pretty much undocumented, in case that's the reason it wasn't implemented. > Mike Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

Dec. 12, 2005

Re: MB_USEGLYPHCHARS glyph table

by Mike McCormack

Willie Sippel wrote: > I just tried to find out why Poser won't display any fonts (no luck, BTW), > when I noticed the obviously quite common "MB_USEGLYPHCHARS not supported" > fixme. I don't know if it's related to the missing fonts thing, so I googled > a little. In case someone wants to implement this (the unicode stuff is _way_ > over my head), I found this description and a glyph table - there seems to be > next to know useful info on MB_USEGLYPHCHARS on MSDN, so maybe it helps: > > http://blogs.msdn.com/michkap/archive/2005/02/26/381020.aspx Maybe you could write a test case for it? Seems like you'd just call WideCharToMultiByte on a WCHAR string like { 1,2,3,4,5,6,7,8 }, then check the output for the cases that MB_USEGLYPHCHARS is specified and isn't. The output strings should be different. Perhaps try it on a few different code pages? Mike

Dec. 12, 2005

Problems generating c++ project since wine 0.9.3

by Sergio

Hi all, I've been having problems trying to compile one c++ project since latest wine version (0.9.3). This project compiled and worked fine with previous versions. The error messages look like: /usr/include/wine/windows/unknwn.h:26: error: expected unqualified-id before ‘{’ token ... /usr/include/wine/windows/objidl.h:66: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/oaidl.h:553: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/propidl.h:287: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/oleidl.h:46: error: expected unqualified-id before ‘:’ token ... Is there something that I am misisng when generating this project? Or is this a known issue? Thanks. Sergio.

Dec. 12, 2005

MB_USEGLYPHCHARS glyph table

by Willie Sippel

Hi there. I just tried to find out why Poser won't display any fonts (no luck, BTW), when I noticed the obviously quite common "MB_USEGLYPHCHARS not supported" fixme. I don't know if it's related to the missing fonts thing, so I googled a little. In case someone wants to implement this (the unicode stuff is _way_ over my head), I found this description and a glyph table - there seems to be next to know useful info on MB_USEGLYPHCHARS on MSDN, so maybe it helps: http://blogs.msdn.com/michkap/archive/2005/02/26/381020.aspx Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

Dec. 12, 2005

Re: OLE without TLS libraries

by Cihan Altinay

Ok, I am replying to myself as the problem persists. Quoting Cihan Altinay <cihan(a)uq.edu.au>: > Quoting Marcus Meissner <marcus(a)jet.franken.de>: > > > On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote: > > > Hi, > > > > > > having a Xen system my Linux tls library path is not > > > in place (renamed to /lib/tls.disabled). > > > When I run a program that uses OLE/DCOM (with native > > > ole libraries) it crashes immediately. Using > > > LD_LIBRARY_PATH=/lib/tls.disabled wine program > > > makes it work again. > > > I am not sure if this is true for all OLE apps. > > > > > > Is this known/expected behaviour or a bug? > > > > Do you have a backtrace of the crash or similar? > > Just wanted to create one with the latest CVS but it seems > it was fixed some days ago. I investigated a bit and to my > surprise the problem was in x11drv which was patched > 2005-12-06. Obviously this is not true. I found out that the following happens: When I ran the program first thing this morning I got the following (with disabled tls libraries): wine: Unhandled page fault on read access to 0x7e7ffd80 at address 0xb7f223a3 (thread 000f), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x7f6c5560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000d, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7f6c5560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000b, blocked by 000f, retrying (60 sec) err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("rpcrt4.dbg") wine: Unhandled exception 0x0eedfade at address 0x0000:0x404cc6f0 (thread 0009), starting debugger... WineDbg starting on pid 0x8 (I couldn't get it to crash yet with WINEDEBUG=relay so that's all output I can give at the moment...) If I run it again directly afterwards it works fine - until I wait for some time (after wineserver has quit) or if I start other programs (like firefox) it seems. That makes me suspect that it crashes if the process memory of one of the libraries (or the program itself) is not in the cache anymore and has to be reloaded. The program is G-Ware which can be downloaded here: http://clearone.com/docs/downloads/G-Ware5.0.6.zip [~20MB] (works only with native ole) When starting up it uses DCOM to start a "server" (PSRServe.exe). Two comments on this: - Even if it crashes it succeeds starting the server - If the server is started manually (wine psrserve.exe) the program doesn't crash As said before, the program works fine when the TLS libraries are in the library path. Cheers, Cihan

Dec. 12, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Peter Beutner

Vitaliy Margolen schrieb: > Sunday, December 11, 2005, 11:23:18 AM, Peter Beutner wrote: >>The name suggests it's more about signal handling than a place to throw every arch >>dependent code in it ;) >>But that's not the point. >>I just thought it might not be the best solution to duplicate that check in every signal >>handler. >>Besides what about somebody changes the Dr* registers in an exception handler invoked by >>an exception raised by the application via RaiseException(i.e. not via a signal handler >>called by the kernel)? >>*Every* installed exception handler can change the registers in the CONTEXT structure, >>thats why I think it would be the easiest way to implement it in __regs_RtlRaiseException. > > > Good point but it needs a test. Besides I'm not sure that we will change > any registers in that case at all. (just checked and no, we won't change > any registers). hm what exactly do you need to test? And afaik the registers will be changed when the CONTEXT structure is restored on return from __regs_RtlRaiseException. see __wine_call_from_32_regs.

Dec. 11, 2005

Re: Small CVS-Update-Script

by Christian Lachner

OK, more news. I updated my cvs-script a little bit (nothing really noticeable) but that's not all. Since everybody seems to have changed to GIT i wrote a git-version of my wine-update-script. Features, functionality and so on are the same as in the cvs-version. getwinecvs.sh is now version: 0.36 getwinegit.sh is version: 0.1 (based on getwinecvs.sh v0.36)

Dec. 11, 2005

workspace switching and fullscreen apps

by Tomas Carnecky

When I switch from a fullscreen app (WoW) to another workspace, the screen is black for ~3 seconds, but switching back to the app happens instantly, no black screen or other delays. This doesn't happen with cedega and it didn't happen with wine from about a month ago. I remember that when I switched from WoW to another workspace under gnome (metacity windows manager) the window was minimized and maximized about three or four times in a very short time (~1 second) and the screen was flickering because of this. Seems like the game recieved too many minimize/maximize messages, mor than it should have. Now I have e17 and maybe their window manager handles this differently. Is there anything I could try to improve the behaviour? I've tried to comment out the maximize/minimize code in the source, because WoW doesn't really need to know, but that isn't the best solution. thanks tom

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Vitaliy Margolen

Sunday, December 11, 2005, 11:23:18 AM, Peter Beutner wrote: > Vitaliy Margolen schrieb: >> Sunday, December 11, 2005, 10:36:39 AM, Peter Beutner wrote: >> >>>Vitaliy Margolen schrieb: >>> >>>>Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote: >>>> >>>> >>>>>Vitaliy Margolen schrieb: >>>>> >>>>> >>>>>>ChangeLog: >>>>>>ntdll: Program could modify Dr* registers in segv_handler too. >>>>>> >>>>> >>>>>Doesn't every exception handler could modify these registers? >>>>>So probably it would be better to put this check into RtlRaiseException? >>>> >>>>Nope can't. __regs_RtlRaiseException is common for all the platforms >>>>(implemented in dlls/ntdll/exception.c). While Dr* registers are not >>>>available on all the platforms. >> >> >>>What about putting some >>>#ifdef __i386__ >>>... >>>#endif >>>around it? >> >> >> That's what signal_*.c are for... > The name suggests it's more about signal handling than a place to throw every arch > dependent code in it ;) > But that's not the point. > I just thought it might not be the best solution to duplicate that check in every signal > handler. > Besides what about somebody changes the Dr* registers in an exception handler invoked by > an exception raised by the application via RaiseException(i.e. not via a signal handler > called by the kernel)? > *Every* installed exception handler can change the registers in the CONTEXT structure, > thats why I think it would be the easiest way to implement it in __regs_RtlRaiseException. Good point but it needs a test. Besides I'm not sure that we will change any registers in that case at all. (just checked and no, we won't change any registers).

Dec. 11, 2005