Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

Wine Traffic #99 For 5 Jul 2001

By Brian Vincent

Table Of Contents

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:

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.

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:

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

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:

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

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.