WWN Issue 263

This is the 263rd issue of the Wine Weekly News publication. Its main goal is to find a dark corner of the library. 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, 227 posts consumed 2959 K. There were 77 different contributors. 43 (55%) posted more than once. 41 (53%) posted last week too.

The top 5 posters of the week were:

16 posts in 54K by Mike Hearn
13 posts in 31K by Alexandre Julliard
13 posts in 63K by Alex Woods
9 posts in 25K by Lionel Ulmer
9 posts in 24K by Tom

News: WGA Articles, Misc Press	02/19/2005	Archive
News Ziff-Davis confuses me. The same article appeared in both Microsoft Watch and eWeek written by Mary Jo Foley with two different titles. The title from the Microsoft Watch article makes me cringe, so I'll quote from eWeek's Microsoft Seeks to Bottle Up Open Source Wine article: 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. Yes it did generate a lot of comments. Earlier this week another article appeared on eWeek, Microsoft vs. Wine: Deja Vu on the FUD Front , by Steven J. Vaughan-Nichols. It's a great summary, I'd suggest reading it. A little quote: 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. Feel the love. Later in the week, ZDNet UK picked up the story and included an interview with Jeremy White: "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." Unmentioned in any of the articles are the recent developments in Wine. I guess that's what WWN is for. Many major components being protected with the WGA are already in the process of being replaced, including MSI and DCOM. Government Computer News reviewed 3 Linux distributions and Mac OS X. The Xandros review was quite favorable: 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 Dreamweaver 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. Linux Journal had a series of three articles discussing the integration of Linux and Windows. It's a pretty neat series and contains some original ideas. In part 3 they included a few paragraphs discussing Wine, specifically using Lotus Notes with it: 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. On a lighter note, over at linuX-gamers.net an article about World of Warcraft appeared complementing a thread on wine-devel that's covered below. Just a few years ago it seemed like gaming with Wine was stagnant so the recent activity is great to see: Since there was 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. The best part of the news? Screenshots! Screenshot #1 Screenshot #2

News: WGA Articles, Misc Press

02/19/2005

Archive

News

Ziff-Davis confuses me. The same article appeared in both Microsoft Watch and eWeek written by Mary Jo Foley with two different titles. The title from the Microsoft Watch article makes me cringe, so I'll quote from eWeek's Microsoft Seeks to Bottle Up Open Source Wine article:

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.

Yes it did generate a lot of comments.

Earlier this week another article appeared on eWeek, Microsoft vs. Wine: Deja Vu on the FUD Front , by Steven J. Vaughan-Nichols. It's a great summary, I'd suggest reading it. A little quote:

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.

Feel the love.

Later in the week, ZDNet UK picked up the story and included an interview with Jeremy White:

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

Unmentioned in any of the articles are the recent developments in Wine. I guess that's what WWN is for. Many major components being protected with the WGA are already in the process of being replaced, including MSI and DCOM.

Government Computer News reviewed 3 Linux distributions and Mac OS X. The Xandros review was quite favorable:

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

Linux Journal had a series of three articles discussing the integration of Linux and Windows. It's a pretty neat series and contains some original ideas. In part 3 they included a few paragraphs discussing Wine, specifically using Lotus Notes with it:

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.

On a lighter note, over at linuX-gamers.net an article about World of Warcraft appeared complementing a thread on wine-devel that's covered below. Just a few years ago it seemed like gaming with Wine was stagnant so the recent activity is great to see:

Since there was 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.

The best part of the news? Screenshots!

World of Warcraft & PBuffers 02/16/2005 Archive

World of Warcraft & PBuffers	02/16/2005	Archive
DirectX Graphics The World of Warcraft news above spawned from a lengthy thread on wine-devel that stretched through 57 messages. This also happens to be the thread I mentioned last week that I hadn't covered. Well, over the past week more debugging and testing by Alex Woods resolved the major problem. After a few debugging sessions, the heart of the problem was identified and Alex wrote: 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 ;) That begs the question, what is all this PBuffer crap? Pixel buffers are part of OpenGL and can be used to do off-screen rendering. Generally the reason you want to render off-screen is for performance. First, you set up a nice image buffer and you do all your rendering into it. The processing to make a complete scene can be extensive and doing it in real-time can incur a noticeable performance hit. After you've rendered your scene into a buffer, it simply gets copied onto the screen. Needing PBuffer support led Lionel Ulmer to remark: Ah ah !! Now we have some motivation to actually work on PBuffers... Now who, from Raphael, Olivier or me will send the patch first :-) ? The next day Raphael Junqueira came up with a patch . Alex tried it out and reported: 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 Raphael cleaned up the patch and submitted it to wine-patches. There appears to be some parts Alexandre didn't like, but hopefully it's on its way in. Alex noted World of Warcraft supports both DirectX9 and OpenGL for 3D, but only the latter works: 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.

DirectX Graphics

The World of Warcraft news above spawned from a lengthy thread on wine-devel that stretched through 57 messages. This also happens to be the thread I mentioned last week that I hadn't covered. Well, over the past week more debugging and testing by Alex Woods resolved the major problem. After a few debugging sessions, the heart of the problem was identified and Alex wrote:

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 ;)

That begs the question, what is all this PBuffer crap? Pixel buffers are part of OpenGL and can be used to do off-screen rendering. Generally the reason you want to render off-screen is for performance. First, you set up a nice image buffer and you do all your rendering into it. The processing to make a complete scene can be extensive and doing it in real-time can incur a noticeable performance hit. After you've rendered your scene into a buffer, it simply gets copied onto the screen. Needing PBuffer support led Lionel Ulmer to remark:

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

The next day Raphael Junqueira came up with a patch . Alex tried it out and reported:

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

Raphael cleaned up the patch and submitted it to wine-patches. There appears to be some parts Alexandre didn't like, but hopefully it's on its way in.

Alex noted World of Warcraft supports both DirectX9 and OpenGL for 3D, but only the latter works:

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.

OLE Status	02/18/2005	Archive
Status Updates Mike McCormack wanted to know what issues with OLE32 needed to be tacked, I'd like to compile a list of all applications that don't work correctly without native ole32 (aka dcom95), then go through and try fix them. Mike Hearn ran through a list of issues: Here is a brain dump of what I already know we need to fix for the CW supported apps: InstallShield: RPC call re-entrancy Lotus Notes: OLE drag/drop leaves an image of the window behind when it closes. Native does this functionality very differently to us. 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 OLE Storage: IIRC misc things break in Office when this is pulled Office embedding: We need marshallers for IOleObject for this, I think ... possibly a lot more. I do not know the details. 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: 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? :)

OLE Status

02/18/2005

Archive

Status Updates

Mike McCormack wanted to know what issues with OLE32 needed to be tacked, I'd like to compile a list of all applications that don't work correctly without native ole32 (aka dcom95), then go through and try fix them.

Mike Hearn ran through a list of issues:

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

InstallShield:
Lotus Notes:
VB apps:
OLE Storage:
Office embedding:
iTunes/iPod:
And one thing we probably don't care about:
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? :)

Forwarding rsabase to rsaenh	02/19/2005	Archive
Security Michael Jung has done a lot of work to implement the new rsaenh crypto library. This week he commented on what direction this should take: 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). Alexandre cautioned against removing it completely since some apps might specifically look for it. Then he noted, We could remove the code though, and make it forward everything to rsaenh. Michael went ahead and did that, As suggested by Alexandre, I removed all implementation code from rsabase and made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's unicows.dll to do so. Alexandre looked at it and noted, You don't need that, you can forward directly in the spec file. Unicows has to do it differently because of the way it's loaded, but other dlls can use normal forwards. Michael made the change and submitted a patch.

Forwarding rsabase to rsaenh

02/19/2005

Archive

Security

Michael Jung has done a lot of work to implement the new rsaenh crypto library. This week he commented on what direction this should take:

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

Alexandre cautioned against removing it completely since some apps might specifically look for it. Then he noted, We could remove the code though, and make it forward everything to rsaenh.

Michael went ahead and did that, As suggested by Alexandre, I removed all implementation code from rsabase and made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's unicows.dll to do so.

Alexandre looked at it and noted, You don't need that, you can forward directly in the spec file. Unicows has to do it differently because of the way it's loaded, but other dlls can use normal forwards.

Michael made the change and submitted a patch.

Compiling for Windows and Cross-Compiling 02/24/2005 Archive

Compiling for Windows and Cross-Compiling	02/24/2005	Archive
Build Process Michael Jung wanted to know how to compile a DLL for Windows, I would like to test a wine dll I'm working on on windows. Could you please tell me how the wine dlls are build for windows ? (Or beat me to the place where it is documented.) Steven Edwards gave some pointers: 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 Hans Leidekker offered some suggestions as well: 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 errors (make -k) or cd into the dll's directory first.

Build Process

Michael Jung wanted to know how to compile a DLL for Windows, I would like to test a wine dll I'm working on on windows. Could you please tell me how the wine dlls are build for windows ? (Or beat me to the place where it is documented.)

Steven Edwards gave some pointers:

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

Hans Leidekker offered some suggestions as well:

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 errors (make -k) or cd into the dll's directory first.

Why Custom Threading?	02/ /2005	Archive
Bill Medland wanted to know the details about how Wine's threading works and what was involved with implementing it: 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. Mike Hearn pointed out the docs had moved, but were still around: 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://www.winehq.org/docs/winedev-guide/ntdll

Why Custom Threading?

02/ /2005

Archive

Bill Medland wanted to know the details about how Wine's threading works and what was involved with implementing it:

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.

Mike Hearn pointed out the docs had moved, but were still around:

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://www.winehq.org/docs/winedev-guide/ntdll

World Wine News