Wine Traffic Brian Vincent

This is the 127th 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).

News CodeWeavers News Michael Robertson NewsForge Jeremy White Xandros DesktopLinux

DesktopLinux.com has proclaimed July 4th wIndependence Day: wIndependence Day celebrates the burgeoning use of Linux on business, government, educational institution, and personal end-user computer desktops as an alternative to dependence on Microsoft's Windows operating system and associated products. Quotes are included from Michael Robertson of Lindows.com and Jeremy White of CodeWeavers. Essays are being solicited with winners receiving at shot at some great prizes.

Speaking of contests, TransGaming has extended both the Win a Gaming PC and the Name the Logo contest. The first one requires you to refer people to TransGaming for membership, the second is a contest open to all TransGaming members. Anyway, that's not the interesting news.

Seen on the sidebar of the TransGaming website was a reference to COMING SOON: Three KOHAN titles available at TransGaming. Kohan is an immensely popular game that falls into the real time strategy genre.

The biggest news of all comes out of Wal-Mart. You can now purchase a Microtel PC pre-loaded with Lindows SPX online. NewsForge pointed out the wording on the website has changed since the initial press release.

After reading that press release I was a little disappointed. Michael Robertson had promised to release source code when a product came out. Well, I didn't want to come out and ignorantly accuse them of not complying with their own release terms so I did a little digging. Unfortunately I can't find the original interview I got this from, but Mr. Robertson gave a pointer to the LindowsOS source code. I spent some time digging through it and found quite a few references to Xandros - specifically for what appears to be print filters, umsdos, and autofs code. Internally it seems this code is referred to as version 0.91 which may correlate to their 2nd preview release. One file makes a reference to Wine:

3. Specifically, there are no WINE source code mods here, because ALL of our WINE changes (even those changes we made when WINE was X11) have been submitted for inclusion to the main LGPL wine tree. Pretty much all of our changes were accepted and are currently in wine. Lindows.com currently does all their development on the LGPL wine tree, submitting all our changes back.

I wonder if anyone told Bruce Perens?

Documentation codeweavers

The next thread touched on documentation a bit, so I figured I'd repost some links to the various Wine guides. These docs are more linear than the standard Wine FAQ. At various times the Wine documentation ranges from excellent to non-existent. And sometimes the documentation is out of date and just not correct. In case you're getting started with Wine and haven't seen the various guides you may find these useful. Even better, if you think you can contribute feel free to fill-in the noticably missing pieces:

Creating Stubs

Sylvain Petreolle asked, I want to run a program that needs d3d8.dll. Using winedump I see there are only 5 functions exported. So what would the way to do a stub dll ?

A stub is just an unimplemented Windows function. In Wine the function will get called but typically won't do anything other than print a debugging message. Once in a while the function required isn't actually doing anything important, so a stub may be enough to make a program run. In many cases though, at least partial functionality is needed. A stub DLL refers to an entire DLL of unimplemented functions. In this case Sylvain is looking for DirectX 8.0. Lionel Ulmer commented, Yes, but if the program really needs D3D8, just stubbing these function will not help you much... The problem is that D3D (and the whole DirectX) is implemented using COM : there is only a bunch of functions exported from the DLL but that hides a LOT of code as function pointers in the COM object. So it's definitely NOT trivial to stub (except if you plan to return 'not supported' :-) ).

Ian Stewart gave a pointer for documentation, I did some initial work implementing a stup ctl3d.dll (which I intend to get back to, honest!). I found the 'IMPLEMENTING A NEW DLL' section of DEVELEPORS-HINTS to be a good starting point. According to Alexandre, this file is grossly outdated and 'real' documentation will be written eventually. Until then, I reckon DEVELOPERS-HINTS is better than a poke in the eye...

Lionel replied with a more detailed explanation:

Well, just look at, for example, 'dinput8'. That's the easiest DLL I know and should be pretty equivalent to 'd3d8'.

Basically, you need to

  1. create the d3d8 directory
  2. create a spec file with what winedump tells you
  3. create a d3d8_main.c (or whatever) file with the stubs in it
  4. create a Makefile.in file
    (from 2) to 4) is just basic copy / paste / replace from what is in dinput8 using the information provided by MSDN / winedump).
  5. run make_dlls in the dlls directory
  6. add a 'dlls/d3d8/Makefile' line in configure.ac and regenerate configure

And that should be all :-)

Sylvain reported some success, Thank you Lionel and others, I now have a box saying that Direct3D 8.0 isn't detected instead of a crash and my stub function reports it correctly on the d3d debug channel.

Fixes

Jason Edmeades came across a problem, A program I am debugging has a 'View Readme' button which when clicked attempts to load the readme into write. Just a suggestion, but perhaps when we install the default applications we could have a symbolic link or dummy application which launches the wine version of notepad instead?

Francois Gouget said it wasn't that simple, The problem is that write will handle RTF and Word documents correctly, while notepad is just a text editor and will only display garbage... (yes, wordpad will probably have problems with complex word documents, but it should work with simple ones) Dmitry Timoshkov gave a little more detail and a possible solution:

I believe that Write is able to handle only old Word 5.x/6.x format files (and of course RTFs). RTFs should not produce too much trouble (just feed them to a richedit control). Regarding Word 5.x format here is a snipped from my very old DOS code which handled those files (*.doc,*.wri) well (it completely ignores formatting though):

I.e. there is a 128 bytes header with signature and text length in it.

I think that our notepad could be easy enhanced to deal with that format. Write could be just a symlink to notepad.

Internationalization

Shachar Shemesh was wondering how to go about adding the FriBiDi library to Wine in order to support bi-directional text:

I'm seeing two possible solutions to this problem:

  • If Fribidi was present during compile, check for its existance during run time. If not present, don't enable the run time option. or
  • Copy (port?) Fribidi into the WINE code. It's LGPL, so the license does allow that.

Francois Gouget put forth some ideas:

A way to deal with [it ] is to do like for FreeType, i.e. load the library dynamically at runtime, and disable support for it if that fails.

But I have another question which you have probably already envisioned (might even have already discussed on the list though I can't remember right now): FriBiDi being a Unix Unicode library, I assume it uses 4-byte Unicode characters? Won't it be a problem since Wine uses 2-byte Unicode characters?

That may be another argument for integrating FriBiDi with Wine

Behdad Esfahbod jumped in to mention that FriBiDi supports two or four byte characters depending on how it's compiled. A simple check in configure can determine which is the case. Behdad also thought maybe a customized version of FriBiDi residing in Wine code might be needed.

Alexandre thought adding it to Wine was probably a good idea, We need 16-bit Unicode chars anyway so you probably can't use the standard Fribidi. And this way we can share the Unicode tables with the rest of our code instead of duplicating a whole lot of it. All you really need from Fribidi is the algorithms, and these are not going to change often anyway so copying them into Wine shouldn't be too bad.

Documentation Ian Pilcher

Ian Pilcher was having a redrawing problem with the Lotus Notes client (version 4.6.7). In the course of discussion Ian mentioned that it had worked about a year ago but a patch had caused a problem at some point. Tony Lambregts mentioned, I estimate that it should take no more then 12 itinerations to find the day of patch that broke it Ian wanted to avoid installing Wine multiple times because of the hassle of tweaking the installations. Several people jumped in to mention that it's really not that hard to do. Vincent Beron had the first suggestion:

Wouldn't it be possible to just install it in a scratch directory in the home dir or in /tmp? That's what I do now for test builds, and it works pretty well. I just use a wrapper script (yes, another) to wine, which sets up the environment variables needed for it to work (PATH, LD_LIBRARY_PATH, etc.).

In fact, I attach it here if you'd need it (or if somebody else needs it). Of course, you also need to tell ./configure --prefix=/where/you/want/it, then it's a normal make depend, make, make install.

The first time, you'll also need to modify your wine.conf and install the basic registry. And when you're finished with it, rm -rf (or F8 in mc).

Francois suggested something similar:

You don't even need to install it at all. I have never installed Wine on my system.

What I do is something along the lines of:

    export WINE_ROOT=/home/fgouget/wine/wine
    export LD_LIBRARY_PATH="$WINE_ROOT:$LD_LIBRARY_PATH"
    export PATH="$WINE_ROOT:$WINE_ROOT/server:$WINE_ROOT/tools:$PATH"
    export WINEDLLPATH="$WINE_ROOT/dlls"

Actually I have a script that does the above and which I use to pick one Wine tree or another (". wenv wine" or ". wenv wine2", etc.).

I also have a ~/.wine directory with a fake_windows configuration that I reuse from one time to the next. I also have it tarred so I can in essence "rm -rf ~/.wine && tar xvfz dotwine.tar.gz".

Vincent asked about some of the variables in the script to which Francois replied:

WINE_ROOT is just an environment variable I use so that I don't have to type the full path to the Wine sources over and over. It's even more useful in my wenv script.

WINEDLLPATH tells Wine where to find the builtin Wine dlls. Here /home/fgouget/wine/dlls

WINE_PREFIX tells Wine where to find its configuration file. By default this is $HOME/.wine