Re: prevent peekmessage from crashing when msg == NULL
Eric wrote:
Somewhere, for some reason, our client code was calling PeekMessage(NULL, ...), basically asking windows to discard a single message without returning it. From the MSDN docs, this seems like an illegal use of the function, but Windows does the right thing when we do it and wine crashes.
This sounds like a good place to write a test case. --Juan p.s. and I'll call that bluff: how _do_ you know what happens when you have more than 500 printers defined? ;) __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
"Juan Lang" <juan_lang(a)yahoo.com> wrote:
Somewhere, for some reason, our client code was calling PeekMessage(NULL, ...), basically asking windows to discard a single message without returning it. From the MSDN docs, this seems like an illegal use of the function, but Windows does the right thing when we do it and wine crashes.
This sounds like a good place to write a test case.
I must admit I've never looked at the test suite. What kinds of things should have tests? Are they intended to verify implementations of the undocumented or poorly-documented parts of the windows API? I guess by that standard, the other patch I posted which fixed the behavior of two consecutive calls to OpenClipboard() would be another good candidate for a test case. I'll take a look at the test code when I get a chance and see if I can make a proper test for this when I get a chance. It might take me a while to get around to it, right now I'm under pressure to get winelib working on HPUX. Until this week, we've been working with a version of winelib that was over a year old so we were never able to submit reasonable patches. We've been sitting on most of these changes for the better part of a year, so I wanted to get them out in the open before we fall behind again.
p.s. and I'll call that bluff: how _do_ you know what happens when you have more than 500 printers defined? ;)
One of our customers, of course, wanted to run our software on a machine with nearly 600 printers installed. I kept looking at the debugging logs and thinking that there *must* be an infininte loop in the printcap parser... I'm still having a hard time wrapping my head around that one; I have two printers installed and I still print to the wrong one more than I care to admit. Eric
--- Eric Frias <efrias(a)syncad.com> wrote:
I must admit I've never looked at the test suite. What kinds of things should have tests? Are they intended to verify implementations of the undocumented or poorly-documented parts of the windows API?
That, as well as correct and documented behavior. The more the merrier.
I guess by that standard, the other patch I posted which fixed the behavior of two consecutive calls to OpenClipboard() would be another good candidate for a test case.
I think so. The test code is pretty straightforward: you use the ok macro to check a condition. Something like, ok(GetLastError() == ERROR_NO_MORE_DATA, "Expected ERROR_NO_MORE_DATA, got %d\n", GetLastError()); If you write a test that fails under wine, and you don't have a chance to fix it, you can still submit the test with a todo_wine, like: todo_wine ok(...) You can run the tests with make test. I try to do a make test before sending in a patch to make sure I didn't regress anything (fortunately Alexandre seems to as well). In some areas, particularly new areas of code, having no tests is acceptable. In existing code, having a test case will go a long way to getting a patch accepted.
It might take me a while to get around to it, right now I'm under pressure to get winelib working on HPUX.
Good luck! --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
Juan Lang wrote:
I try to do a make test before sending in a patch to make sure I didn't regress anything (fortunately Alexandre seems to as well).
Problem is that, for me, make tests fails on vanilla wine. For that reason, I don't usually bother. I have never managed to figure out what is causing these failures. For example, just got a fresh CVS, compiled and ran the tests:
make[3]: Entering directory `/home/sun/sources/wine/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so capture.c && touch capture.ok ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so ds3d.c && touch ds3d.ok ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so ds3d8.c && touch ds3d8.ok ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok fixme:ole:CoCreateInstance no instance created for interface {279afa83-4981-11ce-a521-0020af0be560} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x88780078 dsound.c:177: Test failed: CoCreateInstance(CLSID_DirectSound) failed: DSERR_NODRIVER fixme:ole:CoCreateInstance no instance created for interface {279afa83-4981-11ce-a521-0020af0be560} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x88780078 dsound.c:186: Test failed: CoCreateInstance(CLSID_DirectSound) failed: DSERR_NODRIVER fixme:ole:CoCreateInstance no instance created for interface {279afa83-4981-11ce-a521-0020af0be560} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x88780078 dsound.c:195: Test failed: CoCreateInstance(CLSID_DirectSound) failed: DSERR_NODRIVER fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x80004002 fixme:ole:CoCreateInstance no classfactory created for CLSID {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca}, hres is 0x80040154 make[3]: *** [dsound.ok] Error 3 make[3]: Leaving directory `/home/sun/sources/wine/wine/dlls/dsound/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/dsound' make[1]: *** [dsound/__test__] Error 2
Is this something wrong on my config? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
--- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote:
Problem is that, for me, make tests fails on vanilla wine. For that reason, I don't usually bother. I have never managed to figure out what is causing these failures. For example, just got a fresh CVS, compiled and ran the tests: Is this something wrong on my config?
Hmm, no idea, maybe one of the dsound guys has a clue. I usually just do a make test on the DLL I'm working on. --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
participants (3)
-
Eric Frias -
Juan Lang -
Shachar Shemesh