Using DOS ints in Windows XP

[Todd]

First, a little background - I am 65 and retired, and haven't written a legitimate line of code in 20+ years. But once the bits, bytes, and Boolean algebra get in the blood...well, here I am continuing to play around with programming. I wrote a lot of code back in the DOS days, assembly language being my favorite, so in an effort to recapture some of the fun back in the Glory Days (that's what old people are always trying to do) I want to find out about doing assembly language in the Windows world. Hutch, by the way, has done a wonderful job with MASM32 and this MASM Forum. Now for my question -

I read somewhere on the Internet that Windows XP and later versions do not allow the use of DOS or BIOS interrupts. I have found this to be true in my own little tests using assembly language in the Visual Studio 2008 C++ environment. I've also tried writing the code in a text editor and assembling/linking at the command line. The program hangs and tends to generate other forms of chaos. So it seems to be true. However, it cannot be the total truth. In my relentless search for "How to program in assembler in Windows," I ran into a page - http://illegalargumentexception.blogspot.com/2008/05/assembler-using-debugexe-to-write-dos.html - where the author uses Microsoft's Debug program to write a simple example, and it uses DOS interrupts without any hangups! The code is simple -

   mov ax, 02
   mov dx, 41
   int 21
   int 20

- that's it. The numbers are hex, and if you follow his Debug commands and write this out as file (PCHAR.COM), it will run at the command prompt just fine - it prints a capital A in the console window. In doing a dump of the file, only the code for the above instructions are in the executable file: B8 00 02 BA 41 00 CD 21 CD 20. I thought maybe MS's Debug was wrapping or re-mapping the DOS interrupts. That does not appear to be the case. Other possibilities exist. Since it is a .com file, maybe the Windows console program emulates the DOS interrupts. However, it seems to be problematic trying to produce a .com file with Masm 6.15 or later to test this.

Whatever...I remain intrigued by the idea that if Debug can produce an executable that uses the old DOS interrupts then so should I.

cheers!
~todd

[jj2007]

Hi Todd,
Welcome to the Forum :thumbu

Using interrupts is no problem in Win XP, but it's DOS and needs the old 16-bit linker:

Code Select Expand

.model tiny

.code
org 100h
start:
mov ah, 09h ; write string to STDOUT
mov dx, 82h ; get command line
int 21h ; show it... ;-)
ret
end start



By the way: probably the shortest application that can display a string :bg

[qWord]

hi,
for executing, you should use emulators like DOSBox.
For 64Bit OSs, 16Bit support is completely removed, thus you must use emulators.

[Manos]

Windows run in Protected Mode and interrupts does not allowed.
Only some interrupts can use to handle errors, like int 3.
If you want to use interrupts, you can do this in Real Mode or in Virtual Mode.

Manos.

[MichaelW]

Up through Window XP, and with a few exceptions, the DOS and BIOS interrupts should work fine from a DOS app running under Windows. You can even run DOS apps that install temporary interrupt handlers, or that use DPMI to run in protected mode and have access to a much larger "flat" address space.

[Todd]

I really appreciate the replies, especially the code snippets. I really did not intend on ending up in the 16 bit DOS world, but I now understand why the Debug operation worked with the interrupts.

Well, now I am off to explore the MASM32 package.

Cheers!
~todd

[redskull]

I think it's important to point out DOS interrupts don't "work fine" under XP (or any version of NT, for that matter); it's just that Microsoft has put in a staggeringly complex system of emulation and hacks to make it look like that.  When your DOS program tries to execute the interrupt, it will fault like any other program.  But right before an exception happens, the kernel checks to see if it's a DOS program, and if so, it manually performs the branch in software.  There are actually special-case system code (NTIO.SYS, NTDOS.SYS), that emulate the original system call by deliberatly executing a special invalid opcode which again faults back to the kernel, checks for the code, and then launches into special 32-bit code to perform the appropriate action using the win32 API.  If you trace into an INT 21 interrupt far enough using debug, you'll get to a point where the disassembler gets lost trying to decode 0xC4C4, which is the super-secret hack to talk to 32-bit windows and get it to actually do anything of value.  Just because it looks like you are doing 16-bit assembly language doesn't mean you actually are.  If you want some quick fun, manually enter "c4 c4 50 41" into debug and try to trace over it. Even though Debug will choke on the trace, you will see that the windows host name magically got put into the address specified in ds:dx.

-r

[jj2007]

Red,

Thanks for the background - much appreciated :U

But MS did a good job, actually - it looks like real :bg and works even with Masm version 10. Attached a batch file that creates, assembles, links and executes the hello world example above. The executable is really 8 bytes short.

Code Select Expand

Microsoft (R) Macro Assembler Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Assembling: HiDos.asm

Microsoft (R) Segmented Executable Linker  Version 5.60.339 Dec  5 1994
Copyright (C) Microsoft Corp 1984-1993.  All rights reserved.


######### NOW TESTING THE RESULT: ############

Why on Earth ... does this work?

#########  That was easy, right?  ############

Directory of D:\TEMP

25.03.2012  23:14                 8 HelloDos.com
               1 File              8 byte


P.S.: Just a word on the assembler commandline:
Recent versions need the /omf switch:
   \masm32\bin\mlv10.exe /omf /c HiDos.asm
Old versions (6.14) don't like the /omf switch:
   \masm32\bin\ml.exe /c HiDos.asm

[MichaelW]

I think it's important to point out DOS interrupts don't "work fine" under XP (or any version of NT, for that matter); it's just that Microsoft has put in a staggeringly complex system of emulation and hacks...

Most of them do work fine, where I define "fine" to mean that they do what they are documented to do, irrespective of all the monkey motion going on in the background.

[redskull]

But MS did a good job, actually

IMHO, the NTVDM system is some of the most ingenious programming MS has ever done.  It's easy to start off with a blank slate and build some pristine system, but to take a decades worth of wild-west DOS software, and rig it up to work under a totally new OS and have most things not just still run, but run responsively and integrate seamlessly into the OS?  We should all be so clever.

It's been a long time since I've been knee-deep in it, but there's a whole host of stupid-NTVDM tricks you can do.  There's a whole parallel section of debugging events that get generated (you could make a WIN32 debugger that steps and traps and traces through a 16-bit program), a slick custom interface where you can actually write a 32-bit DLL that you can call from a 16-bit program, a way to take control of port ranges and build 32-bit drivers that do the IO, and even a Star Wars themed debugger for debugging x86 programs if you're running on non-x86 hardware.

I keep toying with idea of putting all my notes into some sort of document, but as support has been dropped in 64-bit windows, it doesn't seem worth it. Besides, japeth knows far more about this stuff than I could ever hope, and would be better suited to the task.  Maybe i can find a way to beat 8 bytes..... :toothy

-r