How Computers Work
Building of a program in memory has become a complex task. The original home computers were based on 16 bit systems and could only count to the number 65,535. This became known as the infamous 64 KB barrier.
While today’s CPUs can handle programs and memory to several hundred gigabytes, the original Apple II, IBM XT and other first generation computers were limited to a total block of 65,535 bytes of program and memory access. The Commodore and the IBM XT both had provisions to work with two separate groups or banks of 64 KB program data in memory and switch between these elements.
IBM furthered this process with the concept of extended and expanded memory with the introduction of an new add on element into the OS known as EMM386. This program running silently in memory at boot-up allowed the OS and CPU to swap small blocks of memory. By swapping a few thousand blocks of memory from the 64 KB main block allowed programmers to build programs at large as a megabyte or more in size and then switch between blocks.
Quick BASIC for DOS came up with a very novel approach of allow up to 16 different 64 KB modules that could be exchanged in a given program.
The original IBM XT was based on the original CP/M off-shoot with small 64 KB “dot com” (.com) programs plus the “dot exe” (.exe) executables.. With the advent of memory swaps, expanded and extended memory came a wide variety of support files such as DLLs (dynamic link libraries) that could be called up from within the .exe kernel to perform tasks such as building new front ends or making menus.
This situation existed in the IBM PC world up to the last few years with the introduction of Windows XP which is a DOS-less system based entirely on free running 32 bit data in massive gulps over 100 gigabytes. But all older programs that are compatible with Windows 95 and Windows 98 are still locked into the DOS 64 KB barrier and have to deal with extended and expanded memory managers to operate.
The OS must now keep track of all these files in memory and herein lies the main reason why programs lock up and crash. It is also the reason why Windows so often locks up and crashes.
Windows success or failure is tied into “system resources” of which API and GDI are the two main elements. API is the Application interface while GDI is the Graphical Device Interface. When too many programs run or when too many files remain in disk based virtual memory the resources drop. When GDI drops below 20% you can almost always expect a system crash. When API drops below 35% you can expect poor performance from the system.
One of the main problems with Windows is release of the GDI unused resources. Macintosh requires all programmers to clear all graphic handles when the program is finished with them. Windows relies on garbage disposal which can take hours to adequately perform. Globs of support files remain in virtual memory until you close the system down or let the system rest long enough for a garbage disposal to come around and see what is still active and what is not, then remove the files from the disk.