Jeff Latimer a écrit :
Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc.
those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle A+
Eric Pouech wrote:
Jeff Latimer a écrit :
Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc.
those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle
I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case?
Jeff
Jeff L a écrit :
Eric Pouech wrote:
Jeff Latimer a écrit :
Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc.
those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle
I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case?
my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test
rationale behind this: - that's what is the most logical - when someone changes DLL X, he/she doesn't want (at first) to rerun the tests from every DLL
note: there's currently only one case of this (in kernel32/tests) for virtual memory, and it should be moved to ntdll
A+
On 2/17/07, Eric Pouech eric.pouech@wanadoo.fr wrote:
Jeff L a écrit :
Eric Pouech wrote:
Jeff Latimer a écrit :
Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc.
those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle
I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case?
my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test
perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ?
richardvoigt@gmail.com a écrit :
On 2/17/07, Eric Pouech eric.pouech@wanadoo.fr wrote:
Jeff L a écrit :
Eric Pouech wrote:
Jeff Latimer a écrit :
Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc.
those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle
I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case?
my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test
perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ?
dlls/ntdll/tests/mailslot.c A+
-
Eric Pouech -
Jeff L -
richardvoigt＠gmail.com