Wine Traffic #109 For 24 Nov 2001

By Brian Vincent

Table Of Contents

Introduction

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

There's a new website out there with lots of screenshots and info on using Wine with various applications and games. Check out http://franksworld.net/wine/ for lots of eye candy and good info. For instance, here's the page on Corel's Bryce 4.0: http://franksworld.net/wine/pages/apps21.html (http://franksworld.net/wine/pages/apps21.html) .

Also worth mentioning again is the official Wine apps database (http://http://wine.codeweavers.com/appdb/) . Have you gotten a Wine application to run (or not run!) under a recent release? Add (http://wine.codeweavers.com/appdb/appsubmit.php) it to the database!

Mailing List Stats For This Week

We looked at 170 posts in 544K.

There were 50 different contributors. 29 posted more than once. 20 posted last week too.

The top posters of the week were:

1. Running 3D Studio Max

13 Nov 2001 - 14 Nov 2001 (5 posts) Archive Link: "3D Studio 4 notes"

People: Peter BortasMaxGerard Patel

Peter Bortas took a quick look at running 3D Studio Max v4 with Wine. His initial report wasn't too promising, " I took a quick look at running 3DS Max v4 in Wine. It pretty quickly chokes when when feeding RegSetValueExA with a null pointer as the data for the key "NullFile". The appended hack will go around that. Unfortunately the executable dies later on"

.

Gerard Patel thought the error looked like something that might be fixed in the latest version from CVS, but Peter verified that he was running the latest. From there Gerard suggested using the native mscvrt.dll rather than the builtin one.

2. MIDL and COM

14 Nov 2001 - 19 Nov 2001 (4 posts) Archive Link: "MIDL and COM"

People: Ove KaavenAlexandre JulliardFrancois GougetPatrik StridvallPatrik StridvalOve Kåven

Ove Kåven wanted some thoughts on a few different subjects:

OK, since list traffic is low at the moment (which might be because /var on WineHQ got full again, and as usual the secondary MX provided by Corel seems to have the functionality of a black hole, so I've now moved the apache logs off /var), I thought I'd try to liven it up a bit with a couple of things I'm wondering about...

Problem 1: MIDL-generated code.
midl.exe is Microsoft's IDL compiler, it reads .idl files which describe RPC and COM interface, from which it generates .c files, .h files, and typelibs. (It is possible to find copies of midl.exe floating on the net, as some people have put together "COM kits" for Borland C++ that contains midl.exe and some standard .idl files and put them on the web)

But can the machine-generated sources that MIDL outputs be put into the official Wine source?

And how about source IDL files? Can we put into Wine IDL extracted from real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from MIDL-generated Windows SDK .h files, like objidl.h, with a script?

Problem 2: RPCSS
rpcss.exe is the place that keeps track of which process owns which RPC endpoints, exported COM objects, and object activation tables. The IRunningObjectTable interface, for example, is managed by rpcss.exe, and keeps track of certain kinds of COM objects on the computer, so that other processes can connect to running COM objects. We probably don't want Wine to have to run a separate process for this? If not, can we put this kind of COM stuff into the wineserver?

Alexandre Julliard replied with some answers. As far as including .idl files, Alexandre preferred not to, but " If we want to use .idl files we'll have to come up with our own compiler, and then we can put the .idl source in the tree and compile it at build time." As far as extracting IDL, " No, anything generated from a Windows file is copyrighted by Microsoft, so we cannot distribute it. We need to rewrite these files from scratch, just like we do for the normal headers." And finally, to Ove's last point Alexandre felt it would be best to have the COM management stuff in a separate process for the first implementation.

Francois Gouget wondered, " Now where are all the usual non-lawyers on this list who would argue that API definitions, like prototypes in header files (which of course IDL, as a formalized API spec format, is all about), cannot be copyrighted? Oh well..."

Patrik Stridvall stepped up and threw out some more ideas:

I'm here. :-)

Well, I wouldn't really go quite that far. The API definitions in themselves can't be copyrighted, true. But a specific way of expressing them is, so compiling any Microsoft file will generate create a derived work copyrighted by Microsoft as the main rule.

However it is not quite that easy, since only the specific expression is protected, the compilation result is only a derived work if it still contains any protected expression.

In light of this you could argue that since, I presume, MIDL removes whitespace and commments which is IIRC the only really expression, since the rest the API defintions are just facts, that the MIDL compiled files just contains facts not any part of the protected expression.

However that is a little thin line to walk, since there is quite of lack of real cases in the area, so I would recommend that we do as Alexandre suggest. Beside having the real .idl files in the Wine tree might be useful for other things as well.

Patrik also added that, " There already are a multitude of open souce (GPL and otherwise) CORBA .idl compilers. Of course Wine have probably slightly different requirements but I should guess that we could save 90% of the work compared to writing it from scratch."

3. Screensaver Settings

15 Nov 2001 - 16 Nov 2001 (12 posts) Archive Link: "Re: SystemParametersInfo: Screen Save actions"

People: Andreas MohrFrancois GougetAlexandre JulliardAndriy Palamarchuk

Andreas Mohr saw a patch come across wine-patches and wondered why Andriy Palamarchuk had submitted it:

Hmm, why did you remove X11 screen saving completely ??

Probably because it was horribly broken, right ? (SPI_SETSCREENSAVEACTIVE *activated* screen saver instead of *enabling* it - doh !)

Why don't you fix this strange code instead of removing it ? I guess I should do it...

Andriy replied that he'd had a discussion with Alexandre and decided system parameters would be independent from X settings. So in this case there would be no integration with how an application wants the screensaver settings to behave compared the actual X settings. Francois Gouget explained in more detail:

I don't know for SETSCREENSAVETIMEOUT but an application would want to get SETSCREENSAVEACTIVE and SPI_GETSCREENSAVERRUNNING right.

SPI_GET/SETSCREENSAVEACTIVE seems to be typically used by movie players. Imagine, you start palying a DVD, relax, and every five minutes the screensaver kicks in. This is why many movie players disable the screensaver when you start playing the movie and restore its initial state when the movie is finished. This is the case of mplayer for instance (and yes, it's a pain if they crash).

I don't see why we should prevent Windows applications from doing so. Similarly, SPI_GETSCREENSAVERRUNNING could be used by an application to stop its slide-show since noone will be able to see it. But actually, it now occurs to me that it may also be used by distributed-computing applications to know when to start their computations (for those that are not screen-savers). SPI_SETSCREENSAVERRUNNING seems pure evil though (and according to the doc applications are not supposed to use it anyway).

In fact, I disagree with Alexandre when he says:

> If users want to reconfigure X behavior, they have to use the X > configuration programs.

I think Wine is about more than just running Windows applications on Linux. It's about integrating Windows and Linux applications and thus they should be able to manipulate these kind of settings. Otherwise Wine would only support the 'desktop mode' or it would not exist at all and everyone would be happy with running Windows in a sand-box ala VMWare.

So it may make sense to maintain some parameters separately from the X settings (especially when their is not corresponding X setting), but I think the above parameters should be 100% backed by the corresponding X setting.

Alexandre clarified his position, " I also said there could be exceptions... I agree temporarily disabling the screen saver can be useful, so we probably want to allow at least that. I'm not sure we want to allow messing with the timeout though. " From there the discussion centered around whether to support the screensaver timeout or not. Andreas felt the optimal solution would be to have a configurable parameter that allowed changing the timeout. Francois felt there were a lot worse things an application could do, so why not let them mess with the timeouts too. Andriy said he would begin working on an implementation in a few days.

4. Source Code Graph: x=sqrt(|y|)

16 Nov 2001 (2 posts) Archive Link: "I've been too damn bored today..."

People: Andreas Mohr

Andreas Mohr got bored and posted a graph of Wine growth: http://home.nexgo.de/andi.mohr/download/nicegraph.png (http://home.nexgo.de/andi.mohr/download/nicegraph.png)

5. Loading mmsystem

22 Nov 2001 - 23 Nov 2001 (7 posts) Archive Link: "mmsystem should be loaded at startup "

People: Josh ThielenAndreas MohrEric Pouech

Josh Thielen wanted some comments on a solution to a problem he was having, " Finale expects mmsystem to be present without having to call LoadLibrary on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm extensions are available. I checked out windows 95, and it has mmsystem and winmm loaded when no apps are runing besides the desktop / explorer. This patch links wine with winmm and makes winmm load mmsystem on init. Finale gets by this ok now. I don't know if this the correct approach, though. Could someone (Eric or Alexandre?) please take a look at it before I send it to wine-patches?"

Andreas Mohr noted that the King's Quest 2 installer had the same problem. Alexandre thought that was best to only load mmsystem in wine_initial_task since that way it would only impact 16-bit apps. Eric Pouech agreed and posted some error reporting changes to Josh's patch.

6. shlwapi Improvements

20 Nov 2001 (1 post) Archive Link: "New level of Shlwapi (parts 1 & 2)"

People: Guy AlbertelliGuy Alberte

Guy Albertelli posted some patches to wine-patches and explained:

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows:

With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32

V5 of OE - requires native commctrl, comctl32:

V5 of IE - Does not start up yet. Requires native shlwapi

<sarcasm>
I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi.
</sarcasm>

 

 

 

 

 

 

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.