WWN Issue 189

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

This week, 261 posts consumed 964 K. There were 61 different contributors. 35 (57%) posted more than once. 32 (52%) posted last week too.

The top 5 posters of the week were:

46 posts in 222K by Dimitrie O. Paun
25 posts in 59K by Alexandre Julliard
21 posts in 151K by Dimitrie O. Paun
19 posts in 114K by Eric Pouech
16 posts in 39K by Mike Hearn

Filesystem Roadmap	09/18/2003	Archive
Status Updates Filesystems 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 through 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 one 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: review some internal namings (that's easy) and file naming get Alexandre review (that's harder... I mean to get a positive review) cleanup the initialisation code 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: stick to current device structures, and store every bit of information (server-side) in the 'pathgate' object. beef up the device server object to store this information (unix device name, fake label, fake serial number). The latter 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: get the NtCreateFile ready and include it in the tree fix the introduces bugs convert the file/paths related functions finish the server side objects (devices...) Solution 2: 3. 1 2.a 2.b Thus far there hasn't been many responses. Alexandre hasn't committed the patch.

Filesystem Roadmap

09/18/2003

Archive

Status Updates Filesystems

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 through 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 one 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:

review some internal namings (that's easy) and file naming
get Alexandre review (that's harder... I mean to get a positive review)
cleanup the initialisation code

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:

stick to current device structures, and store every bit of information (server-side) in the 'pathgate' object.
beef up the device server object to store this information (unix device name, fake label, fake serial number).

The latter 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:

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

Solution 2:

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

The --dll Option Goes Away 09/25/2003 Archive

The --dll Option Goes Away	09/25/2003	Archive
Configuration 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 `wine --dll ole32,oleaut32,rpcrt4=n myprog.exe` basically because this is more convenient than altering the config file for each combination. I guess `WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n" wine myprog.exe` is only slightly longer. Why must wine's command line options be removed though? They are often handy for testing things out.

Configuration

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


wine --dll ole32,oleaut32,rpcrt4=n myprog.exe

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


WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n" wine myprog.exe

is only slightly longer.

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

Wine Developer's Guide Update	09/21/2003	Archive
Documentation 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 than 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.

Winelib: Advantages and Disadvantages 09/25/2003 Archive

Winelib: Advantages and Disadvantages	09/25/2003	Archive
Winelib 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 an executable file that can be run without wine ? Dimi's simple answer: No. That prompted the original person to reach an epiphany: Hmmm.... Then i don't see any reason to compile program using winelib. What is the difference between `wine program.exe` and `wine program.exe.so` 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: being able to call Unix functions from your Win32 program 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 a 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 certainly 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 an 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.

Winelib

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 an executable file that can be run without wine ?

Dimi's simple answer:

No.

That prompted the original person to reach an epiphany:

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


wine program.exe

and


wine program.exe.so

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:

being able to call Unix functions from your Win32 program
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 a 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 certainly 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 an 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.

Script to Help Translators	09/20/2003	Archive
Internationalization 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 to his original email in the archives. Vincent Béron then took a stab at creating a similar program .

Script to Help Translators

09/20/2003

Archive

Internationalization

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 to his original email in the archives. Vincent Béron then took a stab at creating a similar program .

Don't Translate Winecfg.. Yet	09/19/2003	Archive
Internationalization 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.

New Tests For Windows	09/23/2003	Archive
Testing 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/ 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.

New Tests For Windows

09/23/2003

Archive

Testing

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/

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.

Lecture Slides Available	09/20/2003	Archive
Documentation 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 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.

Lecture Slides Available

09/20/2003

Archive

Documentation

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

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.

World Wine News