Wine Traffic #71 For 27 Nov 2000
Table Of Contents
Introduction
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:
- 8 posts in 16K by Dimitrie O. Paun <dimi@cs.toronto.edu>
- 7 posts in 20K by lawson_whitney@juno.com
- 5 posts in 13K by Jon <tntjpgriff@tsnxt.co.uk>
- 4 posts in 9K by Alexandre Julliard <julliard@winehq.com>
- 4 posts in 8K by Ove Kaaven <ovehk@ping.uio.no>
- Full Stats
1.
Headlines
People:
- This has been a very quiet week, as if every Wine developer
was more attracted by Thanksgiving's turkey than by writing some mails
or patches...
- Last week at Comdex, Corel talked about selling the Linux part
of Corel's (
http://news.cnet.com/news/0-1003-200-3785993.html)
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:
[Int13]
Bios0=/dev/fd0
Bios1=/dev/fd1
Bios80=/dev/hda
Bios81=/dev/hdb
[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).
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.
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.
/*
* 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.
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.
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
http://gluck.debian.org/~andreas/debian/dists/wine/main/
or can be installed automatically with these lines in your
/etc/apt/sources.list:
deb http://gluck.debian.org/~andreas/debian wine main
deb-src http://gluck.debian.org/~andreas/debian 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.
Sharon And Joy