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:
Check out the changelog for more details: 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.
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.
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-win16Unfortunately 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).
...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.
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=0257Running 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.