Prev: ERROR_BAD_IMPERSONATION_LEVEL with Vista SP1, any workaround?
Next: DEP and /NXCOMPAT troubles...
From: Pavel A. on 28 Oct 2008 18:38
Volodymyr M. Shcherbyna wrote:
> 2 Pavel,
>
> Even if we speak about kernel mode, I would prefer to use NtCurrentThread
> instead of using -2 define in my code, as if things will change in future
> you will have a hidden bug which could be hard to trace.
>
> On the other hand, If your driver will be using NtCurrentThread you will
> discover problem at compilation stage (linker will fail if NtCurrentThread
> will be removed from list of exported functions by ntoskrnl) or at customer
> side driver just would not load and there will be apropriate entry in event
> manager ...
>

Volodymyr, you know what... Microsoft will always find
a fresh and creative way to get us, no matter how we prepare.
The recent Cygwin issue is a good example.

--PA
From: Tim Roberts on 29 Oct 2008 01:47
Richard Russell <news(a)rtrussell.co.uk> wrote:
>
>Are there any circumstances, with any version of Windows, in which
>GetCurrentThread can return a value other than the constant -2? Apart
>from inelegance, is there any risk in using (HANDLE) -2 instead?

Do the 16-bit systems matter to you? On Windows 95/98/ME, GetCurrentThread
does not return -2.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Richard Russell on 29 Oct 2008 06:07
On Oct 29, 5:47 am, Tim Roberts <t...(a)probo.com> wrote:
> Do the 16-bit systems matter to you?  On Windows 95/98/ME, GetCurrentThread
> does not return -2.

GetCurrentThread *does* return -2 on Windows 95 (OSR2). At least, it
does here on the system I've just run up to check it.

Hang on a mo' while I fire up my WinMe system (considerably less
accessible, since it's in the attic!).... yep that returns -2 too.

If there are circumstances in which you believe Win9x might return a
value other than -2 I'd be interested to know what they are. Such
systems *do* matter to me.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
From: Pavel A. on 29 Oct 2008 11:09
ZwCurrentProcess() and ZwCurrentThread() _are_ documented in MSDN,
with following description:

"The returned value is not a true handle, but it is a special value that
always represents the current process. "

However, these macros are declared not like normal constants
(in uppercase) but like functions; maybe this suggests that the actual
value could change in various Windows versions and should be obtained in
runtime.

--PA
From: Ben Voigt [C++ MVP] on 29 Oct 2008 15:45
Pavel A. wrote:
> ZwCurrentProcess() and ZwCurrentThread() _are_ documented in MSDN,
> with following description:
>
> "The returned value is not a true handle, but it is a special value
> that always represents the current process. "
>
> However, these macros are declared not like normal constants
> (in uppercase) but like functions; maybe this suggests that the actual
> value could change in various Windows versions and should be obtained
> in runtime.

You want to explain how a macro obtains anything at runtime? It doesn't
even survive until compile-time as it is substituted by the preprocessor.

>
> --PA


First  |  Prev  | 
Pages: 1 2
Prev: ERROR_BAD_IMPERSONATION_LEVEL with Vista SP1, any workaround?
Next: DEP and /NXCOMPAT troubles...