about int 21h

[qWord]

hi all,
My question is about the interupt 21h (aka as DOS interupt). AFAIK microsoft has introduced this interrupt for their MS-DOS API. However, for me it seems like you can use this interupt also if no OS (MS-DOS) is installed. My question is if it is ensured that the DOS interupt is available on each x86 System (is there some standart?).

qWord

[BogdanOntanu]

hi all,
My question is about the interupt 21h (aka as DOS interupt). AFAIK microsoft has introduced this interrupt for their MS-DOS API. However, for me it seems like you can use this interupt also if no OS (MS-DOS) is installed. My question is if it is ensured that the DOS interupt is available on each x86 System (is there some standart?).

qWord

No, it is not present. it is installed by the OS (aka MS-DOS or some sort of clone)

Anyway this is old and kind of obsolete technology....

[qWord]

hi,

No, it is not present. it is installed by the OS (aka MS-DOS or some sort of clone)

Anyway this is old and kind of obsolete technology....

that confirm my assumption  :bg
Just curios, over the years I've seen many people propagating the int 21h as a part of the BIOS ... or maybe I've missunderstood them.

qWord

[dedndave]

originally, they went something like this...

Code Select Expand

INT    Use
00-0F  hardware
10-1F  BIOS
20-2F  DOS

examples...
0, of course, is divide by 0
9 is the hardware interrupt generated when a key is pressed
10h is the BIOS video service interrupt - quite often revectored by BIOS on old video cards
13h is the BIOS disk services routine
16h is the BIOS keyboard service interrupt
20h was old DOS terminate
21h is most of the DOS function dispatcher

during boot, most of INT 21h is not loaded
so, if you are writing a .SYS driver, you had to be careful about which functions you used
i think DOS 1.0 did not support .SYS drivers - lol
early DOS had almost nothing loaded at that time
later versions had most of the keyboard and display routines up and running

even on modern systems, you may see remnants of DOS structures and support routines
with protected mode, it is hard to know what is going on down there   :bg

it is interesting to note that parts of DOS were based on CP/M
so, certain aspects of CP/M still exist
much of the PSP segment that is still supported when running 16-bit programs is similar to CP/M

[allynm]

Hi Dedndave,

So, 'Dave, my follow-on question is:  where are the various "int's" now in my protected mode 32 bit machine?  Is my OS simply "emulating them" when I write a 16 bit program and call int 21h, or are they really stashed somewhere down there in a black hole inside NTDLL?  Or maybe even in some Ring 0 cave?

I liked your quick summary.  Very informative.

Regards,
Mark Allyn

[redskull]

Trying to execute an INT in 16-bit code does the same thing as 32-bit code; it causes an exception.  The only difference is that the NT trap handlers are hard-coded to test whether the faulting process is NTVDM, and if it is, it manually calculates the address to jump to (the old-style IVT inside the dos programs virtual memory), and returns execution to there.  Once back in NTVDM, it's the 16-bit NTDOS.SYS (loaded implicity when you start a 16-bit program) that executes a super-secret opcode to signal NTVDM to do the appropriate protected-mode API call.

-r

[dedndave]

well - i have to assume that some of the BIOS and hardware interrupts are running   :P
i have no experience with win32 use of vectored interrupts - haven't dug that deep
but - you have the right idea - much of what runs in 16-bit mode under NTVDM is emulated

[FORTRANS]

Hi,

   Interrupts are handled by the service routines pointed to by
the Interrupt Vector table in real mode (IVT 16-bit) or the
Interrupt Descriptor Table in protected mode (IDT 16 or 32 bit).
Windows (or other OSes) supports real mode programs with an
emulator.  DOS Int 21H interrupts are intercepted and fed to the
emulator (NTVDM in Windows).  All of the hardware interrupts
are still running and being serviced under Windows.  But user
mode Windows programs are not really allowed to play with
interrupts directly (there are exceptions, but mostly not very
relevant).

Regards,

Steve N.

[MichaelW]

well - i have to assume that some of the BIOS and hardware interrupts are running   :P

The hardware interrupts have to be running, but AFAIK nothing of the real-mode BIOS is.

Although not interrupt related, this did get me to thinking about what I had previously seen, with the aid of WinIo, of the bottom of physical memory as viewed from a Windows app. Under Windows 2000 WinIo can be used to access the bottom 1MB of physical memory. Under Windows XP only the bottom 4096 bytes is accessible. So I set out to create a Windows console app that does a hex-ascii dump of the bottom 4096 bytes of physical memory. WinIo has been updated to version 3.0 some time recently, and while I did not have time to get all of it working, I did get far enough to do what I needed to do.

On my test system, running Windows 2000, the dump of low memory looks like a dump of the same memory under DOS, with the major difference being that everything (e.g the BIOS tick count, key buffer, etc) is static from run to run.

For a dump from a 16-bit DOS app running under Windows, the things that you would expect to be changing, from run to run, are changing. And another difference is that the words that store the base I/O addresses for the serial and parallel ports are fully populated (and IIRC all of the ports are at least partially functional).

So it would seem that the contents of low physical memory are just leftovers from the boot process, but why preserve them?

The WinIo MapPhysToLin function "maps a region of physical memory into the linear address space of the application". Since the physical memory is mapped, in addition to being read it can be written, and at least under Windows 2000 the value written will persist from run to run. So I selected a byte in the BIOS data area that is normally unused, linear address 4A1h, and added code to toggle the byte between 0 and 1. I then created a small 16-bit DOS app that reads and displays this byte. Surprisingly, the DOS app can see the current value. Debug can see it too, but only the value as it existed when Debug was started. And Debug can change it, but the change does not appear in the physical memory, will not persist from run to run of Debug, and my DOS test app cannot see it.

So it looks to me like the low memory is being preserved for use as a pattern, from which the memory for each DOS session is copied (with modifications).

Code, import library, EXE, etc in the attachment, but to actually run it you will need winio32.dll and winio32.sys, available in the download from the link above.

[dedndave]

i am sure much of it has been revectored
but it is a safe bet that the OS saves most of the original BIOS vectors in data and branches through them
the BIOS code standardizes the interface for hardware that may have slight variations from machine to machine

[MichaelW]

I don't know about the recent BIOSs, that I have been told have some protected mode support, but I seriously doubt that Windows calls any real-mode BIOS code other than possibly during its initialization.

[dedndave]

i think it has to, Michael
a case in particular that comes to mind is the keyboard interface
while most machines share common design philosophy, there are a few out there that do not

the video card is another example
the BIOS code that exists on add-in video adapters varies greatly from card to card
the OS is obliged to use at least some of the functions, even after init

[MichaelW]

The hardware manufacturers pretty much have to provide drivers for Windows, or otherwise they can't sell their hardware.

[FORTRANS]

Hi,

   The Windows NT series almost certainly does not use the real
mode BIOS.  NT started out as "OS/3" when MS and IBM were
working together, and OS/2 does not use the BIOS except for
some kludges to get around Dave's hardware differences.  And
those require separate drivers at times!  Michael's last comment
is exactly what I see in practice.  The hardware is standard enough
to boot, than the OS  supplies its own "drivers" for everything.

Cheers,

Steve N.