NOTICE! Use of this site signifies acceptence of the Contract for site usage
VIM stands for VIrtual Machine. Long ago, I wrote an interpreter for x86 machine code. Setup as a debugger, it handles up to REAL MODE 80286 code.
Since this is a debugger, I can't let a bad program take out the interrupt vectors, DOS, or whatever. Hence the "Virtual" in the name -- VIM takes whatever memory it can get, and sets up the interpreter to use a "virtual" processor. So, when the interpreter uses Interrupts, DOS, etc, it's using the virtual copy, so that a bad program destroying them won't hurt VIM, the real DOS, real interrupt vectors, etc.
VIM was originally written to break a copy protection scheme. The company that I was working for at the time used a very expensive piece of software, and the introduction of faster machines (286 boxes, as I remember) broke it -- the timing was different, so this had to be a "copy". The company didn't want to fix it immediately, and so I was asked if I could get rid of the copy protection.
So, I started working on it with DEBUG, pencil, and paper. About 10 pages of notes into the guts of the program, I asked myself "Why am I doing all this tracing and note taking? I have a computer!" and the idea for VIM was born.
About a month of work later, VIM was usable enough to do the job. The copy protection yielded shortly thereafter.
But, VIM turned out to be the right tool for MANY jobs (and, yes, I know that when all you have is a hammer everything looks like a nail). Writing TSR programs and device drivers became a breeze, as I could easily debug them. System killing software bugs didn't even slow me down.
Not to mention that, if you can write a processor in software, you know it *VERY* well. I became *MUCH* better at programming assembly language.
The company I worked for turned into one of the early Anti-Virus companies, and VIM (and it's offspring, CODEGEN) were once again the right tools for the job. I could analyze viruses in a snap, watch viruses execute despite anti-debug and anti-disassembly code, and CODEGEN gave me disassemblies as fast as I could type.
The VIM documentation is in ASCII TEXT format. You will quickly note that it is called VMDEBUG.DOC, and internally calls the program VMDEBUG. This is because, at one time, I tried selling it commercially through I company I was doing some work for (Wendin, which created PC-VMS and PC-UNIX, which were "shells" for DOS, and later Wendin-DOS, which was a true OS that was built on VAX VMS philosophy, but still tried to be DOS compatible). They noted that "VIM" was trademarked by someone, and so it became VMDEBUG. It never sold worth a damn, and I kept calling it VIM because that was the name I wrote it under. I haven't bothered to update the documentation, however.
The VIM executable runs under DOS, and should be fine with DOS 2.0 through DOS 5.0. I'm not sure about higher versions, you'll have to test that yourself. I usually run it under DOS 5, and it works fine.
You MUST remember that you can't use HIMEM.SYS or EMM386.EXE, as they use 386 instructions that aren't implemented in VIM.
The VIM executable package also contains some other files
VMDEBUG.DOC -- documentation for VIM (aka VMDEBUG) (ASCII text)
VIM_INIT -- an init file for VIM and DOS 5.0
SYSROM3.DAT -- replacement system BIOSIf your system does not run VIM (you'll hit an undefined opcode fairly soon), run a "bare" copy of DOS 5.0 (see CONFIG.5 and AUTOEXEC.5 for examples), and try again. If it still doesn't run, use this file via 'ZI VIM_INIT' when you first enter VIM. It will load replacement ROM images and some patches, which may help.
SYSROM7.DAT -- replacement VGA BIOS
CLICKER.ASM -- sample program referred to in VMDEBUG.DOC
LOADER.ASM -- sample program referred to in VMDEBUG.DOC
NULLDEV.ASM -- sample program referred to in VMDEBUG.DOC
CONFIG.5 -- sample CONFIG.SYS for DOS 5
AUTOEXEC.5 -- sample AUTOEXEC.BAT for DOS 5
Luckily, when I wrote VIM I allowed it to replace system ROMs with user specified files. Most modern machines have ROM's that VIM can't support, as they use 386+ instructions. I've included some ROM images that can replace your system ROMs in the VIM virtual space. SYSROM3.DAT is a replacement SYSTEM BIOS from a 486 machine that should work in most any system. Note that, as this is an "old" ROM, IDE drives are limited to 528Megs.
The SYSROM7.DAT file contains a replacement VGA BIOS, and a a BIOS
image from a GSI model 11 (I think... I'd have to check) hard drive
controller to replace the system IDE code. Unfortunately, the GSI
board "flashes" itself with the drive parameters rather than using
"soft" parameters, and this image is expecting a 3Gig hard drive. And,
as I found later, there is a bug in the GSI code, it wouldn't properly
update itself for a 5Gig drive.
I'm sure some adventurous sole will write, or find, replacment IDE
code that will let VIM address arbitrarily sized hard drives (up
to 8 Gigs, at least...)
VIM was written to be a true implementation of an Intel chip, and as
such it can run itself. And run itself running other code. Even if
you can't access the hard drive, you can watch VIM run itself running
DOS. Though you *DO* want to use a modern, fast chip. :)
Boot a DOS floppy (I prefer DOS 5) with the sample CONFIG and AUTOEXEC noted above, and run VIM. NOTE: If you give VIM *ANY* command line parameter, it will not reset the video to a known state. This will be used in this example, just to make sure we don't upset the hardware.
VIM AOne interesting thing to note is that VIM reports the number of instructions executed when it stop. So, if you start both copies of VIM at the same time (just before you hit "enter" after the G for the 2nd copy of VIM, hotkey back into the first copy of VIM, type G, and then "enter" TWICE, FAST -- the first "enter" will start the "first" VIM, and the second "enter" will start the "second" VIM) and stop both copies at the same time (actually, what you do is to hotkey the FIRST VIM, (RightShift)(SpaceBar) in this example, note the number of instructions, then type G
;Use ZI VIM_INIT if you need to replace the ROM images, otherwise just use ZD
ZI VIM_INIT
;Use ZH to set the hotkey to (right-shift)(Spacebar)
ZH 39
N VIM.EXE
L
;the next statement fakes a command line to the 2nd copy of VIM
E DS:80 2 20 41 0D
G
;The interpreted copy of VIM starts running here
;furthur commands in this example are to the 2nd copy of VIM
;
;Note that I'm using a plain ZD. Even if you had to use ZI to replace
;ROM images, they are now part of the VIM virtual space, and don't have to
;be loaded again for the 2nd copy of VIM.
ZD
G
;
; And, after a while (~10 minutes {sigh} on a Celeron 300A (not overclocked)
; if DOS wants to reload COMMAND.COM, otherwise sooner)
; you'll be at a DOS prompt. Type DOS commands like DIR, VER, SET, or
; run programs from the disk. They will work, though slowly.
;
; You can use a hotkey to interrupt either running copy of VIM --
; The "first" copy of VIM, which is running another copy of VIM, can be
; interrupted by (right-shift)(spacebar)
; and the "second" copy of VIM, which is being run under the first copy
; of VIM, can be interrupted by (right-shift)(Esc)
and IMMEDIATELY hotkey the SECOND VIM, (RightShift)(ESC) in this example, and note the number of instructions it has executed), you can find out several interesting things.
For example, on a Celeron 300A (not overclocked), I did a 15 Minute 0 Second run, with the following numbers
First VIM: 1A79CA65H instructionsDividing, I find that VIM used an average of 365.89 instructions to interpret one instruction. Then I use that figure times the instructions executed by the first copy of VIM to find that the CPU executed approximately 162,524,417,500 instructions in that 15 minutes, for approximately 180.58 MIPS.
Second VIM: 128575H instructions
The VIM source code is terrible. Ugly, poorly written in places, with very few comments. It is also about the only C code for personal use that *IS NOT* written in DeSmet C.
I'd appreciate a copy of any changes you make to VIM.
VIM was originally written in DeSmet C, but while DeSmet is good, it wasn't good enough. There wasn't anything that DeSmet couldn't handle, but Aztec C (version 4.10c by Manx Software) produced smaller, faster code. VIM grew to the point where I needed the extra space, and the extra speed was just icing on the cake.
Fortunately, DeSmet and Aztec are very close in terms of syntax (they're both K&R), libraries, and extensions (such as inline assembly), so it was an easy port.
The VIM source code is a .ZIP file that contains the Aztec compiler directory tree as well as the VIM source code.
These pages last modified 1/10/2001