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

Re: Perl/Wine extension for perusal

by Alexandre Julliard

Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > Do you really feel like a C compiler is less common than a perl binary > under Windows ? I seriously doubt it... Anybody can install a perl binary on their machine, while nearly all Windows compilers are commercial software... > well, the stubs between perl and windows will not be exactly the same > anyway, so you'll anyway introduce code differences between the two > (not to speak about the perl interpreters which might have small differences > too). You'll need some serious testing to make sure that both interpreters behave the same way of course; but you only have to do this once, you can then share test scripts freely. If you have to compile them you'll never know if your foo.exe and your foo.so were compiled from the same source, since you cannot diff them to check. > In some other cases, it may also be interesting > to simply run existing programs (if they exist). This shouldn't part > of the whole test system, but if program exists then use it (of course > command based programs are much easier than UI ones...) That's a completely different test environment. The perl stuff is meant for unit testing (a single API at a time), and especially for catching regressions. Running whole applications is of course necessary too, but it's not the same usage nor the same goal. I don't want 'make test' to launch winword so that I can test it too. > where I want to end up to is that we'd need several tests environments > (perl to be one, pure C could be another one... - it's anyway needed to > test the Winelib part, and the associated tools..., command line programs > from shell scripts could be a third). > the driving idea would be that all of those test tools spit the same > type of outputs (they all belong to the first pass), so we can share > the analysis tools I don't see any need for that. The tests and the results are very different, and I don't see what you'll be able to share. The result of the unit test would be something like 'HeapFree does not set the correct last error code when called with pointer xxx'; the result of running an application will be 'winword crashes when I click on save'. It's a completely different approach to testing, both are necessary but not within the same environment IMO. > there's just one point that worries me. Let me explain how I ended up with > XML. one thing I don't like is to have a "reference" file, but I don't > know what it refers to. I think the test process should output both the result > of the test (pure ASCII is fine) but also the environment of the test > (Windows - if so version, even DLLs used... -, vs wine - which version, which > DLLs are used, native vs builtin...) so that we could make usefull > comparisons But none of this information is relevant for unit testing. The only information that may be needed is the Windows version, and this only for the few APIs that actually behave differently between versions. And if you do your test scripts right you don't even need to know about it. For instance, instead of doing something like: kernel32->MapViewOfFile(bad params); print kernel32->GetLastError(); which would print different things on 95 and NT, you'd do: kernel32->MapViewOfFile(bad params); $err = kernel32->GetLastError(); if (kernel32->GetVersion() == win95) { print ($err == ERROR_INVALID_ADDRESS) ? "OK" : "failed: $err"; } else { print ($err == ERROR_INVALID_PARAMETER) ? "OK" : "failed: $err"; } This way the script always prints the same thing no matter the Windows version, and you can use a simple diff against a single reference file. -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

> > So, this imposes to have the test programs also (compile) and run under > > windows... This could even allow (from source code for example) to have > > 3 test caes : > > 1/ compiled and running under windows > > 2/ compiled under windows, but run with wine > > 3/ compiled as a winelib app > > The idea of using an interpreter like Perl is precisely that you don't > need to compile anything to run tests. I think this is important > because not everybody has a Windows compiler. Do you really feel like a C compiler is less common than a perl binary under Windows ? I seriously doubt it... > It also allows using the > exact same test script under Windows and Wine, so that you don't have > to worry whether your Windows binary exactly matches your Winelib > binary. well, the stubs between perl and windows will not be exactly the same anyway, so you'll anyway introduce code differences between the two (not to speak about the perl interpreters which might have small differences too). but let's try to open up this a bit. I don't think that perl only testing is sufficient (it can a very good test bed for some cases, but I won't cover any aspects). In some other cases, it may also be interesting to simply run existing programs (if they exist). This shouldn't part of the whole test system, but if program exists then use it (of course command based programs are much easier than UI ones...) where I want to end up to is that we'd need several tests environments (perl to be one, pure C could be another one... - it's anyway needed to test the Winelib part, and the associated tools..., command line programs from shell scripts could be a third). the driving idea would be that all of those test tools spit the same type of outputs (they all belong to the first pass), so we can share the analysis tools > > in order to help the pass 2 (and even produce all possible reports), I > > had in mind (but didn't give a good look at it) to let the test scripts > > produce an XML output. This would allow the test harness to spit out any > > information (like used DLLs native/builtin, version of those, version of > > windows (emulated by wine or native...), plus the output by itself > > analysis and report should be (partially) driven by some XSL/XSLT tools > > I don't think we need anything fancy like that. The output should be > simple ASCII that can be automatically compared with diff, and the > test is considered a failure if diff finds any difference against the > reference output. Everything should be automated as much as possible. there's just one point that worries me. Let me explain how I ended up with XML. one thing I don't like is to have a "reference" file, but I don't know what it refers to. I think the test process should output both the result of the test (pure ASCII is fine) but also the environment of the test (Windows - if so version, even DLLs used... -, vs wine - which version, which DLLs are used, native vs builtin...) so that we could make usefull comparisons XML is just the way to structure the metadata about the test, the output of the test per se could be pure ASCII A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 23, 2001

Re: huge library renaming ?

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > one thing that occurred to me: > Shouldn't we rename *all* Wine libraries to libwineXXX ? This was discussed already. The dlls will ultimately reside in /usr/lib/wine so there won't be any conflict; the libraries that have to be in /usr/lib already use the libwine prefix (libwine_unicode, libwine_tsx11 etc.) -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

RE: huge library renaming ?

by Ove Kaaven

On Fri, 23 Feb 2001, Patrik Stridvall wrote: > Sure Wine uses (or can be made to use rpath), but I'm not sure we > want to require all Winelib applications to do the same. No, the configure script applies rpath to the winelib dlls. The wine binary itself doesn't use rpath by default. > It would IMHO be much better if a simple Winelib applications just > could add -lwin32_XXX and be done with it. Winelib apps should never link to the .so files using -lXXX. They should add "import XXX" to the main .spec file and let winelib handle the actual loading, but never link to the libs directly at the ELF level. At least that's Alexandre's plan...

Feb. 23, 2001

RE: huge library renaming ?

by Patrik Stridvall

> On Fri, 23 Feb 2001, Andreas Mohr wrote: > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > Any reason for doing this? > I can't think of any... > > The Debian packages work perfectly, without any potential for > conflict. > They install the dlls into /usr/lib/wine, do *not* put > /usr/lib/wine into > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > /usr/lib (and Wine's own configure adds rpath stuff last time > I looked) I think the discussion is more about what Winelib applications in general do (or should do) rather than what Wine (a very specific Winelib application) does. Sure Wine uses (or can be made to use rpath), but I'm not sure we want to require all Winelib applications to do the same. It would IMHO be much better if a simple Winelib applications just could add -lwin32_XXX and be done with it.

Feb. 23, 2001

Re: huge library renaming ?

by Bernhard Rosenkraenzer

On Fri, 23 Feb 2001, Ove Kaaven wrote: > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > Any reason for doing this? > I can't think of any... > > The Debian packages work perfectly, without any potential for conflict. > They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > /usr/lib (and Wine's own configure adds rpath stuff last time I looked) The Red Hat package does the same thing, but still I'd prefer renaming the libraries for all the people who compile from source without knowing all the details. You quickly get from "I'm a total newbie" to "I'm still a newbie, but I know that basics and I've figured out I can install almost any program from source by just typing "./configure --prefix=/usr; make install"!" state. We shouldn't kill those users' normal libraries. [Yes, I know users should in theory put all their stuff to /usr/local, but I haven't seen many people who actually do] Either rename them, or make configure intelligent enough to do /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly told not to do it... LLaP bero

Feb. 23, 2001

Re: huge library renaming ?

by Ove Kaaven

On Fri, 23 Feb 2001, Andreas Mohr wrote: > AFAIR there have been several naming conflicts with other projects > (libole, ...), and people who need to remove a previous Wine install > from their system manually have a rather hard time... > > Any reason for not doing this ? > I can't think of any... Any reason for doing this? I can't think of any... The Debian packages work perfectly, without any potential for conflict. They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from /usr/lib (and Wine's own configure adds rpath stuff last time I looked)

Feb. 23, 2001

Re: huge library renaming ?

by Gerald Pfeifer

On Fri, 23 Feb 2001, Marcus Meissner wrote: > Why not put them in /usr/lib/wine/ as suggested by the FHS? That's what I've been doing for the FreeBSD port for ages. Welcome to the club! :-) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

RE: huge library renaming ?

by Patrik Stridvall

> On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > > Hello all, > > > > one thing that occurred to me: > > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > > > If this is a good thing, then we should do this NOW, not > when it's too late. I agree, if we do we must do it before Wine 1.0. > > The current drawbacks are just too much IMHO. > > Why not put them in /usr/lib/wine/ as suggested by the FHS? I second that. However I would suggest that we also put symbolic link to the corresponding files in /usr/lib following the suggested naming scheme libwineXXX or something similar. Other suggestions. 1. libwine_XXX 2. libwin32_XXX Personal think I would prefer the libwin32_XXX variant because in theory use could have other implementations of the Windows API than Wine and that is of no pariticular concern of the programmer eventhough of course it is for the administrator of the system. If a programmer wanted to use say Win32 filehandling functions he could, in theory, just link with libwin32_kernel32 and be done with it. Something (in our case Wine) provides it, but he doesn't care what. This is currently not possible IIRC but it might be in the future. Additionally is makes it possible to support both Win32 and Win64 on 64bit systems like Itanium by having libwin64_XXX. This would make it easier to properly link to the files in Winelib application. This means you can do gcc -o foo foo.c -lwin32_ole instead of doing gcc -o foo foo.c -I/usr/lib/wine -lole that might cause problems if libole.so exist in another path. Also not that this also makes it harder to link to the DLL:s that are not supposed to be use with Winelib by misstake, like the Win16 DLL:s since we can choose to not provide symbolic links to them.

Feb. 23, 2001

Re: huge library renaming ?

by Marcus Meissner

On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > Hello all, > > one thing that occurred to me: > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > AFAIR there have been several naming conflicts with other projects > (libole, ...), and people who need to remove a previous Wine install > from their system manually have a rather hard time... > > Any reason for not doing this ? > I can't think of any... > > If this is a good thing, then we should do this NOW, not when it's too late. > > The current drawbacks are just too much IMHO. Why not put them in /usr/lib/wine/ as suggested by the FHS? Ciao, Marcus

Feb. 23, 2001