Wine Traffic #189 For 26�Sep�2003

By Brian Vincent

Table Of Contents

Introduction

This is the 189th issue of the Wine Weekly News publication. Its main goal is to walk carefully on thin ledges. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.com (http://www.winehq.com)

Mailing List Stats For This Week

We looked at 261 posts in 964K.

There were 61 different contributors. 35 posted more than once. 32 posted last week too.

The top posters of the week were:

1. Filesystem Roadmap

18�Sep�2003 (1 post) Archive Link: "update on ntdll/kernel32 separation"

Topics: Status Updates, Filesystems

People: Eric Pouech,�

Alexandre's work on NTDLL/Kernel32 DLL separation was kicked into high gear a few weeks ago. Much work has been done. Eric Pouech has been relatively quiet though in this latest round. He wrote in to give an update on what he's concentrating on:

I've been quite quiet recently on ntdll separation. I was working on the NtCreateFile implementation.

Even, if it's not ready for prime time, I've been running lots of apps since once week without issues (which doesn't mean that none are left). You'll find attached the patch for review. (Since Alexandre has been busy lately, better to share some info)

However, it's not ready for prime time yet. Among things that remain to be done:

There are some parts I don't like. The current server scheme doesn't fit well with the device manipulation we need.

Currently, I set, at a given point in NT pathnames (say \??\C:) a link to a Unix pathname (say /opt/windows). This fits well with path conversions. It doesn't work for real device configuration, in particular CDROMs, where we need both the unix path for data access (/mnt/cdrom) and the unix path of the associated unix device (/dev/cdrom).

I'm still thinking of either:

The later is in fact more suited for an evolution of the current server device object.

My final question is more on which order we go on: Solution 1:

  1. get the NtCreateFile ready and include it in the tree
    1. fix the introduces bugs
    2. convert the file/paths related functions
  2. finish the server side objects (devices...)

Solution 1:

Thus far there hasn't been many responses. Alexandre hasn't committed the patch.

2. The --dll Option Goes Away

25�Sep�2003 (3 posts) Archive Link: "RE: wine/ tools/runtest misc/options.c include/mod ..."

Topics: Configuration

People: Alexandre Julliard,�Robert Shearman,�Mike Hearn,�

This will likely produce some email to the devel list over the next few months. Alexandre committed a patch with the following note in the changelog:

Removed the --dll option and replaced it by the WINEDLLOVERRIDES environment variable.

Now, if you've ever followed Wine development you'll know Alexandre's patches don't go up for review. His work gets committed directly to CVS and you can comment after the fact. A testament to his ability is that very few folks object. This one is a little different though since it's an option in userspace. Rob Shearman wondered, " This will break a lot of HOWTOs on various sites that describe how to get apps working with Wine. Can we not have some period of time where we can use both methods and maybe remove the --dll option later (say when winecfg is ready)? "

Alexandre felt the behavior was already deprecated, " I don't see why, the HOWTOs should explain how to set dll overrides in the config file, that has been the standard way for a long time now. "

Mike Hearn explained some uses:

For doing things like InstallShields etc, it's common practice for people to be given canned command lines, such as

basically because this is more convenient than altering the config file for each combination. I guess

is only slightly longer.

Why must wines command line options be removed though? They are often handy for testing things out.

3. Wine Developer's Guide Update

21�Sep�2003 (1 post) Archive Link: "docs: wine-devel [0/16]"

Topics: Documentation

People: Dimitrie Paun,�

Dimi Paun submitted a bunch of patches to update the Wine Developer's Guide. There was a big push early this year to update documentation when the new website was rolled out but since then there's just been sporadic FAQ updates. Dimi proposed some ideas to help keep the docs up to date:

I've been doing some work on the Wine Developer's Guide. It's in better shape now, but I'd still rate it at 2.5 stars. It still needs some work until it's production quality, but the end is in sight. In fact, if Lionel can look at the OpenGL section (lots of things changed in there lately), and Eric at the Multimedia section (lots of things out of date), we'd be so much closer.

Instead of sending all the updates as one big patch, I've tried to split them up, for all the known reasons. But before I start sending patches, I have a few comments about this documentation business.

First, we have to resist the temptation to add a lot of redundant information. Like what is cvs, how it functions, etc. There are better resources available on the web, and we simply don't have the manpower to maintain, translate, etc. all this information. Having a lot of documentation may give us a warm and fuzzy feeling, but in fact it just shows how we have failed to make Wine transparent, and/or we haven't refined the docs. Nobody likes to read documentation, so let's keep it short, sweet, and interesting.

Second, we have to avoid at all cost including information that can change often. We get an update for these docs only once every few years, and having obsolete information in there is way worse than having no information at all. There are better places to put such info: man pages, web pages (WineHQ), etc. Having it duplicated somewhere in the depths of these manuals serves no purpose then to create more (and useless) work for us.

Third, we have to try to make these things look as books, and less likely a motley collection of files, interlaced with TODOs/FIXMEs/etc.

4. Winelib: Advantages and Disadvantages

25�Sep�2003 (8 posts) Archive Link: "How to run program without wine ?"

Topics: Winelib

People: flyker,�Dimitrie Paun,�Shachar Shemesh,�Mike Hearn,�,�Michael Stefaniuc

This thread comes up from time to time. I'm sure I've covered it before; multiple times most likely. It's probably in the FAQ too. I imagine most of the documentation guides. But, hey, it's always fun to rehash this stuff because who knows how many folks are just tuning in. Simple question:

Can i compile my program to executable file that can be run without wine ?

Dimi's simple answer:

No.

That prompted the original person to reach an epiphany:

Hmmm.... Than i don't see any reason to compile program using winelib. What is the difference between

and

I think the goal of winelib is to make independent executable. And i don't see any other goal.

Which would seemingly make sense.. why bother at all? Is the pain worth it? Dimi explained some reasons why you might want to port it and the difference between a native winelib app and a normal Win32 program:

True, there's not much reason to do so other than:

  1. being able to call Unix functions from your Win32 program
  2. a warm and fuzzy feeling that you've "ported" the app to Linux :)

Right now, not much [difference], other than one is in the PE format, the other in the ELF format. So the second one is in the native Linux binary format, which a lot a people seem to like (at an emotional level). The second one allows you do interact with the Unix environment, so it's not a complete waste of time.

Shachar Shemesh explained that it would be very difficult to remove Wine from the equation:

A Win32 program needs Win32 environment. Be that a registry, the Win32 APIs, or a forest directory structure and "My Documents" and "Program Files". While you may theoretically get the APIs by statically linking the DLLs into the executable, all of the rest are only available if Wine is installed on the machine. As such, I don't think a Winelib app will be able to ever live without a wine environment.

It is true that we can let go of the PE loader (in principle), but that is such a minor part of the grand scheme of things, that I don't see any reason to even attempt it.

As things stand, and it's certanly what I'm recommending to people - if all you want is to have your program function on an i386 Linux - just make sure the same PE works on Wine.

Mike Hearn explained a bit about the advantages to the porting process:

An app that is slowly being ported to be "native" may well need to be done in chunks. You can remove the registry requirements, teach it the FHS and so on, while still using HeapAlloc.

It's true there's little point just recompiling the app and saying "that's it", but obviously the value of winelib is not in allowing us to use ld.so instead of wine, it's in the ability to take a port slowly but surely, maybe never being completed but along the way getting sufficient integration for it not to matter.

Michael Stefaniuc mentioned that a app ported with Winelib is also capable of running on non-x86 machines. (At least in theory.) That's a pretty good summary of this topic. No one mentioned speed as a reason for using Winelib, the reason being is that there really isn't any difference. So the short answer is.. Winelib has it's advantages but it's probably not for the reasons you think.

5. Script to Help Translators

20�Sep�2003�-�22�Sep�2003 (10 posts) Archive Link: "tools/translations_status"

Topics: Internationalization

People: Dimitrie Paun,�

Dimi posted a little script, " Here is a little script that can help translators to keep their languages up to date. It already helped get the French translation updated :))) "

You can find it attached (http://www.winehq.com/hypermail/wine-devel/2003/09/0712.html) to his original email in the archives. Vincent B�ron then took a stab at creating a similar program (http://www.winehq.com/hypermail/wine-devel/2003/09/0765.html) .

6. Don't Translate Winecfg.. Yet

19�Sep�2003 (1 post) Archive Link: "winecfg translations"

Topics: Internationalization

People: Mike Hearn,�

Some new patches appeared for translations of Winecfg to other languages. Mike Hearn had some advice for anyone wanting to write translations:

Basically, please don't do them.

For starters, the GUI resources are constantly changing. Keeping the other versions in sync would be a full time job.

Secondly, it causes problems with getting a clean diff against CVS because of the way I'm doing it..

Right now I don't think winecfg is stable enough to be doing translation work, especially considering the total lack of support in the win32 windowing system for non-sucky i18n.

7. New Tests For Windows

23�Sep�2003 (1 post) Archive Link: "New winetests.exe"

Topics: Testing

People: Jakob Eriksson,�

Jakob Eriksson announced a new version of his conformance tests for Windows:

Ok people, new version. This time the tests (but not timetests.exe) are compiled with MSVC 7 instead of crosscompiled.

(No agenda behind that decision - it's just that current CVS is broken when it comes to crosstest.)

http://vmlinux.org/jakov/Wine/ (http://vmlinux.org/jakov/Wine/)

If you had fun with it the first time be sure to download it for another thrilling ride. Jakob then began working on making it compile with native MSVC headers. Thus far about 17 of the 20 tests compile. Alexandre suggested making sure he had the latest ones.

8. Lecture Slides Available

20�Sep�2003�-�23�Sep�2003 (16 posts) Archive Link: "Wine lecture slides"

Topics: Documentation

People: Shachar Shemesh,�

Shachar Shemesh posted a link to a presentation he put together:

I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html (http://shemesh.biz/lectures.html)

The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.

Several people pointed out inaccuracies or misleading comments. They do serve as a good outline for a presentation on Wine. Shachar mentioned it took two hours to go through this material.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.