World Wine News

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:

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 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.

What is perhaps more realistic to require IMHO that Office and other Microsoft applications shouldn't crash or behave in an inconsistent 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>

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.

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.

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:
   • 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)...

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.

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.

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/

We're happy to contribute this in our next outward merge if people think it's useful.

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).

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.

i hadn't heard from you in a while, so i thought 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.

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 occurrence was a 'locking' of the screen on a print preview.

Since then, this 'locking' is the only issue (though I haven'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?

I got sent a Christmas card in Windows EXE format. Since it works perfectly with wine I thought I'd share it :)