July 2002 - Wine-devel - list.winehq.org

2 quick things on the Cygwin/Mingw port
by Steven Edwards 03 Jul '02

03 Jul '02

Hola 1. This is simple but as you guys know I have this lysdexic thing when it comes to configure. Libwine needs to import certain functions from the c library to compile, at present it is hard coded for -lmsvcrt. This needs to be changes to import -lcygwin if configure detects a cygwin host/target. I know its simple we just need to have the check in configure that sets CLIBRARY=(lmsvcrt or lcygwin) then Makefile.in in libwine needs to be changed like this: libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) -lmsvcrt to libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) $(CLIBRARY) 2. I was able to get Wineserver.exe to compile under cygwin when I stubbed getthreadcontext and setthreadcontext. Kernel32.dll implements these to functions so on the Mingw or Cygwin port can I import it for these needed functions? Thanks and have a good 4th Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Re: DOSFS_GetPathDrive patch
by Alexandre Julliard 03 Jul '02

03 Jul '02

Duane Clark <dclark(a)akamail.com> writes: > In particular, it calls GetFileAttributes with a path like: > \c\Xilinx\bin\lib\tcl8.3\init.tcl > which fails in DOSFS_GetPathDrive. > > Changelog: Check for absolute Unix path in DOSFS_GetPathDrive The problem I see with that is that the app can no longer access a directory that has the same name as a drive root (for instance if you have a /msdos drive then the app cannot use \msdos to mean c:\msdos). Where does the Xilinx path come from? That's not a valid Windows path anyway so that looks like a bug. -- Alexandre Julliard julliard(a)winehq.com

2 1

(no subject)
by Steven Edwards 03 Jul '02

03 Jul '02

Anyone planning on attending the Linux World Expo? I was going to be in the Bay area on the 12th anyway to tour Berkley so I think I'm going to extend my trip to make the show. Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Bug in RegEnumValueA ?
by Massimo 03 Jul '02

03 Jul '02

Again investigating AutoCAD r14 app under wine, I found a bug that make app hang when some registry values are present. At first I've made a script that cleans up registry before launching AutoCAD,but this was only a way-around to the problem. Looking at relay output, I found a loop in calling RegEnumValueA : // @@@@ START OF LOOP BLOCK HERE......... :Call advapi32.dll.RegEnumValueA (000000cc,00000001,40486844,404868ec,00000000,404868f4,41e62020, 404868fc) ret=008a3850 :Call ntdll.dll.NtEnumerateValueKey (000000cc,00000001,00000001,40486544,00000100,40486540) ret=406afb24 :Ret ntdll.dll.NtEnumerateValueKey() retval=00000000 ret=406afb24 :Call ntdll.dll.RtlUnicodeToMultiByteSize(4048653c,40486558 L"REGPATH\\\\HKEY_LOCAL_MACHINE\\Software\\Autodesk\\AutoCAD\\R1 4.0\\ACAD-2452448:80143967\\AutodeskApps\\LsObj",0000000e) ret=406afc03 :Ret ntdll.dll.RtlUnicodeToMultiByteSize() retval=00000000 ret=406afc03 :Call ntdll.dll.RtlUnicodeToMultiByteN (40486844,00000007,00000000,40486558,0000000e) ret=406afc24 :Ret ntdll.dll.RtlUnicodeToMultiByteN() retval=00000000 ret=406afc24 :Call ntdll.dll.RtlUnicodeToMultiByteSize(40486538,40486566 L"\\\\HKEY_LOCAL_MACHINE\\Software\\Autodesk\\AutoCAD\\R14.0\\AC AD-2452448:80143967\\AutodeskApps\\LsObj",000000bc) ret=406afc77 :Ret ntdll.dll.RtlUnicodeToMultiByteSize() retval=00000000 ret=406afc77 :Call ntdll.dll.RtlNtStatusToDosError(80000005) <--ERROR HERE ! ret=406afd5d :Ret ntdll.dll.RtlNtStatusToDosError() retval=000000ea ret=406afd5d :Ret advapi32.dll.RegEnumValueA() retval=000000ea ret=008a3850 <-- MORE DATA AVAILABLE RETURN (AUTOCAD KEEPS TRYING TO GET DATA) // @@@@ END OF LOOP BLOCK HERE Here RegEnumValueA returns an error of invalid buffer; Looking into code it seems to me that the NtEnumerateValueKey() used to find the largest name and value sizes of keys to be enumerated returns a wrong size; next use for reading the key gives an arror of buffer overflow, being it allocated with wrong (too small) size. AutoCAD keeps trying to get the keys/values, in and endless loop. Looking more with some debug print statements, it appears that Autocad allocates 4 bytes of buffer for the value, but RegEnumValueA needs much more, 94 in this case, giving an Out-Of-Buffer error back. It seems to me that the 94 bytes are for the name of the key, not for the value.... Regards Max

3 2

Re: Fix for [bug 829] DIB_DirectDrawSurface_Blt same src./dest. surface = screen corruption
by Lionel Ulmer 03 Jul '02

03 Jul '02

The patch looks fine to me. There is just one comment opn these lines : > + if (SameSurface) > + { > + static BOOL WarnSurface = FALSE; > + if (!WarnSurface) > + { > + FIXME("\tSame source and destination could cause display problems\n"); > + WarnSurface = TRUE; > + } > + } Why did you add this ? If you verified your patch and it's working, why add additionnal debug informations that will only confuse people :-) ? Moreover, I do not know the performance hit between a 'memcpy' and a 'memmove', but well, one could have put the old code in a if (!SameSurface) to have the fastest path available to the most common case. A part from these nitpicks, the patch looks fine and I will test it this evening on FalloutTactics to see if it fixes the screen corruption :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Re: Fix for [bug 829] DIB_DirectDrawSurface_Blt same src./dest. surface = screen corruption
by Ian D. Stewart 03 Jul '02

03 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 July 2002 18:57, Tony Lambregts wrote: > Change log: Fix screen corruption when source and destination are the > same surface and areas are the same size. I've applied this patch. While the on-screen garbage has not entirely gone away, it does appear to be better (but then, it could just be my imagination...). No change to hang-up after playing movies. Ian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Iv8YAjpHQQmBAUMRAtjMAJ0eSyS5Z06Kr51uLloq/Nn9CuKQXwCglPrD Ff3Vfg2m2tcqpA1VkeQI9+0= =IPbG -----END PGP SIGNATURE-----

2 1

Arts, DSound, and Media Player
by Jeremy Shaw 03 Jul '02

03 Jul '02

Hello, I am trying to get media player to work with the winearts audio driver. I compiled the latest source from CVS, added Drivers="winearts.drv" to the config file, and installed media player. When I try to play a file (like an mp3), I do not get any audio. If I watch the elapse time, it will increment normally for a few seconds and then start playing super fast. Also when it starts playing super-fast I get the following error a bunch of times: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=17640 < primary_done=49392) At this point in time I know very little about what is wrong. Do you guys (we are all guys ???) think it is a problem with the wine source, my build of KDE, or just some messed up config files. Or perhaps I just installed too many native DLLs trying to make media player work? I will keep hacking away, but any guidance will be highly valued. I have not gotten ever gotten sound using the winearts driver, but so far I have only tried media player. Thanks in advance, Jeremy Shaw.

2 1

Re: [help] GDI text fonts
by Huw D M Davies 03 Jul '02

03 Jul '02

On Wed, Jul 03, 2002 at 04:54:18PM +0800, leanne wrote: > Huw D M Davies wrote: > > > > >It's still not clear to me whether you're using XServer rendered fonts > >or client side (Wine) rendered fonts. Could you send me the > >--debugmsg +font,+xrender log ? > > > >Huw. > > > Hello, > > I have checked cvs today and found that it supports to download tt > fonts to printer but the position of the text messes up. > Maybe it's a bug. > > I still find the font of the interface is very ugly, what do you think? > Attached please find the log and screenshot. > Very thanks. > > trace:font:DumpFontList Family: L"AR PL Mingti2L Big5" > trace:font:DumpFontList L"Reguler" > trace:font:DumpFontList Family: L"AR PL KaitiM Big5" > trace:font:DumpFontList L"Regular" There's a problem with Type42 font downloads, a workaround for this to edit generic.ppd and change the line *TTRasterizer: Type42 to *TTRasterizer: None this will tell Wine to send download the font as a Type 1 outline which should work. Do you mean that the roman (English) font is ugly (since I have no idea whether the Chinese characters look ok maybe you let me know how they look)? You only have two fonts installed (see the above fragment from the log), so the english text has to come from one of these fonts. What you may want to do is to install some fonts like Arial, Times New Roman etc. You could either copy these from a Windows installation (or add a line to the [FontDirs] section of config to point at an existing Windows partition font directory), or you can download a selection of the core Windows fonts from Microsoft's website. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Still getting this error
by Steven Edwards 03 Jul '02

03 Jul '02

With the last release I can build and use wine but with the current CVS I still get the following errors. Warning: loading builtin gdi32.dll, but native version already present. Expect trouble. Warning: loading builtin user32.dll, but native version already present. Expect trouble. wine: Unhandled exception, starting debugger... I am still not able to track down the patch that causes this. I have a clean WINE with no windows on any of my drives in my slackware box. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 1

Re: Private Profile Regression Test
by Dmitry Timoshkov 03 Jul '02

03 Jul '02

"Joshua Thielen" <thielen(a)netprince.net> wrote: > Anyhoo, please let me know what you think - are the tests sufficient, > too much, not written properly? etc. First of all, thank you very much Joshua! Really great work! A couple of comments though: /* * Special case: NULL lpReturnedString with size > 0 * This causes an application error in win2k. Let's make wine better :) */ IMO it's not very good idea to make some tests succeed under Wine, which clearly crashes under win2k. That would play some bad role in the case of the back porting Wine code to Windows, since some code, internal to Wine, could rely on that forbidden API behaviour. I also have the following failures under win2k: Number of bytes read do not match FAIL: c:\result.ini does not match compare1.ini Number of bytes read do not match FAIL: c:\result.ini does not match compare2.ini -- Dmitry.

2 2