DOS program methods methods to check for Windows

[IBMMuseum]

I'll have to dig some of my old code I wrote to see the order I made these calls to go through the different Windows versions (but versions like 9x would use them to block Windows 3.x & earlier from running in a DOS box). And rather than for DOS program usage they were probably design for preventing early Windows from being run recursively. Tested up through about W98SE, because that is all I had at the time, and definately not tested under any form of a VM designed to let things like this work.

Let's just toss the stuff out for comment:

INT 2F Function 1600h
"Windows Enhanced Mode Installation Check"
Registers at call:
AX = 1600h

Return Registers:
AL = Status:
00h: Neither Windows 3.x Enhanced Mode nor Windows/386 2.x running
01h: Windows/386 2.x running
80h: XMS version 1 driver installed (marked as obsolete, further details on request)
FFh: Windows/386 2.x running (see notes)
AL = anything else
AL = Windows major version >= 3
AH = Windows minor version number

Notes: I don't know why there is a duplicate entry for Windows/386 2.x running

INT 2F Function 1605h
"Windows Enhanced Mode & 286 DOSX INIT Broadcast"
Registers at call:
AX = 1605h
ES:BX = 0000:0000h
DS:SI = 0000:0000h
CX = 0000h
DX = bit flag used:
Bit 0 = 0 if Windows Enhanced Mode initialization (which is what we would use)
Bit 0 = 1 if Microsoft 286 DOS Extender initialization
DI = version number (major in upper byte, minor in lower)

Return Registers:
CX = 0000h if okay for Windows to load
CX = non-zero if Windows should not load
ES:BX -> startup info structure (more details if needed)
DS:SI -> virtual86 mode enable/disable callback or 0000:0000h

Notes: Even though this is for a TSR program to hook into (there is also an exit call), I remember the Windows hooked this itself. Can't remember if I used it (or some of the values I used), but we would look for the CX = 0 return value as evidence that Windows was not running.

INT 2Fh Function 160Ah
"Identify Windows Version and Type"
Registers at call:
AX = 1605h
BX = 0000h
CX = 0000h

Return Registers:
AX = 0000h if call supported
Then BH = major version
BL = minor version
CX = mode:
0002h = Standard Mode
0003h = Enhanced Mode

Notes: If at least Windows 3.1 (lowest version supporting the call) or higher needs to be checked, this is the call to use.

There is also DOS interrupts for VM IDs within Windows & switching VMs. Most other detection (like for OS/2) is done by getting DOS version calls, with TRUEVER & DR-DOS methods (listed later). I suppose a table could be generated for the different Windows/DOS OSes/interfaces, including whether the OS can deceive the calls, deliberately or otherwise.

 

[IBMMuseum]

[Dead silence...]


Uhhhmmm....


So does anyone at least check the version of DOS running on the system from their program (say to check for a feature not on older versions)?

 

[mbbrutman]

Dead silence ..

Happens here fairly often, unless you are in the off topic areas. ;-0

I target DOS 2.1 or better on my programs and I use fairly basic routines, so checking the DOS version is generally unnecessary.

I find that unless you are doing something fancy, that approach works just fine. For device drivers, code that works with network drives, etc. you would need to be more sensitive to version numbers.

 

[IBMMuseum]

...I target DOS 2.1 or better on my programs and I use fairly basic routines, so checking the DOS version is generally unnecessary.

I find that unless you are doing something fancy, that approach works just fine. For device drivers, code that works with network drives, etc. you would need to be more sensitive to version numbers.

What, you don't need to commonly check for the number of days in February, given the year?:

INT 2Fh Function 121Bh (DOS 3+)
Registers at Call:
AX = 121Bh
CL = year to check minus 1980
DS = CS

Return Registers:
AL = number of days in February for that year



Yeah, DOS 2 covered most of the stuff needed, with the exceptions you mentioned (Leap year calculation really isn't that hard)...

 

[mbbrutman]

I've really only done one program that worked with dates extensively, and that was to interface a Dallas clock chip to PCjr. And for that, I did my own date verification.

That project was extremely interesting. The DS1216E fits in a ROM socket on your motherboard, and allows you to put the BIOS chip that was in the ROM socket piggybacked on the DS1216E.

So the question becomes, how does one read and write the date and time to a clock chip that is in a ROM socket? And how do you do it without intefering with the normal operation of the BIOS chip sharing the same socket?

The data sheet on the DS1216E tells all ... ingenious people.

 

[IBMMuseum]

Real Time Clock information for PCs...

Real Time Clock information for PCs...

I've really only done one program that worked with dates extensively, and that was to interface a Dallas clock chip to PCjr. And for that, I did my own date verification.

That project was extremely interesting. The DS1216E fits in a ROM socket on your motherboard, and allows you to put the BIOS chip that was in the ROM socket piggybacked on the DS1216E.

So the question becomes, how does one read and write the date and time to a clock chip that is in a ROM socket? And how do you do it without intefering with the normal operation of the BIOS chip sharing the same socket?

The data sheet on the DS1216E tells all ... ingenious people.

Yes, I looked over your PCjr pages & really liked what I saw. Good job. I've got a few of these units myself & really want to try some of the upgrades.

On one of my PS/2 Model 25 8086 (the only PS/2 without an RTC stock) I found one of these Dallas units. Kind of neat, but (as you commented) very expensive for the new part. And what do you do when the battery dies?

Prior to Y2K I did some testing of various PC RTC behaviors. Purely from a hardware standpoint, not any corrections that software, including OSes, made. There is three major areas: Y2K problems, leap yeap calculation, and Daylight Savings "bugs".

The Y2K "bug" (on the RTC hardware level) stems from the original Motorola 146818 clock functions tracking the two-digit year value ("00" to "99"), but leaving it up to the designer that would use the chip to plan for storing the century value. IBM picked a byte location in the CMOS RAM storage area (that mostly held the configuration information of the system) to store the century value for the IBM AT, and most clone designers followed suit.

A few of the Dallas chips are battery-backed versions of the Motorola chip, with other companies also incorporating the features into their own chips & chipsets (like the 82C206), almost all with the same problem areas. A few fixed the Y2K issue (actually it would happen every 100 years, or is in reality a "Century Byte Bug") later on their parts, but IBM had also changed the century byte location on most of the PS/2 models in the meantime, compounding the problem for some (like me).

Amazingly the Model 30 8086 (lowest level of PS/2 with an RTC) doesn't have this problem because it uses another type of clock chip, the National Semiconductor 58167. This is on most of the XT adapters that add an RTC, like the AST cards. Quite funny when older technology behaves better than new.

Since the 146818 & its clones didn't keep track of the century they also consider every year evenly divisible by four as a leap year (and the DOS interrupt given above could correct for that). This would have not held up for the year 2000, because the rule is actually if the year is evenly divisible by four, but not four hundred (ie 1600, 2000, 2400 are not leap years). For a problem only occuring every 400 years it can probably be ignored.

The "Daylight Savings Bug" has been human-induced. There is a bit to control whether the 146818 chips adjust for Daylight Savings Time on the chip itself. When the chip was designed, DST was changed on the last Sunday of April & October. But President Reagan changed that (for the United States) in 1986 to be the first Sunday in April instead (and the chip adjusts on the wrong date now).

It will change again (for the United States again) next year (2007), becoming the second Sunday in March, and the first Sunday in November. That change is not yet regarded as permanent, as a study will be done to see if it saves more energy dollars. Probably a good thing that DST is tracked fully in software now (an old bug of DOS would turn the DST-changing features of the 146818 & clones off if the DATE command was used anyway).