This is the 112th 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).
It's been a little while since we've seen a development release, so it shouldn't come as a surprise Alexandre released one. In the 20011226 release we have these changes announced:
Wine has had some severe regression problems over the past year. If you read the wine-users you'll see lots of posts that mention something like "don't use wn20011108 use wn20010510 instead!". The inter-process window communication stuff has created some problems for example. Andreas Mohr was working on LoadModule16() and noticed it had some major problems. The he decided to write a test program to discover how bad it was. The end result is, Andreas put out a request to put together a test suite for Wine:
due to the number of regressions I found few days ago, it occurred to me that we really need an API test suite now. Thus I went ahead and implemented a test functionality for LoadModule16(). The result: 7 of the 21 tests that I implemented were FAILING !! That's ONE THIRD. And that for such a highly basic function as LoadModule16(). That's quite incredible.
I guess we really should change our development model from trying tons of programs to *systematically* testing functions and Windows mechanisms now. If we can show everyone where stuff is failing, it might be a lot easier to attract new people.
I attached a preview of the posting I intend to post on *tons* of Windows devel newsgroups ("Call For Volunteers"). That way we might actually get hold of hundreds of Windows developers helping us implement a complete test suite (complete tests of up to 12000 Windows functions). Not to mention the additional PR we might get out of this...
If this works, then we'd need someone in charge of managing the assignment of specific windows functions to specific programmers. I won't do that (very limited time). Anyone from Codeweavers up to the task ? Or maybe someone non-developer and rather foreign to the Wine devel could do that task ?
About the program: My goal was to get a program with very easy parsing interface: fields separated by colons, nothing fancy and difficult to implement, ... A .exe can be found at: http://home.nexgo.de/andi.mohr/download/wt_ldr16.exe
Please comment on both my intended posting and the way I programmed the first version of the test suite (I'm not extremely happy with the current program; if you have any improvements, then get them here ASAP !).
As 12000 Windows functions is an enormous number, I think we should really start doing this NOW instead of years later once Wine really needs this. Wine does not extremely need this yet, but we're getting pretty damn close to that already.
Francois Gouget felt that such a testing framework could be very
helpful to others and might draw more contributors,
After all a Win32
conformance test suite could also benefit other projects like Odin,
ReactOS?, and any other Win32 reimplementation. Thus there may be an
argument that it could be beneficial to have a test suite that everyone
could contribute to. It could even be under a different license, like
GPL to ensure that all projects contribute to it fairly (and who wants a
proprietary Win32 conformance suite anyway). Such a strategy would even
make more sense if there was already such a test suite out there.
He also added that Wine's commandline handling would be perfect for such
testing. Although it recently received some updates, it's still buggy
and needs testing.
Andreas Mohr and Andriy Palamarchuk began exchanging emails and discussing
the format of the tests and the output. Both agreed that commandline tests
were the way to go. The output would be easily parsed and the tests could
be easily automated. Andriy did a search for testing frameworks and came
a list of some. Before any discussion took place as to which ones would
work, Alexandre pointed out,
Look at programs/winetest, that's the tool we should use to write
tests IMO. Andriy looked at winetest and reported:
Just looked at the tool. It only provides gateway from Perl to wine API functions, right?
Advantages I see in using script-based tests:
- tests can be used without recompilation
- Perl is familiar to many developers
- programming in scripting language is usually easier than in C
- Perl is widely used for testing purposes and I expect to find many testing tools in Perl.
- Many current Wine contributors don't know Perl
- one more level of abstraction does not give significant advantages in this application. On the contrary, it is more difficult to locate cause of problems because developer has to go trough one more, often not familiar layer. Absense of strict typing in this layer will hurt a lot.
Advantages of using C-based tests:
- compilation has to be used to run the tests. In some cases this is an advantage. Before running the tests you'd better be sure it at least compiles in both environments.
- C is the most familiar to developers language and the language itself is simpler than Perl
- Documentation for Win32 API is C-oriented. Examples, given in documentation are in C or easy translated to C
- Developers already have some testing code snippets in C
The discussion branched into whether the existing perl framework was robust enough to be useful. Alexandre argued that until people started using it and found fault with it, then there was no point in getting rid of what was already in place. He also felt that perl was usable and that creating the tests in C wasn't really necessary:
For Perl all you need is the winetest app that is in the tree, plus a bit of Makefile glue which is pretty trivial to do.
In fact here's a 10-minute hack to add a make test target. With that all you have to do is create a test script in dlls/xxx/tests/foo.test, put the expected output in tests/foo.test.ref (presumably generated by running the test under Windows), add your script to the makefile and run make test.
There were some arguments put forth for using C, but no one really experimented with the perl setup. Of course, one of the arguments for using C was that not very many developers were familiar with perl. Jeremy White gave everyone some reasons why the perl framework was enough and went on to list how to really make it usable:
- Modify the makefiles so that 'make test' (or make regress, or pick your poison) does something interesting, and does so without much hassle.
- Define a standard for how tests should work. For example, if I wanted to write a test for FunctionFoo(), I should be able to create wine/programs/winetest/tests/foo.pl, add '/wine/foo.html' to winetest/tests/Makefile.in, and my test should automatically become part of the regression suite.
(Note that adding tests/foo.c is just as trivial).
I believe that the defacto standard chosen at this point is that a test prints 'OK' if all went well, and it doesn't on error, and prints some clue as to what went wrong.
- Add a section to the documentation on how to do the same.
For testing under Windows, Jeremy felt,
Ideally, we would have a 'winetest.zip' such that all I would
have to do is install Perl, and then I'd have a nice set of
sample test scripts I could run/modify/tweak to my hearts
satisfaction. Alexandre agreed and added,
Exactly, yes. If possible winetest.zip should also include perl.dll
and the needed packages so that you don't even need to install perl at
all. I think it may be a good idea to have a winetest.zip that
contains winetest.exe and related files that you only have to install
once, and another zip that contains the test themselves which you may
need to upgrade more frequently (or that you could get directly from
CVS if you have a CVS client on Windows).
Francois then went and wrote a lengthy description of how to implement the testing. He purposely left it open to any language. I'll refer you to the link for the full description, but he started out with:
A test unit is an executable or script. You can name it anyway you like (please no space in the names, it's always annoying). All test units should be non-interactive. A test unit called xxx generates two outputs:
- its exit code
- text output on either or both of stdout and stderr, both of which are normally redirected to a file called 'xxx.out'.
A test succeeds if:
- its exit code is 0
- and its output, 'xxx.out' matches the reference output according to the rules described later.
Reciprocally it fails if:
- its exit code is non zero Either because one aspect of the test failed and thus the test unit decided to return a non-zero code to indicate failure, or because it crashed and thus the parent got a >= 128 error code.
- or because its output differs from the reference output established on Windows
Under this model each test unit may actually be comprised of more than one process (for instance to test CreateProcess, inter-process messaging, inter-process DDE, etc.). All that counts is that the original process does not finish until the testing is complete so that the testing framework knows when to check the test output and move on.
(There is no provision for hung tests. A time out based mechanism, with a large time out, like 5 minutes, could do the trick.)
A test unit can also exercise more than one aspect of one or more APIs. But, as a rule of thumb, a specific test should not exercise more than a couple to a handful related APIs (or up to a dozen in extreme cases). Also, more than one test could exercise different aspects a given API.
So when running the Wine regression tests, if we find that 3 tests out of 50 failed, it means that three processes had an incorrect exit code or output out of fifty. One should then analyze in more details what went wrong during the execution of these processes to determine which specific API or aspect of an API misbehaved. This can be done either by looking at their output, by running them again with Wine traces, or even by running them in a debugger.
The discussion began to turn toward what the expected output of a test should be. Most developers felt that a simple PASS/FAIL output wasn't necessarily enough. For instance, it's important to have something like a "TO-DO" output where you know the test is going to fail and you don't really want to track it as being a failed test for regression purposes. Ulrich Weigand posted an interesting note about how the dejagnu test suite works (which is currently used by gcc):
When you run the test, every test case either passes or fails, which results in a classification into four subsets:
PASS Test case was expected to pass, and it did
FAIL Test case was expected to pass, but failed
XPASS Test case was expected to fail, but passed
XFAIL Test case was expected to fail, and it did
Only a test case in the FAIL category causes the whole test run to fail, and is reported even in the test run summary. The other categories are only reported as total numbers.
If you are getting nonzero FAIL numbers, you have introduced a regression. Nonzero PASS and XFAIL numbers are expected; if you get nonzero XPASS numbers you might look at the cases in question and decide whether you want to remove the 'expected to fail' flag.
Alexandre posted some examples he had written. From that Andriy Palamarchuk created some different tests and posted what he learned:
I ported a sample of my tests from C to the Perl framework. Want to share my experiences.
- 1) AFAICS technically you could do all the things you could do in C - working with structures, using callback functions, using threads. Existing problems probably can be ironed out.
- additional processing of the test results can be done easier and quicker than in C
- constants must be explicitely declared or plain numbers used instead
- no documentation on the framework yet.
- in many cases data sizes must be specified manually - for structures processing, function parameters.
- more difficult to track issues. than in C
Note, issues (1) and (2) probably can be fixed.
The Odin Project is the OS/2 equivalent of Wine. The code is actually based on Wine, but it branched a long time ago. Since then a lot of fixes have appeared in both trees that could benefit both projects. Sander van Leeuwen from the Odin Project wrote to the wine-devel list to seek cooperation between the projects:
As some of you might remember I'm the lead developer of the Odin project. (project for OS/2 with the same goals as Wine). Odin is partly based on Wine code. The core dlls (gdi32, user32, kernel32) + some special dlls (winmm, directx, winsock) use some Wine code, but is basically incompatible with Wine for obvious reasons. Most of the remaining dlls are based entirely on Wine code.
The last few years there has been little cooperation between both projects for several reasons. One of them is that we have far fewer active developers and cooperation sometimes proved to be difficult. Some source files of the two project had grown apart since changes were never merged back into Wine.
Now, I'm trying to change this situation, but am wondering how to proceed. I can post bug fixes to this list, but it will be difficult for me to actually test these changes in Wine itself. (too time consuming) Posting diff files is not always possible due to the major differences between source files.
Merging changes from Wine into our source tree is no problem. We can do that ourselves. However, it would be nice if compiler incompatibilites (we use IBM VisualAge C++, not GCC) could be resolved. There aren't many, but the IBM compiler is not always as flexible as GCC and of course doesn't understand any GCC extensions. It would be a big help if incompatible code could be changed. Switching compilers is not an option for us. I can post a (small) list of changes we had to make.
The license of our project is not compatible with Wine, but the dlls that are largely based on Wine (such as comctl32, shell32, ole) are an exception to the project license. The sources of those dlls are released under the Wine license. In case there is ever interest in the other sources, then you can just ask me. I'd be happy to 'donate' them to Wine.
For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). There you can find out where to download the sources (cvs).
The next post from me will contains some patches for bugs in Wine that I've recently found.
His next post contained a bunch of bug fixes. However, changes in the code bases prevented true diffs couldn't be created. This could be an excellent opportunity for someone to get involved with Wine - fix up the existing changes Sander pointed out (which requires just a basic understanding of C) and then see if there's anything else that could be merged from their project.
It's gotten a little rough lately for Lindows.com. Microsoft filed a lawsuit the day before Christmas arguing that the name was too similar to "Windows". It should be noted that the name of Michael Robertson's company is Lindows.com, Inc and they are very careful to refer to it that way. Similarly, the name of their product is LindowsOS. They are avoiding use of just "Lindows". At any rate, this week Michael Robertson sent an open letter to Bill Gates about the trademark dispute. The text of which can be found at: http://www.lindows.com/lindows_michaelsminutes_letter.php
More interesting are the screenshots they released. Hetz Ben Hamo wrote to the list:
I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots
Now, IF they did use wine (and thats a big if - from the screenshots they're running either Office 2K or office XP, Internet Explorer, the fonts looks like MS TTF fonts, and I think those screenshots are modified a bit - look at the 2nd screenshots, behind the start menu - look at the "file/edit/view" menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today.
From the looks of the screenshots they're just using Linux + KDE + Wine.
Also new on the LindowsOS front is the " Insider" program. If you pay them $99 a year you get to sign a non-disclosure agreement and "share your time, perspective and expertise".
Dan Kegel had some questions concerning a product he found:
While doing research for my site on the Microsoft antitrust trial ( http://www.kegel.com/remedy/ ), I came across a nasty little EULA for a product called MSNBC News Alert. The EULA is at http://www.msnbc.com/tools/newsalert/naeula.asp and saysMSNBC Interactive grants you the right to install and use copies of the SOFTWARE PRODUCT on your computers running validly licensed copies of the operating system for which the SOFTWARE PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.].
Jeremy White replied,
Microsoft seems to be updating their free download products
to use a EULA like this. You'll find it in Windows Media
Player, Direct X, and other places. Dan looked
into it more and found,
Yep. With Microsoft stuff, they tend to call the free downloads
'operating system components' to make it sound more reasonable.
They can't use that dodge with products from MSNBC, though, so
it looks more ham-handed there.
Chris Green announced:
I've just experimentally, in my own copy of the CVS, changed the code in misc/cdrom.c so that it handles mixed mode CDs the same as data CDs for retrieving CD labels. (In the process of trying to get Age of Empires 1 to run in single-player mode).
And surprisingly, it worked! (mind you AOE is not fast under wine, but that's another problem).
Does anyone have any comments on this approach? if not I'll submit a patch...
Andreas Mohr wondered,
Hmm, did you actually implement something new or just used old sector reading
code ? I know for a fact that you need special raw sector ioctl()s at least
for certain mixed-mode CDs... To which Chris replied,
I didn't do anything other than use the old sector-reading code. I can say
though that it worked for picking up the correct label for both Age of
Empires and for Diablo 1, so it does work for at least some CDs.
Chris also was unsure exactly which kinds of CD's caused problems.
I guess it might be music CDs with builtin biography data/programs often that are problematic.
If you get hold of such CDs, then you need to experiment with CDROMREADMODE2, CDROMREADMODE1 and/or CDROMREADRAW ioctl()s (in /usr/include/linux/cdrom.h) to get back sector data. I already verified once that you can get the CD label of "problematic" mixed-mode CDs this way. I couldn't figure out the mechanism that e.g. Windows uses to calculate the serial number of these CDs, though.
You might probably want to figure out a way to have misc/cdrom.c also support label and serial reading of problematic mixed-mode CDs, in a modular way (i.e. one that doesn't look too awful code-wise ;)
Chris looked into it and reported:
Ok - I've been doing some serious experimenting here, including reading the iso 9660 spec :)
I've found some interesting things too.
First, it seems that some CD's don't just store the 'best' data in higher-numbered volume descriptors. Some seem to store 'everything' in the type 1 (primary) descriptor, and only store the modified info in the type 2 (secondary) descriptor. So the routine CDROM_Data_FindBestVoldesc (it returns the highest-numbered descriptor) might need some rethinking...
Secondly, I found a real curiosity in one particular CD: Microsoft's Multimedia Beethoven (about 1992) isn't ISO9660 at all. It's a mixed mode CD, and is readable in Windows, as well as Wine, but the label is screwy (Windows XP gets it wrong too). Instead of using the specification identifier 'CD001' (ISO9660) it uses 'CDROM' and has two dwords stored at the start of the volume descriptor, as well as having a few other discrepancies. I have no conclusive proof as to what specification it's written, but I'm guessing its possibly the original High Sierra format, or perhaps an even earlier, semi-proprietary, spec. Either way, it makes me wonder whether some of the 'strange' mixed-mode CDs are of a similar nature.
Anyway, what I'm thinking is to rewrite the code that deals with CD labels to take into account what I've found so far - I'll also include support to get the label from the 'CDROM' type I've found, so we'll have the right label for that CD too. Quite possibly, that'll fix the 'strange' mixed mode CD's too.
If anyone has an odd CD lying around, they can email me the first 65536 bytes of the CD (hopefully no vendor will care about copyright on their volume descriptors!) so I can compare the structure of the volume descriptors - I've got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 count=1' and compress the result before emailing it to me :)
Chris went on to make a patch and explained exactly what it does,
What I've done is to check for the pre-iso signature, and if it occurs, to
increase the offset by 8. This puts the offset in a position that makes the
get label function find the correct entry. I've tested it with both 'normal'
iso9660 cds, and with pre-iso cds (e.g. MS Multimedia Beethoven, and MS
Cinemania 92) and it works flawlessly in both cases.
Sylvain Petreolle reported,
Using Dark Reign (The Future of War) mixed CD,
(one data track and several audio after),
label is reported correctly. Good Job !