![[LWN Logo]](/images/lcorner.png) |
|
![[LWN.net]](/images/Included.png) |
Kernel Cousin Wine #110 For 12 Dec
By Brian Vincent
Table Of Contents
* Default Format
* Text Format
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 10 Dec (8 posts) Wine, Office, and the Antitrust Settlement
2. 10 Dec - 11 Dec (8 posts) OSS Fixes
3. 4 Dec - 6 Dec (8 posts) SHLWAPI Additions
4. 9 Dec - 10 Dec (4 posts) InstallShield 6 Patches
5. 5 Dec - 11 Dec (22 posts) UNC Patch
6. 2 Dec - 3 Dec (6 posts) Using a FAT32 Filesystem
7. 4 Dec (2 posts) Async I/O Patch
8. 29 Nov (1 posts) FoxPro 5 Success
9. 5 Dec (1 posts) Merry Christmas!
Introduction
This is the 110th 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 139 posts in 508K.
There were 57 different contributors. 23 (40%) posted more than once. 27 (47%)
posted last week too.
The top posters of the week were:
* 14 posts in 35K by Alexandre Julliard <julliard@winehq.com>
* 11 posts in 27K by Francois Gouget <fgouget@free.fr>
* 8 posts in 22K by Andreas Mohr <andi@rhlx01.fht-esslingen.de>
* 8 posts in 22K by Dan Kegel <dank@kegel.com>
* 7 posts in 24K by Oliver Sampson <olsam@quickaudio.com>
1. Wine, Office, and the Antitrust Settlement
10 Dec Archive Link: Wine, Office, and the antitrust settlement
I haven't read much on the antitrust settlement the states are trying to reach.
Frankly, most of the coverage has been rather academic and inconclusive. But
Dan Kegel [*] took the time to dig through some of the challenges that face the
open source community and ways to reach a common ground. He posted the
following message to wine-devel:
I'm proposing that Wine be part of the settlement of the Microsoft
antitrust trial. See http://www.kegel.com/remedy.html (http://www.kegel.com
/remedy.html) Comments welcome.
I have a few questions for Wine developers, especially the good folks at
Codeweavers and Transgaming:
1. How much would it cost to achieve full support for Office 2000 in Wine?
2. Is it true that Office uses undocumented Windows APIs? If so, how many?
Are they a significant part of the challenge of supporting Office?
I highly recommend clicking on the link and perusing through some of the points
Dan brings up. Jeremy White [*] replied with some concerns:
I read your remedy proposal; nice work.
I obviously like your proposal (hire CodeWeavers to port Office, great
idea! <grin>). I'm skeptical that this proposal will be accepted, and I
also feel a bit uncomfortable advocating it as it clearly benefits
organizations like mine, and doesn't so clearly benefit the Wine community.
However, to answer your question, if you value time (i.e. assume people get
paid market wages, as opposed to donate their time), a reasonable off the
cuff guess for MS Office support (to make it *really* work) is probably on
the order of $1-2M or so.
Please note, that's largely a guess, and includes a large fudge factor
because it's unclear how much work Office XP is going to require (AFAIK, no
one has brought it up in Wine yet).
We could probably reduce the cost and effort if we had engineers at MS
actively helping us (so we weren't always fighting up hill).
As far as undocumented APIs in Office, I know of only one used in Office
2000 (of course, the problem with undocumented APIs is that there may be
many more we're ignorant of).
Finally, I think my largest concern with Wine is in securing protection
from Microsoft patents.
I've lost some large sales because Mainsoft sales people use patent FUD
successfully on my potential customers.
Further, it is unclear whether or not open source projects such as Samba,
Mono, and Wine are going to be permitted to play in the post .NET world. My
greatest fear is that MS will be able to take some legal action that will
prevent Wine from supporting any .net enabled application.
IANAL, so I have not idea as to the full extent of the threat from MS or
what a potential remedy would look like, but IMHO, that's a more
significant issue than others we've faced.
Patrik Stridvall [*] had some thoughts as well:
What is perhaps more realistic to require IMHO that Office and other
Microsoft applications shouldn't crash or behave in a inconsistant way just
because some odd feature in some API call is not available. Instead it
should say, sorry can't do that not supported in the OS.
This would prevent Microsoft from sabotaging Wine as well preventing users
of say Windows 95 from needlessly having to upgrade.
Yes, I'm aware of that Microsoft of course not can check every API call and
have a fallback for each function, but groups of features that is
potentially unneeded for basic features in Office like:
1. DirectX
2. MAPI
3. .NET
4. DAO
5. "Sound"
6. "Networking"
7. <Insert whatever favorite technology from Microsoft that you like>
shouldn't be required to do normal stuff in Office.
In response to Dan's question about undocumented calls, Andreas Mohr [*]
suggested:
Well, I'd say SETUPAPI/SETUPX and SHLWAPI are certainly everything but
documented... There do exist some header file defines for some stuff, but
that's about it. My guess is that we could come up with a list of at least
10 DLLs that are rather badly documented (some even with some malicious
intent, I'd say). OTOH I'm not sure whether we should try to play some role
in that settlement. After all we're probably not too visible to Microsoft
right now, and we're coming along rather nicely. Which would probably
change rather fast once we make our public voice get heard...
We really should make up our mind NOW on whether we want to take part or
not, though.
2. OSS Fixes
10 Dec - 11 Dec (8 posts) Archive Link: OSS fixes
There have been some audio shake-ups for the past month. A few different
patches have been thrown around. Eric Pouech [*] submitted a new patch to
audio.c and asked, "could the people who had issues with the latest OSS patch
(es) test if this one fixes all their issues ?"
Duane Clark [*] replied a few minutes later and reported, "This patch causes
both Riven and Myst to immediately freeze for me, and no sound at all. Without
the patch, the sound in Myst works pretty good (occasional brief dropouts). In
Riven without the patch, only the opening sequence has sound, and that has many
large dropouts. I'm using ALSA drivers in Redhat." Eric asked for a debugging
trace which Duane provided.
The next day Eric submitted another version of the patch and it was greeted
enthusiatically by everyone. Duane wrote back, "That one works great. Both Myst
and Riven work, and for the first time in Riven all the sound works. There is
slight bit of static in the sound, though part of that might be cheap sound
hardware (onboard VIA 82C686A - which never gives particularly good sound)."
Michael Stefaniuc [*] mentioned, "Tested it with Quicktime and sound works now
flawlessly. Good work." And Gerard Patel [*]'s test suite seemed happy too, "I
have only one serious issue, and it's fixed by your patch."
Excellent work!
3. SHLWAPI Additions
4 Dec - 6 Dec (8 posts) Archive Link: SHLWAPI pre-submit questions
Jon Griffiths [*] wrote in to say he's been working on some improvements to the
SHLWAPI dll. SHLWAPI is the Shell Lightweight API used for all kinds of tasks
such as finding paths and
I've been hacking on SHLWAPI.dll for a couple of months now while
holidaying around Thailand, using a beaten up laptop. Since I just obtained
free use of a real machine with a good net connection, I want to start
submitting my work but I thought I'd clear up a few style issues
beforehand:
1. Is it OK to give meaningful names to undocumented functions?
e.g. SHLWAPI_1/2 => UrlGetInfoA/W
SHLWAPI_5/6 => PathFindOnPathExA/W
I want to do this where the names are no-brainers, as in the case
above, and the functions are referenced by the dll internally.
2. Is it OK to sync shlwapi.h with the windows version ?
e.g. Remove undocumented entries, Remove its dependence on obj_base.h
(windows has none), Add the function exclusion defines as per windows
I assume this is fine, but doing this causes the next question -
3. How to deal with shared undocumented functions?
e.g. StrRetToBufA/W is used by shell32, but should not defined in
shlwapi.h.
Here there are 4 Choices:
1. Define twice (Ugly)
2. Put into a new wine/undocshlwapi.h (Seems that these are
depreciated?)
3. Define anyway (Im not a fan of having undoc functions in public
headers)
4. Have shell32 functions #include "../shlwapi/internal.h" (A little
unclean)
I'd like to go for 4, any objections?
I'll start feeding in the new function implementations over the next little
while, once the structure is sorted.
There were a lot of different opinions for each of the points. For the first
point, Alexandre suggested, "No, this will cause major confusion. What you can
do is create a SHLWAPI_UrlGetInfo internal function that is called both by
SHLWAPI_1 and by other functions that need it."
Guy Albertelli [*] has been hacking on SHLWAPI for a while and had some
suggestions. As far as syncing up the headers, Guy thought, "Be careful here,
some of the entries took a long time to find since it is not that they are
undocumented, but just not well documented (in fact I only found some of the #
defines in Borlands lastest bcc)." Guy also felt it would be a good thing to
remove the dependence on obj_base.h. There were other suggestions for how to
deal with the shared undocumented functions, Guy's take on it was, "I created
"shlwapi/ordinal.h" for that very purpose (since ordinal.c has the
"undocumented" routines) and defined the structures for _1 and _2 in it. Note
that _1 and _2 are used by other parts of shlwapi."
Jon wrote back with game plan:
Thanks for your prompt responses. Based on your feedback I'll:
1. Create internal functions with meaningful names and call them when
ordinal calls are used within the DLL (A plus to this is that the
ordinal functions can stay in ordinal.c, and the implementation can go
into the appropriate file, eg. path.c).
2. Make shlwapi.h correspond to its windows cousin, except that:
o Any functions exported by name get defined too, along with
structures needed to call them (I think we should wrap these in "#
if defined (__WINE__) || defined (SHLWAPI_UNDOC)", but that can
wait).
o All ordinal functions get defined in shlwapi/ordinal.h
o Internal functions go into shlwapi/ordinal.h too.
There shouldn't be any conflicts with Guys work: my tree is so out of date
I have to adapt everything anyway, so I'll make the changes as
non-gratuitous as possible. The first patch only might be a little large
due to the header re-org.
Header patches coming first, followed by code in managable chunks. I've
been dying to get this code out in case someone nicks my laptop or it blows
up (its 7 years old, the poor thing)...
4. InstallShield 6 Patches
9 Dec - 10 Dec (4 posts) Archive Link: Installshield 6 (inter-proc) patches
Transgaming has done a lot of work on getting InstallShield 6 installers to
work under Wine and Ove Kåven's work can be found in the WineX code on
SourceForge. So James Brown [*] was wondering, "Any idea when Oves interprocess
patches will be put into the main Wine CVS tree? The code currently in WineX
isn't really that ugly at all, and it is a very important part of Wine to have
working IS6 support.".
Alexandre responded, "It could certainly be applied, even if it's not 100%
clean it will always be better than not supporting InstallShield at all, as
long as it doesn't break other things. However I cannot apply anything that
hasn't been submitted to me under the Wine license, so for more information
you'll have to ask Transgaming."
Gavriel State [*] from Transgaming also replied to James to say, "There are
several factors to that equation, and I'm afraid we don't have a firm ETA yet."
Which prompted Alexandre to write:
Well, this worries me. It sounds like you are planning to do the same thing
you did with your DirectX stuff: by making the code available on your site,
and promising to release it at some hypothetical future date, you remove
all incentive for other people to spend time improving the main Wine, thus
ensuring that it always lacks some features. I don't like this at all.
If you can't/don't want to release your code, I'd strongly suggest that you
reconsider your strategy of making it publicly available. If it was only
available to paying customers, there would at least be a reason for other
people to work on a free implementation. But if everybody who needs some
feature in Wine can simply download WineX instead, no one will spend time
re-implementing that feature. This is beginning to seriously hurt the
project, and we need to find a way to address this issue.
5. UNC Patch
5 Dec - 11 Dec (22 posts) Archive Link: Re:UNC patch
Stefan Leichter [*] submitted a patch that would allow UNC paths to work under
Wine. Namely, if a Windows program was searching for something like f:\x Wine
would be intelligent enough to look through the mounted filesystems (in
particular remote filesystems) and come up with answer. Dan Kegel [*]'s
original suggestion for doing this suggested the following process:
Given a UNC path \\foo\bar,
+ look at /etc/mtab for a matching smbfs mount.
+ If one is found, look at .wine/config for a drive letter mapped to that
mount.
+ If one is found, convert the UNC path to be relative to that drive
letter.
Namely, this would allow the UNC path \\windows-server\x to show up as f:\x if
it was mounted. In turn, that can be determined if smbfs is being used to mount
a filesystem. Eric Pouech [*] suggested making this configurable, such as
whether or not to enable it on a per host basis. The thread quickly turned to
what depth of configurability to offer. On the one hand, if a smbfs filesystem
is mounted why not just use it? Alexandre also mentioned that it might not even
be worth parsing /etc/mtab and just create the drive mappings in the wine
config file. Gavriel State [*] wrote in to say:
One of the problems we've come across recently is this: for games that use
copy protection, we need to have direct access to the device that a CD-ROM
drive uses. For the moment, this relys on the user to manually configure
their drive letters. From what we've seen, doing so is beyond the ken of
many of our users.
As such, we've put together a scheme for parsing /etc/fstab on startup (not
mtab: the drive may not be mounted), and automatically adding drive letters
for each iso9660 filesystem listed. The patch (to the WineX tree) is here:
http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ (http://
www.geocrawler.com/archives/3/9376/2001/11/0/7204310/)
We're happy to contribute this in our next outward merge if people think
it's useful.
Alexandre wrote, "It's clear that the current mechanism is not very
user-friendly nor very flexible. The first thing to do would be to make it
possible to change drive mappings at run-time, and then have them integrated as
much as possible with the Unix environment, detecting all local filesystems,
partition types, media changes, possibly even calling mount/umount from Wine,
etc."
Bill Medlands [*] thoughts were:
Like Dan I initially considered the idea of equating the samba mount point
with a drive and using the drive. However that is a hack; Windows doesn't
require a UNC to equate to a drive. Therefore whatever is done needs to
involve extending the "equate a DOS filename to a unix filename"
functionality.
There is one further consideration; equating Samba and nfs (and that would
possibly require something in the config file as suggested by Eric). The
complication is byte locking (which I know we don't do yet but maybe one
day soon we will). The complication is that although nfs does handle it to
the best of my knowledge smbfs doesn't (and isn't smbfs unavailable on any
unix other than Linux?). Therefore to do locking we would need to equate a
UNC to a mount point that was actually supported through nfs or some other
mechanism (I presume smb and nfs are not the only options).
And speaking of things other than smbfs, Bob Lunnon was against making the
patch so linux-centric, "On Solaris fstab is vfstab, and mtab is mnttab,
parsing these files is no good unless it is done in some portable way. (Not
that smbfs even works on Solaris) I would think that persistent share selection
should be saved in the registry and accessed through smbclient rather than
smbfs, then smb shares would work for all OSs supporting Samba, not just those
supporting smbfs."
6. Using a FAT32 Filesystem
2 Dec - 3 Dec (6 posts) Archive Link: Win XP installation support?
Hetz Ben-Hamo [*] had a problem accessing his Windows partition, "I have
installed wine cvs and I have here on this machine Windows XP pro
installed..now - the partition is fat32 and I can access it with /mnt/win
without any problem. However, the tools/wineinstall script simply doesn't
recognize my windows partition".
Lawson Whitney [*] suggested going into /etc/fstab and taking a look at where
it mounts the Windows partition. He suggested changing the filesystem type from
"auto" to "vfat". Hetz replied that he had already done that. Gerard Patel [*]
submitted a tiny patch to wineconf and wondered if it fixed the problem. Hetz
announced, "Yes, that helps, could you commit it to the CVS please?"
7. Async I/O Patch
4 Dec Archive Link: [RFC] Async I/O patch: server code + ReadFileEx()
Martin Wilck [*] announced some fixes for async I/O problems that have been
discussed before:
here is a patch that fixes some of the issues with the async IO
implementation in Wine that we discussed previously. My work on this was
delayed by other duties, sorry. To make matters worse, I'll be out of
office for the next 4 weeks (vacation :-)
THIS PATCH IS NOT FOR PRODUCTION USE.
I am submitting it as a RFC to show the basic concepts I am aiming at. Most
important is the server-side code (server/async.h, server/async.c) that
demonstrates the basic mechanism I am suggesting.
As an example, I recoded ReadFileEx() to use the new approach. Basic
testing with disk file I/O works as expected. The code no longer messes up
the order of requests.
Please have a look at this code and tell me if you consider it a reasonable
basis for further development.
Mike McCormack [*] replied:
i hadn't heard from you in a while, so i though you might have given up
after nobody said anything about the last patch, but i see you've been busy
:-)
i also had a go at fixing the problems you pointed out. i've attached the
patch i've been working on... don't use it, it _will_ crash your
wineserver! i need to create a requeue async request like yours, and
activate my queues properly. The code is written to support async on serial
port objects, not file objects.
8. FoxPro 5 Success
29 Nov Archive Link: FoxPro 5 Applications
Rick Romero [*] reported:
I've been attempting to get Foxpro 5 applications running for a while now.
Actually, I just download from cvs randomly, and see what happens.
It's been a while, but I decided to try again in October. At that time,
there was an OLE error, but the only other strange occurance was a
'locking' of the screen on a print preview.
Since then, this 'locking' is the only issue (though I havn't yet attempted
to print). The apps I'm trying are my own, basically just a form is called,
the user puts in a date range, and a report is run. You can view the report
in the print preview window, close the window, use the scroll button on the
mouse to change pages, etc. BUT, if you click on the preview itself, and
attempt to scroll down to the bottom of the page, a 'lockup' appears to
happen. I've just been waiting around hoping for it to be fixed.
Today, for giggles, I decided to run the whole Visual Foxpro development
environment. It ran! (BTW, I'm trying to do this all with fake windows, and
all I've added is the VFP 5 runtime)
BUT, anytime I click in an edit Window, MDI interface, the program acts as
if I'm holding the shift key down, and as I move my mouse, all the text
gets highlighted. I can't 'turn it off', so if there wasn't any text there,
it surely would appear locked.
I've changed the config from the fake_windows, to point to my Win2k
install, but the behavior is the same.
I'm actually getting kind of excited now, because we're a small company,
and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6
win), and Office 2k.
If I can run the development environment in Linux, I can take a real look
at using linux desktops, either directly, or via LTSP.
I don't get any debug info when the 'shift' occurs, and I'm not sure how to
dump enough information to see the 'shift keypress' happen (assuming I
could fix the problem myself in a way that doesn't interfere with the
programming standards..), can someone point me in the right direction?
9. Merry Christmas!
5 Dec Archive Link: Happy Christmas wine
Russell Howe [*] posted a link:
I got sent a Christmas card in Windows EXE format. Since it works perfectly
with wine I thought I'd share it :)
The file is at http://www2.cs.man.ac.uk/~hower0/crimbo.exe.gz (http://
www2.cs.man.ac.uk/~hower0/crimbo.exe.gz)
Free Dmitry Sklyarov!
All Kernel Traffic and Cousin issues and summaries are copyright their original
authors, and distributed under the terms of the
GNU General Public License, version 2.0.