Is GetCurrentThread really a constant?
Richard Russell
GetCurrentThread can return a value other than the constant -2? Apart
from inelegance, is there any risk in using (HANDLE) -2 instead?
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Pavel A.
From wdm.h:
#define NtCurrentThread() ( (HANDLE)(LONG_PTR) -2 )
So perhaps you can use this macro instead of -2.
Regards,
--PA
Volodymyr M. Shcherbyna
problems in future when pseudohandle will change from -2 to -whatever.
--
Volodymyr, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:%234qRMSG...@TK2MSFTNGP02.phx.gbl...
Pavel A.
> Using macro in code instead of calling function can theoretically bring
> problems in future when pseudohandle will change from -2 to -whatever.
>
This is why linux kernel folks hate macros and typedefs...
Indeed, why someone needs another name for -2 ?
--PA
Volodymyr M. Shcherbyna
> Indeed, why someone needs another name for -2 ?
>
> --PA
I don't know, but why someone changed PID for System process in Windows XP
to 4 from 8 (in Windows 2k)?
--
Volodymyr, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:uQphnUOO...@TK2MSFTNGP06.phx.gbl...
Pavel A.
>> This is why linux kernel folks hate macros and typedefs...
>> Indeed, why someone needs another name for -2 ?
>>
>> --PA
>
> I don't know, but why someone changed PID for System process in Windows XP
> to 4 from 8 (in Windows 2k)?
This could be part of boot optimization <g>
Seriously, system processes can be detected by other sane means
(PsInitialSystemProcess, PsIsSystemThread)
--PA
Volodymyr M. Shcherbyna
method (GetCurrentThread) to use? :)
--
Volodymyr, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:e78Y0yRO...@TK2MSFTNGP02.phx.gbl...
Pavel A.
> So why in the hell someone has to rely on (HANDLE)2 if there is public
> method (GetCurrentThread) to use? :)
>
GetCurrentThread is Win32 API, you can't call it in a driver.
NtCurrentThread is a native API (obviously, not mentioned in MSDN).
So yes, -2 is better, to avoid undocumented stuff ;)
--PA
Volodymyr M. Shcherbyna
assume we speak about user mode :)
--
Volodymyr, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:OlN0xfUO...@TK2MSFTNGP03.phx.gbl...
Volodymyr M. Shcherbyna
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, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Volodymyr M. Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:edBglkUO...@TK2MSFTNGP03.phx.gbl...
Richard Russell
> So why in the hell someone has to rely on (HANDLE)2 if there is public
> method (GetCurrentThread) to use? :)
I don't suppose anybody *has* to rely on it, although there are
obvious (if small) advantages such as slightly shorter code and
slightly faster execution speed.
I would turn the question around. If existing code uses (HANDLE)-2,
is there a good reason to go to the trouble of changing it? My
reading of the replies in this thread is probably not. The
"theoretical" possibility of the value changing in the future doesn't
worry me, because almost certainly other things would require changing
then too.
Pavel A.
> 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
Tim Roberts
>
>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, ti...@probo.com
Providenza & Boekelheide, Inc.
Richard Russell
> 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.
Pavel A.
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
Ben Voigt [C++ MVP]
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
Pavel A.
No, what I wanted to say is that this macro probably was intended
to hide the fact that it always evaluates to constant.
OTOH, someone from MS wrote that once a public API has been defined
as macro or inline function, it will never change later,
because this would break binary compatibility.
--PA
Tim Roberts
>
>On Oct 29, 5:47 am, Tim Roberts <t...@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.
Hmmm. Was it Win32s where it didn't? That, I suppose, no longer matters
to ANYONE.
David Connet
news:e62lg45rcovdp924k...@4ax.com:
> Richard Russell <ne...@rtrussell.co.uk> wrote:
>>
>>On Oct 29, 5:47 am, Tim Roberts <t...@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.
>
> Hmmm. Was it Win32s where it didn't? That, I suppose, no longer
> matters to ANYONE.
Oh G*d - that word - and on Halloween to boot! I'll have nightmares for
weeks! Win32s, Comm, thunking, AAHHHHHH
Dave Connet