Wine Traffic #263 For 25 Feb 2005

On Wednesday, a developer of Wine - an open-source implementation of the Windows application-programming interface that allows Windows applications to run on Unix and Linux - said he discovered that Microsoft's Windows validation tool checks for Wine and generates an error when it is found.

Wine developer Ivan Leo Puoti's e-mail was linked on the Slashdot.org site and immediately generated a flood of comments.

Now, what do most users think when something doesn't work? That's right, they think it's whoever builds the software. So in this case, the problem won't be the people behind Wine. But, it's not them, it's Microsoft.

"The reason we love this is because this shows that Microsoft is aware of Wine at very high levels," said White. "For us it's exciting -- it is an acknowledgement of us as a threat. Microsoft does not want the world to know how terrified of Wine they are."

But by far the most powerful feature of Xandros is its ability to run Microsoft Office applications through a program called Crossover, written by CodeWeavers Inc. of St. Paul, Minn. Crossover Office 4.1, originally bundled in Xandros 2.5, lets several supported Windows applications such as Microsoft Office 97, 2000, and XP run in the Linux environment. Crossover also makes Adobe PhotoShop 6, Adobe FrameMaker 7.1 and Dream-Weaver MX file compatible in the Xandros environment. With Crossover, government agencies using Lotus Notes 5 or later are also safe to use those applications. The Crossover application makes the transition from a Windows environment to a Linux world particularly easy.

I had high hopes that IBM would provide a Linux client for Notes, but none is available as of yet. IBM is committed to Linux as a Notes server platform, which is great, but its support of a Linux client is lacking. That being said, there is a way to run a Windows Notes client on the Linux desktop--WINE to the rescue.

Since the were only two things preventing operation of the game. The people at WineHQ have got World of Warcraft working with the help of Blizzard's WoW maintainer on the latest cvs and some patches provided on the developer mailing list. The game is playable under OpenGL using Raphael's Pbuffer patch.

It looks as though it's the Pbuffer stuff it is after. Right after all those wglGetProcAddress it does this:

trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
trace:opengl:wglGetPbufferDCARB ((nil))

So I guess it could be setting up stuff for the minimap long before it gets into the actual game.

Have you actually started on the Pbuffer code now Raphael? If you have, is there anything I can do to help? At the very least I have a testbed I suppose ;)

Ah ah !! Now we have some motivation to actually work on PBuffers... Now who, from Raphael, Olivier or me will send the patch first :-) ?

I owe you a beer!

It works great. No crash, and the minimap is there looking how I think it should (don't have windows or cedega so it's the first time I've seen inside the game properly). Unfortunately, wine crashes out if I move the mouse to another display. so I can't take a screenshot for you :( I'll take a look at that later when I've got more time. The minimap even works indoors (I think start rooms count as indoors), which is apparently something that doesn't work in cedega in opengl mode ;)

There were a couple of compile warnings, but nothing to worry about

The game is playable under OpenGL using Raphael's Pbuffer patch. The d3d9 mode doesn't currently work since the support for this dll is not complete. With Oliver Stieber's DirectX 9 patches the game has been run, but isn't quite playable yet.

Here is a brain dump of what I already know we need to fix for the CW supported apps:

1. InstallShield:
   RPC call re-entrancy
2. Lotus Notes:
   OLE drag/drop leaves an image of the window behind when it closes. Native does this functionality very differently to us.
3. VB apps:
   As Holly Bostick discovered to her cost, we can't load all OLEPicture resources correctly. Our OLEFont code also has misc bugs in, but we don't have any tests and code which uses these objects is rare so the full extent of the work here is an unknown
4. OLE Storage:
   IIRC misc things break in Office when this is pulled
5. Office embedding:
   We need marshallers for IOleObject for this, I think ... possibly a lot more. I do not know the details.
6. iTunes/iPod:
   Not fully investigated yet but I think we need to drop the typelib marshaller hack (this stands a good chance of breaking InstallShield for a short time as well)
   And one thing we probably don't care about:
7. Microsoft Transaction Server needs the typelib marshaller to generate RPC marshal-ops (format strings) instead of using custom marshalling like we do right now. But who cares about MTS while InstallShield and Office still aren't there? :)

As a rough guess, I would say that rsaenh.dll is 70% complete by now.

I think we should get rid of the rsabase.dll entry on the status_dll site (and probably also in wine cvs): rsaenh.dll is a complete replacement and rsabase isn't shipped anymore by Microsoft since Win2k (Applications don't load rsabase/rsaenh directly, but via advapi32, which looks it up in the registry).

Ivan has a script he uses and there are a few patches I keep in my tree. You can build on Windows using Msys and Mingw. Or if you want to cross-compile from linux I can send you my compiler.

Get msys and from www.sourceforge.net/projects/mingw and the compiler versions that work best are the ones listed here

http://reactos.com/wiki/index.php/Build_Environment

Older binutils have a forward exports bug that can cause problems.

You will also need a copy of flex and bison for windows. You can get them from here

http://prdownloads.sourceforge.net/mingw/mingwDTK-1.0.0-alpha-1.tar.gz

Among other possibilities, if you have an RPM based distro you could use my MinGW cross compiler RPM packages, prebuilt for Fedora Core and SUSE but also available as source RPMS to rebuild yourself:

http://mirzam.it.vu.nl/mingw

You need to do an out-of-tree build for the Wine tools as well as the PE build. Off the top of my head I repeat Alexandre's original recipe here: Assuming your wine tree is at /sources/wine:

$ cd /sources
$ mkdir wine-tools wine-pe
$ cd wine-tools
$ ../wine/configure && make depend && make tools
$ cd ../wine-pe
$ ../wine/configure --with-wine-tools=../wine-tools --host=i386-ming32
$ make depend && make

The last step will spit out many errors mostly because Wine targets Unix platforms, not a Windows platform like MinGW. But most dlls will actually build if you ignore the erros (make -k) or cd into the dll's directory first.

Does anyone know any site or book or something with a decent discussion about the problems of the different threading models and their implementations?

In the Developer's Guide in section 8.3 there are references to "the threading chapter". Is this a section that has not yet been written?

As I understand it we (in the pthreads version) "override the native pthreads library". What does this mean?

I am trying to research the issues associated with threading so that I understand the complications. The fact that Linux has two models and that Wine, FreeDCE and Samba (that I know of) seem to have found it necessary to bypass/hack/modify/override them indicates to me that there is something to understand.

It was written, and then the developer guide was reorganised and a ton of content was moved around. It's now under "NTDLL", which IMHO isn't very intuitive but I didn't reorganise it so I would say that :)

http://winehq.com/site/docs/wine-devel/c2749#NTDLL