This is the 142nd 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).
SuSE is releasing a product called "SuSE Linux Office Desktop" sometime early next year. They've released this product before (or at least something very similar) but this time they've added CrossOver Office 1.2.
Xandros announced special pricing for LUG members worldwide. If you're a member of a Linux User Group ask your officers about it and what the discount code is. Also in Xandros news, ExtremeTech did a review. obScreenShot.
Also, check out the Contribute page on WineHQ to find things that need to be worked on - Andi Mohr updated some of the jobs on there this week. And a lot of them don't even involve coding.
The talk on the wine-devel mailing list this week has been less about the technical details of Wine and more oriented towards project management. It seemed pretty much everyone was in agreement that everything surrounding Wine needed to be revamped, updated, or completely redone. Discussion centered around WineHQ, release management, documentation, and configuring Wine. Basically anything that's considered a barrier to people using Wine was discussed. I'm not going to go into the details of some of the discussion, though some of the topics are discussed below. I urge you to check out the archives for more details. Also, insofar as public forums go, mailing lists tend to only generate discussion when people disagree. Most of the disagreement in the discussion has been over relatively minor points. Does that mean most of the developers seem to agree?
I'm going to do a poor job summarizing this topic in general. And most certainly I'll do a disservice to anyone who contributed to this discussion. First, let me just run down a quick summary of the threads that generated this discussion:
people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases.
Again, lots of discussion ensued. At press time, Dimi had once again revised his list and narrowed it down. Also, Alexandre had suggested most of the items fell into the .9 release plan hence the initial comment:
This will probably get renamed to Wine 0.9 TODO, after Alexandre's clarification, but I haven't changed the name just yet, to avoid confusion.
Once again, what I mean by 0.8:
- Users can start using Wine: works well for a fair number of apps, no MS DLLs required (from real Windows)
- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away
What is NOT in 0.8:
- stable server protocol: no binary compatibility
- DLL separation: ditto
That being said, this is my initial list. Comments, flames, suggestions, are appreciated.
- WineHQ work (Beta at: http://lostwages.winehq.org)
- Website redesign
- Jeremy Newman
- Reorganize the navigational menu
- There is a proposal being discussed on the list
- Create some really sexy screenshots
- one app per screenshot, avoid cluttered desktop
- minimize size, if possible by using 'Positioned Color Dithering'
- Rework the FAQ interface
- (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) Agreed on the list. Should be written in SGML, so we can output all sorts of formats. Which means we need layouts, etc. Any takers?
- Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, Mandrake, Debian)
- Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows. Carlos is running with it.
- Documentation work
Andy, take it away! :)
- We need to figure first _what_ is out of date.
- Wine configuration
- Merge configuration into the registry
- Write control panel applets for editing it
- Have decent defaults so we can start control panel without prior configuration
- Have wizard like app to autoconfigure wine WineSetupTk proposed by Jeremy White
- Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg
- Write .inf script to setup a new Wine installation
- Have a wineboot script for RunOnce stuff
- Stabilize utilities
- Get rid of the init directive from .spec files Alexandre Julliard volunteered
- Make sure the .spec file format is fairly stable Any other things that may need changing here?
- Ensure the various utilities' options are stable Anything here?
- Important fixes
- Window management rewrite, so we can install apps in managed mode.
Jeremy White put forth the following proposition concerning WineSetupTk (CodeWeavers' graphical configuration tool):
In responding to Dimi's call for better binary packaging, and the whole issue of getting a base line config ready, it felt clear to me that WineSetupTk is a tool that is underutilized.
I have been trying to persuade Alexandre to include WineSetupTk in the main Wine distribution for some time now, and have always failed. (Alexandre is rightly concerned about increasing the dependencies in Wine).
However, it struck me that we ought to be able to do a better job of making it available to binary packagers so that it could be included in more packages. We could also make it easier for people to get both Wine and WineSetupTk from source.
To that end, I have the following proposal, and I wanted to see what folks here thought.
We would create a parallel CVS tree to Wine; say the winesetuptk tree. We'd put that code out under a dual license (GPL/but we still own rights). I'd probably welcome multiple maintainers.
The only thorny issue is that we share code between WineSetupTk and some of our proprietary pieces. We could shift our main WineSetupTk development to this tree, and share the common bits, including our developments as we make them. However, in exchange, we would need anyone making changes to WineSetupTk to grant us a license to use their changes in our proprietary stuff. (And, of course, if we ever abuse this, someone can take the GPL tree and go host it somewhere else).
As of press time there hasn't been much response, however I suspect most people think this would be a great tool to have available.
Wine documentation.. never mind, I won't even open that can of worms. Suffice to say, lots of it needs some care and attention. Jeremy White put out a call for someone to maintain Wine's FAQ:
Andi and I have talked about the FAQ a lot on and off through the years, going back to when he was in St. Paul and first set up the FAQ-o-matic.
When I go visit a project the very first thing I look at (before screenshots, about, or *anything* else) is the FAQ.
Therefore, I think it's extremely important to have a good FAQ.
Now, Andi has poured a lot of work and energy into the FAQ over the years. But, here's the truth - it's not really a job he wants. (He and I discussed it privately). There are a lot of other things he'd rather do.
So, I'm hoping that we could get a volunteer to step forward and take over responsibility for the FAQ from Andi. I'm particularly hoping that one of the new crop of wine-devel participants would be inspired to volunteer.
My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.
Dimi Paun threw out the first idea,
Please get rid of the FAQ-O-matic. The interface
is atrocious. A hand written one would do just
fine, is not like we add 100 questions per day!
(And if we do, something's wrong, who's gonna read them?)
The FAQ-O-Matic he refers to is the
link above. The interface is hard to use for
just basic information. Andi Mohr pointed out
that it also houses a troubleshooting guide, and
for that it seems suited. Others argued that even
for a troubleshooting guide the interface is so bad
it detracts from the content.
In the end, everyone agreed a static page needed to be created for the FAQ that was easy to navigate. Jeremy Newman suggested any work on the FAQ be done with SGML in order to make converting it to other formats easy. Anyone want to volunteer? It's as easy as responding to Jeremy's original post.
The conversion to using -DSTRICT covered a few weeks ago is progressing well. Michael Stefaniuc wrote in with a status update:
status reports seems to be pretty popular this day so here is mine regarding compiling wine with -DSTRICT. Below is the amount of warnings we get when removing -DWINE_NO_STRICT:
dll real total commdlg 21 63 gdi 128 273 ntdll 148 178 ole32 16 38 shell32 120 155 user 450 839 winmm/wavemap 7 40 winmm 104 145 winsock 14 42 x11drv 60 79 total 1068 1852 "real" is the number of warning for which real work is need to be done, the rest up to "total" are warnings of the type "int format, HANDLE arg". And to fix this beasts just grab http://people.redhat.com/mstefani/wine/fixpointerarg.pl and do:
and you should be done.
cd wine/dlls/$dll_in_work
make clean
make 2>&1 | fixpointerarg.plP.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours.
Peter Andersson started a thread out innocently enough by asking about implementing more security in Wine:
I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large.
A lot of random ideas were thrown about, and almost everyone was
averse to the idea of changing Wine. A lot of people felt the
best thing to do was use existing tools to provide a safer environment.
Vincent Beron suggested,
Use the LSM patches for Linux if you want to monitor certain system calls.
Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you
want to protect your current $HOME.
Greg Turner expounded on that idea:
I concur with Vincent, here. As wine exists here and now, we are basically implementing the level of "security" provided by Windows 9x. That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.
Luckily, the native operating systems that host wine tend to be rich with security features, and those can be used to sandbox wine until some more sophisticated application-level security measures exist.
We've recently talked about some ways to move forward towards implementing the NT-style security model in wine. When those plans move forward, one of the issues to consider is the tendency of windows to propogate virii, and the possible need to selectively prohibit wine from accessing resources that the user invoking wine might have full control of.
Unless wine is going to be a true emulator (instead of an engine for executing windows apps natively under the security context of the invoking user), we simply cannot solve this "problem," by definition.
The closest thing to a solution involves a massive reconceptualization of how wine works (for example, the invoking user runs userwine, which uses some kind of IPC to talk to sandbox-wine, which does all the actual executing of windows code or, alternatively, wine works like a just-in-time compiler, verifying code is safe before it's loaded into memory (terrible idea IMHO)). Since "emulating" the NT security model for wine is a similarly major undertaking, and provides most of the same benefits as Peter would have, I think this is how we should solve this "problem".
Food for thought: by Peter's definition, neither Windows, nor most Unix operating systems, provide an acceptable level of security. Wine is no better, but also no worse, than any other powerful application, such as GNU make, bash, or the Konqueror file browser, from a security perspective. All of these can be used to destroy your $HOME directory and any other file you can delete.
I think the problem is one of wine being closely associated with Windows, and windows having a reputation of being insecure; in other words, it's a problem of perception, not of technical merit. Nothing wrong with that -- problems of perception can kill a project -- but bear in mind that, if wine, even as it exists today, is run in a carefully administered manner on a good secure OS, it ought to be safer than native Windows to run, if you accept the assumption that UNIX-like OS's are more secure than Windows ones. If you really don't trust windows, you could argue that running under wine in a sandbox is the /only/ safe way to run windows programs outside of an emulator.
Just my opinion, probably worth about what you paid for it, but there you go.
Alexandre's opinion was,
If you run untrusted code under your account it can do
anything that you are allowed to. This is exactly equivalent to
running an untrusted Linux app. From a security standpoint there is
absolutely no difference between a Windows binary running under Wine
and a Linux binary running natively.
You can use the DOS drive configuration to limit the potential
problems a bug in a Windows app can cause; but it is impossible to
protect against malicious code except by not running it. Wine is not,
and cannot be, a sandbox for running untrusted code.
Creating a sandbox by using other programs was discussed. Francois Gouget thought jail might be a possibility:
Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this.
Also, I'm told that jail (available on FreeBSD) is much better than chroot. chroot only restricts access to files while I believe jail can also restrict access to other running processes and other system resources. Unfortunately I don't think a jail-like functionality is implemented on Linux. If you were to implement this I'm sure countless people would be grateful.
http://docs.freebsd.org/44doc/papers/jail/jail.html
Finally you could wrap it up by writing scripts that would make it easy to run Wine in a sandbox, and restore the sandbox to a clean state after a program has been run.
David Hagood thought checking the execute bit of a file before
running it might provide a little better security, especially
for things like the Klez virus running via KMail. But Eric
Pouech pointed out a problem,
that could bring some issues while trying to run a native executable
from a mounted FAT driver (without the proper umask option for mount)
(this could be circumvented by a drive configuration option in wine, but
that would be a bit tricky to set for the average user)
Andi Mohr mentioned that it would break installers too.
Other discussion involved making it much harder to run Wine as root, intercepting Wine server calls, and other architecture changes.
Alberto Massari wanted to know how to go about detecting a Wine environment:
I am working on making our software (Stylus Studio, http://www.stylusstudio.com) run under WINE, if this is feasible. To achieve this, I have already implemented a bunch of APIs (the application is built against the UNICODE version of the Win32 APIs) and fixed some bugs I hit (I already mailed the first patch to wine-patches@winehq.com).
However, I would feel better if I could detect I am running under WINE and gracefully disable some functionalities that are not yet fully supported; is there any way to achieve this? Is there a WIN32 API (like, say, GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is WINE trying to be as stealth as possible?
Pretty much everyone was in agreement that specifically detecting Wine was not the solution. Instead, the missing functionality should just be added. However, as Uwe Bonnes pointed out, it's possible to look for Wine registry entries. Patrik Stridvall mentioned doing so wasn't necessarily guaranteed since those entries may not be there due to future changes. Paul Rupe's suggestion was a little more graceful:
My suggestion is whenever possible check for features, not version strings. Just call the API and if it fails, then gracefully disable whatever functionality. When some future version of Wine supports that API, it will just start working without any further effort on your part. An added benefit is that whichever Wine developer is implementing that feature will have your app to test with. Also have some sympathy for the poor Wine developer tearing his hair out trying to figure out why your app behaves differently in Wine vs. Windows no matter how perfect his shiny new DX12/DCOM/HAL/TANSTAAFL implementation is. :)
Ove Kåven asked:
Now WIDL is good enough to generate a drop-in replacement for Wine's wtypes.h (attached) from a suitably crafted Wine-compatible wtypes.idl (also attached). I've included all the definitions that were already in Wine's wtypes.h (but I was too lazy to do everything that's in Microsoft's wtypes.idl yet).
What do you think, is this good enough to go into Wine? Are there some desirable changes to widl or wtypes.idl? And should IDL files go into the main include dir along with the other Win32 headers?
IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h?
Concerning the structure of the files, Alexandre replied,
No, I think we should follow the Microsoft way. Sure it's a mess, but
so is the rest of the API anyway... And every time we tried to do
things better than Microsoft we ended up having to revert it.
The work seems to stand a decent chance of making it into Wine. Greg Turner volunteered to merge the work from the ReWind tree Ove is working out of into the Alexandre's LGPL'ed one.