Wine Traffic #182 For 8�Aug�2003

Change Log For CrossOver Plugin
2.0.2 - August 5, 2003

• This release is now built from the same codebase as CrossOver Office which means that compared to Plugin 1.x you get
  • a major update of the Wine code
  • a major update of PluginSetup
• Support for glibc 2.3 based distributions, including NPTL-based ones. This adds out-of-the-box support for RedHat 9.0, Mandrake 9.1 and SuSE 8.2.
• Added support for Acrobat Reader 5.
• Added support for the Cortona VRML plugin.
• Added support for the ebrary Reader plugin.
• Added support for the Quick View Plus viewer and plugin.
• Improved printing support: CUPS support, better compatibility with printers, especially HP4000, improved print speed, etc.

The project has paid off tremendously for Disney this year alone. Development of the porting solution, including site licenses, cost Disney less than $15,000. Had he opted to run Photoshop on Windows machines, it would have cost upward of $50,000 just in annual licensing fees, said Brooks. He estimates support would have been an additional $40,000 a year.

Although Linux has proven success on servers, it is just beginning to gain ground on enterprise desktops, experts said. Much of this has to do with emulators such as Wine, which enable companies to run Windows-only applications on Linux, said Chad Robinson, an analyst at Robert Frances Group Inc., a research company in Westport, Conn.

"Wine has always been an important element in considering Linux deployment on the desktop in corporate environments because desktop product vendors have simply not kept pace with server product vendors in porting their products," Robinson said. "Although there are a few methods of emulation available, Wine is one of the most complete and effective; and while not every application runs perfectly, enough do that many companies end up using it at some point."

Cool!

But "Micorosft Installer" might not be the most appropriate name for this implementation, eh? :P How about "Mike's Sexy Installer" ;)

Having clearly delved into this deeper than most of us, how complete would you say the documentation for MSI is? What do you think is the future outlook of this work?

The documentation for MSI is fairly incomplete. The file format was mostly undocumented, but it looks like things get better as they get more abstract ;)

Fortunately it seems fairly well structured. The database and installer parts are cleanly seperated from each other.

The next steps are:

• create a second parser for MSI conditional expressions (and figure out how to get two parsers into the code and keep Alexandre happy ... since pure parsers require a fairly new version of bison :)
• make the database read/write - not immediately important, but necessary later

There's undocumented interaction with shell32 to create "Advertised Shortcuts", which are evil shortcuts that contain an identifier that only MSI can understand. If you look through SHELL32.DLL from Windows 2000, you can see it links to MSI.DLL.

However, now that the database is understood, the main installer loop is a little easier... it appears that you just iterate over the "Action" tables, and do the actions in the order specified.

I don't have lots of time to work on this at the moment, so if somebody wants to have a go, I'm happy to help them out.

ps. maybe we can just call it the Wine installer...

Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments. (What's good, how it can be better, and what features could be there, but aren't) Currently the web interface consists of a few forms which do the following:

1. Compare imports or exports between two windows versions. This will output all APIs imported or exported by a dll you specify along with which version exports that API. Example: you specify wine and windows95 as windows versions. Each API will say it is exported by wine only, win95 only, or both. It is color coded in the hope of making it slightly more readable.
2. Perform general queries. This just does SQL queries based on the criteria you specify. You can query by any or all fields.
3. Find unimplemented APIs for a given program. This locates all APIs imported by a specified application and outputs the ones which are unimplemented or stubs in wine. This is broken down by dll which the app tries to import from. Red APIs are not in wine spec files while blue APIs are listed as stubs in the spec files. There are only a couple of apps listed right now. Leave the application field empty for a complete list. I intend to make the output hyperlinks which will query for all apps importing that specific API. Maybe that will help find test cases when tracking down a bug.

The forms are currently at http://24.229.94.2 Unfortunately I can't keep this as a permanent location. The PC is just too slow and the scripts really hog CPU. They do lots of SQL queries. :)

personally I'd like to see:

• which DLLs exist under which versions of Windows/WINE. I'm thinking a table which lists each DLL (the union of all of them) in a row, and column for each Windows version indicating whether it exists.
• for each DLL, which functions it exports under which versions of Windows/WINE.

I have completed work on a script which makes an export table. That is, it's completed if noone discovers a problem or feature that should be added. This table will have all windows versions in a row across the top, and dlls in a column down the left side. Each dll has an X for versions of windows - including wine which export that dll. The X is a link to one of the CGIs which queries for all APIs exported by that dll in that particular windows version. The script is currently generating the table and it seems it will take a good 8 hours or so to finish!! There is a HUGE number of dlls. I think some .ref files might not be from clean installs. If anyone can identify for certain dlls which are not part of windows please let me know so I can clean up the database and the table. You can check it's progress at http://24.229.94.2/export_table.html. I think when finished it could use some color, maybe a style sheet. Any other comments?

The compare.cgi script now has a checkbox which toggles all output vs only differences as Dimi suggested.

In case anyone noticed winnt40-sp6a queries did not return any results. The version field was truncated. I fixed it by dropping the 0. :)

A windows NT 3.51 version has been added to the database.

(Try#3 - Also fixes Operation Flashpoint problem which was introduced AND includes the patch... oops!)

This is the first patch which looks at the performance of changing the textures on a texture unit. As was pointed out to me by Lucho, certain information is per texture unit and hence not affected when a different texture object is bound. This patch on my machine changes the displayed fps by the Billboard sample from 30.6 to about 42.6. [Actually it was 43.0 with patch b, but I dont see why!]

There is still more optimization which can be done here, but this is a start.

My goodness... Flashpoint works? How long has that been? Good $*^!$#^@ work!!

But: you should /not/ have told me this as I will be much less productive now.

I should define 'work' - The graphics appear ok now, but I always run with sound disabled (I have enough problems without adding to them) so I have no idea if sound works. However, this is the game I mention has a weird mouse cursor which does silly things like jumping and not liking diagonals!

Therefore it is viewable (I started the tutorial and it all seems to display fine), but I wouldnt call it playable...

Get on with the OLE/DCOM stuff instead :-)