Wine Traffic #211 For 20 Feb 2004

This is the 211th issue of the Wine Weekly News publication. Its main goal is to slouch. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

There were 58 different contributors. 30 posted more than once. 24 posted last week too.

WineHQ saw quite a few site updates this week. A history of Wine has been added. For the most part it's the same as what appeared in WWN #183. The status pages were updated, including two new pages for porting status and Winecfg options. The introduction page now has a short index of resources that were previously buried a few links deep. Lastly, the Who's Who page has been completely rewritten and includes new bios of Wine developers.

All of those items are on the To Do list. It was updated to reflect the changes. I guess now is as good of a time as any to start keeping track of how progress is going on the To Do items:

Some newsworthy items came out of TransGaming this week. The biggest story is the release of WineX 3.3:

The majority of the technical improvements in WineX 3.3 have been driven by the implementation of support of Steam. Support for its online games has resulted in improved socket and pipe support as well as a major enhancement to font support. In addition to Steam, this release contains copyprotection enhancements and support for Dark Age Of Camelot as well some success in making a number of other titles functional with workarounds, although not yet to a point where we can say that they are supported. You will find some of these titles listed in the Known Problems section below.

Steam is Valve's peer to peer network designed to keep games such as CounterStrike and Half-Life up-to-date with the latest versions. It also has an instant messaging client that works while you're playing a game. Their release notes have a lot of technical detail about new additions. On a side note, Point2Play was updated to release 1.2.1 and now supports joystick and font configuration.

TransGaming's February Development Status and Voting Report outlines a lot of work in many diverse areas. In fact, there's so many things they're working on I'd have to copy the whole report to do it justice. So rather than do that, I'll let you follow the link and instead I'll just give the results of the top-ranked technology poll items:

I should also note that an article by InfoWorld, "IBM to launch MS Office for Linux", caused a bit of a stir. No one really knew what to make of it but Wine is the first thing that comes to mind when you read their objectives. Late in the week another article came out refuting the original claims. Whether or not something is going on behind closed doors remains to be seen, but you can bet that the technical manager that leaked the original story got his ass handed to him on a platter.

Kevin Koltzau is making progress on adding theming to Wine. In a patch on Sunday he remarked, " With this some apps may start looking partly themed (eg. the toolbar buttons in newer versions of mIRC are themed), and we can start adding theming code to widgets"

Mike Hearn asked, " Presumably this is only if you have a native luna theme lying around somewhere, right? Do you know what files we need?"

Luna would work yes, but thats not the only theme out there Many skinning sites have sections for msstyle themes, you could check out

http://www.skinbase.org/section.php?sections=msstyles

for example. Many themes are shipped with a ton of files, right now only the *.msstyles files are useful I've done the majority of my testing with the Luna theme, so bug reports on other themes would be appreciated

I'm working on a winelib app that will let you properly install themes, but for now you can set the following reg keys (replacing the filename to your selected theme)


[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ThemeManager]

"ThemeActive"="1"

"LoadedBefore"="1"

"DllName"=str(2):"%SystemRoot%\\resources\\Themes\\Luna\\Luna.msstyles"

ColorName"="NormalColor"

"SizeName"="NormalSize"

Later he posted a sample app to query, install, and uninstall a theme. Alexandre asked that he merge it into Winecfg rather than leave it as a standalone program.

A few weeks ago we mentioned Mike McCormack had gotten Mozilla Active X embedding to work (issue #206). Well, that attempt went awry and Mike went back and worked on it some more. This week he announced:

OK, this time I've done it the right way, and it at least works for one or two apps, with a screen shot to prove it.

Screen shot was produced by installing an older version of WinAmp (winamp281_full.exe) and the Mozilla ActiveX control version 1.6 from

http://www.iol.ie/~locka/mozilla/mozilla.htm

It would be nice if we could build Mozilla as a winelib app... ;)

To see the screenshot Mike mentions, see the post on wine-patches. Dimi wondered, " Very cool indeed Mike! One thing that I've noticed is that the code uses a lot of Mozilla dependent names, but the only thing that's actually Mozilla specific is the CLSID. Shouldn't we just read that info from the registry (from some sort of HtmlControl key), so that people can experiment with other things as well (e.g. IE) just by changing the configuration?"

Well, the way to experiment with IE is to do:


"shdocvw" = "native"

since shdocvw is part of Internet Explorer itself.

Ferenc Wagner has been working for quite a while on integrating the test results from Wine's test suite into the web site. This way a bunch of tests can be performed on real Windows boxes to make sure we have a baseline to measure Wine against. Once we get the test results they need to be parsed and organized in some fashion. That's what Ferenc's been working on. An initial commit was done this week, although it's not working yet. The basic framework is complete and you can find it in the tools module in CVS. Ferenc wrote the following README file about it:

This machinery is for receiving and analysing the reports resulting from running programs/winetest. The winetest program is a single- executable version of all the DLL conformance test programs suitable for unattended testing and report submitting. This package provides the destination for that and presents the results in an ordered form.

winetest.conf

winetest.cgi

A CGI script, which receives uploads from winetest and provides manual uploading facility. Asks the CGI.pm module to create its temporary file in $queuedir, then renames it to repXXXXX/report.

winetest.cron

Sample crontab entry illustrating the intended use of the tools.

dissect

This program looks for a file matching $queuedir/rep*/report, takes it apart in its directory while also creating summary.txt. If an error occurs the directory is renamed to errXXXXX to avoid future attempts at processing this report. If everything goes flawlessly the whole directory is renamed (based on the information learned in the process) to $datadir/BUILD/VERSION_TAG_DIGIT where DIGIT is for resolving name clashes and $datadir/BUILD/outdated is created to signal the change in the given build. Allowed builds are those in $builds. See also the head of the file.

gather

This program is intended to run as a second stage. See the sample crontab file, races and concurrency problems must be dealed with on that higher level. The program looks for a file matching $datadir/*/outdated, creates index.html in the same directory and removes the outdated file. See also the head of the file.

summary.css, summary.js, resultform.html

These files are referenced by the index.html files created by gather.

builds.txt

The file to have $builds point to.

Marcus spent some time this week getting Windows kernel drivers loading. Specifically, he tried to get SafeDisc working so that copy protection on games would be support. This was discussed a bit at WineConf and various ideas were kicked around. SafeDisc isn't working yet, and it's not even clear it's possible to support it, but Marcus took a stab at it. >From his changelogs:

This implements some very basic and functional kernel driver loading and execution.

Currently only tested with one driver and with just DeviceIoControl support.

Changelog:

This is sufficient to support the first windows kernel driver.

Note the lack of fastcall support (I just ignore the IofCompleteRequests arguments anyway).

Run necessary tools for dll adding ;)

Changelog:

Very first (partially hackish) implementation of ntoskrnl.exe.

This led Uwe Bonnes to ask what was working and what was still unsupported. Marcus explained, although in theory the SafeDisc driver should be working, it wasn't:

There is no need for any setup.

secdrv.sys of InstallShield just requires some functions of ntoskrnl.exe, which I have implemented to a degree it that it functions.

As of working, in Need for Speed v4 from Electronic Arts I now see the SafeDisc[tm] Splashscreen, then it is seeking on the CD pretty heavily, then the program terminates.

So consider the first step towards SafeDisc support done as soon as they are merged to CVS.

The driver, secdrv.sys, ships with each game using SafeDisc copy protection. It gets loaded when the game starts up, and until now wasn't supported at all. Mike Hearn theorized why it still wasn't working:

For the record (we already discussed this a bit on IRC) this is probably SafeDisc taking seek-time profiles from the CD drive. SafeDiscs contain certain blocks in unusual widely-spaced ordering that is not possible to recreate using standard CD burners. By reading each block in turn and checking that the seek times are high enough they can verify the CD has not been copied using consumer-grade equipment.

This test, in other words, should pass - as long as the Linux/Wine CD subsystems have similar timing profiles to Windows (gulp)

"Similar timing profiles" means the Linux driver for the CD-ROM and the Windows driver must operate in almost the exact same manner. If the driver expects a certain amount of time to read blocks on Windows it must take the same amount of time on Linux. Carlos Lozano pointed out things are further complicated by the fact that several different versions of SafeDisc exist and they operate in different ways.

One of the big to-do items is to cut over to the new configuration tools - winecfg and regedit. Both of them are now usable to the point where all of the wine config items can be stored in the registry. Right now we have some items in the default registry and other items still in .wine/config. The idea is to make the config file go away.

That leads to the question, how do you set up a registry if you don't have one? This isn't too unlike trying to get a config file if you don't have one. Except, Windows already has a mechanism for setting up and changing a registry - INF files. There is a caveat though. In order to install a registry you need to have the proper directory structure in place so Wine knows where "Windows" (c:\windows) is. For now, we won't worry about that little detail and just go on to cover Chris Morgan's work in this area. Chris announced an initial implemention of setting up the registry from an INF file:

Here is a first pass at replacing winedefault.reg with a windows inf file and dll registration. The registry entries in the inf file are not complete. Other than quite a few missed entries I've also left out the keys for Codepages and the Country List entries as these are pretty large(lots of typing, I'm lazy).

setupregistry is a shell script that registers dlls with regsvr32 and then installs the inf file using rundll32. Registering ddraw.dll results in a crash on my machine even though regsvr32 says it was registered successfully.

The best documentation I've found thus far for inf files, http://www.leeos.com/infdoc.html#Top, doesn't have anything about running programs from inside of an inf file. If this is possible it would probably make more sense to have the inf file register the dlls.

I've also attached a patch to implement InstallHinfSectionW() which passes the inf file to lower level setupapi functions for installation. Wasn't sure what the root key parameter to SetupInstallFromInfSectionW() should be, set it to \\HKEY_CURRENT_USER for now.

Some folks suggested using the RunOnce registry key entries to execute the DLL self registration. I mentioned to Chris that two INF sections seem to exist that would do the same thing: RunPreSetupCommands and RunPostSetupCommands. Chris looked into it and confirmed they exist even though they're highly undocumented. Steven Edwards mentioned the ReactOS tree was also working on implementing those sections but they weren't completed yet. Chris decided to work on them on his own.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	14 Feb 2004 - 20 Feb 2004	(3 posts)	News: WineHQ Updates, WineX 3.3
2.	16 Feb 2004	(4 posts)	Theming Update
3.	14 Feb 2004	(4 posts)	Embedding Mozilla's ActiveX Control
4.	19 Feb 2004	(2 posts)	Winetest Parser Committed
5.	16 Feb 2004 - 17 Feb 2004	(4 posts)	Kernel Driver (SafeDisc) Initial Support
6.	14 Feb 2004 - 15 Feb 2004	(7 posts)	Registry Setup Script

Wine Traffic #211 For 20 Feb 2004

By Brian Vincent