HIGHESTNUMANODENUMBER

[npocmaka_]

HIGHESTNUMANODENUMBER is an environment variable in command prompt which I suppose implements:

http://msdn.microsoft.com/en-us/library ... 03(v=vs.85).aspx

Strangely I can't see it even with

Code: Select all

SET "

(can anybody else can?)

but these works:

Code: Select all

>echo %HIGHESTNUMANODENUMBER%

>if defined HIGHESTNUMANODENUMBER echo defined
defined

I have no idea which windows versions have it (mine is win8 and it is here) - according to this :

Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: Processor groups are not supported.

But in the first link is written:

Minimum supported client
Windows Vista, Windows XP Professional x64 Edition, Windows XP with SP2 [desktop apps only]
Minimum supported server
Windows Server 2003 [desktop apps only]
Header
WinBase.h on Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 (include Windows.h);
Systemtopologyapi.h on Windows 8 and Windows Server 2012

[foxidrive]

It exists in Windows 8.1 32 bit Eng

Code: Select all

c:\>echo %HIGHESTNUMANODENUMBER%
0

[npocmaka_]

It exists in Windows 8.1 32 bit Eng

Code: Select all

c:\>echo %HIGHESTNUMANODENUMBER%
0

Thanks for the reply.But can you see it in set " output?

[foxidrive]

It exists in Windows 8.1 32 bit Eng

Code: Select all

c:\>echo %HIGHESTNUMANODENUMBER%
0

Thanks for the reply.But can you see it in set " output?

Negative.

[Squashman]

There are few environmental variables that you can not see from running the SET command.

[npocmaka_]

There are few environmental variables that you can not see from running the SET command.

I know but I thought that all of them can be seen with set "

I don't know about other that cannot be seen in that way.

[Squashman]

There are few environmental variables that you can not see from running the SET command.

I know but I thought that all of them can be seen with set "

Your reply contradicts itself.

[npocmaka_]

ok.

cmdcmdline ,random ,time , date ,cd are dynamically generated and not seen in SET output.

Suppose HIGHESTNUMANODENUMBER is dynamically generated which fit in the description given by MS

[foxidrive]

ok.

cmdcmdline ,random ,time , date ,cd are dynamically generated and not seen in SET output.

Suppose HIGHESTNUMANODENUMBER is dynamically generated which fit in the description given by MS

I wonder how many other variables are hidden that way...

[dbenham]

I've been fascinated by dynamic variables for a while. My testing shows there are 3 distinct classes of dynamic variables: http://stackoverflow.com/a/20169219/1012053. I recommend reading the entire link, but below is a very brief summary that excludes some of the more interesting details.

1) Normal looking "variables" without any prefix or suffix that can be overridden.

I believe HIGHESTNUMANODENUMBER can be lumped into this class

Other examples include ERRORLEVEL, CD, DATE, TIME, etc.

2) Dynamic variables prefixed with =
These values cannot be overridden except by another process outside of CMD.EXE

Examples include =C: =EXITCODE =EXITCODEASCII

Then there is the mysterious =:: which exists on some machines, and not on others: viewtopic.php?p=8231#p8231

3) The unique variable __C__

This baby is really wierd. An override value can be defined, but not accessed, except via SET or SET /A EDIT: This is true on Win 7 and Win 8, but not true on XP. Not sure about Vista


Dave Benham

[penpen]

I think that the environment variable cmdcmdline should be in its own category (named "Heisenberg Variables"), too.
It's the only one that could vanish, when accessing only parts of it, and it stays always defined:

Code: Select all

echo %cmdcmdline%
echo %cmdcmdline:~1%
echo %cmdcmdline%
echo %cmdcmdline:~1000%
if defined cmdcmdline echo Cmdcmdline is still defined.

penpen

[dbenham]

Oooh, I forgot about that nasty CMDCMDLINE behavior

I think I would classify it as 1A instead of a totally new class unto itself. It has all of the behaviors of all of the other class 1 variables, but it also has a unique "feature" that causes the value to be permanently changed if substring or search/replace operations are performed during expansion.

I think the underlying mechanism for CMDCMDLINE is the same as all the other class 1 variables, except I believe there is an implementation bug. I suspect the code to get the dynamic value is supposed to provide a pointer to a copy of the string, but %CMDCMDLINE% returns a pointer to the original string instead. So value manipulation ends up being destructive.

It does not surprise me that IF DEFINED CMDCMDLINE returns true after the value has been erased by %CMDCMDLINE:~1000%. I think it is still pointing to a valid memory address, but the string shows as empty because of a null byte at the first position.

Of course, all of this is only an educated guess


Dave Benham

[aGerman]

Dave

Were you able to follow Magoo's (SO) assumption that __CD__ could be related to the ~f modifier of FOR variables?

Regards
aGerman

[dbenham]

I think I understand his suggestion, but it is purely speculative.

When a FOR variable (call it %%V) does not include a full path, then %%~fV must access the current directory information to establish the full path. He is speculating that the virtual __CD__ variable is used to get the current directory. I don't see any reason to suspect that, but I suppose it could be true.

Perhaps it could be tested on XP, but I no longer have access to XP. If you look at the comments to MC ND's answer you will see reports that ECHO %__CD__% does echo a user supplied value, if it exists.

Take the following code:

Code: Select all

@echo off
setlocal
set "__CD__=z:\bogus\"
pushd c:\
for %%A in (test) do echo %%~fA

On my Win 7 machine I get c:\test

If Magoo is correct, then I think XP should produce z:\bogus\test.

My guess is that XP will not give that result, but who knows


Dave Benham

[penpen]

My interpretation of what Magoo has written differs a lot!
I think he said(in other words): The "for" command needs the dynamic variable in order to work correctly.

And in addition i think Magoo predicts, that "c:\test" is returned in your above example, although the static environment variable __CD__ is set to "z:\bogus\".

SET __CD__ to whatever you like, the current dirname will STILL be echoed.
PUSHD someconvenientdir before that FOR and someconvenientdir will be echoed.
SET CD=bogus and the current directory will be echoed (...)

After using "PUSHD someconvenientdir" someconvenientdir is the current directory.
=> Prediction: The current (real) directory is returned no matter of the value in the static environment variable:

~f will use %__CD__% NOT from the environment where the directoryname isn't explicit

Btw: Using your above example, Windows XP returns "C:\test".

penpen

Edit: I've changed the first (misleading) part, so it should be more clear.