|
The Importance of OS-Independence
Many of our customers want to know what the
specific advantages are to them of having diagnostic software
that is operating system-independent, like MicroScope, rather
than one of the many programs that run under DOS and Windows,
some of which are less expensive.
Almost all of the IBM-type personal computers
in the world run a general-purpose operating system such as
Windows, DOS or Linux. General purpose means it allows the
user to run a wide variety of applications, everything from
word processing to video games. The operating system (OS)
provides the basic interface for the user, and in the background
it runs all of the hardware.
This means that if an application needs data
from the disk drive, it's actually the OS that finds the data,
decides where to put it in RAM, and then makes it available
to the application. The application does not know the actual
physical location of that data, either in RAM or on the hard
drive. Every other action the application takes that involves
hardware is more of the same, with the OS running interference
in the background.
Now, this is normally a very good thing.
It would be quite cumbersome if every application had to contain
the code to manage disk I/Os, keystroke and mouse input, video
etc. It would be worse yet if the user had to deal with all
of that, because everyone would need to be a trained technician
just to get anything done on a computer.
However, problems arise if the application
is trying to troubleshoot or benchmark the hardware. For example,
how can you test a specific sector of a hard drive if the
operating system (in conjunction with the drive controller
and the BIOS) decides where the data will go on the drive?
And if the operation fails, how can we determine if the drive
mechanism or the controller was at fault? All the application
knows is that it hands data off to the OS for disk storage
and then gets it back in altered form or not at all.
Another example is memory testing. Normally
the OS assigns a block of memory to an application, which
can play around within that block by using something called
logical addressing. The application knows where specific contents
are relative to the other contents of the block, but it doesn't
know where the block is physically located in memory, which
makes it very difficult to know just which chip or module
is at fault when an error occurs. To complicate things even
more, most systems use a cache, which stores the RAM contents
being currently used by the CPU in order to provide faster
access to those contents. When a memory test writes to memory
and then reads back different data, did the error occur in
the RAM or in the cache?
The tests for most other hardware will run
into some kind of OS interference similar to the ones above,
and we will have a couple of additional examples in a moment.
By now though, you are probably wondering how MicroScope is
able to avoid these problems.
When we say that MicroScope is OS-independent,
that doesn't mean it can run without an operating system.
Every application must have an operating system, or it must
include one. MicroScope comes with its own operating system,
and a system boots up to our OS in order to run the MicroScope
routines. This OS is one that is written especially to allow
diagnostic operation of the hardware, for instance to access
a specific memory or disk location.
In order to do this, it was necessary to
write the operating system and the diagnostic routines in
something called Assembly language. This programming language
is considered a low-level language because each instruction
in the program represents one instruction for the CPU. The
instructions must still be translated into ones and zeroes
for the CPU but otherwise nothing gets changed, which allows
for very precise control by the programmer.
By comparison, most programming languages
are what are called high-level languages. In these, each line
in the program may represent many, many CPU instructions.
The programmer's written code has to be run through another
program called a compiler, which translates each program line
into a set of CPU instructions, determines the order they
will run in, and assigns them all relative locations within
the compiled program. Right from the beginning, the programmer
has lost control over where the CPU instructions will be located
in memory, or even within the program itself, because it's
all determined by the compiler program.
Almost all diagnostic programs other than
MicroScope are written in one of these high-level languages.
When you add the fact that they will run under an OS designed
to operate the hardware completely in the background, it's
easy to see why MicroScope allows for greater precision and
superior accuracy.
In wrapping this up, let's look at just two
more examples. Occasionally a second hardware device will
mistakenly get set to the same IRQ as something already in
the system. This causes errors of course, because the CPU
can't tell which device is requesting an interrupt. Windows
is not capable of considering that a second device might be
using an assigned IRQ, since this is not an allowed circumstance,
and therefore will not report the second device to the user
or to a diagnostic program. MicroScope handles this situation
easily, and lets you locate the offender with just a couple
of keystrokes.
Last, consider a simple request for information,
such as CPU speed. If an application running under Windows
wants this data it must ask Windows for it, which will then
return the value that's been set in CMOS. This may or may
not be an accurate value, and certainly won't tell you if
the CPU chip is being over-clocked. With this and any other
system information, Windows also won't actually tell you (or
the diagnostic) whether the data is coming from a direct measure
of a hardware device (almost never), or from a reading of
the CMOS or other stored information (almost always). On the
other hand, MicroScope lets you have it both ways, and tells
you which is which.
|
