January 2002 - Wine-Devel - list.winehq.org

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

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Gerard Patel wrote: > This has given me an idea - while I don't expect it to be > used in Wine, I will try to write my own test progs > with it : use the *windows* python interpreter under Wine. > >From the doc, it's possible to call any win32 api from > it using a 'calldll' interface. If it works well, I won't need > a 'test framework' - just use the standard, available tool. And that's a very cool idea. In fact, we don't need a test harness. What we need is to say: 'A test is an executable. The exit status is 0 on success, and non-zero on error. If the test fails, it should explain why on stderr. Verbose output (if any) goes on stdout.' Now, from the POV of Wine, we don't care (just like the kernel), if the executable is a native binary or a #! executable. Everything else are a few Makefile rules, which are conditional on the given compiler/interpreter being available (which can be checked quite easily by configure). -- Dimi.

Jan. 9, 2002

Re: Listview ctrl

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Applied to our case, if we have fooW and fooA, then typically fooA looks > as such: > > fooA() > { > strdupAtoW > fooW > strdupWtoA > } > > So, even if we do go only from A->W at the API level, the actual string > conversions do go both ways. Very few functions would need something like that. The normal case would be: fooA() { strdupAtoW fooW copy W back into A if needed } The W->A case is not a strdup, it's a simple WideCharToMultiByte. Probably at least 90% of the existing calls to HEAP_strdupWtoA are because of a W function calling a A function, which is precisely what should be discouraged. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

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

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Francois Gouget wrote: > The perl test framework will need a way to build a zip file of some > sort with all the necessary stuff to run the perl tests on Windows. All > we need is for this to not be confused when we add the C tests. The C > tests will need such a functionality too. And it should package just the > C tests and not the perl tests. In fact, this should be possible in C as well. Say configure can check if gcc can generate PE executables, and if so, we can compile (in Linux/*BSD/etc) the C tests as PE executable so that we actually run the exact same binary in Wine and Windows. >From the testers POV they should be as easy to run as the Perl tests (if not easier), and all that is required is a cross-compiling gcc. You don't have that, no big problem, you simply can not package the C tests. -- Dimi.

Jan. 9, 2002

Re: Listview ctrl

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > That's just as much pollution. We must not introduce incompatibilities > except where there's clearly no other possibility. In this case there > are tons of other options. If you insist... :) > > Indeed. MultiByteToWideChar is just brutal IMO. But many times if we need > > to go W->A we also need to go A->W, and hence my proposal for symetrical > > functions. > > The asymmetry could be considered a feature, since people should be > encouraged to go A->W instead of W->A wherever possible. In theory, yes. But you know what Larry McVoy once said: The difference between theory and practice is that in theory there is no difference, while in practice there is. Applied to our case, if we have fooW and fooA, then typically fooA looks as such: fooA() { strdupAtoW fooW strdupWtoA } So, even if we do go only from A->W at the API level, the actual string conversions do go both ways. -- Dimi.

Jan. 9, 2002

Re: Listview ctrl

by Francois Gouget

On Tue, 8 Jan 2002, Dimitrie O. Paun wrote: [...] > The bad news is that I have no > idea how to test it. So any suggestions on how to test the listview > control, or any help with the testing is greatly appreciated, as well as > any comments on the patch itself. I believe you will find the 'Common Control Spy Samples' very useful in testing common controls. You can download them from Microsoft's web site: http://www.microsoft.com/msj/0998/code/controlspy.exe You may also want to read the following article: "Control Spy Exposes the Clandestine Life of Windows Common Controls" * Part I http://www.microsoft.com/msj/0798/controlspy.htm * Part II http://www.microsoft.com/msj/0998/control/control.htm * Part III http://www.microsoft.com/msj/1298/controlspy3/controlspy3.htm (from http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Jan. 9, 2002

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

by Gerard Patel

At 04:44 PM 08/01/2002 -0500, you wrote: <snip> >(Another Pythoner, cool :) ) This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine. >From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool. Gerard

Jan. 9, 2002

Re: Listview ctrl

by Gerard Patel

At 09:31 AM 08/01/2002 -0500, you wrote: <snip> >So, after much work and no testing, here is a first try at doing that. The >good news is that it seems it compiles. The bad news is that I have no >idea how to test it. So any suggestions on how to test the listview >control, or any help with the testing is greatly appreciated, as well as >any comments on the patch itself. > I have tested it with some of my test apps and I see a few regressions. With rowlist.exe that comes with Vc++, using 'large icons' and 'full details' only the first character of the text is displayed. The little program found at www.timex.com (IIRC it installs correctly under Wine) displays another problem (maybe related) : columns other than the first can be not displayed in some cases. Gerard

Jan. 9, 2002

Re: Wine & non X86 processors

by Francois Gouget

On Tue, 8 Jan 2002, Hetz Ben Hamo wrote: > Hi, > > A friend of mine who uses sparc machine wants to write a pentium emulator & > use wine with it to run some apps... > > His question is - are there any special notes about wine in big endian? does > he need to make lots of changes? if so, in whats parts in general? Note that if his intention is to run Windows applications, i.e. x86 applications, with Wine on Sparc, there are many more issues than just compiling Wine on Sparc. For instance you will have to convert all the data structures (e.g. messages) between little and big endian format each time you switch between Wine and the application. You will also need to properly invoke the emulator each time Wine invokes a callback. Some applications also expect to be able to 'communicate' with the OS via interrupts, or other very low level things and you will need a very tight integration between the emulator and Wine to implement that. All this will require widespread modifications in Wine's code. If you want to run x86 windows applications on Sparc, your best bet is to run Wine itself in the CPU emulator. This way you don't even need to worry about porting Wine to Sparc. If on the other hand he wants to use Winelib to port Windows applications to Sparc then he does not need a CPU emulator at all. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Jan. 9, 2002

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

by Francois Gouget

On 8 Jan 2002, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > > > So, bottom line, I think you should accept whatever tests you get. If the > > author gets a woody writing them in C, or using some test harness or > > another, let's just consider it the motivating factor behind writing the > > tests in the first place. > > Unfortunately that's not possible. If everybody uses his favorite test > harness we will soon have more of them than actual tests. It's already > going to be enough work maintaining one framework and making sure it > always works both on Windows and Wine, we can't afford to have several. I agree that we should not have as many testing frameworks as test writers. But maybe two would be acceptable. I propose the following: * you posted the beginning of a perl test framework. What is needed before it can be committed to CVS? AFAICS all it lacks is support for difference files, aka TODO tests. * so let's complete that framework and commit it to CVS * then if someone really wants a C testing framework, let them develop it. And then we can replace test: <run-perl-tests> with: ptests: <run-perl-tests> ctests: <run-c-tests> tests: ptests ctests The perl test framework will need a way to build a zip file of some sort with all the necessary stuff to run the perl tests on Windows. All we need is for this to not be confused when we add the C tests. The C tests will need such a functionality too. And it should package just the C tests and not the perl tests. So we should be able to have perl and C tests side by side, in such a way that they basically ignore each other. Then we'll see after a little while which framework is being used. And if one of them is never used, then as Dimitrie said, we can convert its tests and remove it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Jan. 9, 2002

Re: Listview ctrl

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Excellent. I was not preaching header pollution :). But if we do that, why > not have a wine/heap.h header with the said functions? That's just as much pollution. We must not introduce incompatibilities except where there's clearly no other possibility. In this case there are tons of other options. > Indeed. MultiByteToWideChar is just brutal IMO. But many times if we need > to go W->A we also need to go A->W, and hence my proposal for symetrical > functions. The asymmetry could be considered a feature, since people should be encouraged to go A->W instead of W->A wherever possible. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

Re: Listview ctrl

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > You can just as well put the inline functions directly into the C > file, or in some dll private headers. The functions are only 3 lines > long, it's no big deal to have a few duplicates. There is no reason to > pollute the standard headers with that. Excellent. I was not preaching header pollution :). But if we do that, why not have a wine/heap.h header with the said functions? > In many cases you could also use RtlCreateUnicodeStringFromAsciiz, > which is an exported API and is probably more readable that > MultiByteToWideChar etc. Indeed. MultiByteToWideChar is just brutal IMO. But many times if we need to go W->A we also need to go A->W, and hence my proposal for symetrical functions. -- Dimi.

Jan. 8, 2002

Re: Listview ctrl

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > What would be wrong with: > > LPSTR wine_strdupWtoA(LPCWSTR); > LPWSTR wine_strdupAtoW(LPCSTR); > void wine_strfreeA(LPSTR); > void wine_strfreeW(LPWSTR) > exported from, say, ntdll? > > Besides, they can remain inlined (as they are now), so they don't really > need to be exported from anywhere. You can just as well put the inline functions directly into the C file, or in some dll private headers. The functions are only 3 lines long, it's no big deal to have a few duplicates. There is no reason to pollute the standard headers with that. In many cases you could also use RtlCreateUnicodeStringFromAsciiz, which is an exported API and is probably more readable that MultiByteToWideChar etc. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

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

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > Unfortunately that's not possible. If everybody uses his favorite test > harness we will soon have more of them than actual tests. Certainly, I was exaggerating. However, we should accept tests written in C. -- Dimi.

Jan. 8, 2002

Re: Listview ctrl

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > The reason is very simple: WideCharXXX are Windows API, HEAP_strdupA/W > are not. I have supported your effort for getting rid of the HEAP_strdupA/W calls for this very reason: I strongly believe using the standard API is very important for too many reasons to list here. However, looking over the code with critical eye, I realized that we are uglifing/obfuscating the code with this change, rather then cleaning it up. As a result, I've been kindda torn between the desire to use a standard API, and the aesthetics of the code base. Now, thinking about the problem, I realized that the strdupA/W is not a standard Windows API because apps should not typically need it, while it is _clearly_ needed as an internal API for the Win32 API. What would be wrong with: LPSTR wine_strdupWtoA(LPCWSTR); LPWSTR wine_strdupAtoW(LPCSTR); void wine_strfreeA(LPSTR); void wine_strfreeW(LPWSTR) exported from, say, ntdll? Besides, they can remain inlined (as they are now), so they don't really need to be exported from anywhere. -- Dimi.

Jan. 8, 2002

Linux Today - Tonight Live: New Directions for a New Year. We talk about WINE >> on The Linux Show

by Jeremy White

FYI, they're apparently going to be talking about Wine tonight. Jer <http://linuxtoday.com/news_story.php3?ltsn=2002-01-08-024-20-OP-CY>

Jan. 8, 2002

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

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > So, bottom line, I think you should accept whatever tests you get. If the > author gets a woody writing them in C, or using some test harness or > another, let's just consider it the motivating factor behind writing the > tests in the first place. Unfortunately that's not possible. If everybody uses his favorite test harness we will soon have more of them than actual tests. It's already going to be enough work maintaining one framework and making sure it always works both on Windows and Wine, we can't afford to have several. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

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

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Ove Kaaven wrote: > Well, if random opinions count here, I also would prefer Perl. As much as > I hate Perl (I'm more in the Python camp), I'd hate writing regression > tests in C much more. (Another Pythoner, cool :) ) But if we accept tests in C, we don't loose anything. If it's a pain to do them in C, we'll end up with just a handful of them which we can simply convert to Perl (which should be trivial since they are just a few). On the other hand, if we end up with a lot of C tests, means that people simply prefer C over Perl (for whatever reason), so we would still have won since we end up with all those tests. -- Dimi.

Jan. 8, 2002

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

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > I personally think Perl would be a better choice, but I seem to be > pretty much the only one of this opinion. In any case the most > important thing is to choose something that people are going to use, > and so far the Perl stuff isn't a success in this respect. I'm not > convinced a C infrastructure would fare better, but maybe we should > try it and see. And this is an excellent point. I, for one, know enough Perl to know that I find it ugly as bloody hell, and as such I have no desire to learn it. Writing tests is a big pain in the ass in the first place, and I can tell you I would not do it in Perl if I was paid to do it. Now, I kept quiet on this issue because I can see the merits of using a scripting language to write said tests. However, I would like to point out that the _hard_ problem is getting the tests written, it doesn't really matter in what language. If the infrastructure (compiler, libs, etc) is not present on the current platform (configure is the 'man'), it is trivial enough to simply not run them (or run some dummied up tests instead, something like true(1)). So, bottom line, I think you should accept whatever tests you get. If the author gets a woody writing them in C, or using some test harness or another, let's just consider it the motivating factor behind writing the tests in the first place. -- Dimi.

Jan. 8, 2002

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

by Ove Kaaven

On 8 Jan 2002, Alexandre Julliard wrote: > I personally think Perl would be a better choice, but I seem to be > pretty much the only one of this opinion. Well, if random opinions count here, I also would prefer Perl. As much as I hate Perl (I'm more in the Python camp), I'd hate writing regression tests in C much more.

Jan. 8, 2002

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Could you, please, list the additional features we > need? I'll try to estimate amount of work necessary to > implement them in Test::Harness. Basically the features I get with my 10-line makefile hack: ability to run tests for modified dlls and their dependencies (for instance if you change something in user32 and run make test it doesn't run tests for kernel32), ability to remember which tests failed and run only these the second time around, trivial integration of new tests (just add one line in a makefile). > Do you want to use architecture, completely different > from Test::Harness + Test::Simple modules or you only > want to replace Test::Harness? I think we would be much better off developing a simple infrastructure from scratch that does exactly what we want, than trying to bend an existing framework to our needs. This will also ensure that the framework remains as simple as possible, which is important since every extra feature, even one we don't use, can possibly introduce problems (like the pipes/fork issues have shown). > Does this output look closer to the one you want? > Let me know if you need any other information. I don't really care about the output. My point is that this output is not necessary, a simple "assertion foo failed at line xx" on failure and no output at all on success would work just as well. I've nothing against such an output either, but I don't think it justifies introducing the complexity of reusing the Test stuff. > Sorry, misinterpreted your statement that threads > won't be used for tests in Perl. Could you give your > vision when C is used? In my vision we either use Perl everywhere, or C everywhere. If we use Perl there may be a need for a few little glue programs in C, but this doesn't require any C infrastructure. I personally think Perl would be a better choice, but I seem to be pretty much the only one of this opinion. In any case the most important thing is to choose something that people are going to use, and so far the Perl stuff isn't a success in this respect. I'm not convinced a C infrastructure would fare better, but maybe we should try it and see. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

Re: Wine & non X86 processors

by eric pouech

> A friend of mine who uses sparc machine wants to write a pentium emulator & > use wine with it to run some apps... > > His question is - are there any special notes about wine in big endian? does > he need to make lots of changes? if so, in whats parts in general? lots of work have been done already. wine has been ported (a while ago) and ran (as winelib) on PowerPC. So, the endianness shouldn't be too much of an issue. What should remain is: - compiler: gcc stickiness - disabling/getting rid of 16 bit code - and of course, evolutions of the code since the port was (half)-done A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 8, 2002

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

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: [...] > But adapting the framework to do what we want is IMO > more work than > simply reimplementing from scratch the few features > that we actually > need. We don't really gain anything by making the > effort of reusing > all that code, since we don't need most of it. Could you, please, list the additional features we need? I'll try to estimate amount of work necessary to implement them in Test::Harness. Do you want to use architecture, completely different from Test::Harness + Test::Simple modules or you only want to replace Test::Harness? Existing architecture: Individual test scripts (executables) are very simple (use Test::Simple). They only print messages like "ok 4 - action SPI_FOO # TODO not implemented" for each check. Test::Harness module parses output, has logic to analyze test results, creates overall report and details of failures, including crashes. > I don't want to know about the details of > the 250 individual > checks. You got an impression that Test::Harness does not report individual failures. Sorry, I gave too simple demo. Example of Test::Harness output for a few failures: test2.p.............NOK 2# Failed test (test2.pl at line 8) # got: '1' # expected: '0' test2.p.............NOK 3# Failed test (test2.pl at line 9) # got: '1' # expected: '0' test2.p.............NOK 4# Failed test (test2.pl at line 10) test2.p.............ok 8/8# Looks like you failed 3 tests of 8. [... summary report output is skipped ...] Does this output look closer to the one you want? Let me know if you need any other information. > > 2) mixed C/Perl environment will be used for the > tests > > development. Choosing the tool is a matter of > personal > > preferences. > > I don't think I agree. For me the value of Perl is > in that it makes it > trivial to take the suite over the Windows; but if > half the tests are > in C we lose this advantage, and then we might as > well do everything > in C. Sorry, misinterpreted your statement that threads won't be used for tests in Perl. Could you give your vision when C is used? > What I want is a make-like > system that keeps > track of which tests have been run, which ones need > to be re-run > because they have been modified etc. This usage of make is fine with me. I just want to separate unit tests from main code and have centralized control. You still can call subset of unit tests from the build process. > You cannot put the whole test suite in a single > application, you need > to split things up some way. A decent test suite > will probably be > several times the size of the code it is testing; > you don't want that > in a single application. We were not careful about the terms. Yes, the tests will be bunch of the executables. I assumed these executables to be parts of one test application. Completely agree with you. > > You preferred to have unit tests > > spreaded over the Wine directory tree. The main > > argument for this was possibility of running > subsets > > of test. > > No, the argument is modularity. I'm all for modular unit tests and there are a few ways to divide the tests between modules. > Then when you change something in kernel32 you can > change the test > that is right next to it, run make test in the > kernel32 directory and > have it re-run the relevant tests, and then do cvs > diff dlls/kernel32 > and get a complete diff including the code and the > test changes. Agree, this is not so convenient for separate test application. Separate unit tests application has its own advantages: 1) Separate distributions are used for Wine and the test applications. The only case when we want them together - Wine development under *nix. In all other cases we need only one of them. 2) The unit tests will be mostly developed under Windows. The unit tests build process has extra Windows compatibility requirements. 3) Having unit tests as a separate application we create possibilities to collaborate with other W32 implementation OS projects (ODIN comes to mind). All the tasks we mentioned can be implemented with any approach. I believe the tasks you described will be not much more difficult with my approach, especially if directory tree has parallel structure. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 8, 2002

RFC: NamedPipes emulation API

by Luke Kenneth Casson Leighton

this is an RFC document describing an API that may be used to provide Windows NT Style "NamedPipe" functionality. it will be of interest to samba, wine, freedce and win32 developers wishing to port applications to unix (via the wine win32 implementation of NamedPipes). the functionality described in this document is equivalent to, if you have access to the MSDN, the following (incomplete list of) Win32 functions: - CreateNamedPipe (returns a file handle) - TransactNamedPipe - a read operation on the named pipe file handle, above - a write operation on the named pipe file handle, above - a close operation on the named pipe file handle, above - WaitNamedPipe there follows a list of function declarations. these are samba-specific functions that are only of use to SAMBA 3 developers. int named_pipe_create( connection_struct *connection, /* contains all info needed, e.g. user security context */ const char *pipe_name, /* e.g. \\server\PIPE\pipe_name or \\.\PIPE\pipe_name */ ); this function returns -1 on failure or an SMB file index (fnum) on success. it is called when an SMBopenX or NTcreateX is received. from memory, the access point is api_pipe_open(), in pipe.c or reply.c. STATUS named_pipe_transact(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length, /* zero or more bytes */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. if there is more data to be received, then the function must return ERROR_MORE_DATA. NT_STATUS_OK is returned on success. from memory, the access point is api_pipe_readwrite() or reply_trans2(), or maybe reply_pipe_trans(). i don't recall which. again, it'll be in pipe.c or reply.c. STATUS named_pipe_read(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_read() (api_pipe_read()?) STATUS named_pipe_write(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_write() (api_pipe_write()?) the use of this API is quite simple, and provides a clean "cut-off" point between samba and all NamedPipe transactions. lkcl

Jan. 8, 2002

Re: wine/ files/file.c server/file.c

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > I just wanted to make this distinction more logical. I think it is > necessary to separate fd types and flags. The distinction between > regular files, pipes, sockets, ... that the patch introduces is > currently not needed, but doesn't hurt IMO. I prefer that we make the distinction only where needed, to encourage people to write generic code if possible. > If you wish, I can strip the patch down to its essential part > (have separate flags for overlapped and timeout flags). That would be better yes. Also I think they should be really separate: the type should be an enum and the flags should be in a separate variable. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Almost all complexity you are talking about is already > implemented for us. Usage of the framework is very > simple, do not require from test writers anything. > They are only required to correctly use Test::Simple > (or Test::More). They don't need to remember about > Test::Harness. But adapting the framework to do what we want is IMO more work than simply reimplementing from scratch the few features that we actually need. We don't really gain anything by making the effort of reusing all that code, since we don't need most of it. > There are reasons to use Test::Harness: > 1) control of TODO tests - I really want to use this > feature. > 2) control of SKIP tests - very useful for > Wine-specific tests, choosing behavior, depending on > Windows versions, etc. I need this feature too. Yes, I agree we want that. I think there are easy to implement no matter what we use, we don't really need Test::Harness for that. > 3) we already need to manage the test output. I'd > estimate number of checks for my existing > SystemParametersInfo unit test as: > 25 (number of implemented actions) * 10 (minimal > number of checks for each action) = 250 - 350 tests > We'll definitely have huge number of tests. Why not > pick up scaleable approach from very beginning? For me your SystemParametersInfo is one test, not 250. All I want to know if whether it passed or not, and if not what was the cause of the failure. I don't want to know about the details of the 250 individual checks. > Suggest decisions from the discussion: > 1) unit tests are very important for the project > 2) mixed C/Perl environment will be used for the tests > development. Choosing the tool is a matter of personal > preferences. I don't think I agree. For me the value of Perl is in that it makes it trivial to take the suite over the Windows; but if half the tests are in C we lose this advantage, and then we might as well do everything in C. > 3) Test::Harness will be used to compile report for > test batches I don't see the need. What I want is a make-like system that keeps track of which tests have been run, which ones need to be re-run because they have been modified etc. I don't think there is any use in a report stating that 12.42% of the tests failed, this doesn't tell us anything. > 4) The unit test will be a separate application You cannot put the whole test suite in a single application, you need to split things up some way. A decent test suite will probably be several times the size of the code it is testing; you don't want that in a single application. > Alexandre, we explicitely did not agree on this > decision yet. You preferred to have unit tests > spreaded over the Wine directory tree. The main > argument for this was possibility of running subsets > of test. No, the argument is modularity. The tests for kernel32 have nothing to do with the tests for opengl, and have everything to do with the kernel32 code they are testing. So it seems logical to put them together. Then when you change something in kernel32 you can change the test that is right next to it, run make test in the kernel32 directory and have it re-run the relevant tests, and then do cvs diff dlls/kernel32 and get a complete diff including the code and the test changes. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002