Detecting NT from DOS

[Bernard Chapman]

1. Is there any way to detect whether NT is running from PBDOS?

2. Am I correct in assuming that there is no way to get total disk size of a large HD FAT16 partition under PBDOS?

Interrupt 21H Function 36H has problems.

TIA

Bern

[Bernard Chapman]

1. A search revealed a contribution from Scott Turchin last year which relied on ENVIRON$("OS") which seems to do the trick. I must admit though I feel a bit uneasy about the use of environment variables as they can so easily be altered by any program.

Thanks Scott

[Matthew Berg]

Is there any way to detect whether NT is running from PBDOS?

I was about to suggest INT 2Fh function 1600h but I've just checked it under Windows NT and the function determines that "Windows" is not present! Oh well...

Am I correct in assuming that there is no way to get total disk size of a large HD FAT16 partition under PBDOS?

Interrupt 21H Function 36H has problems.

What do you mean by "large FAT16 partition"? Under DOS/Win 3.xx/Win 95, FAT16 partitions are limited to 2GB. Windows NT supports FAT16 partitions up to 4GB.

Under DOS & Win 3.xx, any call to INT 21h function 36h is incapable of returning correct information for volumes larger than 2GB. A call to this function under Windows 95 will be artificially limited to 2GB (for backwards compatibility) if used on a volume larger than 2GB. There is the "GET EXTENDED FREE SPACE ON DRIVE" function at INT 21h subfunction 7303h, but it is listed as being available only under Windows 95 for use on FAT32 partitions.

If you want to get the total size, not free space, of a "large" volume, I recall reading a usenet post which suggested that you could read the partition information at the start of the HDD which would provide the start and end clusters of the partition(s). This information could then be used to calculate the total size of the partition(s) regardless of the OS. Haven't tried this myself though.

For more information, read articles Q127851 and Q118335 in the Micro$oft KB.

[Lance Edmonds]

What value does the DOS version interrupt return under NT? (I don't have NT here to test with)

print DosVer!
FUNCTION DosVer! LOCAL PUBLIC
REG 1, &H3000
CALL INTERRUPT &H21
DosVer! = REG (1) MOD 256 + (REG (1) \ 256) / 100
END FUNCTION

Lance
PowerBASIC Support

[Mike Luther]

Lance..

For your information, if it matters, the routine, when used
with OS/2, returns the number 20.4 for a pure OS/2 DOS-VDM
session. I think that is supposed to mean DOS version 20,
running under OS/2 Warp Merlin 4.0 ....

However you should also note that OS/2 can be asked to
re-configure its emulation of DOS and style it as any other
version of MS-DOS that has been produced! You may, for any
given program, set it up so that DOS will be emulated as
and reported to that program, as any version you like!

Very, very few programs need that service in my experience.
I haven't tested your routine with restrictive emulations,
but I suspect that if I told OS/2 I wanted DOS 6.20, for the
session, I would see it come back with 6.2 or whatever it
does with actual 6.20.

Gee, if the *IS* some reason that PB has to know it is running
under a specific DOS or DOS range, and not Caldera DOS or
whatever ... PLEASE let me know. I've never known that...
plus think I can handle the emulation restrictions, if it's
needed!



Mike Luther
[email protected]

[Lance Edmonds]

Mike, your comments are quite valid, but... in all of the years I've been working on/at/for clients' sites, I have never once come across a single PC that has had the version information "fiddled" to report a non-original version ID. Outside of some retail POS installations and some banking installations, I've never come across any other business/commercial users in my "domain" that are using OS2 either
Out of curiousity... how many others (apart from you) that frequent this BBS use OS2? How many of their clients? I would be interesting to get some idea of the penetration of OS2 at this time (1999).

BTW, I posted the above code in response to the original question at the top of this thread, followed by Bern's comment about disliking querying environment variables... While no-one has yet posted any results from an NT box, it may be a YAM (Yet Another Method) of determining if NT is running (maybe used in conjunction to the "OS" environment variable)... afterall, you can't restart in plain DOS mode on a pure NT box!
Also it should be noted that Novell DOS 7 also uses the "OS" environment variable too... "NWDOS" was a common value for this.

AFAIK, PB's only restriction with DOS is it must be Version 3.3 or better.

Lance
PowerBASIC Support

[Matthew Berg]

What value does the DOS version interrupt return under NT?

I tested the DOS version number functions under Windows NT, with the following results:
INT 21h, function 30h "GET DOS VERSION" - 5.00
INT 2Fh, function 3306h "GET TRUE VERSION NUMBER" - 5.50

I also came across INT 2Fh, function 1602h "GET API ENTRY POINT". A call to this function under Windows 3.11 and Windows 95a returned a valid address. Under DOS 6.2 and Windows NT Workstation v4, it returned a null (0000:0000) address.

Interestingly, when I typed the "ver" command at an NT "DOS" prompt, it reported "4.0" as the version. This may be because the "DOS" prompt is actually a console application, in which case it would have access to the Windows API to call the GetVersion() API function.

[Mike Luther]

Yes, Lance, I do understand!

LE> In all of the years I've been working on/at/for clients' sites, I
LE> have never once come across a single PC that has had the version
LE> information "fiddled" to report a non-original version ID.

Many DOS programs, especially network operations programs with which
OS/2 must maintain 'heritage' compatibility, have to report specific
version numbers. For example the last two in the 'standard bag of OS/2
tricks' get reported:

WIN200.BIN,10,10,4
SHARE.EXE,5,00,255

That means OS/2 reports to WIN200.BIN a DOS level 10.10, subversion 4.
Bet you maybe didn't realize that certain versions of SHARE.EXE have to
be told the correct version of DOS that is used! In this case we have
to tell 'SHARE' (Which one? Grin!) that it is running under DOS version
5.0, subversion 255, in order for OS/2 to cooperate with what 'share'
provides under certain uses for it..

We have to note that OS/2 is expected to operate 'seamlessly' with all
the NETBIOS stuff, TCPIP, Novell stuff, WIN-95-98 and even NT, as
well as the whole IBM-LAN Manager and PEER deal! From a server point
of view OS/2 is expected to and can interface with *ALL* of them out
of the same box! (And does!)

OS/2 is 'expected' to provide for virtually all heritage apps. It,
chortle, failed, to a great degree, to provide for perfect timing with
many games! The emulation of DOS is superb, but, unfortunately, it
runs much faster than pure DOS, and many of the games simply were and
are un-playable on it!

Us OS/2 folks were Doomed from the start, seems!

LE> Outside of some retail POS installations and some banking
LE> installations, I've never come across any other business/commercial
LE> users in my "domain" that are using OS2 either

I don't find that surprising. More important, I don't mean that to be,
in any way, a snide comment of any sort. OS/2 isn't something the
run-of-the-mill computer user either has knowledge of, nor use for, nor
is wanted, in any way, by IBM .. They really don't want you or me
around even asking questions! We are pests to them! (Maybe like I
may be to ya'll!)

LE> Out of curiousity... how many others (apart from you) that frequent
LE> this BBS use OS2? How many of their clients? I would be interesting
LE> to get some idea of the penetration of OS2 at this time (1999).

My guess is that there are very few. I would be surprised if more
than about 2% of your BBS users are OS/2 shops, if that. However, to
address-align your comment, I'd like to post some numbers that were
released by John Thompson of IBM, of, what I recall were 1997 total
performance figures for IBM, Microsoft, and Oracle which may help
'define' these things you and many other don't get a chance to see and
don't show up well.

It isn't how many boxes things are deployed upon that counts, it also
has to do with what kind of boxes they are deployed that one doesn't
get a chance to see that may mean things...

That said, let's note Thompson's published statements about all this.
Recall that IBM really doesn't talk much at all about things like this.
I was dumbfounded to see it come out. Thompson, by the way, is, as
best I know, the one and same guy who was just shifted to Presidency
of Symantec which IBM bought recently .. chuckle.

He noted that in that year, IBM grossed over 71 Billion world-wide.
He also noted that for the same period, Microsoft's total gross revenue
was some 7.6 Billion world-wide. As well, the third largest vendor was
Oracle, having bumped the year before Computer Associates into forth
place with what was noted to be Oracle's 6.8 Billion. He then
commented that OS/2 was responsible for out of that 71 Billion gross
for IBM, over 17 Billion worth of revenue, world-wide, for IBM.

That, per IBM, was a statement that OS/2 was worth more to IBM, than
the entire revenue of Microsoft and Oracle put together ...

Surprised?

IBM refuses to discuss, much, the issue.

Despite your exposure to it, and, for that matter, all but a very tiny
percentage of the computing professional public, that's one heck of a
lot of chow for a puppy, Lance.

Actually, Microsoft gets, so said, a fair chunk of royalty change on
certain aspects of OS/2. Not a, so said, favorite subject with IBM.

Since that time, it's only been intimated, that the issue hasn't really
changed much inside IBM. We think IBM wishes the whole issue would go
away; it won't. Even, per my ex-next door neighbor whom now works
in the IBM data storage farms doing OS/2 driver work, much of their
whole internal operation is still solidly tied to it. In his case,
he is talking about buildings (many!) larger than a football field,
which have relay rack row after relay rack row of tape units holding
archival and data-mining storage for professional clients. I asked
him, once, whom would patronize such a thing? He mumbled something
like, "Oh, all the old well logging data in the whole world in the
Schlumberge library, for example!" Further, affiant sayeth not...



Worse, the contracts just keep on getting bigger and bigger, and going
further on into the future. Bank of Brazil's reported $6,000,000
single software sale for OS/2 with a guaranteed six-year support run
was the largest single software sale of the year in 1998 (7?). The
Rockwell Collins OS/2 world-wide C2 level secured voice server system
to the USAF, two years ago, was, so revealed by our board vendor, a
ten-year run.

C2 .. Not just two machines for WIN NT 3 years ago, the whole network,
so said...

Recall that Dave Navarro has posted here he is, more or less, just in
the beginning stages of working with WIN-NT 4.0 .. and of course, now
2000 whatever it is...

From what I gather, PowerBASIC isn't six to ten years deep into all
this stuff at this point. Many vendors are, but they aren't,
necessarily, those you and I will see in our travels! Further, they
aren't expected to be. There is, as you note, virtually no mass
market into this world of this stuff in a general sense and, frankly,
Bob Zale and crew have done a beautiful job with PowerBASIC, in my
somewhat, I guess, un-wanted opinion, at this. They have targeted
well and well-addressed what a respectable number of people have bought
and, are, pleased with, with the PB products.

I work with OS/2 because it has saved my a great deal of time and
misery in handling my problems. It's terribly flexible for DOS work.
My clients are still DOS, will be, it seems for a good while yet, or
will go to LINUX or JAVA, perhaps, if that can be done.

You simply can't afford to take down a facility for Mellissa, CIH, or
anything like that, nor afford, as they see it, to have a medical record
pushed clandestinely, or whatever, all in the name of what the mass
market people share for a fascination with disaster!

So too, part of this is driven by Y2K and Euro guarantees. IBM is
specific. The whole shooting match has been Y2K and Euro certified
since about October of last year, Lance.

That's important.

I cannot certify Y2K for my work, on any system in which the operating
system is not also Y2K! As far as I can tell, neither can anyone else.
To solve the Y2K problem in the time frame allotted *LAST* year, it is
my understanding that Nation's Bank here took a reported 250,000 seats
of OS/2. It was revealed that, I'm pretty sure, it was Bank of Ohio
which took some 70,000 more. The same source indicated that Boeing
Aircraft, for certain of their operations took 60,000 seats. A close
associate's son is a key troubleshooter for Boeing in the computer
game here in Texas. Their only hope with WIN-NT was to gain access to
the source and custom modify all of NT 4.0 to even get close to a
temporary solution and they have, so I'm told bounced all WIN-98 from
the place as unacceptable.

It was reported that Diamler Benz, with no other choice for mission
critical requirements and the future, had to totally covert to OS/2
late last year and, you might remember that Benz just bought Chrysler.
That should tell you something else. As well, to my understanding,
the entire Ford operation, world-wide, is solid blue and .. OS/2 .
I doubt if you or I will tear up a Ford car computer, world-wide,
just to get at the embedded kernel. I'd really like to know the
answer to that, but ... smile, even if I had the tools and could
do that job with my skills, they get a fair chunk of change for
that little embedded puppy!

It's reasonable knowledge that a substantial part of the whole US
railway industry runs on OS/2. In specific, it's been published that
the entire Burlington-Northern Santa-Fe combine does so, as well, as
I was recently told, does the whole Union Pacific combo..

As well, the entire Bank of Spain, I think, both Singapore and HongKong,
the Union of South Africa and most of the lower half of South Africa
have all been banked and captured in passing by IBM ...

LE> BTW, I posted the above code in response to the original question at
LE> the top of this thread, followed by Bern's comment about disliking
LE> querying environment variables...

I understand. I was simply curious, not only to what your function would
report from OS/2, but if it, indeed, OS/2 can prang the result! Grin...

LE> While no-one has yet posted any results from an NT box, it may be a
LE> YAM (Yet Another Method) of determining if NT is running
LE> (maybe used in conjunction to the "OS" environment variable)...
LE> afterall, you can't restart in plain DOS mode on a pure NT box!

Indeed!!!

LE> Also it should be noted that Novell DOS 7 also uses the "OS"
LE> environment variable too... "NWDOS" was a common value for this.

Plus, don't leave out Caldera's latest incantation of all this!

LE> AFAIK, PB's only restriction with DOS is it must be Version 3.3
LE> or better.

Yes, but then .. chuckle, that's saying, sort of that it must be MSDOS
Version 3.3 or better.. When we start to joust about which versions
of EMM-396 are blinko and all that, the customers really seem to be
entitled to some of the intelligencia about the product, I opine.

That means your contribution and all of this is relevant, I think!

Mike Luther
[email protected]

[Bernard Chapman]

Lance,

What value does the DOS version interrupt return under NT?

FWIW like Matthew I also get 5

Seems like ENVIRON$("OS") is not so bad after all. I'll accept the small risk that someone may have fiddled with the environment variables.

Thanks,

Bern

[Matthew Berg]

I may have found a way to detect whether or not a DOS program is running under Windows NT. It involves checking a memory location at the top of base memory. The following code demonstrates this:

DIM lpLoadAddress AS DWORD PTR

LET lpLoadAddress = &H00000600
PRINT "DOS 1 load address: "; LEFT$( RIGHT$( "0000000" + HEX$( @lpLoadAddress ), 8 ), 4 ) + ":" + RIGHT$( "000" + HEX$( @lpLoadAddress ), 4 )

The memory location holds the "MS-DOS 1.x LOAD ADDRESS". I've tested it in DOS v6.2, WFW v3.11, Windows 95, and Windows NT Workstation v4. Under all environments except NT, it returned a "valid" (non-null) address. Under Windows NT, it returned a null (0000:0000) address. I have not been able to test it in Windows 2000.

Unfortunately it can't be used to determine the version of NT in use, but hopefully this information should still be useful.

[Mike Luther]

Matt ..

Not sure how valuable it will be.. For curiousity, I
also tried this one in an OS/2 DOS-VDM session ..

There it also returns:

DOS 1 load address: 0000:0000

Thus, a party using the technique couldn't determine,
at least on the basis of this one, whether the box
were running WIN-NT or OS/2 ....

Mike Luther
[email protected]

[Matthew Berg]

If you are concerned about OS/2, you could check the OEM number with INT 21h function 30h. Under all the platforms I have available, a call to this function (correctly) returned a value of FFh (the Micro$oft OEM number). Of course this method would likely run into problems with IBM's PC-DOS.

%AX = 1 : %BX = 2 : %CX = 3 : %DX = 4
%SI = 5 : %DI = 6 : %BP = 7 : %DS = 8
%ES = 9 : %FLAGS = 0

REG %AX, &H3000
CALL INTERRUPT &H21
PRINT "OEM #: "; LEFT$( RIGHT$( "000" + HEX$( REG( %BX ) ), 4 ), 2 )

Or, you could use INT 2Fh, function 4010h "OS/2 v2.0+ - INSTALLATION CHECK / GET VERSION". See Ralf Brown's Interrupt List for further information on this function.

That must cover just about all the bases, eh? Don't even get started about DOSEMU under Linux, or other such systems...

[Mike Luther]

Matt ...

FWIW I added your first suggestion to the test bed for PB in OS/2
DOS-VDM sessions. It returns a value of zero (0) under Warp 4.0
Merlin.

I also coded in the OS/2 specific interrupt routine, just to see
what would become of that. In Warp 4.0 Merlin, the AX register,
indeed, has been reset to zero (0), ostensibly confirming that
OS/2 is, indeed loaded. The interesting part, is that version
number for OS/2. which, per this routine that showed up back in
version 2 of OS/2, should return the version number for OS/2 in
the BX register, returns decimal 5160 under PB 3.5 for DOS? That,
when run from a 4.0 system .. ?

We're slowly collecting all the trivialities which could let one,
I guess, really determine under which operating system PB 3.5 was
actually running. I still don't know why it should be so horrible
to have OS/2 able to conform 'DOS' to whatever flavor (at least
of those IBM has let us!) maight be needed for a particular
program.

Actually, per the original post here, when we get back an
'unmolested' response to the DOS version via Lance's suggestion,
there is a 'meaning' to the 20.4 that is returned. Somewhere
in the fog, I think that the 20 is related, somehow, to OS/2 and
DOS under IBM and, maybe the 4 is related to version 4.0 of
OS/2 ..

PD7 can compile some versions of native CODE under OS/2 as well
as DOS executables. I'll try to get time, just for funzy, to
see what Lance's suggestion does under PD7 compiled under OS/2
and reports! I wonder if we get back the same 20.4 under that?

One really, grin, ought to be objective about all this! Maybe,
a la eastern philosophy, all operating systems are just a dream,
and this is all our imagination, anyway!

Smiley

Mike Luther
[email protected]

[Matthew Berg]

I added your first suggestion to the test bed for PB in OS/2 DOS-VDM sessions. It returns a value of zero (0) under Warp 4.0
Merlin.

... and 0 just happens to be the OEM number for IBM.

If you are interested, I posted some code to the Source Code forum that attempts to determine the OS platform and version. However, in light of your results for my second suggestion (the OS/2 installation check function), it looks like my code will incorrectly determine the OS/2 version number. Hopefully it should at least be a starting point for those that want/need to know the OS platform and/or OS version their program is running on.

Really must get around to installing OS/2 on my PC...

[Mike Luther]

Matt ..

I posted the following in the porting usegroup:

**************

Is there a better way to determine the presence of OS/2 and the correct
version number than Ralf's:

INT 2Fh, function 4010h "OS/2 v2.0+ - INSTALLATION CHECK / GET VERSION"?

When run in PowerBASIC 3.5 for DOS, it does return the "0" in the AX
register, but the BX register contains the number "5160" and that isn't
Merlin 4 (?) which is running.

Or, does something else need to be done to the 'return' value to get us
back to version 4 or 3 or perhaps even 2?

Alternatively, is there a completely different better way to do this?
If we use the function suggested by Lance Edmonson:

print DosVer!
FUNCTION DosVer! LOCAL PUBLIC
REG 1, &H3000
CALL INTERRUPT &H21
END FUNCTION

we get the 'correct' 20.4, but I think that can be pranged in a DOS-VDM
session if the session settings have be chosen to report a specific DOS
version as is necessary for some versions of SHARE.EXE and so on...

*************

It really would be nice to be able to have a catchall routine to
determine what operating system and version is in use. Adding that
together with video mode determination and so on seems useful.

Mike Luther
[email protected]

[Eric Pearson]

> It really would be nice to be able to have
> a catchall routine to determine what operating
> system and version is in use.

My company's new DOSBox product (which is available as free Shareware) includes a function that a DOS or console program can use to obtain the exact version of Windows that is being used, right down to the build number, with 100% accuracy. DOSBox can also be used in a batch file, and it will return an errorlevel that indicates the "basic" version of Windows... 95, 98, NT4, 2000, or ME. (If it is possible that Windows is not running you have to perform another test first, but DOSBox can do that too.)

> video mode determination and so on

DOSBox can tell you that too, and lots more!

For more information about how DOSBox can allow DOS programs to access many different "Windows only" functions...

http://www.perfectsync.com/DOSBox.htm

-- Eric

DOSBox can also report the current screen resolution, the size of the console window, etc.

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Scott Turchin]

I just tested my environmental variable and changing it.
Yes you CAN change it, temporarily, from an application.
Will it stay changed?
No.
I changed it to Windows 98, and after I exited the DOS box and opened a new one this is what I got.
Windows_NT

My Inter-sceptre for Dos program uses this and I've never had a problem, I ran it on NT for a while (Unreliable modem activity however because of our buddy HAL).

For what it's worth here's my environmental variables in NT 4.0, SP6

Also note, this machine is behind at least 4 firewalls and is NOT physically possible to get to it at this point in time, so please don't try.


CLASSPATH=C:\JAVA\LIB\CLASSES.ZIP
COMPUTERNAME=XXX
ComSpec=C:\WINNT\system32\cmd.exe
DIRCMD=/OG
HOMEDRIVE=C:
HOMEPATH=\
INCLUDE=C:\Program Files\Mts\Include
LIB=C:\Program Files\Mts\Lib
LOGONSERVER=\\XXX
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Os2LibPath=C:\WINNT\system32\os2\dll;
Path=C:\;C:\WINNT;C:\WINNT\SYSTEM32;C:\CMD;C:\PROGRA~1\E!PC;C:\JAVA\BIN;C:\Program Files\Mts
PATHEXT=.COM;.EXE;.BAT;.CMD;.JS;.VBE;.JSE;.WSF;.WSH;.VBS
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 5 Stepping 2, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0502
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT
TEMP=C:\TmpFiles
TMP=C:\TmpFiles
USERDOMAIN=XXXXXX
USERNAME=xxxxx
USERPROFILE=C:\WINNT\Profiles\xxxxx
windir=C:\WINNT


------------------
Scott
mailto:[email protected][email protected]</A>

[This message has been edited by Scott Turchin (edited July 11, 2000).]