World Wine News

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 )
  1. Website redesign
     • Jeremy Newman
  2. Reorganize the navigational menu
     • There is a proposal being discussed on the list
  3. Create some really sexy screenshots
     • one app per screenshot, avoid cluttered desktop
     • minimize size, if possible by using 'Positioned Color Dithering'
  4. 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?
  5. Enlist some 'official' distribution maintainers (at the minimum RedHat, SuSE, Mandrake, Debian)
  6. 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! :)
  1. We need to figure first _what_ is out of date.
• Wine configuration
  1. Merge configuration into the registry
  2. Write control panel applets for editing it
  3. Have decent defaults so we can start control panel without prior configuration
  4. Have wizard like app to autoconfigure wine WineSetupTk proposed by Jeremy White
  5. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg
  6. Write .inf script to setup a new Wine installation
  7. Have a wineboot script for RunOnce stuff
• Stabilize utilities
  1. Get rid of the init directive from .spec files Alexandre Julliard volunteered
  2. Make sure the .spec file format is fairly stable Any other things that may need changing here?
  3. Ensure the various utilities' options are stable Anything here?
• Important fixes
  1. Window management rewrite, so we can install apps in managed mode.

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

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.

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:

"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:

cd wine/dlls/$dll_in_work
make clean
make 2>&1 | fixpointerarg.pl


P.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours.

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 wouldn't.

Can't we at least 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.

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

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.

I am working on making our software (Stylus Studio, http://www.sonicsoftware.com/products/additional_software/stylus_studio/index.ssp ) 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 [email protected]).

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?

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

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?