Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GetThreadId() on Win-XP?
707 views
Skip to first unread message
ElChino
Nov 3, 2014, 12:26:19 PM11/3/14
to
The GetThreadId() function is available on Win-Vista or above
I believe. (in kernet32.dll). Does anybody know a good emulation
for this function on Win-XP?
First I tried with using some bits from the ThreadHandle
value and combining those with the getpid() value, but
there must be some better way.
I believe. (in kernet32.dll). Does anybody know a good emulation
for this function on Win-XP?
First I tried with using some bits from the ThreadHandle
value and combining those with the getpid() value, but
there must be some better way.
David Lowndes
Nov 3, 2014, 12:34:09 PM11/3/14
to
>The GetThreadId() function is available on Win-Vista or above
>I believe. (in kernet32.dll).
I suspect the documentation may not be telling you the whole truth -
>I believe. (in kernet32.dll).
test it on XP SP3, it may well exist there too.
Dave
R.Wieser
Nov 3, 2014, 2:22:10 PM11/3/14
to
ElChino,
> The GetThreadId() function is available on Win-Vista or
> above I believe.
That seems to be correct. My copy of XPsp3 does not seem to have it.
> Does anybody know a good emulation for this function on Win-XP?
There seem to be several different solutions available. All you need to do
is to use Google with a few keywords. The combination I used was "XP
GetThreadID", to which the "get lucky" link (to stackoverflow.com) already
seems to be quite interresting.
Regards,
Rudy Wieser
-- Origional message:
ElChino <elc...@cnn.cn> schreef in berichtnieuws
m38drg$d7v$1...@dont-email.me...
> The GetThreadId() function is available on Win-Vista or
> above I believe.
> Does anybody know a good emulation for this function on Win-XP?
is to use Google with a few keywords. The combination I used was "XP
GetThreadID", to which the "get lucky" link (to stackoverflow.com) already
seems to be quite interresting.
Regards,
Rudy Wieser
-- Origional message:
ElChino <elc...@cnn.cn> schreef in berichtnieuws
m38drg$d7v$1...@dont-email.me...
Geoff
Nov 3, 2014, 4:20:17 PM11/3/14
to
MSDN has been falling on its face in recent years. Replacing
references to Win95 or Windows NT with Windows Vista, etc. which
causes me to always question whether "minimum supported client" has
any validity for many API functions. For instance, GetCurrentProcessId
function documentation has Windows XP as minimum supported client
while it surely existed in Windows 95. I don't know what their
justification is for this modification of history other than they
simply don't want to "support" legacy systems like Windows 95/NT/XP
even though the API exists in those systems.
The only way to know whether it exists is to boot up that old legacy
system and test it or poke into a copy of Windows XP's kernel32.dll
with Dependency Walker and see if it's there.
I think someone went a little wild with global find and replace in
MSDN a while ago and it's never been quite as good a resource as it
was back in the good old days of the MSDN CDs.
If you're in the thread and you want its ID, use GetCurrentThreadId()
which the MSDN online documents to be supported in XP.
If you created your thread using CreateThread then you can establish
the thread ID at that time by passing a non-null LPDWORD to receive
the thread ID when it's created.
Seeking to avoid the revisionist web, I opened up my old CD box and
installed the MSDN library for VS 6.0 and cannot find documentation to
support the GetThreadId function so it looks like it didn't exist at
that time but GetCurrentThreadId() did exist.
Deanna Earley
Nov 4, 2014, 4:01:59 AM11/4/14
to
On 03/11/2014 21:20, Geoff wrote:
> On Mon, 03 Nov 2014 17:29:53 +0000, ElChino <elc...@cnn.cn> wrote:
>
>> The GetThreadId() function is available on Win-Vista or above
>> I believe. (in kernet32.dll). Does anybody know a good emulation
>> for this function on Win-XP?
>>
>> First I tried with using some bits from the ThreadHandle
>> value and combining those with the getpid() value, but
>> there must be some better way.
>
> It wouldn't be the first time the MSDN documentation was wrong.
>
> MSDN has been falling on its face in recent years. Replacing
> references to Win95 or Windows NT with Windows Vista, etc. which
> causes me to always question whether "minimum supported client" has
> any validity for many API functions. For instance, GetCurrentProcessId
> function documentation has Windows XP as minimum supported client
> while it surely existed in Windows 95. I don't know what their
> justification is for this modification of history other than they
> simply don't want to "support" legacy systems like Windows 95/NT/XP
> even though the API exists in those systems.
The "Minimum supported XX" is the minimum version supported by Microosoft.
> On Mon, 03 Nov 2014 17:29:53 +0000, ElChino <elc...@cnn.cn> wrote:
>
>> The GetThreadId() function is available on Win-Vista or above
>> I believe. (in kernet32.dll). Does anybody know a good emulation
>> for this function on Win-XP?
>>
>> First I tried with using some bits from the ThreadHandle
>> value and combining those with the getpid() value, but
>> there must be some better way.
>
> It wouldn't be the first time the MSDN documentation was wrong.
>
> MSDN has been falling on its face in recent years. Replacing
> references to Win95 or Windows NT with Windows Vista, etc. which
> causes me to always question whether "minimum supported client" has
> any validity for many API functions. For instance, GetCurrentProcessId
> function documentation has Windows XP as minimum supported client
> while it surely existed in Windows 95. I don't know what their
> justification is for this modification of history other than they
> simply don't want to "support" legacy systems like Windows 95/NT/XP
> even though the API exists in those systems.
It is no longer the "Minimum required".
--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/
iCode Systems
(Replies direct to my email address will be printed, shredded then fed
to the rats. Please reply to the group.)
JJ
Nov 4, 2014, 4:59:47 AM11/4/14
to
NtQueryInformationThread to get ThreadBasicInformation-class structure, then
retrieve its ClientId.UniqueThread field.
Geoff
Nov 4, 2014, 9:14:32 AM11/4/14
to
On Tue, 04 Nov 2014 09:01:17 +0000, Deanna Earley
<dee.e...@icode.co.uk> wrote:
>The "Minimum supported XX" is the minimum version supported by Microosoft.
>It is no longer the "Minimum required".
I agree and that is the way I have been interpreting it for the last
<dee.e...@icode.co.uk> wrote:
>The "Minimum supported XX" is the minimum version supported by Microosoft.
>It is no longer the "Minimum required".
two years or so. I made the comment for the larger audience who seem
to interpret it to mean "available in systems since XX", which in this
case it seems to mean so since it's not in MSDN CDs vintage 1999 and
VS 6.0 doesn't use it.
What I object to is that MSDN appears to use it inconsistently and
readers are left to fend for themselves. A proper documentation of the
API should be more precise.
Deanna Earley
Nov 4, 2014, 9:39:35 AM11/4/14
to
On 04/11/2014 14:14, Geoff wrote:
> On Tue, 04 Nov 2014 09:01:17 +0000, Deanna Earley
> <dee.e...@icode.co.uk> wrote:
>
>> The "Minimum supported XX" is the minimum version supported by Microosoft.
>> It is no longer the "Minimum required".
>
> I agree and that is the way I have been interpreting it for the last
> two years or so. I made the comment for the larger audience who seem
> to interpret it to mean "available in systems since XX", which in this
> case it seems to mean so since it's not in MSDN CDs vintage 1999 and
> VS 6.0 doesn't use it.
It's also wrapped in:
> On Tue, 04 Nov 2014 09:01:17 +0000, Deanna Earley
> <dee.e...@icode.co.uk> wrote:
>
>> The "Minimum supported XX" is the minimum version supported by Microosoft.
>> It is no longer the "Minimum required".
>
> I agree and that is the way I have been interpreting it for the last
> two years or so. I made the comment for the larger audience who seem
> to interpret it to mean "available in systems since XX", which in this
> case it seems to mean so since it's not in MSDN CDs vintage 1999 and
> VS 6.0 doesn't use it.
#if (_WIN32_WINNT >= 0x0502)
This is 64-bit XP and Server 2003 or newer.
(32-bit XP is 0x0501)
> What I object to is that MSDN appears to use it inconsistently and
> readers are left to fend for themselves. A proper documentation of the
> API should be more precise.
ElChino
Nov 4, 2014, 2:17:59 PM11/4/14
to
JJ <jj4p...@vfemail.net> wrote:
> GetThreadId() if just a helper function. It simply calls
> NtQueryInformationThread to get ThreadBasicInformation-class structure, then
> retrieve its ClientId.UniqueThread field.
Good to know. Thanks.
> GetThreadId() if just a helper function. It simply calls
> NtQueryInformationThread to get ThreadBasicInformation-class structure, then
> retrieve its ClientId.UniqueThread field.
Geoff
Nov 5, 2014, 11:06:40 AM11/5/14
to
On Tue, 04 Nov 2014 14:38:54 +0000, Deanna Earley
environment it's being targeted for. It replaces the question, "Why
does the SDK documentation suck?" with "Why is that function undefined
when I try to use it?" and if it is undefined it will be difficult or
impossible to find depending on your host environment or the SDK
you're using.
>> What I object to is that MSDN appears to use it inconsistently and
>> readers are left to fend for themselves. A proper documentation of the
>> API should be more precise.
>
>Fancy reading the include files? :p
Actually, no. I prefer accurate and succinct documentation.
So far, you have contributed nothing to answering ElChino's question.
<dee.e...@icode.co.uk> wrote:
>On 04/11/2014 14:14, Geoff wrote:
>> On Tue, 04 Nov 2014 09:01:17 +0000, Deanna Earley
>> <dee.e...@icode.co.uk> wrote:
>>
>>> The "Minimum supported XX" is the minimum version supported by Microosoft.
>>> It is no longer the "Minimum required".
>>
>> I agree and that is the way I have been interpreting it for the last
>> two years or so. I made the comment for the larger audience who seem
>> to interpret it to mean "available in systems since XX", which in this
>> case it seems to mean so since it's not in MSDN CDs vintage 1999 and
>> VS 6.0 doesn't use it.
>
>It's also wrapped in:
>#if (_WIN32_WINNT >= 0x0502)
>
>This is 64-bit XP and Server 2003 or newer.
>(32-bit XP is 0x0501)
>
Those are defined by the SDK it's being built with, not the
>On 04/11/2014 14:14, Geoff wrote:
>> On Tue, 04 Nov 2014 09:01:17 +0000, Deanna Earley
>> <dee.e...@icode.co.uk> wrote:
>>
>>> The "Minimum supported XX" is the minimum version supported by Microosoft.
>>> It is no longer the "Minimum required".
>>
>> I agree and that is the way I have been interpreting it for the last
>> two years or so. I made the comment for the larger audience who seem
>> to interpret it to mean "available in systems since XX", which in this
>> case it seems to mean so since it's not in MSDN CDs vintage 1999 and
>> VS 6.0 doesn't use it.
>
>It's also wrapped in:
>#if (_WIN32_WINNT >= 0x0502)
>
>This is 64-bit XP and Server 2003 or newer.
>(32-bit XP is 0x0501)
>
environment it's being targeted for. It replaces the question, "Why
does the SDK documentation suck?" with "Why is that function undefined
when I try to use it?" and if it is undefined it will be difficult or
impossible to find depending on your host environment or the SDK
you're using.
>> What I object to is that MSDN appears to use it inconsistently and
>> readers are left to fend for themselves. A proper documentation of the
>> API should be more precise.
>
>Fancy reading the include files? :p
So far, you have contributed nothing to answering ElChino's question.
Deanna Earley
Nov 5, 2014, 12:00:39 PM11/5/14
to
On 05/11/2014 16:06, Geoff wrote:
> On Tue, 04 Nov 2014 14:38:54 +0000, Deanna Earley
> <dee.e...@icode.co.uk> wrote:
>> It's also wrapped in:
>> #if (_WIN32_WINNT >= 0x0502)
>>
>> This is 64-bit XP and Server 2003 or newer.
>> (32-bit XP is 0x0501)
>
> Those are defined by the SDK it's being built with, not the
> environment it's being targeted for.
Exactly, that defines the minimum API/kernel that function was available
> On Tue, 04 Nov 2014 14:38:54 +0000, Deanna Earley
> <dee.e...@icode.co.uk> wrote:
>> It's also wrapped in:
>> #if (_WIN32_WINNT >= 0x0502)
>>
>> This is 64-bit XP and Server 2003 or newer.
>> (32-bit XP is 0x0501)
>
> Those are defined by the SDK it's being built with, not the
> environment it's being targeted for.
in, giving a definitive, "it wasn't in 32-bit XP".
> So far, you have contributed nothing to answering ElChino's question.
Feel free to ignore me if you don't like my answers. I have various
people killfiled.
Geoff
Nov 5, 2014, 12:23:20 PM11/5/14
to
On Wed, 05 Nov 2014 16:59:31 +0000, Deanna Earley
<dee.e...@icode.co.uk> wrote:
>Exactly, that defines the minimum API/kernel that function was available
>in, giving a definitive, "it wasn't in 32-bit XP".
Citation please? According to my information 0x0502 is Windows XP SP2
<dee.e...@icode.co.uk> wrote:
>Exactly, that defines the minimum API/kernel that function was available
>in, giving a definitive, "it wasn't in 32-bit XP".
which would apply to both 64 and 32 bit versions.
Deanna Earley
Nov 5, 2014, 12:38:59 PM11/5/14
to
From sdkddkver.h:
#define NTDDI_WINXP 0x05010000
#define NTDDI_WINXPSP1 0x05010100
#define NTDDI_WINXPSP2 0x05010200
#define NTDDI_WINXPSP3 0x05010300
#define NTDDI_WINXPSP4 0x05010400
#define NTDDI_WS03 0x05020000
#define NTDDI_WS03SP1 0x05020100
#define NTDDI_WS03SP2 0x05020200
#define NTDDI_WS03SP3 0x05020300
#define NTDDI_WS03SP4 0x05020400
XPPro 64-bit was built on Server 2003:
https://support.microsoft.com/kb/888733
> The x64-based versions are based on the Windows Server 2003 code tree.
Geoff
Nov 5, 2014, 12:44:54 PM11/5/14
to
On Wed, 05 Nov 2014 17:38:16 +0000, Deanna Earley
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383745
Which states:
Windows Server 2003 with SP1, Windows XP with SP2
_WIN32_WINNT_WS03 (0x0502)
<dee.e...@icode.co.uk> wrote:
>On 05/11/2014 17:23, Geoff wrote:
>> On Wed, 05 Nov 2014 16:59:31 +0000, Deanna Earley
>> <dee.e...@icode.co.uk> wrote:
>>
>>> Exactly, that defines the minimum API/kernel that function was available
>>> in, giving a definitive, "it wasn't in 32-bit XP".
>>
>> Citation please? According to my information 0x0502 is Windows XP SP2
>> which would apply to both 64 and 32 bit versions.
>
>Your information is wrong.
> From sdkddkver.h:
>
>#define NTDDI_WINXP 0x05010000
>#define NTDDI_WINXPSP1 0x05010100
>#define NTDDI_WINXPSP2 0x05010200
>#define NTDDI_WINXPSP3 0x05010300
>#define NTDDI_WINXPSP4 0x05010400
>
>#define NTDDI_WS03 0x05020000
>#define NTDDI_WS03SP1 0x05020100
>#define NTDDI_WS03SP2 0x05020200
>#define NTDDI_WS03SP3 0x05020300
>#define NTDDI_WS03SP4 0x05020400
>
>XPPro 64-bit was built on Server 2003:
>https://support.microsoft.com/kb/888733
>> The x64-based versions are based on the Windows Server 2003 code tree.
Which contradicts:
>On 05/11/2014 17:23, Geoff wrote:
>> On Wed, 05 Nov 2014 16:59:31 +0000, Deanna Earley
>> <dee.e...@icode.co.uk> wrote:
>>
>>> Exactly, that defines the minimum API/kernel that function was available
>>> in, giving a definitive, "it wasn't in 32-bit XP".
>>
>> Citation please? According to my information 0x0502 is Windows XP SP2
>> which would apply to both 64 and 32 bit versions.
>
>Your information is wrong.
> From sdkddkver.h:
>
>#define NTDDI_WINXP 0x05010000
>#define NTDDI_WINXPSP1 0x05010100
>#define NTDDI_WINXPSP2 0x05010200
>#define NTDDI_WINXPSP3 0x05010300
>#define NTDDI_WINXPSP4 0x05010400
>
>#define NTDDI_WS03 0x05020000
>#define NTDDI_WS03SP1 0x05020100
>#define NTDDI_WS03SP2 0x05020200
>#define NTDDI_WS03SP3 0x05020300
>#define NTDDI_WS03SP4 0x05020400
>
>XPPro 64-bit was built on Server 2003:
>https://support.microsoft.com/kb/888733
>> The x64-based versions are based on the Windows Server 2003 code tree.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383745
Which states:
Windows Server 2003 with SP1, Windows XP with SP2
_WIN32_WINNT_WS03 (0x0502)
Deanna Earley
Nov 6, 2014, 4:00:40 AM11/6/14
to
The _WIN32 values are listed as "minimum value", to guarantee that it
will be that OS level. It doesn't say that it works the other way around :(
> Note that some features introduced in the latest version of Windows
> may be added to a service pack for a previous version of Windows.
> Therefore, to target a service pack, you may need to define
> _WIN32_WINNT with the value for the next major operating system
> release.
0 new messages