Wine Traffic Brian Vincent

This is the 199th issue of the Wine Weekly News publication. Its main goal is to become more avy savvy. 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
News Microsoft ReactOS News

Captive appeared on Slashdot this week. For those of you not familiar, Jan Kratochvil made the original Microsoft ntfs.sys driver work under Linux providing full read and write access to NTFS filesystems. The compatibility comes from a piecemeal of Wine and ReactOS parts.

OSNews published a really nice writeup about the combination of SuSE 9.0 and CrossOver Office 2.1.0. The author installed SuSE 9.0 on a colleagues machine when Windows became unstable. Various Windows apps, including the genetic sequencer "Sequencher", were required:

On the other hand, while the barrier to Linux usage by employees is arguably quite low, the real barrier is more likely that management and system administrators in many organizations may not yet have a clue about how to deploy Linux effectively. A clear prerequisite is having sysadmins who understand Linux or other *nix operating systems. For example, while this desktop installation of SuSE 9.0 proceeded flawlessly --and indeed much better than I anticipated would be the case with some failing hardware in the mix-- the installation of Crossover Office required a trivial bit of additional manual setup that certainly could have stumped Windows sysadmins who were new to Linux (Crossover installs without issue on SuSE 9.0, but application icons do not show up on the user's desktop). Solving the nuts and bolts of minor installation issues is however just a small part of the equation. A more important aspect is the realization that tools like Crossover Office exist and may have a number of advantages (speed, cost, ...) over alternative solutions like VMWare for organizations that are looking for practical ways to deploy Linux on a wider scale than they have previously.

The author, Ed Trager, is a bioinformatics programmer at the W. K. Kellogg Eye Center at the University of Michigan, Ann Arbor which happens to be my alma mater. At the time I graduated Linux was just starting to see some use outside of the geek community. Shortly after I left I heard a rumor that the engineering college had put together their own Linux distribution that integrated with the rest of the campus. It's good to see Linux is alive and well in A^2.

Ports

I guess the title I gave this thread is a bit redundant since Opteron implies 64 bit processor. Oh well. Jonathon Grant wondered the feasibility of buying one:

I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU.

Marcus Meissner gave a thumbs up:

There are no issues.

SUSE LINUX 9.0 for AMD64 is capable of running all WINE products, including regular WINE, CrossOver Office, CrossOver Plugin and WineX in the 32bit compat mode.

Jeremy White went a bit further:

Okay, I read that to mean that you can run already built 32 bit binary versions of Wine.

What about compiling? Would compiling Wine on an Opteron work? Hmm. I suppose you could cross compile to 32 bit, couldn't you.

Marcus described how to do it:

Well, I do ;)

SUSE 9.0 comes with full biarch toolchain support on AMD64.

Before you start, install additionaly to the default packages:

  • glibc-devel-32bit
  • freetype2-devel-32bit
  • XFree86-devel-32bit
  • XFree86-Mesa-devel-32bit
  • fontconfig-devel-32bit
  • openssl-devel-32bit
  • ncurses-devel-32bit
  • alsa-32bit
  • and any dependend rpms.

Then:

    export LD="ld -m elf_i386"
    CC="gcc -m32" AS="gcc -c -m32" \
    ./configure --prefix=/usr --x-libraries=/usr/X11R6/lib
    make depend all

The -m32 switches gcc to 32bit mode.

If you have arts-devel installed, you might need to patch dlls/winmm/winearts/Makefile and replace lib64 by lib.

You will also need attached winebuild patch that uses "LD" from the environment.

Multimedia

Tom Wickline revamped the Multimedia status page and asked for comments. You can view that work in his original post. Boaz Harrosh thought something was missing:

What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?

Mainly the filters in Quartz.dll and other basic filters that come with the OS.

if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) . I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.

Tom had those on his radar screen:

DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX.

But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz......

Tom asked if Boaz would be willing to help in the effort. Robert Shearman dropped a note to find out if anyone would be willing to get involved, If anyone would like to help with this please get in contact with me so I can help explain how I've implemented certain things so far, about locking, etc. The main things that are left to do to play 90% of media files out there are implementing the filter graph manager, the reference clock and the audio and video renderers (I have a hacky version of the video renderer in my local tree but it is not ready for submitting as a patch). Anyone that likes COM and graph algorithms should love the filter manager!

Boaz then made the mistake of admitting he knew a little about this and shared his ideas:

I meant to drop you a note, ask what is the status. But you beat me to it.

I have 7 years experience in writing DS filters. I am currently working on enhancing C++ on wine. I have ATL/WTL/MFC compiling and working under winelib. I have compiled COM controls generated by ATL VC++ wizards. I have some problems with the typelibs and so. But this is beside the subject. I would be happy to help in any way I can. I have lots of code that is not MS's. Also I have MS Direct Show Classes compiling and linking under Winelib (again some problems with the typelibs.)

I have my own copyrighted DirectShow video render that is implemented on top of DirectDraw. It uses the Overlay Surfaces YUV or RGB what ever is available/requested. It will also fall back to HW (HardWare) memory surfaces that are not overlay. I did not yet implement the Memory surfaces support. (didn't need to but it should be easy to add them). I could release that code under wine I guess. If so I would also release the windows version of it. But before I do that, there are some issues to resolve (in order of importance):

  1. C++ code must be accepted - This is not an area that C is good enough, and in any way I don't know C I am only good in C++
  2. What is the status of the DDraw lib. Will it support HW and Overlay 2D surfaces? (does it support HW BOB)
  3. I am some what dependent on MS DirectShow Classes. (Derivation) I have a lot, self implemented, but some of the basic stuff I used. I guess I could reimplement them but it will take time. Do you know what is the license issues with this code. I know that I have delivered them to many paying clients, and it was checked by the legal department. I all ways thought that, that code is: Do what you like no liability what so ever.

About the Graph manager: I'll think about it. I can certainly do it. But It is a big project. Do you know of a Company that would like to finance such a thing to some extent. ( condition 1 above applies C++ only). I'll think about it any way. Maybe it is not as big as I think. (Usually projects are much bigger then I think they are)

The problem here may be with C++. In order to use it in Wine you'd need a really good reason.. and so far no one has been able to convince Alexandre of one.

Testing Jakob Eriksson Dimi Paun

Winetest is a new utility we've discussed in past issues. In issue #186 we covered Jakob Eriksson's initial work of getting Wine's test suite to compile and run on Windows. That was back in August, since then more work has been done (see issues #189 and #194). Dimi Paun decided that the few remaining issues preventing it from being integrated into CVS needed to be taken care. After a little discussion and some minor patches, Alexandre committed it.

However, that's only one piece of the puzzle. When you run it it packages up all the test results and sends them to a mailing list. Something is still required to parse those emails and create a nice table of information. Ferenc Wagner has worked on that side and dropped a note this week to start discussion again:

so we should start working out this one, too. First let me sketch the present picture. I've got a directory structure like this:

    |
    + 20030829 + 95
    | + 95_michael
    | + 98
    | + 98_joel
    | + 98_kevin
    | + etc.
    | ` 2003s
    |
    + 20030916 (similar)
    ` 20031127 (similar)

That is, one directory for each test collection and one subdirectory for each submission of it. For a new submission I create a directory, copy the results.txt into it, create a reporter.txt next to it, add it to archs in the Makefile, and make. For a new test collection I create missing.dll.txt's (presently dsound), Makefile and tests.zip in a new directory.

Changes needed at least:

  1. Windows version detected automatically.
  2. Tester name and contact (?) included in the results.
  3. Automatically generated tags, probably simple incremental numbers.
  4. Which submission should be the principal one? The first?
  5. Makefile at one level higher, archs variable autodetected.

But before doing anything, we definitely need the opinion of the website maintainer. We need a very simple CGI to handle the file uploads. Presently it is < http://afavant.elte.hu/~wferi/wine/winetest.pl>. All of the present machinery is available in that directory: Makefile, dissect, gather and the other ingredients. I don't know much about web design or anything about WineHQ's inner workings. What sort of output should we produce?

I think the above is enough for a start...

Dimi had some thoughts, but the key seemed to be getting something completed that worked.

WineConf 2004

Plans are underway for planning Wineconf 2004. Not much has been discussed, but there is a new mailing list for those planning on participating. It's going to happen the weekend of January 31st / February 1st (coincidentally it's Superbowl weekend.) For those planning on attending you'll probably want to get in contact with Jeremy White - group rates are available at the Best Western. Jeremy dropped a note this week about the format:

I've started mulling over an agenda for Wineconf, and I wanted to bounce some ideas off of everyone.

First, at the last Wineconf, while it was great fun, I think there was a strong sense that there were too many 'presentations' and not enough time for simple discussions.

So, to that end, I'd like to propose an agenda that has a fairly modest number of 'presentations', but then also includes slots for structured discussions, and lots of time for unstructured conversations.

And, of course, I think a nice chunk of the unstructured portions should be done over a meal and/or libations.

I've asked Alexandre to do a keynote, and I've asked a few of you to give targetted talks. If anyone has something they'd like to present on, please let me know.

For discussions, I'd like to suggest the following structured topics:

  1. Wine 1.0.
  2. In search of the magic bullet - Can we transform our processes in any way to make Wine go faster?
  3. Game hack fest (this could be all night Saturday, with beers)

Thoughts? Suggestions? All feedback is welcome.

RPC / COM / OLE Suse Microsoft Mike McCormack Ove Kåven TransGaming

Andy Rosenburg touched on a subject that hasn't been discussed in a while - InstallShield installers. You may remember that new versions of InstallShield began to break last year. We've talked about various things you can do to work around it. Andy reported decent success but still had problems:

I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from Suse 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software. I tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them.

We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken.

Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE?

If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did.

Mike Hearn's suggestion was to ditch InstallShield, One obvious solution then is to not use InstallShield. NSIS works quite well in Wine. If you are shipping a Linux version for a customer, simply using native installers (like RPM or Loki Setup) would work much better.

The real problem with InstallShield is its use of OLE and DCOM. Running with native versions of those DLL's helps, but obviously it's not the desired solution. Rob Shearman mentioned some of the problems with native OLE/DCOM:

I belive that it is our lack of proper ThreadingModel support in COM. We currently ignore the registry parameter HKCU\CLSID\{GUID}\InprocServer32\ThreadingModel. I believe we do that right thing in the case of that value being Apartment and the application calling CoInitializeEx(NULL,COINIT_APARTMENTTHREADED). However, we don't do the right thing in any of the other combination of flags. I belive the right course of action is to use stubless proxies to marshal the interface across boundaries in certain cases. These cases are listed in the books "Inside OLE" and "Inside DCOM" by Microsoft Press. Our Local Server COM also leaves a lot to be desired but that may or may not be needed for InstallShield.

Ove Kåven as done a ton of COM work for TransGaming and the ReWind tree. Over the summer Mike Hearn got a hold of it and began reworking it for inclusion in Wine. He described a little of that:

This mostly affects visuals I think - the last "known good" point of InstallShield on Wine was that it did work, and installed without crashing, however it looked ugly because repainting didn't work well (due to the lack of proper interthread marshalling). There have been regressions since then though, Marcus fixed one bad one lately (in-place coercion of arguments to IDispatch::Invoke).

Oves work on interthread marshalling has been X11 licensed and I produced a patch that merged it with WineHQ (and fixed a minor bugs and such). I think Mike McCormack has a copy I sent him, but I never submitted it. I need to do that sometime really.

"Essential COM" by Don Box is another good book, but a lot of the knowledge required is available on MSDN and MSJ articles, it's just scattered all over the net (the DCOM spec is a good reference too).

ReactOS Dimi Paun

Steven Edwards reported that the Windows version of OpenOffice worked with Wine:

I have just compleated a full install of OO 1.1 under WINE. No outsite packages are required to install and configure OpenOffice for Win32 under Wine. There are a few minor bugs with some of the strings in menus but I would rate it at 99%. If anyone is interested in a good hobby project a Winelib port of this would be nice to see.

With a little luck we may be able to have this running for WineConf under ReactOS.

The obvious question most people ask is, why bother since a native Linux version is available? Quite simply, it stresses both Wine and OpenOffice. The chance of running an application under Wine is directly proportional to its size and complexity. Years ago people were happy when Solitaire worked, so this is a dramatic improvement. Dimi Paun thought it might be difficult to demo it under ReactOS because of the build system, before we can attempt that, we need MinGW support in OO, and AFAIK, that's not supported just yet. Does anyone know of any (current) effort to remedy that?

Debugging Ulrich Weigand ReactOS Steven Edwards

Imagehlp.DLL is one of those odd system DLL's that live on the periphery of implementation. It's purpose is to analyze the structure of a PE file, such as another DLL. This library contains a slew of functions for working with and manipulating that structure. It's critical for debugging and error handling on Windows. If you're on Linux then you're probably more interested in using Wine's tools, such as winedbg. Andrew de Quincy wrote to wine-devel wondering about the status of the imagehlp library:

Now that I have IDA nearly sorted, I was wondering.. who maintains the imagehlp dll? It seems kinda empty, and I'm sure it was at one point more complete (I looked into wine some time ago).

Andrew has been in the news recently for another project - the new driver for the ethernet interface of the Nvidia nForce chipset. Alexandre replied, No, it has always been fairly empty, and nobody has been working on it recently. It's all yours...

Rob Shearman provided more insight into Wine's capabilities, However, most of it is implemented already in winedbg. It has been a long-term plan to gradually move code from winedbg to imagehlp (or the new and similar debugging DLL, dbghelp). PDB files are also supported in winedbg (so no investigation of the format should be needed). However, I'm not sure whether .dbg files are supported. They could be quite useful when a crash occurs in a native DLL (that doesn't have an associated PDB file) and Wine is the cause.

Steven Edwards hoped that it could be moved so ReactOS could take advantage of imagehlp and debughlp. Debughlp is the newer cousin of imagehlp. Imagehlp in Windows 2000+ systems still export the API but forward the calls to debughlp. Eric Pouech, the Wine debugger guru, noted that .dbg files are supported, but it also depends on the MS debugging format used. Ulrich Weigand wrote some support for some formats (NB09, NB10 and N11), but latest formats are not supported..

Concerning moving code out of winedbg, he added, I started some time ago porting the winedbg stuff inside dbghelp (I have a skeleton from this later DLL). If someone is interested to spend some time on this, I can provide what I have.

Debugging

Mike Hearn compiled a list of debug channels that are available in Wine. Debug channels let you see messages pertaining to a certain subsystem of Wine and can be turned on and off. For more information, see the debugging section of the Wine Developer's Guide. It's quite probable some of these channels aren't useful for anything any more:

There are quite a few, aren't there? Full marks to anybody who can actually describe what they all monitor :)

  • accel
  • adpcm
  • advapi
  • animate
  • aspi
  • atom
  • avicap
  • avifile
  • bidi
  • bitblt
  • bitmap
  • cabinet
  • capi
  • caret
  • cdrom
  • cfgmgr32
  • class
  • clipboard
  • clipping
  • combo
  • comboex
  • comm
  • commctrl
  • commdlg
  • computername
  • console
  • crtdll
  • crypt
  • curses
  • cursor
  • d3d
  • d3d_shader
  • d3d_surface
  • datetime
  • dc
  • ddeml
  • ddraw
  • ddraw_fps
  • ddraw_geom
  • ddraw_tex
  • debugstr
  • devenum
  • dialog
  • dinput
  • dll
  • dma
  • dmband
  • dmcompos
  • dmfile
  • dmfiledat
  • dmime
  • dmloader
  • dmscript
  • dmstyle
  • dmsynth
  • dmusic
  • dosfs
  • dosmem
  • dplay
  • dplayx
  • dpnhpast
  • driver
  • dsound
  • dsound3d
  • edit
  • enhmetafile
  • environ
  • event
  • eventlog
  • exec
  • file
  • fixup
  • font
  • fps
  • g711
  • gdi
  • global
  • glu
  • graphics
  • header
  • heap
  • hook
  • hotkey
  • icmp
  • icon
  • imagehlp
  • imagelist
  • imm
  • int
  • int21
  • int31
  • io
  • ipaddress
  • iphlpapi
  • jack
  • joystick
  • key
  • keyboard
  • listbox
  • listview
  • loaddll
  • local
  • mapi
  • mci
  • mcianim
  • mciavi
  • mcicda
  • mcimidi
  • mciwave
  • mdi
  • menu
  • menubuilder
  • message
  • metafile
  • midi
  • mmaux
  • mmio
  • mmsys
  • mmtime
  • module
  • monthcal
  • mpeg3
  • mpr
  • msacm
  • msdmo
  • msg
  • mshtml
  • msi
  • msimg32
  • msisys
  • msrle32
  • msvcrt
  • msvideo
  • mswsock
  • nativefont
  • netapi32
  • netbios
  • nls
  • nonclient
  • ntdll
  • odbc
  • ole
  • oledlg
  • olerelay
  • opengl
  • pager
  • palette
  • pidl
  • powermgnt
  • print
  • process
  • profile
  • progress
  • propsheet
  • psapi
  • psdrv
  • qcap
  • quartz
  • ras
  • rebar
  • reg
  • region
  • relay
  • resource
  • richedit
  • rundll32
  • sblaster
  • scroll
  • seh
  • selector
  • server
  • setupapi
  • shdocvw
  • shell
  • shlctrl
  • snmpapi
  • snoop
  • sound
  • static
  • statusbar
  • storage
  • stress
  • string
  • syscolor
  • system
  • tab
  • tape
  • tapi
  • task
  • text
  • thread
  • thunk
  • tid
  • timer
  • toolbar
  • toolhelp
  • tooltips
  • trackbar
  • treeview
  • ttydrv
  • twain
  • typelib
  • uninstaller
  • updown
  • urlmon
  • uxtheme
  • ver
  • virtual
  • vxd
  • wave
  • wc_font
  • win
  • win32
  • wineboot
  • winecfg
  • wineconsole
  • wine_d3d
  • winevdm
  • wing
  • winhelp
  • wininet
  • winmm
  • winsock
  • winspool
  • wintab
  • wintab32
  • wnet
  • x11drv
  • x11settings
  • xdnd
  • xrandr
  • xrender
  • xvidmode