Wine Traffic #71 For 27�Nov�2000

By Eric Pouech

Table Of Contents


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

Ove Kaaven pointed out in last week issue (BROKEN KCREF) that the Drunkard site was building .DEB packages, not .RPM ones... Thanks for correcting.

Mailing List Stats For This Week

We looked at 63 posts in 175K.

There were 25 different contributors. 14 posted more than once. 18 posted last week too.

The top posters of the week were:

1. Headlines


2. Direct drive access

17�Nov�2000�-�21�Nov�2000 (7 posts) Archive Link: "PATCH: INT13 (READ/WRITE SECTORS)"

People: Joerg Mayer,�David Elliot,�Frank Cornelis,�

Frank Cornelis submitted a patch that allowed direct access thru Int 13 emulation to a physical driver. By direct access, it means reading and writing sectors, whatever the filesystem is.

Joerg Mayer wondered why, in the patch, Frank didn't
use the devices from the wine.conf file

David Elliot guessed
one reason is that the devices in the wine.conf generally point to a partition. Now obviously with floppies the device would match, but for a hard-drive it's different. In fact, it really ought to allow assigning a numbered BIOS INT13 device to a specific device separate from the drive letter definitions. Like:

'Admiral' Coeyman reported he, once, wrote a similar patch, but his also allowed to turn on/off the write feature to a device (Frank restricted the read/write access rights to floppy only, assuming hard drives access was too error prone). (For the records, the patch has never been applied).

'Admiral' also suggested [Int13] was a too restrictive name for a section. Here could also be added the direct write access to physical devices, and any other goodies requested for a better BIOS emulation.

Frank was still pitchy about security features. He went on:
Giving wine access to a hard disk via INT13 only is useful if, lets say C is on /mnt/myC and on /mnt/myC the device /dev/hda1 is mounted. Then we can give wine access to /dev/hda as BIOS device 0x80 _if_ your flag in a wine.conf BIOS section allows such low level access.

But, the question is why providing low level access since it could become a big security issue. We are on linux because of the many viruses under DOS and now we're about to implement _the_ virus interrupt INT13. I needed low level INT13 access to write the boot sector of a floppy in order to make a Setup program for my OS. I personally believe that we should restrict INT13 only to access /dev/fdx devices since it could become very dangerous when we give full INT13 access to win32 programs. (or be could disable writing sectors for (virtual) hard disks thus only allowing readings of sectors).

'Admiral' agreed with Frank's comments - even if root would need, under certain circumstances, to get this feature... but, kids, don't try this at home ;-)

3. Wine developers get confused with Microsoft's Windows releases ?

20�Nov�2000 (3 posts) Archive Link: "version patch"

People: Andreas Mohr,�Ove Kaaven,�,�Dimitrie Paun

Andreas Mohr provided a patch which implements more versions for the -winver command line argument (which tweaks Wine behavior to mimic the passed Windows version).

Andreas added the following versions:

Dimitrie Paun and Ove Kaaven got confused by the nt2k name, and asked whether win2k wouldn't be a better name.

Andreas replied:
Maybe not. IMHO win2k is more or less Win ME. (or at least it could be confused this way). So I think we ought to better choose nt2k and winme as --winver values. (as win2k is NT based anyway)

It's not me who created that confusing stuff - it's Me$$ysoft again... I'm just trying to get some order into it :)

But it might be a good idea to alias win2k to nt2k.

Ove Kaaven didn't quite like it:
There is no such thing as nt2k! Adding it is going to create a lot of confusion, more than if you sticked to sensible and understandable names (based on product names), i.e. win2000. And what's this deal with this senseless 2k here and there, instead of just saying "2000" like everyone else is accustomed to, and which actually makes sense (especially to Americans that don't use the metric system...)? I'm not going to just sit and watch someone trying to enforce the illegitimate "2k" instead of "2000" in the version options! It must be "win2000"!

No one actually replied, but Alexandre applied the patch as it was, with the nt2k name.

4. Compilers think different

23�Nov�2000�-�26�Nov�2000 (11 posts) Archive Link: "DLL functions returning structs"

People: Jonathonm Griffiths,�Hidenori Takeshima,�Mike McCormack,�Alexandre Julliard,�,�Ove Kaaven,�Jon Griffiths

Jon Griffiths, while updating his CRT DLL test harness, dug out a nasty issue:
I found a call returning strange values using the native DLL. The call is "ldiv", which returns an ldiv_t struct _by value_. ldiv_t is defined the same under linux and windows.

My (linux) test harness uses LoadLibrary to load the DLL, and GetProcAddress to get the function pointer. Problem is, the code:
      ldiv_t ldt = p_ldiv(20L,3L);
      fprintf(stderr,"%ld, %ld\n",ldt.quot,ldt.rem);

Gives with the wine .so: 6, 2

And with the real DLL: 1079733392, 1073782154

The .so is behaving 'correctly'. The win32 DLL results look like addresses to me.

Compiling the program under vc and running the .exe under wine generates an exception.

With the win32 .exe and win32 DLL i get the correct answer once again.

So it appears that returning structs only works when the dll and caller are built with the same compiler (or return convention).

Before I start checking further, I'd like to check whether anyone has any info on this. Presumably what is happening is that vc++ and gcc have different conventions for returning structs by value.

Hidenori Takeshima quoted the mingw32 sources (which also embeds a CRTDLL implementation):
 * div_t and ldiv_t are structures used to return the results of div and
 * ldiv.
 * NOTE: div and ldiv appear not to work correctly unless
 *       -fno-pcc-struct-return is specified. This is included in the
 *       mingw32 specs file.

Jon kept going with his investigation:
Most regular functions return their result in registers if it will fit (i.e. all integral types). Luckily for us gcc and windows compilers do the same thing when returning integrals (use eax, then edx if needed). So we have no problem calling those functions between the environments (i.e in Wine).

What happens in a call to a function returning a struct differs between the environments, however. Under linux/ix86 gcc pushes a hidden argument on to the stack holding the address of the struct, for structs of _any_ size. VC++ doesn't appear to do this for structs <= 8 bytes. The good news is, structs > 8 bytes should work fine (VC will pass the hidden parameter also).

Because of this, if win32 code calls a unix dll function returning a struct <= 8 bytes, the unix code freaks because the address of where to store it wasn't pushed. Similarly, if unix code calls win32 code, the win32 code freaks because there is an extra argument on the stack.

the gcc info pages state that using the -no-pcc-blah flag might not work on structs < 8 bytes (and it doesn't). In any case that flag is not useful because by default the struct passing for > 8 byte cases is the same between the two environments. Plus it screws up linking with native libs.

Mike McCormack suggested:
Why not implement the function using windows calling convention, then provide a macro/inline function hack in the appropriate header file that, when compiling winelib, converts unix struct calling convention to the windows one?

Better make sure to include the right header when compiling though.

Ove Kaaven also noted that recent ULONGLONG types had been added to .spec files, and this would nicely fit with MS calling convention when returning structures which size is <= 8 bytes.

This should solve the case of a Windows app calling the native CRTDLL, but the case of a WineLib still needed some more thoughts. Alexandre Julliard added the last part of the solution:
I agree that -freg-struct-return is a bad idea, especially if the app mixes libc and crtdll calls. I think a simpler solution would be to have a way to specify in crtdll that ldiv() should not be available for imports from winelib apps; this way the app will always link to the libc function directly. I was planning to add such a mechanism anyway for other simple functions like memcpy() that are always identical between crtdll and libc, so that we can avoid the overhead of the extra indirection through the import table.

5. Drunkard will not stop

27�Nov�2000 (1 post) Archive Link: "daily wine builds for debian"

People: Andreas Schuldei,�Bernhard Rosenkraenzer,�,�Zygo Blaxell

Andreas Schuldei announced:
The service Zygo Blaxell provided for the last year or so will be discontinued because people do not want him to use resources on windows promotion. (I have never seen wine as if it would promote windows, but hey!) The ease of setup of his buildsystem on the debian system encouraged me to announce this new site after a few successful builds.

In the future packages should be available daily from (

or can be installed automatically with these lines in your /etc/apt/sources.list:

deb wine main deb-src wine main

These are not official debian packages and are not distributed with unstable since they are not intended to be frozen with woody (the current development version of debian) and bugreports about the wine-content are not going to be processed by me. These are basic compiles of the CVS tree, so your bugreports concerning wine should go to the wine developers list. However I would like to hear about packaging problems and ways to correct them or other ways to improve this service.

Bernhard Rosenkraenzer also added:
On a similar note, I'm now making daily wine builds for Red Hat Linux 7 available - (

That should be enough for most of the Wine addicts to get their daily fix.

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.