The "Go" tools
     The GoAsm manual

for those new to ....


by Jeremy Gordon -

This article is intended for those who are new to programming in Windows.
It describes those elements of the Windows operating system which it is essential to know before you will be able to write a meaningful program. Of course, there is a lot more to Windows than is described here, and you will need a lot more information before being able to write programs.

Windows – in control

Windows takes control of the computer almost from the time it starts to the time it is terminated. An application can then run only with the permission of Windows, with the assistance of Windows and under the control of Windows. In this way Windows can provide the user with those greatly attractive qualities – predictability and consistency in the user-interface, the ability (apparently) to run several programs at once (multi-tasking) and robustness if an application fails.

of the hardware ..........

Most of the microchips which work with the central processing unit are programmable. For example the display card needs to be told the correct scan rate, resolution and colours. The printer in/out chips need to be told which printer port should normally be used and at what speed the data should be transferred. The keyboard chips need to be told what repeat rate to use. The actual communication with these devices needs to be controlled – each will have their own area of memory to use and they must be told what to expect and when. Windows does all these basic tasks as you would expect from any operating system. You, the application programmer, can then concentrate on the job in hand.

But Windows also takes total control over writing to, and reading from all such devices. This has important advantages to the application programmer.

For example, to print a document the application can merely tell Windows where in memory the document resides and how big it is. Windows will arrange for it to be printed, using the correct printer driver for the printer in use, and putting it in the correct position in the printer queue, which might also contain other print jobs from other applications. The print job is always performed in graphics mode. Windows tells the printer exactly where on the paper every single dot making up the final printed image should go. The advantages to the application programmer are very significant. He is freed from the tedious task of providing printer drivers for his application, and from writing graphics algorithms. He can "think graphics" from the outset without having to worry about the complications arising from this.

Windows does an even cleverer job with the screen display, which is also always in graphics mode. Here Windows probably has to cope with several applications at once trying to display their output on the screen. There may be several windows on the screen at any one time, and to the user, some of them appear to overlap others so that some material is invisible. Windows has the task, which it achieves brilliantly, of building up the final screen image from those parts of the screen output from each application which have a right to appear on the screen. It does this from its record of every window in existence at any one time, and from its knowledge of the priority, screen order, type and style of each window. A lot of your programming work will involve getting these factors right in your own program to ensure that Windows produces the correct screen output.

The necessary corollary to the control that Windows has over the peripheral hardware is that an application cannot (or at least should not) access the peripheral devices directly. But this is usually no disadvantage since Windows provides considerable versatility and with modern computers, sufficient speed for most tasks.

.......... of all applications

So what happens when the user clicks on the icon representing your program with the mouse? Firstly Windows knows exactly where the mouse click took place and what icon was in the field of the mouse pointer (cursor) at that time. It also knows from its lists of "shortcuts" and "properties" which program to start if that particular icon is clicked.

How does it start that program? Firstly Windows loads the program by reading its file and putting it into memory. Then quite simply Windows calls the program. That is, the processor is told to continue execution from the starting address of the program. Accordingly the simplest way for the program to finish is simply to return back to the system with a RET instruction.

.......... of the microprocessor

As seen above, to start the program the processor’s EIP register is given the starting address of your program by Windows. Windows also has control over all the other register values in the processor as well. Windows keeps these in memory in an area of memory called the register context. Windows can and often does, stop the processor, store the then values of the registers, and instruct the processor to run another program instead for a while. So that other program is given a processor time-slice by Windows. When finished, Windows might restore the registers in your program which then continues to execute from where it left off, because it then has a time-slice.

This is how multitasking works under Windows. Each program running in the system will be given a share of the processor. To the user it may appear that several programs are running at once, but that is not, in fact the case in single processor computers. Windows decides the length of the time-slice according to various priorities. For example a disk read or write operation will normally be given a very high priority and may stop other programs from running until the operation is finished.

A program can ask Windows to start another thread. Windows will then give this thread its own time-slices, and its own register values and stack. The new thread will appear to run at the same time as the main thread of the program. This is useful if a program needs to continue with one thing (for example a long calculation) whilst continuing to interface with the user. The program can therefore appear to the user to be doing two or more things at once.

This is called multi-threading.

.......... of memory and data

Your program can do much more than just manipulate data in the registers in the processor. At any one time your program will have its own data in memory. This will be held either in memory which it established for direct addressing or it will be on the stack. How does Windows preserve this data when switching using the time-slice between programs?

The answer is that Windows keeps a memory map of all the program’s data. That is, Windows knows exactly where, in the physical memory in the computer, the program’s data is being kept at any one time. Windows keeps this memory map in an area of memory called the memory context. If physical memory start to run out, Windows will use the hard disk to keep the program’s data if necessary. This is why on low memory systems there is often a lot more disk activity than in higher memory systems.

When the program needs to access its data it must do so by using a virtual address. This means that the address of the memory area does not in fact correspond with the actual address of the data in physical memory. Windows informs the processor where the required memory areas really are. It does this by giving the processor in the CR3 register, the address of its page-mapping table for the program.

.......... of the user-interface

The main reason why Windows was developed in the first place was to provide a consistent and understood interface for the user. The idea is that a user will be able to move from computer to computer without problems, once familiar with the Windows operating system. More importantly for the Windows programmer, each application will interact with the user in a similar way, and have a familiar layout. Therefore users will have a good starting point when trying out a new program, reducing training and learning times dramatically. These aims have been achieved with great success, and there are now millions of computer users around the world using Windows applications who had previously described themselves as "computer illiterate".

Windows has achieved this uniformity by providing applications with standard components to be included in their programs. Obvious examples are menus which appear just under the title bar of an application, dialogs where the user can make choices, titled buttons which the user can click, scroll bars to move the contents of a window up and down, toolbar buttons containing little pictures and standardised help files.

These standard components collectively are called the "Graphical User Interface" or GUI.

How does an application use them? By calling an "Applications Programming Interface" or API. This is a procedure provided by Windows itself which can be called by your program by name. All the APIs are contained in files called Direct Linked Libraries or Dlls. Dlls are executable files with the extension Dll. You will see many of these in your Windows\System folder in your computer. They contain code for export, that is, they are available to be imported to your program when you want to use the Windows GUI.

.......... and of files

The Dlls are constantly being revised by the Windows developers, to add new APIs or change existing ones. These are distributed to the user in various ways, sometimes in a Windows service pack, or when you load a new version of a Microsoft program (a favourite method has been to include new versions of the Dlls with Internet Explorer). The user may not realise this is happening at all, and to you, the programmer it makes no difference. Your program will still call the same API to do the same thing, only it might do it a slightly different way.

Windows keeps a record of the whereabouts of all files which are important to it own operation or for driving peripheral devices. When your program is installed Windows requires that it makes appropriate records in the registry, which is a database kept by Windows about the configuration of the system and the applications which will run under it. Windows also requires a well-behaved application to place its support files in the correctly named folders so that they are quicker and easier to find. All this work is done by the use of an installation program, which is usually shipped with the program and entitled Setup.Exe.

System – application communication

As we have seen above the Windows system controls every important aspect of the computer and also of the applications running at any one time. To achieve this close level of control there has to be a system of communication between system and application.

An application will want to communicate with the system when it needs to know something about the GUI, for example, the size of a particular window or the size of a particular string of text in a particular font. Also when an application wishes to use the features of an API, it must be able to tell the API exactly how it should work.

The usual methods of communication from application to system are as follows:-

    • Data on the stack. Before making an API call, you PUSH data on the stack for the API to retrieve. The data is always dword values but it can often be pointers to structures containing more data, or to strings of text.
    • Messages. You send a message to the system by calling the API SendMessage. The message itself is a dword value pushed on the stack, but you can also send up to 3 dwords of data with the message.
The system will want to communicate with the application to give it the results of an API call, or to inform the application that something is happening in the GUI or that something important is happening in the system itself.

The usual methods of communication from system to application are as follows:-

    • On return from an API, the system usually leaves a value in the register EAX, giving the result of the API call.
    • Sometimes on return from an API the system leaves data in memory at a place specified by the program when it called the API. That place would have been specified by the application PUSHing a pointer on the stack before the API call.
    • Messages to the application. This is achieved by the system calling the application. When this happens the system also sends data on the stack. The application will have informed the system the address in its code of a procedure where such calls can be made. This procedure is called a "callback" procedure, or a "windows procedure" or "WndProc" for short.

Handles and device contexts

All "objects" with which Windows works have handles. Such objects can be windows, controls, menus, dialogs, processes, threads, memory areas, displays, printers, files, disk drives, and even fonts, brushes and pens used for drawing and writing. A handle is a dword value which the application can ask for. The application will use the handle when it wants to communicate with Windows to use or change the object concerned.

All devices which display or produce an output have device contexts. The device context is an area of memory maintained by Windows which contains information about how the device should display its output. Thus a particular window will have a device context which will contain information about what font should be used in the window and in what colour anything drawn or written to the window should appear. And a printer will have a device context containing information about the printer's capabilities, paper size, available colours and so on.

The types of executables

An "executable" is a file which contains code which can be run by the processor. For present purposes we need only look at two of these, those with the file extension Exe (an application) and those with the file extension Dll (dynamic link library).

In order to qualify as a Windows executable the file must be in PE (Portable Executable) format. As its name suggests, this type of file is intended to be portable between different platforms, so that it can run on a computer either with Intel, MIPS, Alpha, Power PC, Motorola 68000, or RISC processors and so on, provided, of course the Windows operating system is loaded on that computer, and the PE file is the correct version for those processors.

Windows knows that the executable is a PE file because the signature "PE" appears early on in the file. A non-PE file, for example a DOS executable, would not have this signature and Windows has to make special arrangements to run those.

A Dll is used if its code or data is to be shared by several applications. Windows uses Dlls to keep the code for its API. The Dll is then said to have exports. This reduces the size of the individual Exe dramatically, because it is known that code will be available in a Dll for use by the Exe. One of the important fields of the PE file is a list of imports. This is a list of functions that the Exe relies on and which it may need to call whilst running. This list also has the name of the Dll containing the function. On loading the Exe, Windows checks that all the functions and the Dlls are available. If not it does not run the program. You can test this yourself by trying to run a program intended only for Windows NT on Windows 98. The chances are that some of the functions or Dlls will be missing. This might also happen if your application calls an API which is only available in later versions of Windows.

You can avoid this problem either by providing different versions of your program to run on different versions of Windows, or you can ensure that the correct API is called at run-time to suit the Windows version. This is done by using the API GetVersionEx to check which version of Windows is running. Then you can call the correct API to suit that Windows version. You have to be careful not to call the API in the usual way, otherwise it appears in the list of imports, which might stop your program running in the first place. Instead you call it by using the APIs LoadLibrary (which loads the Dll concerned if not already loaded) and GetProcAddress (which finds the address in the Dll of the API concerned).

Just as Windows uses Dlls you can also write Dlls to ship with your program. You might do this if you are shipping more than one program and the Dll holds shared code or data. Or another reason might be to reduce the size of updates from time to time. Instead of updating the whole Exe file, you can keep all material which might have to be updated regularly in a Dll.

Copyright © Jeremy Gordon 2002-2003
Back to top