Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #164 For 4 Apr 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 164th release of the Wine's kernel cousin publication. It's main goal is to frantically catch up with Wine development after being on vacation. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 185 posts in 556K.

There were 52 different contributors. 27 posted more than once. 27 posted last week too.

The top posters of the week were:

1. News: Interviews, Reviews, Other News

29 Mar 2003 - 4 Apr 2003 (4 posts) Archive Link: "News"

Topics: News

People: Mono, , Miguel de Icaza, Ender, Jeremy Newman, Ove Kåven, News, Thomas Wickline

Have you looked at the new WineHQ? We've got interviews! The first one went up on Tuesday, Ove Kåven was the victim. Stay tuned for another one this Tuesday. Thanks goes to Jeremy Newman for posting these on WineHQ for me. I'd also like to thank Thomas Wickline, Juliusz Gonera, and Ender for the screenshots they submitted. Jeremy had a hard time grabbing them from my web site so only a few made it in (maybe in the future we can figure out a way to get others on there.) I intend to keep all of them you submitted; there's a collection of all the screenshots as well as a gallery showcasing some of the better ones.

Development is rolling along nicely. We've seen three weeks of daily CVS commits! (Suffice to say, if you're running Wine-20030318 it's considered out of date.) There was a bit of a patch pileup in February, but things are definitely rolling along again. Over the past few weeks Alexandre's caught up on the backlog, committed substantial changes of his own, and reworked others' patches. Speaking of which, if you submitted any patches that didn't get into CVS you may want to revisit them. Also, I expect sometime this week we'll see another snapshot appear out of CVS.

OSNews did an interview with Miguel de Icaza about Mono. He only briefly mentions Wine but does provide a link to screenshots of Mono showing Wine integration. You'll also find a short introduction about Windows.Forms on their website including this interesting quote, " In terms of integrating visually with the desktop, we are hoping to contribute to the Wine project an mechanism to make it use the Gtk+ themes on X11 and Cocoa on MacOS to render the widgets, and get the native look and feel on each of these platforms. "

In other vaguely related news, Guru Labs put together an excellent technical review of RedHat 9.0. Normally I skip over reviews of new distros - they just don't provide enough level of detail to make it worth reading. This article was excellent though. If you're considering upgrading or installing RedHat 9.0 it's a must-read. And yes, it does happen to mention the problems with NPTL + Wine on Linux. (A little more info on that below.)

2. Wine & RedHat 9.0

3 Apr 2003 (4 posts) Archive Link: http://www.winehq.com/hypermail/wine-devel/2003/04/0.html

Topics: Fixes

People: Dimitrie Paun, Alexandre Julliard, 

As discussed in detail in past issues, RedHat 9.0 has a problem with Wine. RedHat's using a new threading library that didn't quite get along with Wine. Alexandre has done a lot of work in this area over the past few weeks and on Tuesday committed some changes that prompted Dimi to ask: " I've noticed you've checked in already some NTPL patches. Does this mean that Wine is ready for RH9? Can I go ahead and upgrade my system?"

Alexandre replied, " Yes, it's supposed to work. You have to use --with-nptl for now, I'm hoping to make it switchable at run time later; but apart from that it's mostly ready."

Dimi wanted to know if it could just be automatically detected when Wine is configured, but Alexandre didn't think so, " No, it really has to be determined at run time, there is no guarantee that the glibc that you are using at build time will be the same at run time. We could try to determine a default value for the --with-nptl flag, but it's not trivial, and we need to get rid of the flag anyway."

So take it all with a grain of salt - most of the heavy lifting seems done, but it might not work for you. Refer to issue #163 for the appropriate workaround. Or dig through the wine-devel archives.

3. Compiling With gcc 2.96

29 Mar 2003 - 30 Mar 2003 (10 posts) Archive Link: "Re: Compiling WINE - Hopeless situation? :)"

Topics: Build Process

People: Sylvain Petreolle, James Juran, , Ian Schmidt, Michael Stefaniuc, Dan Kegel

Matt Bailey needed some help compiling Wine with gcc 2.96 - the version that originally shipped with RedHat 7.0. In response Sylvain Petreolle mentioned, " update gcc to version 3.x.x, gcc2.96 was a broken unofficial version of RedHat"

Ian Schmidt, Michael Stefaniuc, and Dan Kegel all wrote in to mention that it should work just fine. The C++ ABI incompatibilities were a known problem, but it shouldn't have any effect on Wine. The last time gcc 2.96 was mentioned was back in issue #92 when James Juran suggested ditching the gcc 2.96-69 packages that shipped with RH 7.0 in favor of the gcc-2.96-81 packages that came with RH 7.1.

4. Duplicated Include Parameters?

1 Apr 2003 - 2 Apr 2003 (9 posts) Archive Link: "Compiling Wine sources with duplicated include parameters"

Topics: Build Process

People: Rolf Kalbermatter, Alexandre Julliard, Dimitrie Paun, , Francois Gouget

In the "I-noticed-that-too" category, Rolf Kalbermatter asked:

While downloading and compiling the latest CVS sources I noticed that the command line for each (most?) source files reads like

This is not a serious problem but the duplication of the two include parameters strikes me as odd and definitely unnecessary, making the command line unnecessarily long.

Seems like something in the makefile generation is causing this.

Alexandre explained the reasoning, " It's needed for out of tree builds, in that case the include paths are all different."

Dimi wondered when that was ever needed though, " True, but why do we need the -I.? Do we need to ever include anything from the current build dir?"

To which Alexandre replied, " Yes, some headers are generated, for instance the y.tab.h files. " Francois Gouget and Dimi still felt it was unnecessary and that the include paths were provided elsewhere, but Alexandre assured them there was a method to the madness, " Believe it or not, all that stuff is here for a reason. "

5. How to Just Access a Windows DLL

1 Apr 2003 (2 posts) Archive Link: "Whither specmaker?"

Topics: Winelib

People: Kevin Cousins, Mike Hearn, 

Kevin Cousins needed some info on a problem that comes up fairly often with developers of other projects. Say you have this great DLL available on Windows, how can you use functions in it via a native Linux program? Unfortunately the answer is usually not what they want to hear. Kevin mentioned what he worked on:

my problem is the oft-asked "How do I call functions in a Windows DLL from an ELF process?" I appreciate WineLib is an option, and have run into a number of snarls along that path:

  1. I have created a .dll.so to wrap calls to the offending Windows DLL. Calls are made through static function pointers which have been initialised in the .dll.so by calls to GetProcAddress() from what would be the DllMain() function there. I've not managed to get Wine to call that DllMain() function of my .dll.so, other than through a breakpoint in the debugger, and explicitly calling the function at that time. This way, my code runs even returning from calls to the Windows DLL, but mysteriously, no output file is written!
  2. I occasionally see user32.dll.so barf with a SEGV with the call stack mentioning res_146() deep during the first call to wine_dlopen().

I've also had a look at avifile, mplayer, and xine, to investigate how they do things. Linking avifile/plugins/libwin32/loader/libloader.a to my application means I can run as far as attempting to execute DllMain() on my Windows DLL before I see gut-wrenching a SEGV.

What are other people doing?

Mike Hearn confirmed he was on the right track:

Well, see me discussing that with Bill a few days ago on the mailing list archives. Basically you have to make the whole ELF process into a WineLib app, at the moment you can't just call out from a standard linux binary into WineLib. IIRC mplayer does this by copy and pasting some wine code, then hacking it lots, even then that's only for codecs which are extremely simple programs.

The basic problem is that there isn't any good way to initialise WineLib without using the wine loader program at the moment.

 

 

 

 

 

 

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.