Bookmark
Page

Why O/S Independence?

Many technicians 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. Naturally, we are happy to explain. And pardon us if some of this seems a little basic for those of you who have been in the business for years.

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 (Random Access Memory), 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. Sometimes the OS will let the application bypass it, but in systems like Windows NT, the applications are absolutely prevented from accessing any hardware directly. Only the OS has any direct contact with the hardware.

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. Of course 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 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 (Interrupt ReQuest) 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.

Disclaimer - The Micro 2000 Tech Tip is a free service providing information only. While we use reasonable care to see that this information is correct, we do not guarantee it for accuracy, completeness or fitness for a particular purpose. Micro 2000, Inc. shall not be liable for damages of any kind in connection with the use or misuse of this information.