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

Wine Traffic #96 For 26 May 2001

By Brian Vincent

Table Of Contents


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

Mailing List Stats For This Week

We looked at 79 posts in 218K.

There were 26 different contributors. 13 posted more than once. 14 posted last week too.

The top posters of the week were:

1. Wine.conf Addition

22 May 2001 - 23 May 2001 (5 posts) Archive Link: "Configuration/Announce"

People: Eric PouechMike Bond

Eric Pouech posted the following announcement concerning the addition of a new section to the wine.conf configuration file and some new registry keys:

with today's CVS commit (for those who stay up to date with the latest developments), you'll have to modify your Wine configuration to reflect the changes.

First of all, your Wine configuration file now needs a WinMM section containing the following:

Not adding this will print the following message

Note that the above configuration will be shortly required, so don't wait before setting your configuration up

Next, you have also to add a key to your registry. To do so, create a sample file (let's call it foo) containing the following text:

then goto the <wine>/programs/regapi and compile the program the run:

that's it

Not applying the key in the registry will result in various errors in MIDIMAP_ functions (mainly if Wine is set up to use a native Windows system)

Maintainers are welcome to update theirs packages accordingly (default values are in documentation/samples/config & winedefault.reg)

Detailed information is available in documentation/multimedia.sgml.

Mike Bond pointed out it should be [HKEY_CURRENT_USER] rather than [HKEY_LOCAL_USER].

In addition, Alexandre thought that it would be a bad idea to have the hard-coded setup disappear. He thought it wouldn't be very user friendly to make these values go away when Wine had a reasonable chance at guessing the configuration.

2. What About XP?

18 May 2001 - 20 May 2001 (2 posts) Archive Link: "What about XP?"

People: Francois Gouget

A question was posted wondering what will happen with Wine with regards to Microsoft's latest XP incarnation. Basically this comes down to new applications taking advantages of additions to the Windows API. In the past a lot of vendors have avoided immediately using new stuff because they would break backwards capatibility with the older versions of Windows that users are inevitably using. Francois Gouget summed it up by saying:

I understand what you mean, but nope, I think we don't really care about XP.

Sure, one day we'll have to implement whatever new APIs are in XP, but this will come when an application needs it.

The Wine development is application driven, not Windows driven: what we want is for applications to run in Wine and the release of a new version of Windows changes nothing for the 99.99999% of applications that are already out there (and solitaire XP is not the most important app although I quite sure that it will be one of the first XP apps to run).

Now, if you were to ask about Office XP (if such a thing exists)...

In regards to Office XP, here's a little info on it.

3. Installing Office the Wrong Way

21 May 2001 - 22 May 2001 (7 posts) Archive Link: "problem starting winword 97SR2"

People: James Juran

Heiko Nardmann was trying to get Office up and running by copying some of the required files and creating the registry entries. In particular he was copying winword.exe, mso97.dll, and wwintl32.dll. By trial and error he was putting files into place as the app required them. In addition he added a font alias to take care of the annoying message you get upon starting office, namely with "Alias0" = "Tahoma,-adobe-helvetica-". But as James Juran pointed out, that doesn't always work:

You will need to run the installation program or manually copy all the registry entries from an existing installation. The Microsoft Office applications put tons of stuff in the registry which is necessary for them to run.

4. Differences in FreeType Versions

20 May 2001 (5 posts) Archive Link: "wineps include fix"

People: Ian PilcherDavid Hammerton

David Hammerton submitted a small change because the version of FreeType on his system had a different name for the header file. He was unable to #include <freetype/ftnames.h> because on his system it was <freetype/ftsnames.h>. After looking into the problem Ian Pilcher realized the difference in names between what he and David were using:

I just checked, and they appear to have changed the name between 2.0.1 and 2.0.2. I can't help wondering how the FreeType people expect any- one to keep up with this.

I guess I can do an autoconf check specifically for 2.0.1. I simply refuse to try to #ifdef every point release of FreeType. Down that road lies madness.

5. DLL Separation

15 May 2001 - 16 May 2001 (2 posts) Archive Link: "DLL separation and PROFILE functions"

People: Ian PilcherOve KaavenOve Kåven

I won't comment on this too much because the two emails pretty much speak for themselves. If you've heard this term of "DLL separation" in past issues this kind of summarizes an example. Ian Pilcher wrote to the list with:

DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism.

Under this assumption, adding 'IMPORTS = ntdll' to a DLL's file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file.

All of which is wonderful until you consider the following in ntdll.spec:

This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.)

Ove Kåven replied that DLL separation is "needed to be able to have Wine DLLs and Winelib apps be able to seamlessly import and use native PE DLLs" . He also added:

The profile functions are not exported and you should not use them. If you're trying to access the config file, use the registry API instead; for an example, see what Alexandre did in dlls/x11drv/x11drv_main.c. You'll see the reason Alexandre changed the .wine/config file format to the registry format.

You could use #defines in a .h file too, but you shouldn't add wine extensions without a *very* good reason. Alexandre has even advocated code duplication in some instances to keep DLL separation tight.

6. Wine Networking With SuSE and Mandrake Distributions

17 May 2001 - 21 May 2001 (7 posts) Archive Link: "Networking with Mandrake 8.0 and SuSE 7.1"

People: Steve FoxGerard Patel

Steve Fox was wondering why networking in Wine no longer worked after he upgraded to Mandrake 8.0:

I'm running Lotus Notes 5.04a under WINE with one of the January releases and its been working great for months. However, any release since February does not seem to do reliable networking on my Mandrake 8.0 system. I can occassionally actually get into my inbox and even open up a message, but I've never been able to read more than one.

Some cow-orkers using this same setup on Redhat 7.1 do not have this problem, but others using SuSE 7.1 do too.

Does anyone have any ideas why only networking would be affected and only on select distributions? It stumps me because all three mentioned distros use glibc-2.2 and gcc-2.96 (SuSE may use 2.95...not sure). On a related note, another cow-orker who is using Mandrake Cooker (development distro) and his own compiled kernel does not have this problem. I am on a token ring network, which I don't think should matter.

Rob Maurizzi said he had experienced the same problem with SuSE and their 2.2.18 kernel. However, if he compiled a stock kernel it worked ok. Gerard Patel mentioned that it would be better to try out a 2.4 kernel and work from there. But Steve couldn't try that with Mandrake's distribution because they didn't have the PCMCIA token ring patch applied in the standard distribution. However, he did try out the kernel from Mandrake's "Cooker" distribution and discovered it worked: "This weekend I upgraded to Mandrake's 2.4.4 kernel from Cooker (since it fixed both my mouse and token ring) and suddenly this problem has gone away (using Notes 5.0.7 and wine-20010305)."

7. Exposing Non-Windows Functions from DLL's

18 May 2001 (7 posts) Archive Link: "Question on exposing non-windows functions from dlls..."

People: Mike BondOve KaavenAlexandre JulliardIan PilcherOve Kåven

Mike Bond was wondering how to go about exposing functions:

I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c?

Also, from just a cursory glance at exec_wine_binary that I may need to wrap it to do some of the work that fork_and_exec and PROCESS_Create are doing, such as calling DOSFS_GetFullName. I'm not sure what, if anything, the server would need to know about this.

Ove Kåven replied, " The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows."

Mike wondered how to go about implementing those functions using the standard Win32 API. He wanted to know how to go about loading and running an image in-process. Ove reminded him to be careful of assuming that was what was actually happening (Unix semantics are not the same as Microsoft's). Similarly Alexandre mentioned:

You cannot do this with the Win32 API, that's true. And since the native msvcrt is implemented on top of the Win32 API, this means that msvcrt exec functions cannot possibly behave exactly like the Unix ones.

What you must do is find out the expected behavior of the msvcrt exec, and implement the same behavior; you should then be able to do this using the Win32 API, since this is how the native one does it.

Mike wrote back:

I have gone ahead and implemented most of the exec variants as described just terminating the previous process, the internal spawn implementation already provided a flag to accomplish this easily.

On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell.

As a note, it seems NT is doing the same thing as they end up with different address spaces and pids after execl.

And with in regards to the old argument that goes into the extent to which backwards engineering is legal. Ian Pilcher responded with:

Big disclaimer: I am not a lawyer; if you end up in court because you pay attention to anything I say, that's just too darn bad.

It depends on which country you're in. What you've done is classic "black box" reverse engineering, which has historically been protected by the U.S. legal system. Even the DMCA protects it as long as you don't decrypt anything.

UCITA in its unaltered form, however, legitimizes all those software license agreements that U.S. courts have found unenforceable. So I guess it's starting to depends on what state you're in if you're in the U.S.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.