Set/WindowLong problem in user/win test
Greg Turner
gmturner007 at ameritech.net
Tue Dec 24 22:54:43 CST 2002
On Tuesday 24 December 2002 08:23 pm, Francois Gouget wrote:
> On Tue, 24 Dec 2002, Greg Turner wrote:
> > This type of scenario seems to come up a lot lately... perhaps
> > there should be a standard way to detect windows 95 (or another
> > platform) during a test and skip things as may be appropriate on
> > that platform? What do you think?
>
> Tests should *not* check whether they are running on Windows 95, 98
> or other. Just like individual autoconf-like functionality tests are
> better than relying on __LINUX__ or other macros, tests should check
> for the existence of the functions they want to test.
Why not, it seems reasonable enough to me? I'm talking about run-time
checks here -- I don't know the API's, but surely there is some
Microsoft-sanctioned way to determine the OS you are running on...?
And as the wine developers, surely we can decide if we are running
under wine... so why is this really so bad, assuming it's implemented
well, in an easy-to-re-use manner.
> So the best way to handle A/W issues is to just call the function and
> check for failure with the ERROR_CALL_NOT_IMPLEMENTED error. If that
> happens then the check(s) should be skipped. Similarly, the way to
> deal with APIs that only exist on some platforms is to use
> LoadLibrary and GetProcAddress. If the resulting pointer is NULL,
> then skip the test(s). It may even make sense to do so in cases where
> the whole library may be missing (kind of depends on the impact of
> missing libraries on automated runs: does it stop the batch file with
> a messagebox?).
>
> The real issue is that up until now all tests have been written using
> Wine and never tested in Windows. Or if they were actually tested in
> Windows they were only tested with one version of Windows and one
> quickly finds whether that was Win9x or an NT-something.
Yes, the concept of what is being tested seems to have broadened a bit,
from "test the guts of wine" to "test the guts of wine in a
windows-compatible way," which seems like a good thing to me, btw.
It hasn't really been an issue, and perhaps it need never be, but, as
you point out, certainly one could imagine scenarios where it's not so
simple as just checking for ERROR_CALL_NOT_IMPLEMENTED:
perhaps there is no such API to call on some platform, or perhaps the
user needs permission to write to some resource that might depend on
the user's permission on the particular machine... who knows? Testing
a big system like wine which goes pretty deep into the architectural
roots, and all the way up to big honkin' "assemblies" (or
what-have-you's) like the java virtual machine or directx... there
could be a lot of circumstances where the outcome might not be reliable
but we don't want to drop the test out of the default testrun... this
is precisely why it seems that being able to rule out 90% of such cases
with a simple "what environment do I run under?" test seems like a
win... but perhaps you have thought this through more carefully than
I? Am I missing something?
Merry Christmas, and thanks for all the great code and hard work,
--
gmt
"It does not take a majority to prevail ... but rather an irate,
tireless minority, keen on setting brushfires of freedom in the
minds of men." --Samuel Adams, Patriot
More information about the wine-devel
mailing list