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.
Also worth mentioning again is the official Wine apps database. Have you gotten a Wine application to run (or not run!) under a recent release? Add it to the database!
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.
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
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?
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.
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
SETSCREENSAVETIMEOUTbut an application would want to get
SPI_GET/SETSCREENSAVEACTIVEseems 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_GETSCREENSAVERRUNNINGcould 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_SETSCREENSAVERRUNNINGseems 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.
Andreas Mohr got bored and posted a graph of Wine growth: http://home.nexgo.de/andi.mohr/download/nicegraph.png
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.
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
- Certain menu popups either fail to display, or bomb.
- Needs work in comctl32 rebar for extra space.
- OE seems to basicly work.
- Can display messages, change folders, and create messages.
- Cannot invoke address book, but can request address list when creating new message.
V5 of OE - requires native commctrl, comctl32:
- With builtin comctl32: OE fails to startup
- With native commctrl, comctl32: OE comes up but is mostly non-functional. Bombs on shutdown due to shlwapi.208 and shlwapi.210
V5 of IE - Does not start up yet. Requires native shlwapi
- With native shlwapi, builtin comctl32: IE has black toolbars with white lines. Menu line real small.
- With native shlwapi and comctl32: IE has black bitmaps for button bar. Mostly functional, however cannot access dropdown arrow for address bar.
I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi.