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).
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 Comments welcome.
I have a few questions for Wine developers, especially the good folks at Codeweavers and Transgaming:
- How much would it cost to achieve full support for Office 2000 in Wine?
- 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:
shouldn't be required to do normal stuff in Office.
- <Insert whatever favorite technology from Microsoft that you like>
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.
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
The next day Eric submitted another version of the
patch and it was greeted enthusiatically by everyone. Duane wrote
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
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.
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:
- 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.
- 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 -
- 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:
Define twice (Ugly) Put into a new wine/undocshlwapi.h (Seems that these are depreciated?) Define anyway (Im not a fan of having undoc functions in public headers) 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:
- 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).
- Make shlwapi.h correspond to its windows cousin, except that:
- 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).
- All ordinal functions get defined in shlwapi/ordinal.h
- 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)...
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
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..
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.
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
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:
We're happy to contribute this in our next outward merge if people think it's useful.
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
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
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.
Yes, that helps, could you commit it to the CVS please?
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.
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?
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