Wine Traffic #99 For 5 Jul 2001 By Brian Vincent Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Mailing List Stats For This Week * Threads Covered 1. Direct Port Access 2. Teaching Old Dogs New Tricks 3. When You Look Up Redundant in the Dictionary... 4. Wine + Symlinks + Halflife Introduction This is the 99th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator). Some of the changes committed to CVS in the past few weeks include support for /dev/parport for direct port access, support for Traditional Chinese, ole32 separation was finished, and some changes to x11drv for fixing up some of the window management stuff that's come up in the past few weeks. We also saw wn20010629 unleashed. The release notes include the following changes: * Better font metrics support in Postscript driver using Freetype. * Major window management redesign (still in progress). * Message queues in wineserver to prepare for inter-process messaging. * DDE merged from Corel tree, plus various fixes. * 64-bit file size support. * Lots of bug fixes. Check out the changelog for more details: http://cvs.winehq.com/cvsweb/wine/ ChangeLog?rev=1.48&content-type=text/x-cvsweb-markup (http://cvs.winehq.com/ cvsweb/wine/ChangeLog?rev=1.48&content-type=text/x-cvsweb-markup) Not sure if any of you follow the stats, but technically these stats end on 7/ 1. Since there's some ongoing threads we'll wait for those to wrap up for the next issue and then do the stats from 7/1 on. Mailing List Stats For This Week We looked at 65 posts in 230K. There were 25 different contributors. 19 posted more than once. 14 posted last week too. The top posters of the week were: * 6 posts in 14K by Alexandre Julliard * 7 posts in 19K by Uwe Bonnes * 3 posts in 8K by Gilroy Billard * 4 posts in 8K by Heiko Nardmann * 4 posts in 12K by Marcus Meissner * Full Stats 1. Direct Port Access Archive Link: "Initializing Dosvm for direct port access" People: , Uwe Bonnes, Ove K?ven Uwe Bonnes had a program that needed to directly access a dongle in order to verify it's license. He posted a small patch that worked for him but wasn't sure if it was the proper way to do it. Ove K?ven replied, "I meant to reply sooner or later... it doesn't seem right to me to load the entire DOS subsystem for reading out the timer. Direct port access is probably not allowed for win32 apps under NT anyway? Perhaps there should be a fallback there for when the DOS subsystem is not loaded? Then again, I'm not sure how it's supposed to work... it probably can't hook the timer interrupt or set the timer rate or anything without upsetting the OS?" Alexandre wondered how the app responded under NT since that's the best behavior to imitate. Uwe replied that it didn't work and it seemed to be looking for some VXD's, however he hadn't installed it using --winver nt40. 2. Teaching Old Dogs New Tricks Archive Link: "Win16 calls by Win32 functions" People: Patrik Stridvall, Dmitry Timoshkov, Alexandre Julliard, , Patrik Stridval Patrik Stridvall wrote a response to a patch submitted by Dmitry Timoshkov: Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect "illegal" calls from Win32 to Win16. Just do winapi_check --cross-call-win32-win16 Unfortunately there is a bug in the CVS version of winapi_check (fixed in my tree) that makes this option output too many messages. However until it is updated just do "grep 'illegal call'" on the output. The result this is included below. Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions. I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be? Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences. Not that functions like DeleteObject are likely to have such problems but still... Dmitry replied: Well, as Alexandre already has pointed out, Win16 should be mostly implemented by using Win32. I agree with him that use of the 16-bit code should be eliminated as much as possible. Moreover, until now I just have replaced only obvious places: 16-bit functions which just thunk up to win32 without any argument processing. I'm not going to blindly replace 16-bit calls by 32-bit. I look into the code and do think twice before submitting a patch. Anyway, thanks for your comments. Patrik was concerned there might be a problem just replacing Win16 functions with Win32 because there might be undocumented features in one or the other. This also goes back to implementing whatever NT would do. Patrik pointed out quite a few examples that should be looked at. Alexandre Julliard's opinion was, " As a rule it is a good idea, but there are of course exceptions. Basically the rule should be that wherever you can choose between a Win16 or Win32 function to do something, you should pick the Win32 function. But in the cases where the Win16 and Win32 functions have different semantics, then of course you have to use the correct one, even if in some cases it means calling Win16 functions from Win32 (like for the GlobalAlloc stuff)." 3. When You Look Up Redundant in the Dictionary... Archive Link: "Re: configure.in patch" People: Marcus Meissner, Andreas Mohr, , Bang Jun-Young ...it says see redundant. Bang Jung-Young posted a patch that seemingly removed a redundant check for flex when running configure. Marcus Meissner said not to apply it because it really wasn't a redundant check. Marcus explained: The reason we check for 'flex' again is that the standard check sets LEX to 'lex' even if none is found, which lead to confusion during compile. Our check is similar, but it finds out if 'lex' is present and aborts configure if not. This has reduced compiling support queries :) Andreas Mohr agreed, but added that the configure output should be less confusing so the issue doesn't come up again. Bang Jun-Young then went on to post another patch that checked for yacc, byacc, and bison and exited if no suitable parser was found. 4. Wine + Symlinks + Halflife Archive Link: "GDI Memory Leak + err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this." People: adoniz@hushmail.com, Andreas Mohr, A user was having a problem getting Halflife to work and posted the following message: I got these errors while trying to do something a little uncommon: I have been running Halflife from my windows partiton just fine. But I wanted to remove the huge files and replace them with symlinks to a cdrom, but since I can't do symlinks on fat32 (is there a wine hack for this?? i think it would be a great idea!!), I figured I copy the basic files of HL to my linux partition, and symlink the huge pak files. So, I have /mnt/halflife and under there I have some symlinks. I went ahead and added these to my ~/.wine/config [Drive H] "Path" = "/mnt" "Type" = "hd" "Filesystem" = "vfat" Now, as root try running halflife with: cd /mnt/halflife ; wine hl.exe or wine h:\\halflie\hl.exe (or with all the command line options for opengl, software, etc) I get these errors and a SegFault from wine: /mnt/halflife# wine h:\\halflife\\hl.exe -- -console -toconsole -soft -w 640 -win err:local:LOCAL_GetBlock not enough space in GDI heap 0237 for 108 bytes err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 Segmentation fault whatever:/mnt/halflife# err:ntdll:RtlpWaitForCriticalSection Critical section 0x4065da54 wait timed out, retrying (60 sec) fs=0257 Running notepad.exe from /mnt/ works just fine. So something else is happening here... Email me if you need more info Andreas Mohr replied: Hmm, you do know that directory symlinks (*not* file symlinks, though !) are ignored by Wine per default ? Set [wine] "ShowDirSymlinks" = "1" if you *really* (and I mean "really", since it can have bad results) want to use this. Sharon And Joy Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.