Almost all the IBM-type personal computers in the world are running a general purpose operating system like Windows, DOS or Linux. General purpose means that it allows the user to run a broad range of applications, everything from word processing to video games. The operating system (OS) provides the basic interface to the user, in the background it runs all the hardware.
This means that if an application needs data from the disk, it is actually OS, the data, decides where to put it in RAM (Random Access Memory), and then make it available for application. The application does not know the actual ph
ysical location of that information, either in RAM or hard disk. Sometimes the OS will let application circumvent it, but in systems like Windows NT, applications are absolutely unable to access any hardware directly. Only OS has no direct contact with the hardware.
Now, this is normally a very good thing. It would be quite troublesome if all applications should contain code to manage disk I / Os, typing and mouse input, video, etc. It would be even worse if the user had to deal with all this because everyone will have to be a trained technician just to get something done on a computer.
But problems arise if the application tries to troubleshoot or benchmark hardware. For example, how can you test a particular sector of a hard disk if the operating system (along with the drive controller and BIOS) decides where the data will go on the drive And if the operation fails, how can we determine whether the drive mechanism or the controller was to blame? All the application knows is that it hands data off to the OS for disk storage and then get it back in altered form or not.
Another example is the memory test. Normally OS assigns a block of memory for a program that can play around in that block by using something called logical solution. The application knows where specific content is relative to other contents of the block, but I do not know where the block is physically located in memory, making it very difficult to know exactly which chip or module is the error when an error occurs. To complicate matters even further, most systems use a cache that saves the RAM contents, which are currently used by the CPU to provide faster access to this content. When a memory test writes to memory and then reads back different data, the error occurred in RAM or cache?
The tests for most other hardware will run into a sort of
When we say that the microscope is OS-independent, it does not mean it can run without an operating system. Of course, each 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 to run the microscope routines. This OS is one that is written specifically to allow diagnostic operations of hardware, such as access to a specific memory or hard drive location.
To do this, it was necessary to write the operating system and the diagnostic routines in something called assembly languages. This programming language is considered low-level languages, because each instruction in the program represents one instruction for the CPU. The instructions must still be translated into zeros and ones for the CPU, but otherwise nothing will be changed, allowing for very precise control of the programmer.
By comparison, most programming languages, what is high-level languages. In these, each line in the program represent many, many CPU instructions. The programmer writing code to run through another program called a compiler that translates each program line in a set of CPU instructions that determines the order they will run in, and assigns them all the relative locations of the compiled program. Right from the beginning, the programmer loses control over where the CPU instructions will be placed in memory, or even within the program itself, because everything is determined by the compiler program.
Almost all diagnostic programs other than the microscope is written in one of these high-level languages. When you add that they will run under an OS designed to operate hardware completely in the background, it is easy to see why the microscope provides greater precision and superior accuracy.
In wrapping this up, let's look at just two examples. Occasionally a second hardware device will be erroneously set to the same IRQ (Interrupt Request) as something that is already in the system. This causes the error, of course, because the CPU can not tell which device requesting an interrupt. Windows is unable to believe that another entity may use an assigned IRQ as this is not a permitted circumstance, and therefore will not report the second unit to the user or to a diagnostic program. Microscope handles this situation easily, and lets you find the offender with merely a few keystrokes.
Last, consider a simple request for information such as CPU speed. If a program runs under Windows wants this data must ask Windows for it, which will then return the value has been set in CMOS. This may be a precise value, and certainly will not tell you if the CPU chip is clocked. With this and other system information, Windows will not actually tell you (or the diagnostic), the data comes from a direct target of a hardware device (almost never) or from a reading of CMOS or other stored information (almost always). On the other hand, lets microscope you have it both ways, and tells you which is which.
Disclaimer - Micro 2000 Tech Tip is a free service providing information only. While we use reasonable care to see that this information is correct, we can not guarantee it for accuracy, completeness or fitness for a particular purpose. Micro 2000, Inc. is not responsible for damages of any kind in connection with the use or misuse of this information.
Micro 2000 Inc has been helping to solve day-to-day challenges that IT departments face in order to keep their businesses operational as well as profitable for over 14 years. Its primary goal is to put the customer first - through feature-rich, easy to use IT tools that help IT administrators manage their jobs more effectively.
