Re: 1/4 NtCreateMailslotFile tests

[Dmitry Timoshkov]

"Jeff Latimer"  wrote:
> - rc = pNtCreateMailslotFile(&hslot, DesiredAccess,
> -
>     &attr, &IoStatusBlock, CreateOptions, MailslotQuota, MaxMessageSize,
> -
>     &TimeOut);
> - ok( rc == S_OK, "Create MailslotFile failed rc = %x %u\n", rc, GetLastError());

NT APIs return STATUS_xxx error codes, S_OK is an OLE error value.
> - ok( hslot != INVALID_HANDLE_VALUE, "Handle is invalid\n");

INVALID_HANDLE_VALUE is a kernel32 thing, NT APIs don't use it. Most likely
you need to test returned value against 0.
> - ok( CloseHandle(hslot), "CloseHandle failed\n");

To close the handle returned by an NT API you have you use an NT API as well.

1/4 NtCreateMailslotFile tests

[Jeff L]

Dmitry Timoshkov wrote:
> "Jeff Latimer"  wrote:
> > - ok( CloseHandle(hslot), "CloseHandle failed\n");
>
> To close the handle returned by an NT API you have you use an NT API 
> as well.

Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx 
and it seems that NtClose has been superseded by CloseHandle.  So I 
suppose that CloseHandle is the one to use.  Have fixed the other points.

Jeff

1/4 NtCreateMailslotFile tests

[Dmitry Timoshkov]

"Jeff L"  wrote:
> > To close the handle returned by an NT API you have you use an NT API 
> > as well.

What is not apparent in the explanation above?
> Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx 
> and it seems that NtClose has been superseded by CloseHandle.  So I 
> suppose that CloseHandle is the one to use.

The information in MSDN is misleading in this case, CloseHandle is a kernel32
API, not an NT (native) one.

1/4 NtCreateMailslotFile tests

[Jeff L]

Dmitry Timoshkov wrote:
> "Jeff L"  wrote:
> > > To close the handle returned by an NT API you have you use an NT API 
> > > as well.
>
> What is not apparent in the explanation above?

I have no problem with what you have said though I did have a bit of 
difficulty marrying to the sentence below.
> > Have reread MSDN 
> > http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems 
> > that NtClose has been superseded by CloseHandle.  So I suppose that 
> > CloseHandle is the one to use.
>
> The information in MSDN is misleading in this case, CloseHandle is a 
> kernel32
> API, not an NT (native) one.

So the correct move is to use the depreciated function?  Microsoft 
appears to be pushing people away from NtClose.  Is the it that they are 
reserving NtClose etc for their ntdll use?

Jeff

1/4 NtCreateMailslotFile tests

[Dmitry Timoshkov]

"Jeff L"  wrote:
> > > Have reread MSDN 
> > > http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems 
> > > that NtClose has been superseded by CloseHandle.  So I suppose that 
> > > CloseHandle is the one to use.
> >
> > The information in MSDN is misleading in this case, CloseHandle is a 
> > kernel32
> > API, not an NT (native) one.
>
> So the correct move is to use the depreciated function?

It's not deprecated, even Microsof tries to create an impression it is.
> Microsoft 
> appears to be pushing people away from NtClose.

I'd suggest you to find a reason why.
> Is the it that they are 
> reserving NtClose etc for their ntdll use?

Also I'd suggest to learn about a difference between Native and Win32 API
before writing the tests that mix them.

1/4 NtCreateMailslotFile tests

> > Microsoft
> > appears to be pushing people away from NtClose.
>
> I'd suggest you to find a reason why.

That particular documentation happens to be part of the API released
under court order.  They didn't want to give it out to begin with, and
they don't want people using it now.

Perhaps someone should determine if there are any applications
statically linking to any of those functions, which would disprove the
claim "There is no import library, you must use GetProcAddress" and
leave MS in violation of said order.

1/4 NtCreateMailslotFile tests

[Jeff L]

[e-mail] wrote:
> > > Microsoft
> > > appears to be pushing people away from NtClose.
> >
> > I'd suggest you to find a reason why.
>
> That particular documentation happens to be part of the API released
> under court order.  They didn't want to give it out to begin with, and
> they don't want people using it now.

Ok I  am happy with this as an explanation and will move the tests.   
Another case of MSDN telling fibs to the gullible.

Jeff