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 #15 For 1 Nov 1999

By Eric Pouech

Table Of Contents

Introduction

This is the fifteenth 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).

There is also a new Wine version (991031). For very obscure reasons, this release has been dubbed HalloWine (go figure out why !). Here's the main changes:

Mailing List Stats For This Week

We looked at 96 posts in 332K.

There were 37 different contributors. 16 posted more than once. 14 posted last week too.

The top posters of the week were:

1. ICMP

 Archive Link: "ICMP"

People: , Francois Gouget

Francois Gouget provided a first implementation of the ICMP DLL. Basically, this DLLs implements a raw socket access (useful for ping or traceroute commands). The Winsock 1.x DLLs do not provide such a feature, so Microsoft created this DLL. The Winsock 2.0 now provides the notion of raw socket, which could make ICMP obsolete, but Microsoft still ships for backward compatibility. Anyway some programs (like Turnpike) make use of it.

There was some discussion around the creation of a new DLL (some details have been proposed for DEVELOPERS-HINTS file), and also legal issues (to know whether or not the source could be included). As you may know, Wine licensing model is closer to BSD than to GPL; this implies that, for example, GPL source code cannot be included into Wine. Francois's code was based, according to him, on non copyrighted material, unlike some headers in his patch stated.

2. Starting in Wine

 Archive Link: "Starting in Wine"

People: , Lionel Ulmer

Some people asked on methods to start hacking in Wine. So here are some hints for that (they shall make their way soon into Wine documentation). This is derived from a mail from Lionel Ulmer.

The best way to start is to take a Windows application and try to fix what doesn't work.

First of all, be sure you're familiar with the Wine's debugging and tracing facilities. You need to read and understand:

Then, depending on the cause of the misbehavior, you have to adopt different strategies.

If the program crashes inside Wine (e.g. the last stack frame inside Wine's debugger lists a wine file), you can then directly look at the code, peek the variables... and get some idea of what goes wrong. You may also need to rerun the program with the correct -debugmsg switch (normally the one(s) used by the DLL that crashed). In most of the cases, crash is related to this DLL, so you will not have to dig elsewhere.

If the program crashes inside its code (e.g. the last stack frame inside program's code segment), then things are becoming trickier. What you can do (to start with), is to rerun the program with -debugmsg +relay enabled (and/or snoop) and to try to pinpoint is the faulty address appears somewhere in relay, but that's way trickier than the previous case.

If the program doesn't do what it is supposed to do (as in Windows), try to localize the DLL that is likely to behave incorrectly. Then, rerun with -debugmsg for the channels that this DLL uses and look at the calling parameters and return values. Try to find from that which function behaves incorrectly. Sometimes, if the trace generated from running the program spits out 'fixme:xxx:foo(...); stub', it means that function 'foo' is not correctly implemented, and you know where to look at.

There are many other failure cases (like critical section timeouts, other types of signals entering the debugger...), but which require some more knowledge of Wine internals, and are not the easiest ones to start with.

Anyway, when you think you have identified where a function is not correctly implemented, you can start fixing it. Of course, be sure to have all the related SDK material at hand (http://msdn.microsoft.com provides most of the SDK online, you just need a free registration). Beware, that some details have changed between Windows's version, and that a fix can apply to one version, but not to the other (and there are functions behaving differently on different versions, in particular between Windows 9x and NT).

If you're not 100% sure of what you shall be fixing (or how to do it), you can always ask you questions, or post RFC on the fix on wine-devel.

3. Registry alert

 Archive Link: "Registry alert"

People: , Marcus Meissner

For those of you who have updated your CVS tree (or downloaded a Wine package) strictly older than Sunday, October 24th beware that there is some potential breakage of the registry. To fix it (and get all of Marcus Meissner fixes on your machine), get an older Wine version (older than Wednesday should be fine), and also check that your wine configuration files (~/.winerc, wine.conf...) do not contain comments (starting by ';') after a configuration line. For example,

AltCurrentUserFile= ; alternate registry file name: HKCU

should be changed into

; alternate registry file name: HKCU
AltCurrentUserFile=

in the whole [registry] section.

4. VxD:s, Wine and FreeMWare

 Archive Link: "VxD:s, Wine and FreeMWare"

People: Patrik Stridval, Ulrich Weigand, 

From Ulrich Weigand interview by the Irish Linux User Group came some questions regarding some convergence between FreeMWare and Wine (Ulrich contributes to both of them). (Note: FreeMWare is an open-source project to contribute something similar to VMWare).

Patrik Stridval asked whether
it will be possible to use FreeMWare with Wine in order to run VxD:s and/or NT drivers that requires running in ring 0?

Ulrich answered
as far as current plans go, FreeMWare won't touch the real hardware at all. There will be VxDs running inside the VM, if you run Windows, but those only access the emulated hardware...

 

 

 

 

 

 

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.