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

Re: some ntdll functions [Virus checked]

by thomas.mertes＠t-mobile.at

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > > /************************************************************************** > > + * RtlUpperChar (NTDLL.@) > > + */ > > +CHAR WINAPI RtlUpperChar( CHAR ch ) > > +{ > > + return toupper(ch); > > +} > > It's better to avoid using locale dependent functions from an underlying > system because Wine internal code page almost always is different from OS > locale. The way to go is convert to unicode, do desired things, and convert > the result back to ansi. The implementation of RtlUpperString in rtlstr.c gave me the idea to use toupper: /************************************************************************** * RtlUpperString (NTDLL.@) */ void WINAPI RtlUpperString( STRING *dst, const STRING *src ) { unsigned int i, len = min(src->Length, dst->MaximumLength); for (i = 0; i < len; i++) dst->Buffer[i] = toupper(src->Buffer[i]); dst->Length = len; } The docu of RtlUpperChar says: RtlUpperChar returns the uppercase version of the specified character or returns the value specified by the caller for Character if the specified character cannot be converted. RtlUpperChar returns the input Character unconverted if it is the lead byte of a multibyte character or if the uppercase equivalent of Character is a double-byte character. To convert such characters, use RtlUpcaseUnicodeChar. --- End of docu -- IMHO RtlUpperChar has nothing to do for unicode chars. Is there a way to use Wine internal code page to do the conversion without converting to unicode and back? BTW: If it is not ok to use toupper several other places in wine have a problem: $ grep toupper */*.c */*/*.c */*/*/*.c | grep -v toupperW | grep -v str_toupper in wine-20030115 gives a longer list of usages of toupper. Specially msvcrt toupper seems also to use the function from libc. Greetings Thomas Mertes

Jan. 29, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Mike Hearn

> 1. One of the "documents" has blank client areas (mentioned previously); > these don't ever get drawn. > > 2. Another of the "documents" has a blank pane initially, but > if you diddle around a bit, it does draw. These sound like a problem I'm seeing with the Adobe SVG plugin, which means that unfortunately I have to go back to Windows during the day. Basically the app doesn't blit its backbuffer in response to WM_PAINT messages in my case, however, forcing it to redraw itself, for instance due to animation, or a mouseover script causing it to change makes it happen. I keep meaning to look into it, last time I tried I was pretty inexperienced at reading relay traces (well, still am :). -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 29, 2003

spyxx from msvc6.0 crashes on exit...

by Dan Kegel

spyxx from msvc6.0 crashes repeatably. Here's the recipe: $ wine spyxx.exe click the minimize widget on the client document click the quit widget on the app Bingo, unhandled exception. The traceback looks uninformative, so either the stack is corrupt or it's crashing in the very outer routine. Here's the output of +relay and the backtrace (ah, I love it now that the debugger just uses the terminal I started wine with!!): 08076498:Call kernel32.TlsGetValue(00000000) ret=78001322 08076498:Ret kernel32.TlsGetValue() retval=408e0f70 ret=78001322 08076498:Call kernel32.SetLastError(00000000) ret=7800132f 08076498:Ret kernel32.SetLastError() retval=00000000 ret=7800132f 08076498:Call kernel32.GetLastError() ret=78001314 08076498:Ret kernel32.GetLastError() retval=00000000 ret=78001314 08076498:Call kernel32.TlsGetValue(00000000) ret=78001322 08076498:Ret kernel32.TlsGetValue() retval=408e0f70 ret=78001322 08076498:Call kernel32.SetLastError(00000000) ret=7800132f 08076498:Ret kernel32.SetLastError() retval=00000000 ret=7800132f 08076498:Call kernel32.UnhandledExceptionFilter(40440900) ret=7800f914 wine: Unhandled exception, starting debugger... Unhandled exception: page fault on read access to 0x00000040 in 32-bit code (0x0041e214). In 32-bit mode. 0x0041e214 (spyxx.exe..text+0x1d214 in F:\spy\spyxx.exe): movl 0x40(%eax),%edi Wine-dbg> bt Backtrace: =>0 0x0041e214 (spyxx.exe..text+0x1d214 in F:\spy\spyxx.exe) (ebp=0001002f) Wine-dbg> quit WineDbg terminated on pid 8072e48 -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 29, 2003

Why is IOCTL_CDROM_READ_TOC so slow?

by Waldeck Schutzer

I just realized that IOCTL_CDROM_READ_TOC is used almost everywhere in mcicda and somewhere else, but on the other hand it is as fast as a snail. A 68-track CD took 10 minutes to scan in cdplayer and if you press play, another 10 minutes will pass before it even starts playing! It appears to be a good idea to cache the TOC somewhere, but where and how? Best, Waldeck

Jan. 29, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Dan Kegel

I've played with our MDI application a bit more, and have observed two kinds of bugs under cvs wine: First type: things not drawing, probably because of missing messages (we know the WM_NCPAINT message is AWOL, but it might be something else); 1. One of the "documents" has blank client areas (mentioned previously); these don't ever get drawn. 2. Another of the "documents" has a blank pane initially, but if you diddle around a bit, it does draw. 3. Maximizing any of the "documents" is supposed to make a minimize/maximize/close widget appear on the right-hand side of the toolbar, but it doesn't. Second type: things drawing in the wrong place: 4. The text box at the bottom of a three-panel window has its upper left corner in the right place, but its lower right corner is exactly one scrollbar width inset too far. The scrollbars are inset by that amount, too. That leaves the area where the scrollbars ought to be totally undrawn. Duane Clark is looking at the missing message problem in this and another app. Also, I'm setting up Linux and Wine for the guy who wrote our app so he can poke around and look for these problems himself; if nothing else, he can put together a minimal test case. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 29, 2003

Re: some ntdll functions [Virus checked]

by Dmitry Timoshkov

<thomas.mertes(a)t-mobile.at> wrote: > --- old_wine-20030115/dlls/ntdll/rtlstr.c Tue Nov 12 03:17:34 2002 > +++ new_wine-20030115/dlls/ntdll/rtlstr.c Sun Jan 26 00:03:56 2003 > @@ -516,6 +516,15 @@ > */ > > > /************************************************************************** > + * RtlUpperChar (NTDLL.@) > + */ > +CHAR WINAPI RtlUpperChar( CHAR ch ) > +{ > + return toupper(ch); > +} It's better to avoid using locale dependent functions from an underlying system because Wine internal code page almost always is different from OS locale. The way to go is convert to unicode, do desired things, and convert the result back to ansi. -- Dmitry.

Jan. 29, 2003

Re: some ntdll functions [Virus checked]

by Dimitrie O. Paun

On January 28, 2003 04:11 am, thomas.mertes(a)t-mobile.at wrote: > +NTSTATUS WINAPI RtlIntegerToUnicodeString(ULONG value, ULONG base,const > UNICODE_STRING *str); Thomas, It seems the patch got wrapped. Turn off automatic wrapping in your mail client before resending it. -- Dimi.

Jan. 29, 2003

Re: [dx8 patch 12]: huge cleanup + split

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 28 Janvier 2003 22:58, Andrew John Hughes a écrit : > On Tue, 28 Jan 2003 22:21:59 +0100 (CET) > > Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: > > why not file a bug report to NVidia ? > > after all only THEIR headers dont work... > > > > > Including glext.h appears to break the DLL for me. NVidia's GL > > > headers (gl.h) already define some of the > > > types specified in glext.h. I presume X installs glext.h, but I've > > > not had a conflict between the two headers > > > before. > > > > > > In file included from d3d8_private.h:30, > > > from device.c:35: > > > /usr/local/include/GL/glext.h:3142: conflicting types for > > > `glCopyTexSubImage3DEXT' > > > /usr/local/include/GL/gl.h:2486: previous declaration of > > > `glCopyTexSubImage3DEXT' > > > /usr/local/include/GL/glext.h:3566: conflicting types for > > > `glColorSubTableEXT' > > > /usr/local/include/GL/gl.h:2446: previous declaration of > > > `glColorSubTableEXT' > > > /usr/local/include/GL/glext.h:4372: conflicting types for > > > `glTbufferMask3DFX' > > > /usr/local/include/GL/gl.h:2984: previous declaration of > > > `glTbufferMask3DFX' > > > /usr/local/include/GL/glext.h:4406: conflicting types for > > > `glTextureColorMaskSGIS' > > > /usr/local/include/GL/gl.h:3050: previous declaration of > > > `glTextureColorMaskSGIS' > > > > > > -- > > > Andrew :-) > > > > > > Please avoid sending me Word or PowerPoint attachments. > > > See http://www.fsf.org/philosophy/no-word-attachments.html > > > > > > "Windows is the one true OS. MS invented the GUI. MS invented > > > the 32 bit OS. MS is open and standard. MS loves you. We have > > > always been at war with Oceania." > > > > > > ATTACHMENT part 2 application/pgp-signature > > > > ===== > > Sylvain Petreolle > > spetreolle(a)users.sourceforge.net > > Fight against Spam ! http://www.euro.cauce.org/en/index.html > > ICQ #170597259 > > > > "Don't think you are. Know you are." Morpheus, in "Matrix". > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > > Fortunately, the problem is lessened by the fact that the headers don't > appear to be installed by default. However, there is an incentive to > replace the X ones with the NVidia ones as they "contain the most up to > date versions of NVIDIA's OpenGL extensions". > Looking round their website, there doesn't seem to be anywhere to report > the conflict or give any feedback to them at all - I couldn't find any > contact details. Not suprising when you think that they must be the only > company to supply executable headers (implying that they are developed on a > Win32 system). you are right, i'm fixing this problem now (thx to your reply) > It's not all bad though - in the Developer's corner of their web-site, > there seem to be some good examples of DirectX stuff, with source. Might > be useful for testing Wine... (although I don't know the legalities - they > jseem to be freely downloadable) yes they are usefull, as nvidia effect browser is perfect for testing vertex shader emulation code ;) Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Nv6Up7NA3AmQTU4RAluJAJ9zrPZwjAbnRriQ2N/JBgbW7zvQdwCeKT5B EM+7ZI5WepmnAuB8A21Wye0= =cHDs -----END PGP SIGNATURE-----

Jan. 28, 2003

Re: [dx8 patch 12]: huge cleanup + split

by Andrew John Hughes

On Tue, 28 Jan 2003 22:21:59 +0100 (CET) Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: > why not file a bug report to NVidia ? > after all only THEIR headers dont work... > > > Including glext.h appears to break the DLL for me. NVidia's GL > > headers (gl.h) already define some of the > > types specified in glext.h. I presume X installs glext.h, but I've > > not had a conflict between the two headers > > before. > > > > In file included from d3d8_private.h:30, > > from device.c:35: > > /usr/local/include/GL/glext.h:3142: conflicting types for > > `glCopyTexSubImage3DEXT' > > /usr/local/include/GL/gl.h:2486: previous declaration of > > `glCopyTexSubImage3DEXT' > > /usr/local/include/GL/glext.h:3566: conflicting types for > > `glColorSubTableEXT' > > /usr/local/include/GL/gl.h:2446: previous declaration of > > `glColorSubTableEXT' > > /usr/local/include/GL/glext.h:4372: conflicting types for > > `glTbufferMask3DFX' > > /usr/local/include/GL/gl.h:2984: previous declaration of > > `glTbufferMask3DFX' > > /usr/local/include/GL/glext.h:4406: conflicting types for > > `glTextureColorMaskSGIS' > > /usr/local/include/GL/gl.h:3050: previous declaration of > > `glTextureColorMaskSGIS' > > > > -- > > Andrew :-) > > > > Please avoid sending me Word or PowerPoint attachments. > > See http://www.fsf.org/philosophy/no-word-attachments.html > > > > "Windows is the one true OS. MS invented the GUI. MS invented > > the 32 bit OS. MS is open and standard. MS loves you. We have > > always been at war with Oceania." > > > ATTACHMENT part 2 application/pgp-signature > > > ===== > Sylvain Petreolle > spetreolle(a)users.sourceforge.net > Fight against Spam ! http://www.euro.cauce.org/en/index.html > ICQ #170597259 > > "Don't think you are. Know you are." Morpheus, in "Matrix". > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com Fortunately, the problem is lessened by the fact that the headers don't appear to be installed by default. However, there is an incentive to replace the X ones with the NVidia ones as they "contain the most up to date versions of NVIDIA's OpenGL extensions". Looking round their website, there doesn't seem to be anywhere to report the conflict or give any feedback to them at all - I couldn't find any contact details. Not suprising when you think that they must be the only company to supply executable headers (implying that they are developed on a Win32 system). It's not all bad though - in the Developer's corner of their web-site, there seem to be some good examples of DirectX stuff, with source. Might be useful for testing Wine... (although I don't know the legalities - they jseem to be freely downloadable) -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html "Windows is the one true OS. MS invented the GUI. MS invented the 32 bit OS. MS is open and standard. MS loves you. We have always been at war with Oceania."

Jan. 28, 2003

Re: [dx8 patch 12]: huge cleanup + split

by Sylvain Petreolle

why not file a bug report to NVidia ? after all only THEIR headers dont work... > Including glext.h appears to break the DLL for me. NVidia's GL > headers (gl.h) already define some of the > types specified in glext.h. I presume X installs glext.h, but I've > not had a conflict between the two headers > before. > > In file included from d3d8_private.h:30, > from device.c:35: > /usr/local/include/GL/glext.h:3142: conflicting types for > `glCopyTexSubImage3DEXT' > /usr/local/include/GL/gl.h:2486: previous declaration of > `glCopyTexSubImage3DEXT' > /usr/local/include/GL/glext.h:3566: conflicting types for > `glColorSubTableEXT' > /usr/local/include/GL/gl.h:2446: previous declaration of > `glColorSubTableEXT' > /usr/local/include/GL/glext.h:4372: conflicting types for > `glTbufferMask3DFX' > /usr/local/include/GL/gl.h:2984: previous declaration of > `glTbufferMask3DFX' > /usr/local/include/GL/glext.h:4406: conflicting types for > `glTextureColorMaskSGIS' > /usr/local/include/GL/gl.h:3050: previous declaration of > `glTextureColorMaskSGIS' > > -- > Andrew :-) > > Please avoid sending me Word or PowerPoint attachments. > See http://www.fsf.org/philosophy/no-word-attachments.html > > "Windows is the one true OS. MS invented the GUI. MS invented > the 32 bit OS. MS is open and standard. MS loves you. We have > always been at war with Oceania." > ATTACHMENT part 2 application/pgp-signature ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 28, 2003