Wine Traffic Brian Vincent

This is the 203rd issue of the Wine Weekly News publication. Its main goal is to write the wrong year on checks. 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
TransGaming

Once again.. here I am just a few minutes from putting out an issue of WWN and I realize I have no news. Well, that just doesn't isn't acceptable. It's usually possible to scrounge something up. This week Frank's Corner came through with instructions from linux-gamers.net on how to install Steam under Linux.

I found it interesting they advocated using Wine rather than TransGaming's WineX.

Status Updates

Rok Mandeljc did some work on DMusic and gave an update with his patch:

I finally found some time to organise my dmusic work of last two months in useful patch. Dmusic is now DX9 compatible, we have almost fully implemented (but not working :( ) IDirectMusicCollection/IDirectMusicInstrument, fully implemented IDirectMusicContainer and almost completely (but fully working I believe IDirectMusicLoader)...

Short, but not complete ChangeLog:

  • updated resources to DX9
  • completely rewritten headers (DX9 compat.; look much nicer now ;=)
  • removed IDirectMusicSong and IDirectMusicMelodyFormulationTrack (which are removed from DX9; weren't implemented in DX8 anyway)
  • combined/simplified IDirectMusicSomething/IDirectMusicObject/IPersistStream for objects that support loading
  • implemented IDirectMusicObject on all such objects; via generic functions
  • combined IDirectMusicTrack(8)/IPersistStream on all tracks
  • fully implemented IDirectMusicContainer (at least 90% if there are no private interfaces)
  • implemented IDirectMusicCollection (99% work & MS compliant behaviour; except for instruments)
  • tried to implement IDirectMusicInstrument (unfortunately uses some dirty private interfaces... :(
  • added dswave.dll; DirectMusic Wave
  • some changes in style
  • many, many more ;)

oh and if somebody is interested in test programs I wrote & used and some docs on dark sides of dmusic (written by myself ;)), mail me and you'll get them in 24 hours ;)

any feedback, suggestions or whatever are welcome

and happy New Year everyone!
Winelib Microsoft

You can port an app from Windows to Linux using Winelib. This shouldn't come as a surprise to anyone - after all, that's one of the goals of the project. In practice it's a lot harder than that. Boaz Harrosh let everyone know he just completed a major project:

Just wanted to let people know. And share this happy moment with my fellow workman

I have successfully Beta released a WinLib port of a, 1 million lines of code, windows program. QA will Install a first Linux Machine and will start to bang on it tomorrow. (Well more like an advanced Alfa I guess)

Technologies successfully compiled and running in the Project:

  • Windows GUI & API (wrapped in an Old C++ lib, ZAFF).
  • ODBC under CRecordSet from MFC - I use the MSSQL drivers, SQLing data from a neighboring WinXP-SQL Server. I used an mdac.exe installation application from Microsoft. With ODBC32 native DLL.
  • General MFC contains, Strings, OleDispatch OleVariant OleBSTR... and even some GUI. - Actually to manage that I had an MSVC++ wizard generated MFC MDI Application with ODBC access and forms. Which helped me debug the MFC library. So MFC is pretty much covered.
  • ATL/WTL OCX hosting and General ATL use for anything COM. - Here too a WTL app-wizard generated MDI application with IE and other OCXes on Forms help me verify the ATL subsystem. Including support for "uuidof", "#pragma property" and more. Hosting and Events work fine. ( actually ActiveX controls compile too, but TLB problem must be resolved.)
  • A solution for Linking with C++ shared libraries that in-turn also use windows API. (I call them C++ fake DLLs.)
  • C++ STL from STLPort ported to Wine to compile using msvcrt (and MFC)

And more stuff I cannot remember now.

By far the biggest problem was the msvcrt vs STL. and other native C++. This caused a big Linking problem where STL would bypass msvcrt but other application code would not. This proved to be fatal. From circular linking to allocators not matching to Libraries not able to load. Since MFC and ATL would not even think to compile with out msvcrt Headers and lib the issue had to be resolved. The only way I managed to solve it all is by directly linking msvcrt GCC style into STLPort and into every module there of. Now that would make some conflicts with OCX's like IE6 that can only run with native msvcrt.dll, so I also had to change it's name.

One of the thing I would like to eventually do is Make a static msvcrt library using same source code but having different make files to be used in such situations where it has to be directly linked.

Tomorrow I will start synchronization with wine current tree. Once I have it synced (2 days max). I will need someone to help me and guide me on how to send it all in. Dimi, will that be you?

So I guess the scores are:

  • Wine vs Windows 1:1
  • World vs Microsoft 3:10 (we are making progress, wait for the last round)
  • Boaz vs GCC 7:4
  • Good vs Evil (I better not say)

Then Boaz posted his first patch that added a new header to account for some problems he ran into. Although the definitions aren't part of any Microsoft has, he felt it was necessary to have them. Alexandre asked why the ones in winegcc didn't work. Boaz hadn't replied by the time this issue came out.

Integration

Mike Hearn wrote a script to install IE for you. Lots of programs these days depend on IE to be installed in order for them to work. So to simplify that process Mike automated it and made the script available at, http://bylands.dur.ac.uk/~mh/wine-ie/ . Mike put the following notes on that web page:

Just download and run it. The install should be entirely automatic, no options will be presented to you. It is designed to install on a clean WineHQ setup - I can't say whether it'll work if you use a pre-existing wine install full of cruft, or if you use random distro package X. I am a Wine developer so I only test this with WineHQ CVS. Do not try this script on WineX.

Afterwards you can run "iexplore" to launch it whenever you want. There should also be an icon in the menus if you use a standards compliant desktop (gnome 2.x+, kde 3.2+, probably others).

WARNING: This version of IE is not stable on Wine! This script is here to allow programs that depend on IE to function better, not to give you a new web browser. Expect frequent crashes and hangs if you use IE as a web browser.

Please do not report IE crashes to me. I am perfectly capable of reproducing them myself thanks :) If IE fails to install correctly on your machine however I want to know about it.

Integration

This topic has personally interested me since I ran into a problem last year with Wine's shortcomings when it comes to handling other Windows clients. Getting Windows' Network Neighborhood to work is a major undertaking in Wine and Juan Lang has recently done a lot of work in that area. There hasn't been a lot of discussion on the lists about it, but last week Juan posted some large patches. I'll just cover the links to the patches and his changelog notes:

  • SMB changes
    • implement both raw-mode (port 445) SMB and SMB-over-NetBIOS
    • separate file functions from SMB functions
    • remove fd_ops and (unused) dialect from wineserver SMB
    • general SMB fixes
  • implement NetServerEnum and NetShareEnum
    • partially implement NetServerEnum and NetShareEnum using RAP over SMB
  • implement network neighborhood
    • add the Network Neighborhood to the shell
    • Actually opening files doesn't work, but that's somewhere else

Thus far the patches haven't been committed.

Integration Ivan Leo Murray-Smith

Chris Morgan ran into a problem and thought of an easy way to fix it:

In trying to install the United Devices application the installer prompts me to go to a website to get the msi installer. Wine doesn't have a HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key in the registery. I was thinking about making a shell script something along the lines of:

    if browserX exists
      browserX $1
    else if browserY exists
      browserY $1
    ...

I would imagine most people have mozilla installed on their machines and we can check for konqueror, opera and other browsers. I've created a simple 'winebrowser' script, placed it in /usr/local/bin manually thus far, set the value for the above key to 'winebrowser %1' and symlinked /c/windows/system/ winebrowser.exe to /usr/local/bin/winebrowser.

Ivan Leo Murray-Smith suggested adding galeon and netscape to the list. A bit of debate went back and forth on how to integrate with KDE. It's possible to run kfmclient and exec the page directly, but some people pointed out the potential security problems with doing that. A few days later Chris posted a patch:

Has Rein's fix for mozilla and Ivan's additional browsers. Tried to clean the script up a little bit, could probably still use some work but I'm no script guru.

    * tools/winebrowser, tools/wineinstall, tools/Makefile.in, winedefault.reg
    Chris Morgan
    Add HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key and value. Winebrowser script. Makefile changes to install/remove script. Wineinstall should create a simlink from windows/winebrowser.exe to the location of winebrowser on the machine.