Anatomy of Windows Programs

Libraries

Most applications need to do more or less the same kind of thing. From the earliest days when computers principally solved mathematical problems it made sense to keep libraries of 'useful' functions for programs to share. In these days these functions were often mathematical such as trigonometric functions or finding solutions to partial differential equations. The earliest form of library were actually lengths of paper tape that were physically spliced into a program where they were needed.

When an application used a library you needed to specify the library and ensure it was linked into the program code. The linker would work out which particular functions you needed from the library and only include these into the executable image for the program. The 'static library' file was born.

Quite apart from re-using shared code for computations it was also useful to use libraries to ask for services from the Operating System - opening and reading a file for example. This a big deal as it insulates a program from needing to know the details of the way data is stored on discs. The Operating System turned into a set of function libraries for programs to make use of.

Microsoft® Windows®

When Microsoft® developed Windows® for the earliest PCs a memory size of 256Kb was generous and so from the outset it was important to keep memory requirements as low as possible. The last thing they needed were lots of applications containing copies of identical 'library' code. It was this in mind that the concept of Dynamic Link Libraries (or DLLs) was invented. The system consisted of a number of these DLLs. Splitting it up into separate libraries means only a few DLLs need to be loaded into memory at one time. When an application loaded it did not include copies of the shared code anymore it 'dynamically' linked into the system libraries at run time rather than at compile time. It was therefore possible to create very small applications as the code in the system DLLs did much of the work. To implement this an application program has to declare the DLLs that it needs to load, embedded somewhere within the program image. When the program is run the system will know to load up these libraries and link them in. As many applications use the same functions system DLLs can be kept in memory and shared between different programs, greatly economizing on memory required. They need their own data space but the code is 'read only' and so can be freely shared.

Apart from saving valuable memory space this approach has the advantage that an application is 'insulated' from the system. It can run on different makes of PC with different hardware. The system will have different DLLs and drivers to cope with the different devices for an individual PC but the interface presented to the application is just the same. Opening a file on a floppy disc, a CD or a hard disc can be just in the same way as far as the program is concerned.

We are so used to the concept that applications on one computer 'should' run on another that it is easy to forget that it was not always this way. In the bad old days of Operating Systems you could only be sure that an application would run on an identical system (both hardware and software). Quite often an Operating System upgrade or the installation of a new type of disk drive meant you needed to amend and rebuild the applications to make use of it. It was the software development cost of this continual maintenance that helped kill off these other Operating Systems. Windows is remarkably good at running 'old' software. I have a MSDOS® application from 1991 that I can still run on XP® and it does just the same thing and a 16bit Windows application from 1992 that I still use quite frequently.

At the technical level there are actually two 'abstraction levels' at work here. Firstly there is 'HAL' - the Hardware Abstraction Layer that is the key to keeping Windows generic to the hardware devices you connect to it. All devices have to provide the same driver interface to Windows. This is what lets you replace printers or graphics cards from different manufacturers and yet all applications do not need to know a change has been made - they can use a generic 'printer' and 'display'. Secondly there is another 'user interface' abstraction layer. Windows provides the mechanism for displaying edit boxes, dialog boxes and the application just requests 'put a check box here' without knowing the details. Windows can then provide different implementations of a 'check box' without the application knowing or caring about which one is used. The user interface may look rather different on different computers or different versions of Windows but the application itself does not need to change.

DLL Hell

About ten years ago there was a major issue with how Windows was working. Microsoft was issuing quite a few fixes to Operating Systems and also to their development tools (principally Microsoft Visual C++). Unfortunately these led to a number of released products failing to work after the changes had been applied. This became known as DLL Hell, as the root cause was the sharing of DLLs.

If you just add new functions or extend what a function does you should be able to issue a new version that will support all the software that already uses the previous version of the DLL. But the number of parameters and parameter types on an existing function can not be so easily changed - the application would need to be modified and rebuilt to supply the changed parameters.

One good reason that these problems occurred was that developers would try to find an ingenious workaround for a known bug in Windows. To get a program working as required, the developers had little choice but to find a way around the problem, taking account of the way it went wrong. But when the problem eventually gets solved the software may now fail because it relied on the presence of the original bug. At the time this seemed a reasonable strategy for a software developer when faced with a problem they need to quickly workaround. The end-user ended up with an application that worked, but when they upgraded the Operating System the application would fail.

Why did this happen in Windows? Mainly because of its success, lots of developers were writing software for it. In other Operating Systems it tended to be only the computer manufacturer who wrote the software. The other reason was that Windows was designed on the basis of trust rather than distrust. It may seem naive now, but in those days a developer was trusted to write well-behaved software. A bug in an application would more than likely crash the whole of Windows and need a reboot. An application, believe it or not, had to willingly suspend what it was doing at regular time intervals (calling a function 'Yield') to allow other programs to run, if it did not call this function other programs would not get a look-in until the current application had terminated. When you wrote a Windows application you were trusted to be 'fair' to every other program on the system. This is indeed an architecture that needs to work on trust.

Delayed load

Apart from DLL Hell, the main issue that has hit Windows programs is that they threw themselves into the DLL world in too big a way. A program could reference dozens of DLLs that all needed to be loaded before it could be run. This can give an embarrassingly long delay before anything happens. Users are very sensitive to load time as they have decided to run an application and want to start using it a.s.a.p. This is a rather sad state of affairs because the program doesn't need all those DLLs immediately, in fact depending on what the user does, it may never actually need to load some of the DLLs. To get around this Microsoft introduced delayed load DLLs. Not often used, this approach allows a program to put off the loading of DLLs until it actually needs them and so reducing the agonizing delay when a program starts up. If you've wondered why programs display a version 'splash' screen this is another way to disguise the time taken while it gets ready for user input.