Wine Traffic #170 For 16 May 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 170th release of the Wine's kernel cousin publication. It's main goal is to inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 182 posts in 611K.

There were 56 different contributors. 31 posted more than once. 30 posted last week too.

The top posters of the week were:

1. News: TransGaming Poll Update, SpyHunter Port, More on FoxPro

10 May 2003 - 16 May 2003 (3 posts) Archive Link: "News"

Topics: News

People: TransGamingMicrosoftNews

TransGaming updated their polls and opened voting for May. What's significant is the removal of some topics:

April's polling section has now been closed and the new votes for May are up. Check out the topics at in our voting section (http://www.transgaming.com/pollslist.php) .

We have made sufficient progress with WineX 3.0 and Point2Play that the following poll topics have been removed:

TransGaming issued a press release announcing a port of SpyHunter (http://www.transgaming.com/news.php?newsid=71) . What's not clear is if Wine had anything to do with it. Aspyr's web site describes the game (http://www.aspyr.com/products.php?p_product_id=1) as being offered only for Windows 2000/XP or MacOS X.

Linux Journal published an addendum (http://www.linuxjournal.com/article.php?sid=6869) to an earlier story about a Visual FoxPro developer who was prevented from giving a demo to a user group. Microsoft responded with vague wording suggesting end users look elsewhere concerning the legality of running Visual FoxPro with Wine, "you should seek your own legal counsel's advice when interpreting your rights and obligations under the Visual FoxPro End User License Agreement" . One lawyer did just that and posted his interpretation (http://leafe.com/archives/showMsg/139126) . Microsoft's position is ambiguous at best, but with army of lawyers it doesn't need to be any clearer.

More intriguing is Linux Journal's assertion that Microsoft wants to get rid of Visual FoxPro because it's so cheap to develop for. SQL Server is a cash cow comparatively speaking and presumably would want to throw their weight behind development environments that use it. This has led developers to look towards Visual FoxPro for cost savings.

At some point I mentioned there would be an interview every week on WineHQ. So far I've managed to miss deadline for the past month. I'm still shooting for Tuesday releases, now it's going to be every two weeks though.

2. Direct3D Status

13 May 2003 - 15 May 2003 (5 posts) Archive Link: "[dx8-21] Viewport fix"

Topics: Fixes

People: Jason EdmeadesErwin WolffMike McCormackLionel UlmerMax

There's been a ton of Direct3D work over the past week, in part to a public transportation strike (http://famulus.msnbc.com/FamulusIntl/reuters05-14-221212.asp?reg=EUROPE) . Most of it has already been committed to CVS too. Jason Edmeades wrote in to let everyone know Warcraft3 is working with regular old Wine:

FYI With the attached patch (http://www.winehq.com/hypermail/wine-patches/2003/05/att-0171/01-dx22.viewport.patch20030315) on top of the wine cvs tree, a no-cd install (requires native msvcrt until I fix the 'thiscall' issue) and running 'wine war3' warcraft 3 now appears to be pretty much right!!! (No more screen distortion / misplaced faces etc).

Thanks to everyone who has helped get this far, especially Raphael and Lucho.

Warcraft 3 (http://www.blizzard.com) came out last year and has been one of the top selling video games since then.

Erwin Wolff wrote to report Grand Theft Auto 3 is partially working with the latest updates:

I tested GTA3 again, but this time with the latest cvs. GTA3 runs much faster now and produces only one error:

Again, no in-game textures are being shown, only polygons and colors. The only texture that is being shown is the title of the game in the game menu.

Raphael Junqueira, one of the D3D 8 authors, replied that he might be able to get some texture support working for it. Lionel Ulmer gave him a pointer to some D3D 7 GL code that could be adapted.

Jason wrote in with another update later in the week, this time concerning Max Payne, " With this fix MayPayne is starting to be playable. Looks fine as long as you dont change weapon (Fancy doing it all with the pistol?). You have to wait with a black screen during some of the movie sections though. " A few hours later he had more problems fixed, including being able to change weapons, and announced, " Aside from no movies and no sound May Payne looks quite good. I also checked my changes didnt break warcraft3 either, so we now at least have 2 games which are playable. PS Dont expect much more from me for a while now - Busy playing games... "

Late in the week Mike McCormack submitted a patch to delay loading of OpenGL till runtime, noting, " This patch binds opengl at runtime, so we can build binaries with OpenGL enabled and still use some parts of ddraw on systems without OpenGL. " Lionel Ulmer requested that Alexandre not apply the large patch. The eventual goal will be to write a common D3D core that will provide a similar functionality, " Basically, we will have a d3dcore library linked to OpenGL and if DDraw fails to load it (for example if GL is not present on the system), DDraw will not support D3D. "

3. Lotus Notes Breakage

10 May 2003 - 12 May 2003 (6 posts) Archive Link: "Lotus Notes and wine and RedHat 9"

Topics: Fixes

People: Joe SquireUwe BonnesMike HearnMichael Stefaniuc

Joe Squire reported a problem running Lotus Notes and asked for help:

I had been running wine on 7.2 with Lotus Notes 5.0.11 successfully. I made the unfortunate discovery about RH9 and threads and wine a little too late after upgrading to RH9. I will be more careful next time...

Anyways, I downloaded the source (2003-05-08), and managed to configure with --with-nptl

But I ran into a problem that has already been reported at (thank you google)

(the issue was unresolved. Kevin rolled back to a previous wine source from 5/1/2003). As with that post, there had been no changes to the install in the wine directory. The Lotus Notes splash screen comes up. The background for Notes itself comes up. The password box appears, and the error happens when I punch in the password and hit OK.

Uwe Bonnes recognized the problem and described it, " it boiled down that Andi added a lot of functions in the user32 spec file, with no implementation provided. These functions are mostly only implemented in recent windows version, and Notes has to cope with these functions not available. But as we added them in the spec file, this request will be granted, but later fails when this function should be executed. "

Mike Hearn wondered if maybe the functions should be commented out in the spec file until they're implemented. Michael Stefaniuc pointed out that Alexandre had very recently supplied (http://www.winehq.com/hypermail/wine-cvs/2003/05/0131.html) that exact fix.

So, if you're using Lotus Notes and you ran into some problems recently give the latest CVS a try. Instructions (http://www.winehq.com/?page=cvs) for getting Wine from CVS can be found at WineHQ.

4. NPTL Auto Detection & RH9 Packages

9 May 2003 - 10 May 2003 (15 posts) Archive Link: "NPTL auto detection"

Topics: Integration

People: Alexandre JulliardMike HearnVincent Beron

More discussion of the recent threading changes appeared on wine-devel this week. Alexandre once mentioned that he'd like to make the use of NPTL-style threads detectable at runtime. Currently you have to do it when you compile by supplying configure with the "--with-nptl" option. When it came up again this week Alexandre mentioned that CrossOver Office 2.0 used a really ugly hack that wouldn't be included in the LGPL'ed Wine tree, " it's two sets of libraries and a script that tweaks LD_LIBRARY_PATH etc."

Mike Hearn wanted to know if it would be ok to submit a temporary fix that makes configure detect which threading library is in use. Alexandre pointed out a problem with that though, " Well, you can detect the lib in use at compile time but that isn't necessarily what will be used at run time, things like changing the kernel or even simply setting LD_ASSUME_KERNEL differently will break it. So I'm not convinced it's really more reliable. The real problem IMO is that we don't have NPTL rpm packages."

Mike pointed out that RPM's do exist, " We do, over at newrpms.sunsite.dk (http://newrpms.sunsite.dk) iirc, the biggest problems being that I think they depend on ALSA (not sure why) and that nobody knows about them unless they visit IRC. Plus they are for Redhat only (but really it's mostly redhat users with the problems)."

Dimi Paun wanted to add them to the SourceForge repository (http://sourceforge.net/projects/wine/) , but wasn't sure how well the RPM's were packaged. Vincent Beron, the RedHat RPM packager, thought they were ok since they were derived from his RH8 packages. Because of hardware problems it would be a while before he could create the RH 9 ones himself.

5. RPC Documentation Update

9 May 2003 - 10 May 2003 (4 posts) Archive Link: "DCE RPC documentation fund is collecting dust..."

Topics:

People: Greg TurnerMicrosoftJeremy White

A few months ago Jeremy White put together a PayPal fund to purchase some RPC docs. We covered this back in issue #156 (http://www.winehq.com/index.php?issue=156#RPC%20Data%20Marshalling%20(cont'd)) . Greg Turner wrote the list about the status of getting that documentation:

My apologies for not announcing this sooner, but it seems that the DCE RPC documentation package, which many of you kindly donated funds for, is a no-go. I've spent some time researching what, if anything, we need from OpenGroup, and unfortunately, I've never been able to get a coherent answer, even from OpenGroup's sales people.

Part of the problem seems to be that the DCE standard is "discontinued" by OpenGroup as a project. We wouldn't care if we knew what documents had relevance to wine. But it turns out that DCE covers a lot more than just RPC, most of which is not of interest to wine's RPC implementation. The RPC part of the standard, as far as I can tell, is freely available for download, including the fascinating "DCOM/ActiveX" standard (which refers to a separate ORPC standards document I have been unable to find, I'm afraid, to document the ORPC wire protocol :(; btw, I think Microsoft let their similar document fall of the 'net as well, you'll see links to it in various places... but I digress....)

So, insofar as I have questions about whether or not there's anything useful in there, OpenGroup's sales lady is unable to help -- she don't even seem able to give me the information thats available on the website, much less elaborate on it. That leaves me with no choice but to guess what is useful based on the information available to me: which seems to indicate that we don't need anything we can't get for free from OpenGroup.

So, the obvious question is, where does everyone's hard-earned money go? I've confirmed with Jeremy that refunds are an option; if you want your money back, let Jeremy know, and presumably he will make arrangements with you in private to get your money returned.

For those of you who would rather have your donations go to some other wine-releated cause, the matter is open for discussion. One idea which has been tossed around in private discussions between myself, Jeremy and Dimi is to rededictae these funds to the Wine Party Fund or some other wine conference fund. Another would be to find some other documentation we need to buy and use it for that. But, it's your money, and since every contributor essentially has veto power over their own portion of the funds, we obviously want to build some kind of consensus.

Sorry it took me so long to break this news, I spend a fair amount of time trying to salvage the original plan to buy the DCE doc's but it just didn't seem right to spend it on something which potentially has no value to wine... and then the guilt and procrastination set in... ;) Thanks for your patience on this matter.

Everyone who responded seemed fine with letting the donations be used for another purpose in the future.

6. Valgrinding Wine

12 May 2003 (1 post) Archive Link: "Valgrind for WINE tarball now available"

Topics: Debugging

People: Adam Gundy

Adam Gundy wrote in with another announcement for running Wine with Valgrind:

For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website:

no patching needed to WINE or valgrind. Just get the latest snapshot of WINE (or a CVS checkout), build for debugging, get the pre-patched valgrind and use it!

there are still plenty of bugs in WINE which need fixing - most are simple 1 line edits..

7. Separating 16/32 Bit OLE Functions

15 May 2003 (2 posts) Archive Link: "PATCH - Start seperating 16/32 in Ole and ole32 memlockbytes"

Topics: Architecture

People: Steven EdwardsReactOS

Steven Edwards started splitting out some functions in OLE and OLE32. He gave an update of what he's trying to do and some of the issues involved:

I am doing some work trying to seperate Ole* and Ole32 for use in ReactOS. Before we can make use of most of the WINE code all of the Non-Win32api imported functions are going to need to be compiled out or rewitten. I dont need someone to do this for me but I am going to need a little hand-holding as I dont want to waste my or anyone elses time.

Currentlly Ole32 Imports these non-Win32api functions:

Anywhere here is the first patch that removes a few of these imports if --disable-win16 is passed to configure. I still have a lot to go and this may need some cleanup/review from a OLE guru on Linux but it builds for me without warnings or errors under Mingw.

Changelog: Seperate Win16 and Win32 Ole support in memlockbytes.

8. Improving Exception Handling

12 May 2003 - 14 May 2003 (6 posts) Archive Link: "-fexceptions? -fasync-unwind-tables?"

Topics: Fixes

People: Greg TurnerAlexandre JulliardUlrich WeigandMicrosoft

For several weeks Greg Turner has been struggling with getting some exception handling to work. Ulrich Weigand asked Greg for a description of exactly what he was trying to accomplish. Greg described the problem:

Well, you are probably going to laugh, but now that we are using some MIDL-generated code, I'm racking my brains on how to improve the exception handling macro's built into wine. The MIDL-generated code utilizes the typical Microsoftian (Borlandian?) try { } except(bool expr) { } / try { } finally { } construct.

Possible goals are:

Now here comes the part that will make you laugh: I'm supposed to do all this without patching gcc, using c++, or doing anything nonportable. In reality, an x86-specific solution that really worked would probably cut the mustard, IMO, at least as a starting point for cross-platform support.

I made some proof-of-concept patches which use the existing wine macros and various gcc-ism's to achieve some of these goals (they are not "right", of course). I had given up on it, or at least put it on the back burner, but Ove's recent DCOM patches inspired me to continue bashing my head against the wall...

Anyhow, I'll take a look at the dwarf2 goodies, maybe I'll decide that it's do-able, but more trouble than its worth... either way, I intend to make some kind of patch out of this whole investigation, as I am pretty darn sure I can at least fix one of the forementioned deficiencies, maybe even two, without making any major sacrifices.

If I'm lucky, I will stumble upon a solution to all three, but I'm kind of learning some of this (OK, all of it ;) ) as I go, and somewhat skeptical of my chances...

Knowing you, Dr. Weigand, you probably instantly know how to achieve this, so don't worry about spoiling the fun, you can go ahead and tell us ;)

After more head bashing, Greg came up with something and requested some comments on it:

Implement gcc-specific "__TYPED_TRY" macro supposedly capable of intercepting return and running the finally clause. If it compiles, it should work on x86... If it fails to compile, it needs you to specify the return type as in

Other arches may have much less success ;) of course, almost any problem of this kind should be fixed by turning __TRY into the appropriate __TYPED_TRY. __TRY generates warnings, some may be fixable.

For more details, look at the actual patch (http://www.winehq.com/hypermail/wine-devel/2003/05/0394.html) .

Alexandre thought the problem required approaching it from a different angle:

Cool! now you can start considering how to support continue, break, and goto ;-)

(I don't want to discourage you, but I think you will eventually come to realize that the only way to make this work right is to do it in the compiler)

9. SourceForge Download Stats

15 May 2003 (2 posts) Archive Link: "[FYI] SourceForge stats"

Topics: Project Management

People: Dimitrie Paun

Wow. A lot of you use Wine. Then again, you're reading this so you better have some sort of interest. Dimi wrote in with some stats concerning downloads:

For the first time we are in the first 30 downloads (position 29 :)) on SourceForge:

We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;)

Tracking such stats is a good reason to use SourceForge for downloads. In no way should those numbers be representative of the number of how much Wine is used (and the same goes for every other project on SourceForge). Lots of people use Wine directly out of CVS, others stick with an older release because it works, and many download from other locations. It is good to see such a high ranking considering how relatively recent it's been that SourceForge hosts Wine downloads.

 

 

 

 

 

 

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.