December 2001 - Wine-Devel - list.winehq.org

Re: Mixed-mode CD Labels

by Chris Green

On Friday 28 December 2001 20:24, Andreas Mohr wrote: > On Fri, Dec 28, 2001 at 07:06:46PM +1000, Chris Green wrote: > > 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... > > Hmm, did you actually implement something new or just used old sector > reading code ? 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. > I know for a fact that you need special raw sector ioctl()s at least for > certain mixed-mode CDs... Yeah I assumed there must have been something like that going on - I couldn't think of any other reason why it wouldn't have been done. I don't know - does it make sense for wine to support something that seems to work at least some of the time, as opposed to not supporting it at all? If not, are there any CDs in particular that you know of, that have the requirement for a raw ioctl() read, I might have here, so I could experiment with them? regards Chris Green

Dec. 28, 2001

Re: Mixed-mode CD Labels

by Andreas Mohr

On Fri, Dec 28, 2001 at 07:06:46PM +1000, Chris Green wrote: > Hi, > 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... 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... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 28, 2001

Mixed-mode CD Labels

by Chris Green

Hi, 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... regards Chris Green

Dec. 28, 2001

Re: We *really* need a development model change !

by Andreas Mohr

On Fri, Dec 28, 2001 at 12:49:54PM +1300, Geoff Thorpe wrote: [voting for a simple test interface] > If a "testing framework" is anything more complicated - the only people > working on the test suites will be whoever defines/understands the "test > framework specification" and the hard-core wine developers themselves. In > other words, we won't get far. Exactly. We've got so many (up to 12000) functions to write tests for that we really can't afford having a complicated test environment. Just about everybody should be able to write tests for a function. And if this is the case, then we really should try to leverage as much existing Windows developer knowledge/skillset as possible in order to have a working test suite in place in just about an instant. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 28, 2001

Re: We *really* need a development model change !

by Geoff Thorpe

On Friday 28 December 2001 05:00, Andreas Mohr wrote: > > Yes, IMHO we really need a C based test. I'd go along with this. It seems that a variety of tests, written and contributed by a variety of people, and thus written in a variety of mutually inconsistent and collectively odd ways, is inevitable. Rather than people wasting their valuable time on rejigging any existing "modular extensible test framework" or writing anything new, the simplist way forward would surely be to document some simple input/output behaviours test programs should use. Eg. as long as it is described what should and should not be sent by a test program to stdout+stderr, and what input (if any) should be supported on the command line and/or stdin, then you have achieved the only consistency that matters. A simple shell script could then, for example, control the level of debugging in any/all such tests by simply piping output(s) through egrep or whatever - stdout itself could be piped to /dev/null if necessary leaving only stderr, etc. Let's face it - anyone adding new functionality to wine or working on anything non-trivial will be cooking up their own "foo.c" test programs on the fly when developing - the less work it takes for that developer to convert their foo.c into a test-foo32-api.c for use by test scripts, the better off everyone will be. Let's also not forget, if that "standardised form" for input/output of the testing is as logical and uncomplicated as possible, more and more well-meaning code grunts will be capable of making useful contributions - be it clunky GUI wrappers for the testing suites (think what "make xconfig" did for linux kernel rebuilding), or by even taking the various foo.c test fragments from the wine developers and coaxing them into the standardised form on their behalfs. If a "testing framework" is anything more complicated - the only people working on the test suites will be whoever defines/understands the "test framework specification" and the hard-core wine developers themselves. In other words, we won't get far. Cheers, Geoff

Dec. 27, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

I looked at thread "Perl/Wine extension for perusal" ran on February, 2001. Want to bring some information from that thread to this discussion: 1) The discussion started from John Sturtz post, who created the Perl module for Win32 functions. Discussion what is better - C or Perl for unit testing started later as I understand there was no conclusion. Now I can assume that this topic was not "discussed to death" and we can do it now ;-) 2) One of arguments about the tool choice was its availability. Currently you are free to use one of a few commercial compilers, free compiler lcc or gcc as part of Cygwin, mingw packages. One more problem - support for a few compilers environment for C. Perl is available as ActiveState and standard ports. 3) No existing unit tests frameworks were discussed. 4) There was a suggestion to use both - C and Perl tests 5) Was defined that existing application should not be run as part of unit test. I think these are all points of that discussions, which will be interesting for this discussion. Feel free to correct me. --- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > On Thu, Dec 27, 2001 at 12:13:05PM -0800, Francois > Gouget wrote: > > > The big question is a tool to test GUI. I did > not find > > > any OS Windows GUI testing frameworks :-( > > > > Andreas has already replied and i agree with > him. But I'll basically > > repeat what he said to give it more weight :-) > > > > GUI testing is not 'the big question'. It's > irrelevant right now. I'm convinced. > In the meantime we should try to discuss more about > what the test suite > framework should look like, i.e. whether my approach > is good/bad, what > to possibly improve, what the output should look > like and whether > it's suitably parsable. Results of preliminary review of the unit testing frameworks. Some of these frameworks can run tests in a separate address space and can report crashes! Suprisingly I don't have too many options. C frameworks: 1) Check. Problem - POSIX-based (under Windows needs Cygwin). 2) CUnit. Problem - very simple, in development. I think it is not worth trying. 3) cUnit. Problem - Linux only. 4) Autounit. Problem - POSIX-based 5) QMTest. Problem - needs Python. C++ frameworks: 1) CPPUnit. Problem - in C++ Perl frameworks: - there are quite a few Perl modules for testing on CPAN, including port of JUnit to Perl. Summary: What do you think - which ones we still can use despite the constraints? I'll review the chosen frameworks more closely. Perl modules are Ok and I can review them in detail if we decide to go with Perl. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 27, 2001

Re: We *really* need a development model change !

by Andreas Mohr

On Thu, Dec 27, 2001 at 12:13:05PM -0800, Francois Gouget wrote: > On Thu, 27 Dec 2001, Andriy Palamarchuk wrote: > > [... Perl/C pros and cons for testing] > > I think you summarised the pros and cons of both options quite > well. I would add just one thing against perl in its current form: AFAIK > (but it may have changed since), the current perl framework does not > support callback functions. This can be a problem for testing things > like: > * CreateThread: takes a function to be run in the new thread > * timers: SetTimer(...,timerproc) > * window procs: We can write quite a few tests that create some widget > (a list, table, ...) and then sends messages to check the state of that > widget (select an item in the list, then check which item is selected, > whether the 'hot' item is still hot, etc.), and or the resulting > sequence of other messages. While these are not 'GUI' tests in that they > don't make sure that the list displays correctly (or at all), they check > important properties of the widget implementation. Not to mention any other "non-easy" tests, such as highly complicated interaction/message handling/whatever that probably would be rather problematic to implement in perl. Thus I guess that we might want to concentrate on a usable C based test code, while keeping a compatibility scheme for perl based tests in mind. In short: my test model would be usable from that point of view. You could concatenate the output of all C programs and perl scripts easily and get an easy way of determining whether overall compatibility is healthy. > > The big question is a tool to test GUI. I did not find > > any OS Windows GUI testing frameworks :-( > > Andreas has already replied and i agree with him. But I'll basically > repeat what he said to give it more weight :-) > > GUI testing is not 'the big question'. It's irrelevant right now. > And what I really don't want to happen, it to see us refuse to pick > the low hanging fruits and starve to death because we don't have a > ladder that lets us reach the fruits at the top of the tree. Yes. Again, the simple text based "OK"/"FAILED" result would be applicable easily here, too. After all it's only the result that matters... Thus I don't think we need to worry much about it, since most likely it'll fit into such an infrastructure easily. > In other words, there are thousands of APIs that we can test very > easily and we should write tests for them NOW. We should not wait for > the development of a hypothetical framework that would let us also test > graphical (i.e. daoes it display right) issues. Exactly. The most valuable part of API tests is not their infrastructure, but rather the fact that they already tested certain functions pretty well. E.g. we'd be able to port my test code to a different test framework terribly easily, as (hopefully ?) all the test conditions of LoadModule16 are known now due to my evaluation of this function. > Testing all these APIs represents enough work to keep us busy for > quite some time and can already benefit Wine greatly. So really, at this > time, given the amount of effort required to even get something usable, > "GUI testing" is irrelevant and should be postponed. My idea exactly. People kept talking about GUI test framework (also at Codeweavers), but I think we should really get started at all first. > (of course if someone out there really wants to develop a GUI testing > framework and donate it to Wine, go ahead, all I want is that we don't > wait for one) Hehe, right :-) OK, now that we discussed this: I have to admit that I haven't really looked at the perl winetest yet. *blush* I think I'll improve my intended Usenet posting (which will go to truly relevant Windows devel newsgroups only, I'd say), and then I'll mail it to interested parties for review. Any comments/improvements to this text ? In the meantime we should try to discuss more about what the test suite framework should look like, i.e. whether my approach is good/bad, what to possibly improve, what the output should look like and whether it's suitably parsable. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 27, 2001

Re: We *really* need a development model change !

by Francois Gouget

On 27 Dec 2001, Alexandre Julliard wrote: [...] > The C vs. Perl question has been debated already, please check the > archive. The truth is that a lot of people are willing to setup a > testing infrastructure, but nobody is willing to write the actual > tests. I don't know if it is that noone wants to write tests or if it is that: * the current infrastructure has never been officially announced * the Wine project never officially said 'go ahead' write tests with our new testing infrastructure * there is no documentation on either how to write tests, no guidelines on how to write good tests, or on how one is supposed to run the Wine regression test suite * there is no sample test in any of the dlls/xxx directories. There is just one sample perl script in programs/winetest/test.pl * and there is also an autoconf test missing for '-lperl': gcc -shared -Wl,-Bsymbolic winetest.spec.o winetest.o wine.o -o winetest.so -L../../library -lwine `perl -MExtUtils::Embed -e ldopts` -lm -lutil -ldl /usr/bin/ld: cannot find -lperl So I would say we still have work to do on the infrastructure, if nothing else in terms of documentation and 'advertising' it, if we are to expect people to start writing tests. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

Dec. 27, 2001

Re: We *really* need a development model change !

by Francois Gouget

On Thu, 27 Dec 2001, Andriy Palamarchuk wrote: [... Perl/C pros and cons for testing] I think you summarised the pros and cons of both options quite well. I would add just one thing against perl in its current form: AFAIK (but it may have changed since), the current perl framework does not support callback functions. This can be a problem for testing things like: * CreateThread: takes a function to be run in the new thread * timers: SetTimer(...,timerproc) * window procs: We can write quite a few tests that create some widget (a list, table, ...) and then sends messages to check the state of that widget (select an item in the list, then check which item is selected, whether the 'hot' item is still hot, etc.), and or the resulting sequence of other messages. While these are not 'GUI' tests in that they don't make sure that the list displays correctly (or at all), they check important properties of the widget implementation. > The big question is a tool to test GUI. I did not find > any OS Windows GUI testing frameworks :-( Andreas has already replied and i agree with him. But I'll basically repeat what he said to give it more weight :-) GUI testing is not 'the big question'. It's irrelevant right now. And what I really don't want to happen, it to see us refuse to pick the low hanging fruits and starve to death because we don't have a ladder that lets us reach the fruits at the top of the tree. In other words, there are thousands of APIs that we can test very easily and we should write tests for them NOW. We should not wait for the development of a hypothetical framework that would let us also test graphical (i.e. daoes it display right) issues. Testing all these APIs represents enough work to keep us busy for quite some time and can already benefit Wine greatly. So really, at this time, given the amount of effort required to even get something usable, "GUI testing" is irrelevant and should be postponed. (of course if someone out there really wants to develop a GUI testing framework and donate it to Wine, go ahead, all I want is that we don't wait for one) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Dec. 27, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > The truth is that a lot of people are > willing to setup a > testing infrastructure, but nobody is willing to > write the actual > tests. Counterexamples: 1) I suspect that you try to run the code you develop before committing it to CVS ;-) You work on core Wine functionality and the test code snippets you use would be invaluable as unit tests. However I can't find these tests anywhere in CVS tree :-P 2) Besides Perl testing framework there are a few testing applications (vartest, guitest) in CVS, but they are not merged in a single test suite. 3) I tried to submit unit test application for SystemParametersInfo with my first patch to this function, but the unit test was not accepted. I assumed that no unit test is necessary in CVS tree for such really simple function. Summary - there are people who wants to develop unit tests. IMO the problem with unit test in the project is in: 1) Our attitude. We don't have *any* policy about unit tests. Developers are not asked about unit tests, from the documents on WineHQ it is not clear whether we need them at all. 2) Absense of infrastracture. We need to develop or choose unit testing framework, define unit test policies, add information about unit tests to Wine documentation, keep unit tests visible for developers all the time. > So right now we have a minimal infrastructure in > Perl No, ability to call W32 API functions is not considered a unit test infrastracture. I may say Wine has such infrastructure for C since 1993 :-). From this point of view Andreas test application provides more support for unit tests than plain Perl module. In existing CVS tree we have much more tests in C than in Perl (both - a little more than nothing) > I'm not > going to setup another one until someone starts > using the existing one > seriously and demonstrates whether it works or not > in practice. The > theory has been discussed to death already. I agree with you - only usage of the framework can help to choose better one. I'll look more closely at C-based, try to combine our Perl module with Perl-based unit frameworks. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 27, 2001