Wine Traffic #263 For 25 Feb 

By Brian Vincent

Table Of Contents

Introduction

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 (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 227 posts in 2959K.

There were 77 different contributors. 43 posted more than once. 41 posted last week too.

The top posters of the week were:

1. News: WGA Articles, Misc Press

19 Feb  - 25 Feb  (1 post) Archive Link: "News"

Topics: News

People: eWeekJeremy WhiteGovernment Computer NewsLinux JournallinuX-gamers.netCodeWeaverseweekMicrosoftSlashdotNewsZDNetIvan Leo PuotiWineHQXandroscvs

Ziff-Davis confuses me. The same article appeared in both Microsoft Watch (http://www.microsoft-watch.com/article2/0,1995,1766738,00.asp) and eWeek (http://www.eweek.com/article2/0,1759,1766843,00.asp) 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 Winearticle:

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 (http://www.eweek.com/article2/0,1759,1766920,00.asp) , 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 (http://news.zdnet.co.uk/software/linuxunix/0,39020390,39188944,00.htm) 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 (http://www.gcn.com/24_4/prod_reviews/35101-1.html) 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 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.

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 (http://www.linuxjournal.com/article/8113) 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 (http://www.linux-gamers.net/modules/news/article.php?storyid=707) 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 seems is great to see:

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.

The best part of the news? Screenshots!

2. World of Warcraft & PBuffers

16 Feb  - 23 Feb  (57 posts) Archive Link: "World Of Warcraft"

Topics: DirectX, Graphics

People: Alex WoodsLionel UlmerOliver StieberRaphael Junqueira

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:

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 (http://www.mesa3d.org/pbuffers.html) 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 noticable 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 (http://www.winehq.com/hypermail/wine-devel/2005/02/att-0693/01-gl.diff) . 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.

3. OLE Status

18 Feb  - 19 Feb  (5 posts) Archive Link: "Re: Making builtin OLE32 work right"

Topics: Status Updates

People: Mike McCormackMike HearnHolly BostickMicrosoft

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:

  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? :)

4. Forwarding rsabase to rsaenh

19 Feb  - 23 Feb  (10 posts) Archive Link: "Re: status of wine dll's"

Topics: Security

People: Michael JungAlexandre JulliardMicrosoftcvs

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.

5. Compiling for Windows and Cross-Compiling

24 Feb  (4 posts) Archive Link: "Compiling wine dlls for windows"

Topics: Build Process

People: Michael JungSteven EdwardsHans Leidekker

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

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

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:

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:

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.

6. Why Custom Threading?

1 Feb  Archive Link: http://www.winehq.com/hypermail/wine-devel/2005/02/0.html

Topics:

People: Bill MedlandMike Hearn

Bill Medland wanted to know the details about how Wine's threading works and what were 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 :)

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.