A B C D E F G H I J K L M

• 386 Max

• x386 Expanded. Memory. Emulators

• A20 Handler.

• Applet

• Application frameworks, C++ proging Wins

C++ relies on standard libraries for some of its functionality (io-stream being one). However these standard libraries should not be confused with the class libraries created by Borland and MS to encapsulate the Wins API. These provide massive blocks of functionality to speed up Wins proging. For example, classes are defined for docs, views and tool-bars.

App frameworks are C++ class libraries for building Wins apps which enable use of a set of sturdy and robust ready made parts to enable speedy development of apps with later modification amplified.

They facilitate a more orderly prog structure and are coming of age because OOP is rapidly gaining acceptance.

The Wins API is procedural, but app frameworks let you write object-orientated Wins progs and provide pre-written functionality in the form of high level classes that speed app development.

The two major app frameworks products are MFC and OWL and provide numerous advantages, the most important being the object-orientated proging paradigm to Wins proging, which is inherently object orientated. In both libraries there are a few fundamental classes that serve central roles. An application class handles the dispatching and processing of messages and with each framework you derive your application class from the frameworks generic application class, then you create your application object. This object takes over and does whatever you have specified, which usually includes some routine INItialisation and creation of a main window object.

Once window objects exist they are the focus of most of the activity in typical app framework progs. A window class is used to specify the behaviour of a window and both OWL and MFC supply generic window classes from which more specialised classes are derived. Most apps derive a window class for their main window (or child windows in an MDI app), a window class for each dialogue box and various other window classes for special purposes, such as tool-bars.

Some of these are derived directly from the framework's generic window class, but more often they are derived from more specialised classes, like a frameworks generic dialogue class.

Dialogue classes help with all the chores in managing a dialogue box and because a dialogue box is a specialised type of window, it is derived from the generic window class. To implement your own dialogue box, you derive your own dialogue class from the generic class. Your dialogue class typically initialises controls, manages any interaction between controls and interrogates controls for their values as the dialogue box terminates.

Working with an orderly collection of classes lets your apps grow one class at a time, and it often lets you re-use parts of apps with relatively little effort.

• Application Programming Interface (API).

Generally refers to the Windows API, which allows apps to dynamically link function calls to the three main Wins libraries (USER.exe, GDI.exe and KERNEL.exe), plus the external libraries such as mmsystem.dll.

Consists of the functions, messages, data structures, data types and statements you can use in creating apps that run under Wins. A set of subroutines or functions that a prog or app can 'call' to tell the O>S to perform some task. Is used to refer to a set of common functions and / or subroutines used to implement a particular feature.

MS has several other APIs including 'GDI API', 'OLE API', 'MAPI', 'Telephony API' (TAPI) and 'MCI API'. The later stands for Media Control Interface and is the multimedia support component of Wins, managed by mmsystem.dll and related driver files. Many times the term API is misused, referring to each function or subroutine as its own API. The set of functions that are used in Wins is the Wins API and the function WINEXEC is not an API, but the standard API function for calling another app.

The Windows API (see section Wins API) consists of more than 1,000 functions that progs written in C, C++, Pascal and other Languages can call to create 'windows', open files and perform other essential tasks. For instance an app that wishes to display an on-screen message can call the Wins "MessageBox" API function. Proging the app software is thus easier and software looks and works similarly across various types of apps. Just about everything Wins does is accomplished via the API.

MAPI is an API developed by MS and others which provides Wins apps with an implementation independent interface to various messaging systems such as MS Mail, novell's MHS and IBM's OFS.

• Assembly Language.

A programming language that is one step away from machine language. Each assembly language statement is translated into one machine instruction by the assembler. Programmers must be well versed in the computer's architecture, and, undocumented assembly language programs are difficult to maintain. It is hardware dependent; there is a different assembly language for each CPU series.

In the past, control programs (operating systems, database managers, etc.) were written in assembly language to maximize the machine's performance. Today, C is often used instead and is less terse for progers. Like assembly language, C can manipulate the bits at the machine level, but it is also portable to different computer platforms. There are C compilers for most computers.

Although often used synonomously, assembly language and machine language are not the same. Assembly language is turned into machine language, which is at the lowest level. For example, the assembly instruction COMPARE A,B is translated into COMPARE contents of memory bytes 2340-2350 with 4567-4577 (where A and B happen to be located). The physical binary format of the machine instruction is specific to the computer it's running in.

• Associate & Association.

When associating a file with an app, you can 'open' the file and 'start' the app concerned with editing that app, at the same time. If a file is associated with an app, there is a document file icon of some kind next to the filename in the directory window. N.B when you start file manager, some files are already associated with apps, before any more are defined by the user e.g files that have the extension .CRD are associated with the program 'Cardfile' and so when you open a .CRD file (double click it) 'Cardfile' starts and loads the file.

There is a relationship created between the file extension and the app by the associate command. Opening any file with that 'extension' then opens the app automatically and definitions for [extensions] are defined that section of win.ini.

• Background priority

• Basic Input / Output System (BIOS).

A set of 'low-level' Routines in a computers ROM that apps (and O>S) can use. Many plug-in adapters include their own BIOS modules that work in conjunction with the BIOS on the system board.

Also called the ROM BIOS , an area of ROM that contains info about your PC system (such as supported HDD type) and instructions for controlling various aspects of your system (video, keyboard, disks etc.) to allow transfer of info between fundamental hardware such as Mem., disks and monitor. The BIOS Data Area is an area at low RAM address that stores important BIOS data such as the amount of RAM installed, Interrupt vector table etc.

• Boot Sector (or boot record).

The boot sector is the first physical sector in the volume of a hard or floppy disk (or the first logical sector on a HDD partition) and, for bootable disks, contains the code for the bootstrap loader, a small prog that executes when the PC is booted from this disk, beginning the process of locating and loading the O>S (DOS) into memory fromelsewhere on the disk.

This sector also holds a block of data holding info about the architecture of the disk itself, such as the number of File Allocation Tables on the disk and the number of bytesper sector, cluster size etc.

• Cache (Disk, read/write.)

Solid-state electronics inside a PC work much faster than any HDD and so data can not be read from or written to the disk as fast as the memory and the CPU would wish. That is where a read / write cache comes in. A cache prog does a couple of things to help speed up data transfer, first a segment of memory, either part of system RAM or dedicated memory on the controller, is set aside to store temporarily the data going to and from the HDD. With cache memory established, when you write data to the disk it goes first to the 'write' cache memory. When the CPU has time between other tasks, it can write this data to the physical disk.

The opposite happens during a 'read' operation. Info coming off the disk is read first into temporary RAM, the 'read' cache. Actually more data than the calling prog asks for is read into memory and when a prog asks for info the cache memory is searched first. Depending on the sophistication of the cache software, this routine may be able to 'teach' itself about the apps running at any given time, predicting with increasing accuracy what the next requested info will be.

'SmartDrive' is the MS disk cache prog (found in DOS 5.0 & later, c:\dos\smartdrv.exe.) Smartdrv.exe utility usually is installed automatically when you install Wins but you can elect to install it with DOS, depending on needs.

• Compiler.

• Complex Instruction Set Computing (CISC.)

A CPU architecture that favours robustness of the instruction set over the speed with which individual instructions are executed. see article

• Class : definition

The implementation of our software objects will be achieved using a special kind of structure called a class. Shifting our perspective from looking at objects from the 'outside' in an abstract sense we can define exactly how they will do the job on the inside. A class is a data type that specifies what data is to associated with objects of this type, called data members, and what functions we can call from 'within' the object of this type, called member functions or methods. When we want a C++ object we give it a name, like we would a variable and specify what class it belongs to. Encapsulation is the term used to describe the process of 'packaging' the data elements and functionality together. The functions provide the user of the class with an interface, which means they control how the object is to be used and in particular how access is gained to the data elements (the car controls). We now view classes as specifications for encapsulated data and code that represents the properties of an object.

For Input and output we need objects which understand how to input and output data for us, provided we say what we want to input / output and in what form. This is where the I/O stream library is used and the big advantage in using I/O stream objects compared to using individual functions in C, is that we can redefine the meaning of the operators to let us decide how we want the output to appear.

• Client or Server Application

In Object Linking and Embedding terminology, the 'Server' app is a Wins based app where the 'object' is defined or created for linking to, or embedding in, other docs or apps and provides the 'interface' for editing that object or data. The 'Client' app is a Wins based app that can accept linked or embedded objects. An OLE object is 'Embedded' when the 'description' is saved in the 'Client' app, and 'Linked' when the same 'description' is saved in the Server app.

The Server app must be installed on the users system to be used as an interface for editing. Without it, the object may display normally, but cannot be edited and in some cases the user can neither view nor edit the OLE data object if the Server app is not installed. Whether or not the user can view the data object differs from one OLE object to another. (remember type of object)

A linked 'object' is stored in an O>S file, using the standard file format for that kind of 'object' (e.g MS Word file= xxx.doc, suffix) , however you can make changes to the linked OLE object through either the Client or Server app (see OLE). Of course, if the name or location of the linked file is changed, it will not be found or its data displayed. In contrast the data for embedded objects are stored in the Client app, not the O>S. Temporary changes can be made to an embedded object, but these are undone when the app is closed.

In an active link of a Dynamic Data Exchange (DDE) conversation, refers to an app, form or control that requests data from another app acting as a server, the reverse is thus the client. These two terms have been replaced in DDE terminology as 'destination' and 'source.

The use of the terms 'client' and 'server' is not analogous to the 'client' and 'server' components of a database app.

• Client / Server Architecture

A model of computing whereby client apps running on a desktop or personal computer access information on remote servers or host computers. The client portion of the app is typically optimized for user interaction, whereas the server portion provides the centralized, multi user functionality.

• Clipbook Viewer / Clipboard / Local Clipbook.

By using the Clipbook Viewer you can view the contents of the Local Clipbook and the Clipboard. The Local Clipbook window opens when you first start the Viewer. The Clipboard window appears as an icon. (? or vica versa)

The purpose of the Clipboard is to temporarily store info being transferred between docs or apps (a scratch pad or buffer) and when info is on the Clipboard you can save it (.clp), view it in other formats, or remove it. The Local Clipbook is thought of as more of a permanent store and can make info available to other users.

By using cut, copy and paste commands found in most Wins based apps, you can copy or move info within a document, between docs or between apps. When using the cut / copy commands from within an app, the info is placed on the Clipboard and remains there until it is either deleted or cut / copy is used again. Clipboard stores info in multiple formats so clearing it may free some memory to run other apps. You can paste the current info into any doc(s) or app(s) as often as you like. You can copy the contents of the entire screen onto the clipboard by pressing PRINT SCREEN.

The current contents of the Clipboard can be permanently saved by copying it to the Local Clipbook (the only access is via the Clipboard) as a 'page'. Pages can be viewed as a description or 'thumbnail'. A selected page must be copied back to the Clipboard prior to pasting back into a doc or app. Therefore, a Clipbook Page is a piece of info pasted to the Local Clipbook from the Clipboard and info is saved in many formats and can be viewed in any of them. The Clipboard also stores info in multiple formats so that info can be transferred between apps that use different formats.

A Page can be shared (it must be designated for shared use and the object must already be pasted as a page on the other PCs Clipbook) with other users (you can 'connect' to a Clipbook on another PC and other users can 'connect' to your PC to use the info in 'shared' pages) so the other user can link to the page or embed it in a document on another PC. N.B you cannot edit a linked object if the source doc is on another computer (the editing must be done on the other PC) but you can edit an embedded object as long as the app used to create it is present.

• Cluster.

An area of contiguous disk space comprised of one or more sectors. The basic storage allocation unit for a disk and the smallest unit of disk space that can be allocated to a file. Disk space is allocated to files in whole clusters. The number of sectors per cluster varies from one disk type to another. On a single sided FDD, one cluster = one sector. On double sided, one cluster = two sectors. On HDD, clusters can be 4, 8 or more sectors long. Regardless of size, DOS always sets aside disk space by clusters. All DOS files are allocated space in terms of clusters. (see File Allocation table).

• Complementary Metal Oxide Semiconductor (CMOS).

A battery powered / operated permanent RAM chip in an x286> that preserves basic but vital configuration data about the systems hardware, i.e. the current time and date, number and types of HDD & FDD attached, the amount of RAM and the type of video adapter. PS/2s and EISA m/cs have extended CMOS RAM areas that are used to store additional set-up info. Most systems provide a utility prog to alter the info contained in the CMOS.

• Compressed File.

A file that has gone through an encoding process to make the file smaller in size. Several files can be compressed together. MS offers a disk compression utility with DOS 6.22 called DriveSpace (the utility with Ver. 6.0 was called DoubleSpace and was not a success) and there are a variety of third-party utilities. One payoff is because data is compressed into half the normal space yet the speed of the HDD has not changed you can read and write data noticeably faster. However there is an 'overhead' in compressing and decompressing the info on the fly as you use it but a RAM resident driver usually can perform conversion functions at speeds that give an advantage to disk access times over the alternative. The Device Driver must be run when the system is booted and remain memory resident (taking about 40k), 'grabbing' any software calls to the HDD, interpreting the request to read or write, and putting its own 'spin' on the request. The software algorithm takes out unnecessary info before the data is stored to disk (such as blank spaces), carefully remembering how it did so, and then reverses the process when you wish to read the compressed data.

Data Compression can be used to encode data while writing it to a backup device, so that fewer disks or tapes are required. This process has another advantage. Since the PC can typically compress data faster than it can be written to disk, this reduces the amount of data written without causing the backup process to wait for compressed data.

• Conventional Memory

Also called System Mem. or Base Mem., the original 640kb that IBM sets aside for DOS apps which need Conventional Mem. to run. However, Wins always uses a small piece as well, even with enough Upper Memory for Wins to load. Remembering that DOS cannot access the Upper Memory, only the 640kb, this area is valuable address space for DOS apps. The amount of Conventional Mem. available for progs decreases by the amount used by TSRs (Memory Resident progs) and Device Drivers.

• Critical section.

A sequence of instructions in a prog that depends on limited or unique resources. Execution of a critical section must be carefully managed. For example, most DOS interrupt calls are critical sections for Wins Progs, because DOS is not re-entrant. A prog claims a critical section when it wants to prevent re-entry into some prog code. Other Virtual M/cs are prevented from executing the prog code that this critical section protects.

• DataBase

A structured collection of data, contained in one or more data files, plus the key files and other info which describes the order and relations of the data elements A compilation of data consisting of a number of records ( or tables), each constructed of field of a particular type, together with a collection of operations that facilitate searching, sorting, recombination and similar activities.

DB Objects are logical representations of a physical DB, i.e Field, Index, Table.

DataBase Administrator (DBA)- A person responsible for designing and maintaining a multi-user DB system.

DataBase Design - The process of planning and describing the most efficient app or system for storing and managing data for a specific project.

DataBase Driver - A collection of functions and procedures contained in a Dynamic Link Library, supporting low level access to a specific DB file format

DataBase Integrity - Under the relational model, DB integrity consists of two general rules, each DB file or table must have a primary key serving as a unique identifier for all records. When a table has a foreign key matching the primary key of another table, each value in the foreign key must equal a value in the primary key of the other table, or be null.

• Digital Audio Tape (DAT).

DAT cassettes are used by 4mm DAT drives and are 3" long, 2" wide and 3/8" thick. Tapes can be from 60M to 90M long or more. Uncompressed tape capacity is 1.3GB for size 60 and 2GB for size 90. DAT tape drives are generally connected to a PC system through a SCSI host Adapter Card.

• Delphi.

A graphical proging environment, similar toVisual Basic (VB), from Borland. Provides all the facilities of VB and much more. Like VB, Delphi lets you design prototype Wins apps quickly and provides all the resources to create a full blown Wins app. In common with VB, form design (how it looks) is central to app development. To build an app, you place your Wins components on a form, along with their properties, such as colour , caption and font. Next you add code to events such as 'OnClick' and the relevant code is then generated in the code window. However, unlike VB the generated code is in Borlands Object Pascal.

Delphi's real hold over VB is its ability to produce standalone executables, rather than the pseudo-code generated by VB. Apart from making apps faster than their VB equivalents, this also means that Delphi can be used for coding Dynamic Link Libraries. Delphi produces smaller and faster code and has a much richer environment than VB and to top it all can use the VB Custom Controls (also called VBX extensions, see section Visual Basic)

• Device Driver

A Software Prog loaded with Config.sys that gives DOS control over System Hardware not having built-in support in DOS and so serves as a connection or interface for I/O to a device, allowing a PC to communicate to various devices, such as HDD, printer, modem or mouse (& typically upgrades) etc. or to modify the behaviour of various parts of the PC such as the video system (Ansi.sys) and Memory (Himem.sys). Remains in mem.

This bit of speciality code acts as an interpreter and takes Wins requests and provides them to the device in a format that it can understand. Wins'95 supports the two forms of device driver which are the 'real mode' driver (used in Wins 3.1) and the virtual device driver (see section). Wins must keep switching between real and protected mode to use the real mode version.

A Device Driver consists of three main parts; the Header, the Interrupt Routine and the Strategy Routine which saves a small amount of vital info before the Interrupt Routine is invoked. Wins also has installable Device Drivers which are specified in the Windows.ini and System.ini files.

There are three types of Device Drivers that can be used while in Wins. Firstly DOS Device Drivers loaded from Config.sys and Autoexec.bat. Secondly Virtual Device Drivers loaded and managed by Wins. (but only available in Enhanced Mode). Lastly, installable drivers which are Dynamic Link Libraries that are used as Device Drivers.

Display Driver.

Drivers used by Wins to communicate with Video Adapters. Most VGA cards can use the generic drivers provided by MS and shipped with Wins, but for best performance each card requires a Driver written by the manufacturer. Typically, a manufacturer writes a number of Drivers for a Video Adapter, one for each resolution in which the card can be run.

Printer Driver

An 'external' library file containing low level instructions and functions by which the Wins Graphical Device Interface (GDI) library sends specific commands to the printer.

• Direct Memory Access (DMA).

All PC compatible computers are equipped with a DMA controller chip, although 'AT' class and better m/cs have two of them. The DMA controller is used to access Mem and move info between it and peripheral devices such as FDD and HDD controllers without the CPU being required to move each byte itself. A technique that some hardware devices use to transfer data to or from memory directly, without requiring the involvement of the CPU.

This mechanism relieves the CPU of some tedious and sometimes time consuming Mem. manipulation, thereby increasing throughput of the CPU. Several DMA channels or data paths can be established on your system, but each device must communicate over a unique channel.

• Document (doc)

Any file which stores data associated with an app, whatever the app created includinginfo you type, edit, view or save. A doc could be a business report, a spreadsheet, a sound file, or a picture.

A document file has an association with an app. When you open a doc file, the app starts and loads the file, a document file icon represents a file associated with an app. The document window is inside an app window. Each doc window contains a single doc or other data file, in some apps there can be more than one doc window inside the app window.

• DOS Extender.

Some DOS apps use DPMI (Dos Protected Mode Interface) compatible extenders which allow them to run in protected mode. When a DOS app makes a memory request it calls routines in the Virtual Memory manager component of Wins'95 and as with Wins apps, DOS apps cannot directly access the VMM but use the DOS Extender API to make the call. Under Wins 3.1 these apps would still run in V86 mode (See sectionVirtual 8086 Mode.) Wins '95 improves system performance by allowing these apps to run in protected mode.

A prog (or library) that allows DOS progs to run in Protected Mode Wins provides DOSX.exe which gives Wins Standard Mode this capability.

• DOS Transfer Buffers

Used by Wins to perform DOS operations. When Wins needs to communicate with DOS it cannot use Memory above 1MB to pass info back and forth. Therefore, Wins contains DOS Transfer Buffers in Conventional Mem. so that DOS will recognise and be able to use them.

• Double Buffering

A 'SmartDrive' feature that provides compatibility for HDD Controllers that cannot work with Virtual Memory.

• Driver

A prog that enables a specific piece of software, such as network software, or hardware ( a device) to communicate with Wins. Although the software or device may be installed, Wins cannot recognise them until the appropriate driver is installed and configured.

• Drive Parameter Block

An area on the disk containing info DOS requires to properly communicate with the Drive, such as the Media Descriptor Byte, number of bytes / sector, sectors / cluster and other Drive details.

• Dr. Watson.

A utility that monitors the Wins environment for errors and records the set of conditions that Wins detects right before a system failure. When an error, or GPF occurs, Dr. Watson 'appears' allowing you to enter the actions you performed before the GPF occurred. The info you enter, including a detailed status of the Wins environment, is logged to a file called Dr. Watson.log. This file can then be used to troubleshoot app defects at the proging level.

• Dynamic Data Exchange (DDE).

A Wins Inter-Process Communication (IPC) protocol . A DDE 'conversation' consists of two apps trading messages. Within the DDE conversation, one app acts as the client, the other as the server. The app which starts the conversation, requesting data or services from the other, is the client. The contracted app is the server. The server must 'register' with Wins that it has server capability. An app can act as both client and server at the same time, though it requires two separate DDE conversations. (see also Client / Server Application).

An established message protocol for exchanging data through active links between apps that run under Wins. A Wins feature that allows apps to exchange info and commands. A mechanism used in Wins to transfer data between two apps or two separate instances of the same app. Wins itself uses DDE for a variety of purposes from opening docs in running apps when a doc icon is double-clicked in the shell to obtaining prog icons for DOS apps. DDE is also used to support Object linking andEmbedding (OLE.)

• Dynamic Link Library (DLL, file extension = .DLL)

A special type of Wins executable file that enables apps to share code and other resources (e.g icons) necessary to perform particular functions. Unlike a standard proging library, whose functions or subroutines (see subroutines) are linked into an app when the apps code is compiled, an app that uses functions in a DLL links with those library functions at runtime, hence the term 'dynamic'.

DLL's include utility routines for standard app tasks such as retrieving configuration info, managing memory and handling user actions. Other DLL's may provide specific functions not intrinsic to Wins. Note: as DLL's are often used by more than one prog, when uninstalling a prog it is important that you do not delete a 'x'.DLL file that may be required by another app.

Under DOS, an app has to contain every component that it needs to execute. The proger links in library support for graphics, low-level utils, and a variety of other needs and the whole scenario is based on the fact that the app is the only thing running under DOS. Wins is a different kind of environment and there is always more than one task running under Wins and also a good chance that there might be some duplicate code running. For example the display routines used by one app are probably the same as those used by another app at some particular level. Therefore the overall memory requirements of the system can be reduced if you allow all the apps to share these common yet redundant pieces of code instead of loading them from scratch for each app. There are two forms of linking under Wins, the first link cycle combines all the object modules (subs in object code?) required to create a unique app and happens right after the proger finishes compiling the code. The second happens when the user goes to load the app and this is where the DLL comes in.

There are unresolved references to functions inside every Wins app and MS calls them 'Import Library calls'. What these calls do is load a DLL containing the code required to satisfy that function call. If the DLL happens to be in memory when Wins calls it, then Wins increments the DLL's usage level to indicate that more than one app is using it, and correspondingly decrements the DLL's usage level when the app stops using it. When the count goes to zero Wins can unload it from memory and so in effect using DLLs can save quite a bit of memory when loading multiple apps.

This capability also provides Wins with a lot of flexibility. All you need to add printer support for a new printer to Wins. is copy some files to disk. At least one will be a DLL. Every printer DLL contains the same entry points (function names), so that Wins does not need to learn anything new to support the printer, it only has to install a new DLL. Your app performs the same way when you tell it to print. It looks at the DLLs currently installed for the system (not caring whether the printer is a dot matrix or laser) and all it needs to know how to do is tell the printer to print; the DLL takes care of the rest.

Creating a .DLL (Sub-Application)

Typically a prog is created using one Main app and several sub-apps compiled and linked as external .DLLs. Larger projects (such as Wins itself) are structured and designed with team development in mind and so describe aspects of working in a Multi-developer environment. With this approach, each team member creates a separate. DLL that is called by a 'master' app, this requires splitting the app into a 'Main' executable and 'secondary' .DLLs. Team members maintain separate app files for each component and the team leader creates a master app that calls the sub-apps, and a 'data' app that contains (and exports) all the File definitions and Global variables. Optionally, members can call procedures from another members .DLL. Dividing a large project into multiple .DLLs provides many benefits:

þ Each sub-app can be modified and tested independently.

þ Developers can work on their portion of the project without interfering with others on the development team.

þ Each sub-app can be compiled as a .DLL and tested in the main prog without recompiling the entire project. This reduces compile and link time.

þ Dynamic pool limits are avoided on large projects ?

þ Future updates can be deployed by shipping a new .DLL reducing shipping costs.

An external file containing functions and procedures which the app may call at run-time. When an app calls a .DLL without specifying a path to the file, Wins automatically attempts to load the file from the current directory, Wins\System, and directories listed in the 'path' environment variable.

A .DLL is a file 'object' that stores procedures called from other apps and are available only on the MS Wins platform. You can use two kinds of .DLLs, your own or the Wins .DLLs included with the O>S. By writing 'C' code and compiling it you define your own .DLL. The basic system library files behind MS Wins include a wide array of pre-defined procedures that create and manipulate objects and data in the Wins environment.

It has traditionally been difficult to call C code from a Pascal prog and vica versa, mostly because of the significant differences in the respective compilers and Run-Time libraries. DLL's offer a clean solution to this inter-language problem. The DLL can contain whatever C run-time library functions the C routines in the DLL need, and the Pascal code can call the DLL using a standard interface. Of course, it works just as easily the other way round as well, Wins progs written in C can call Pascal DLL's.

A Dynamic Link Library (DLL) is an executable program module, written in C, C++ or Pascal which provides flexibility and language independent code-sharing in the Wins proging environment. DLL's are a powerful, object -orientated way to extend your apps and improve the efficiency of code among progs and across proging languages.

DLL's are modular and flexible enabling further building into new forms, sharing to other modules, simplifying complex mathematical functions, called from within an app and common to apps.

DLL's are the building blocks of Object Link Embedding (OLE) technology allows you to keep info current across apps, simply by changing the info in one of them. OLE support for a software suite ( a complementary set of software products that are designed specifically to work with each other, not just a bundle of disparate products ) would enable you to drag and drop data from one app to any another.

In-place editing with OLE 2.0 means you can even edit the relocated item directly at its new destination.

For the DOS environment, Borland's 'DOS Extender' will allow protected mode DOS progs to use DLL's (non visual ones) in the same way as Wins progs. It also allows DOS progs to use DLL's that are compiled for the Wins environment and if a DLL performs only data processing services and contains no direct user-interface code (GUI), the same DLL executable module can be used by a Wins prog and a protected mode DOS prog, without recompiling any source code.

• Embedded Object

You can embed objects created by apps that support Wins and OLE. When embedding an object, you first make and then place a 'copy' of the object created in one document into another 'destination' doc. Once embedded, the info, called an object, becomes part of the destination doc. The source file is not affected, unlike linking objects. The two docs could have been created using the same app or different ones. When you edit an embedded object, the app used to create it is started from within the current doc by double clicking on the object, to bring up the app and the object is displayed and ready for editing. To 'return' after editing the object select 'EXIT & RETURN TO... ' from the menu and any changes made to the object are reflected in the current doc.

Docs that contain embedded objects often use a lot of memory and contain all the info needed to manage the object and it is important you have enough memory to run all the apps you are using at once. With linking or embedding you do not have to switch to another app to edit an object.

N.B to initially embed from a source doc or app (a selection from an existing file, embedding from the server), COPY to the Clipboard, switch to destination doc and choose PASTE SPECIAL / PASTE.

To embed in the eventual 'destination' doc (embed a 'new' object, embedding in the client) or app use the INSERT menu then OBJECT command. Choose CREATE NEW and the app will display a list of available object types, the objects on the list depend on which apps installed on the PC support Object Linking and Embedding. If you wish you can DISPLAY AS AN ICON rather than display the info itself which is useful when you do not want all the info visible in the destination doc. The appropriate app either opens and displays its own window or replaces (takes over) the client window.

To embed a new 'existing' (an object already created) file, as above only choose CREATE FROM and type the complete path and filename of the file to be embedded. The location reflects the file of choice, also a location may have changed and need updating. If the doc chosen is from an OLE server app then the object in the doc will be displayed unless the DISPLAY AS ICON option is set. If the file type chosen has an association (it is a document) but the app is not an OLE server, the app will start when clicking on the representative icon in the destination doc, if an executable file is chosen, an icon representing it will appear (OLE server or not) so you have a nested app. This is the same as using Object Packager. If the icon box is checked you can change for an alternative icon. If an icon file (ext. = .ico) is chosen an icon will be displayed but nothing will be associated with it. If there is no association then an error will result when double clicking. The LINK option gives the potential to become a linked object, and creates a link to the selected file rather than embedding it.

• Enhanced Mode (386 Enh. Mode)

One of two Modes in which Wins 3.1 runs, the other being Standard Mode ( Wins for Workgroups 3.11 will only run in Enh. Mode.) Enh. Mode requires a x386> class CPU and 2MB of Ext. Memory (4MB effectively, 8MB optimally is recommended.) The default mode that Wins 3.1x use to get the most out of the PC. Superior to Standard Mode because it uses advanced Memory Management Features such as the Virtual Memory abilities of the x386. (by using available HDD space as Memory, apps have access to more Memory {RAM} than is physically installed on your system, giving you more Memory to run apps.) This mode offers the features that are normally associated with Wins., Enh. Mode allows you to Multitask both DOS and Wins apps, that is to run multiple progs simultaneously and switch between them. In Enh. Mode, Wins can also simulateExp. Memory for any DOS apps that need it.

• Environment Space

An area in Mem. that contains the values of the O>S environment variables, which refer to a string in the computers Mem. The names and strings are placed into Mem. by the SET command in DOS. Progs may request the contents of one of these strings by asking for the contents of a particular environment variable name. One of the most often used names is PATH e.g :

PATH = C:\DOS ; C:\WINDOWS ; C:\PCTOOLS ;

• Event / Event-driven

An action which triggers a Wins message to the apps message queue. Wins is an 'event-driven' O>S and event-driven architecture enables management of multiple apps. Wins performs some task for every event. Either it calls the app that can handle the event, or takes care of processing the event itself. An app registers its event handler with Wins when you start it. Whenever an event happens, Wins calls each app to see if the event applies to it. The app then has to interpret the event and take a proper course of action , via. Wins, so all individual actions are co-ordinated with the system as a whole.

Unlike DOS apps where a specific sequence of steps is followed, a Wins app never knows quite what will happen next (think of the GUI, the point and click options for the user and the multitasking nature of Wins.) because there is the possibility of any one of a number of different events happening (as instigated by the user).

Event driven programming - A proging paradigm which describes how an app will respond to possible actions selected and defined by the end user.

• Exception.

An Exception occurs when something 'bad' happens in a Prog, such as a 'division by zero', or attempting to execute an 'invalid m/c instruction'. A Prog can set up Exception Handlers so that they can control what happens when an Exception occurs. Wins defines and uses its own Exception Handlers.

• Executable

A standard '.EXE' app file capable of being launched by the Wins shell.

• Expanded Memory & Expanded Memory Specification (EMS).

Some older progs were written to take advantage of Exp. Memory, a bank switched memory management scheme / technique developed by Lotus/Intel/MS (the LIM standard) to use Memory above 640k. It is slower than Ext. Memory but compatible with much software and provides better MS-DOS performance although is a more restricted utility

A way of providing additional Memory by mapping fresh Memory into a space known as the Page Frame , which exists between the 640k boundary and the 1MB boundary (the Upper Memory Area ). This Memory is under the control of an Expanded Mem. Manager (controlling software) and is 'paged' or 'mapped' into an EMS Page Frame or 'window' within Upper Conventional Mem.

The Pages can be accessed by an app as long as they remain 'paged in'. Later on, the app can request other EMS Pages to be 'paged in' to access more Memory. This is traditionally accomplished through the use of a special Exp. Memory Board, such as the AST 'RAMpage!' or Intel's 'Above Board', the Software Manager is supplied with the Board. On the Board there are usually a number of 64k Banks of chips, say 16 x 64kb, which are not assigned permanent addresses, they are accessed one at a time using a 64k Page split 4 x 16k and transferred into Upper Memory.

Exp. Memory can also be simulated from Ext. Memory (not on a board) with special software called an EMS Emulator which emulates the EMS capabilities of a physical board. To explain, x386> can simulate bank switching thus you can use Ext. Memory to simulate Exp. Memory for MS-DOS progs that require it within Wins. All you need is the correct Memory Manger and starting with DOS 4.0, EMM386.exe was included. Note that the only time you need Exp. Mem. under Wins (later versions) is when the DOS progs you are running need it. Even then Wins can simulate Exp. Memory for them in Enhanced Mode (see section on 'x386 Expanded Memory Emulators.') EMS memory has been all but made obsolete by protected mode O>S such as Wins.

• Extended BIOS Device.

These are Devices that use the extended ROM BIOS data area (that is allocated by BIOS from RAM). PS/2 computers typically use this area as transient (or temporary) storage for additional devices such as the mouse (see section 'Basic I/O System' {BIOS})

• Extended Memory & Extended Memory Specification (XMS).

Linear, System Memory located above DOS's 1MB limit, accessible only when the CPU is running in Protected Mode or Virtual Real Mode (V86 Mode) . (not <x286). Generally, Ext. Memory is not available to DOS progs, but can be utilised for Wins (a requirement for Wins.) and some app software if a Memory Manager is present. Ext. Mem. Managers such as MS's HIMEM.sys (a device driver) can be used to allocate and manage this Memory for the use of real-mode progs without the possibility of apps using the same area at the same time.

Wins and most other progs can use Ext. Memory only after it has been configured as XMS Memory with Himem.sys or another Ext. Mem Manager. In Enhanced Mode x386> and Ext. Memory operational Wins can use all the System Memory for running various progs simultaneously. Each prog can run and do its work whether DOS or Wins, DOS and Wins running side by side. For Wins to activate itself, it has to load a section of itself where DOS can call it. This is why Wins has to load part of itself 'Low'. DOS calls this 'stub' to get Wins attention.

File Allocation Table

• File control Block (FCB).

A data structure used by DOS to manage I/O for a file. FCB's were made obsolete in favour of File Handles with DOS 2.0 but some software still uses them.

• File extension

A file name suffix, up to three characters in the DOS file system, which is separated from the first eight characters by a period. Wins 3.1 forms an association between document files and their app via the [extensions] section in the Win.ini file (see section INI Files )

• File Handle

These contain info about open files and are a number DOS uses to keep track of open files. They have been in use since DOS 2.0 and are more efficient and easier to use than the now obsolete FCB's. Every file currently open while using a PC under DOS must have a File Handle associated with it in order to access the file.

• Foreground Priority

A measure, expressed in a ratio, for the amount of CPU processing time allocated to a prog or task which currently has system focus.

• Format .COM

The DOS Command that enables a disk to store data, there are two kinds; low-level prepares the surface of the disk to store data by writing the addresses that indicate individual sectors; High-Level creates the System Areas necessary for data storage on a drive. A FDD performing a High Level Format also performs a Low Level Format.

• General Protection Fault (GPF)

Signifies that something unexpected happened in the Wins environment. GPF's are usually caused by Progs making improper Memory accesses. The Prog tries to access a Memory Location that it should be able to access and ends up overwriting the Prog Code that is already there. This is usually a temporary Memory conflict which goes away when you restart Wins.

• Graphical Device Interface (GDI.)

The Wins .DLL responsible for outputting text and images to the screen and printer. The component of Wins that permits apps to draw on screens, printers and other output devices. The GDI provides hundreds of functions for drawing lines, circles, and polygons, rendering fonts, querying devices for their output capabilities, and more

• Graphical User Interface (GUI)

PC software such as MS Wins presents progs, procedures, and files as graphics symbols and so users can interact with the PC by manipulating these symbols instead of typing discrete or cryptic commands (as with DOS). The Apple Macintosh (introduced in 1984) was the first business- orientated product to provide a natural, picture-oriented interface for the PC. The Macintosh O>S and other features were designed from the first principles with a GUI in mind in comparison with Wins 'built on' DOS. Advantages are that: apps 'look' the same and so are much easier to learn, no terse commands or cryptic procedures, point and click operation and info can be shared between apps. Most mainstream DOS products that have a large user following have joined the Wins ranks, and also many maintain their old DOS products which are still popular.

The MS Wins O>S makes using PC's easier for everyone and although there are overheads in terms of system memory, backing storage requirements and CPU demands, PC hardware has risen to the challenge by giving us more memory, faster CPU's and more efficient bus architecture.

Similarly there has been a large base of apps software and peripheral hardware devices developed for Wins. In many respects this has made plain old MS DOS a thing of the past, although in fact Wins 'sits' on DOS. The main advantages to be gained from using Wins over DOS based apps are :

• A graphical interface that gives you access to powerful O>S features without forcing you to memorise difficult commands.

• The ability to run as many apps as your system can handle at one time. You can switch back and forth among apps quickly and move info easily from one to another. App re-boot lets you stop a problem app while keeping Wins and other apps running.

• Ability to share data across apps.

Dos apps do not benefit from the above although Wins automatically recognises and sets up most DOS based apps. It follows that a 'mixing' of use of the two could mean later disappointment if it is wished that data be shared with other apps in the Wins environment.

If a productive DOS based app can be used which does not need to benefit from the advantages of the Wins environment, it may be advantageous to avoid some of the complexities and overheads of Wins.

• Heap

A given amount of Memory that can be manipulated by the prog - a kind of dynamic storage area. Every Wins App has at least one heap.

• Help System

Comprised of the Wins help app (Winhelp.exe) and a help doc (*.hlp) distributed by individual apps. When displaying help, both the app which called it, and Winhelp.exe are running.

• High Level Languages inc. Pascal & C

Can be defined as every language other than Assembly Language (a low level language) . Designed to eliminate the tedium and error prone nature of assembly language proging. They do two things,

1). Summarise many m/c language instructions ('ones' & 'zeros') into a single prog command and

2). remove from sight details that have to do with how the PC operates but have nothing to do with the work to be accomplished (e.g use of registers.)

HLL's are characterised by the fact that they generate a comparatively large amount of m/c lang. code when compiled (see Translators) for each command used and by their avoidance of unnecessary details.

Assembly Language requires more expertise to write than most HLL's because it requires more lines of actual prog code in initial construction and attention to detail. AL is therefore more prone to errors. However finished ALP's are usually smaller in final size than HLL's and run faster because the progers use their skills to find efficient ways to perform each step, 'hand crafted' if you like. Using AL, progers can tell the PC to do anything it is capable of doing while HLL's normally do not give the user access to 'lower-level' workings. (see Low Level Languages)

Pascal and C are two well known languages ideally suited for professional proging, both having the features considered most useful in helping progers create well crafted progs that are reliable and easy to update. They have similarities including structural features that promote good proging practices. 'C' is favoured by progers who are looking for utmost efficiency in a HLL and who want their progs to be in tune with one of the directions in which personal computers are evolving. Later versions of the C language including C++ offer an 'Integrated Development Environment'.

C is particularly good for writing progs that need to be 'tight' and efficient and that work closely with the computer's BIOS and DOS. Assembly language subroutines maybe used to perform tasks that cannot be done at a higher level e.g in the creation of professional quality progs often the best proging is done in a HLL with assembly language routines 'called' as a simple and expedient way to go beyond HLL limits.

Writing apps for a GUI environment requires faster code and higher performance CPUs than for text-based systems. Essentially this because of the overhead of the graphics and rather than place the appropriate ASCII code in the relevant location a character has to be built up from a Bitmap which typically takes 8 to 14 times as long. When you introduce movable and re-sizeable windows, proportionally spaced fonts and different typestyles, the processing overhead for each character increases a hundredfold. This was one of the performance problems that made the 'C' language so popular for Wins software development. Although not quite as fast as a native assembler prog, 'C' does provide a performance level that approaches it without giving up many of the advantages of 'third generation' proging. However 'C' is a very complex language and for many smaller non-commercial apps is inappropriate. That is where visual development tools come in. (see Visual Basic )

• High Memory Area (HMA).

The first 64K of Ext. Memory, used by some apps and by Wins. The HMA is available only when an Ext. Memory Manager, such as HIMEM.sys, is present. With DOS 5.0 and later, MS-DOS can be loaded here, leaving more Conventional Mem. for apps. Special Segmentation Techniques make it possible for the CPU to address this Memory in Real Mode.

• Hypertext Markup Language (html)

An ASCII, text-based, script-like language for creating hypertext docs like those on the Internet's World Wide Web. The most common data type on the Web is the 'page', a text doc composed in htm which defines how the doc is organised, how elements are displayed and how 'links' are embedded. To make any page appear on your screen someone first has to write some htm code and then an Internet Browser can receive it and translate into the formatted WWW pages.

The reason why most pages look the same is because there are only a few commands in html and within each command there are only a few basic variables. htm is the one standard that holds the Web together and allows all manner of docs, DB search engines, multimedia and interactive apps to co-exist in a common form.

Although one of the hallmarks of html is its simplicity (an htm doc is ordinary text with tags), a Web editor is a shortcut to htm and takes away the need for even the very simple proging. The main advantage of the Web is the ability to link pages directly to others by use of the command shown below, see section on the Uniform Resource Locator (URL) for a full discussion. Pages can be local (that is on your site) or anywhere else in the world. The command to create a 'hotlink' in htm is simple:

<a href= "URL page address i.e http:// etc." > click to see what's on the page </a>

or other text might include "go back to home page" or "view figures" which could be used to download a file from your site. The text between the chevrons is highlighted on the screen in a different colour and can then be clicked on by a user to transfer his browser to the appropriate page. You are not restricted to text only.

• INI Files ( file extension = .INI)

Used by Wins and other MS apps to hold INItialisation info. The files format is that of a text file (ASCII format) with each line of text holding info. The .INI file is divided into app sections, defined by placing the section name (identifier) in square brackets, an example would be: [WINPROBE]. Variables and there names follow separated by a carriage return, with an equal sign between the variable name and its value which may be strings or integers. Info that is unique to that app is stored in the lines following this marker.

WIN . INI

A File containing info and parameters to control your Wins environment. For example, Wins.ini stores the desktop colour preferences you have chosen or the Wins app you wish to start automatically.

SYSTEM . INI

A start-up file containing system specific, 'lower level' configuration info needed by Wins during start-up. The settings in this File help Wins run on a wide variety of DOS based systems.

• Integrated Development Environment (IDE)

A term for products such as MS's 'Visual C++' language, Borland's 'Delphi' or Sun's 'Java' (see section on WWWeb) that combine a prog editor, a compiler, a debugger and other development tools into one integrated unit.

Part of the power of OOP is that it can take advantage of GUI's in the development of apps and is used to access many features of Windows, as outlined below.

A common feature of contemporary compiler packages is the provision of an IDE which incorporate compilers, editors, project make utilities, class browsers and debuggers. To give the simplest example, just clicking on a warning or error line in the compiler output window takes you straight to the source code responsible. More usefully, you no longer have to create and maintain make-files. Instead, compiler options are selected by point and click and the project build is taken care of for you.

A common element of the IDE's in various compiler packages is that they all support a Windows class library, either Borlands Object Windows Library (OWL) or MS's Foundation Class (MFC) (see next section). Both of these libraries supply generic doc and view classes, which can be the basis of any app. This generic functionality allows the packages to implement code generators that automatically create app frameworks (see next section) according to options selected by the developer, allowing you to concentrate on writing the code to implement the particular functionality of your app. Both OWL and MFC support a message mapping mechanism for directing Windows messages to particular functions. This makes message handling much neater, and makes it easier for the IDE's to have resource editors that automatically link resources to code.

• ISDN (Integrated Services Digital Network)

The CCITT standard that defines a digital communications network geared to replace the world's analogue telephone systems. Among other things, ISDN provides superior dial-up connections for transferring info between computers and connecting to the Internet, supporting transfer rates of 128Kbps compared to 14.4 & 28.8 for modems. It also permits voice and data signals to share the same phone line.

• Internet / Intranet

The Internet is many things, but at the heart it's just a network of networks. Nobody owns or control it, the networks being managed by many different companies with anyone who conforms to the standard protocols connecting to and using the Internet, becoming part of the system in the process. It can be compared to the world road network.

Underlying it all is Transmission Control Protocol / Internet Protocol (TCP/IP) the systems tarmac. A properly formatted and addressed IP packet can be injected anywhere into the 'Net' and will be routed to its destination. Networks that do not use the protocol can be connected, but will have to translate at the interface. Much of the complexity concerns addressing and a basic Internet address is 32-bits long and these are allocated by a central agency, the Internet Network Info Centre. Each interface to the Internet must have a unique address, which is a long number to remember, so to many 'Net' addresses have a corresponding recognisable name. Translation is done by the Domain Name System, a DB distributed across the Net. The combination of Internet address and 'application port number' is referred to as a socket, the choice of socket is usually hidden from the user. (more page 282 Mar'95 Mag) (see Uniform resource Locator)

Setting up your own Internet Server is not a difficult thing to do requiring a Service Provider, a server and some Internet server software

An Intranet is basically a local version of the Internet and is more than likely either a group of networked m/c's or a company-wide network. It does not have to be cut off from the rest of the Net and in fact has positive advantages if joined to the Net either directly or via a firewall for security. Using the Net internally within your company you can create easy to use hyper-linked DBs for keeping everyone informed of your companies policies and products by producing product details or manuals in Hyper Text Markup Language format. (see htm) which can also be accessed externally by users if the local network is directly attached to the Net. Feedback can be obtained from employees via bulletin board type htm pages and upgrades of software or manuals could easily be accessed via the system. The beauty of the system is its low cost, all you need is a copy of an Internet Web browser on each PC and a server with the files details. You do not need Internet server software (unless you are going to attach the server to the Net). Instead load each PC with an Internet Web browser. This is the most expensive part of the set-up, although the next version of Visual Basic will have a set of 'add-ons' to allow production of customised browsers, with little coding. Another solution would be to get a networked version of the browser software, launch the browser, but instead of pointing it to a remote HyperText Transfer Protocol (HTTP) location just point it at a file on your Intranet server.

Say the Intranet server WWW root directory (containing the Internet DB for the company was mapped on the 'G:' drive you would either select 'Open file' and select a file in the directory using Browse, or type in 'file':

/ / / G / index . htm

(see section Uniform Resource Locator for syntax) From then on you could just point and click and get continuously updated details of your company. You could then either add it to your 'Shortcuts' menu in your 'browser' or if using Wins'95, create a shortcut to it. An Intranet is an ideal solution for the dissemination of info in businesses, both large and small. Linked to the Internet, it turns into an excellent way of sending and receiving info from your customers.

• Interrupt.

A signal to the CPU that indicates that something (usually outside the CPU) has 'happened'. Hardware Devices (such as the keyboard) can generate an Interrupt which causes the CPU to put whatever it is doing on hold and execute the Interrupt Service Routine, a set of instructions to perform a specific Task. Once the Interrupt Handler is done, the CPU continues what it was doing before it was interrupted. There are also Software Interrupts. These are used by apps., sometimes to simulate a hardware event and sometimes to access system or BIOS Services.

• INT 9. (hex)

This interrupt is triggered by the keyboard whenever a keyboard key is pressed or released. The Handler for this interrupt reads the key info and places it into the keyboard queue.

• INT 13.

A common BIOS interrupt that handles most sector level disk read / write operations to FDDs and HDDs.

• Interrupt Routine.

The part of a Device Driver that contains the instructions for processing a Command to the Device.

• Interrupt Service Routine

A BIOS or System Routine that services requests from hardware or software generated Interrupts. The Interrupt Vector Table is a list of the addresses of where each of the 255 Interrupt Service Routines reside in Mem.

• Interrupt Vector.

The area of Conventional Mem., starting at the very beginning (address 0000:0000), which contains the addresses of the prog instructions (Interrupt Handlers) for each of the 255 Interrupts.

• IRQ (Interrupt ReQuest) Level.

An IRQ is a signal from a hardware device indicating that it needs the CPU's attention. IRQ signals are transmitted along IRQ lines, which connect peripheral devices to a programmable interrupt controller or PIC. The PIC prioritises the incoming interrupt requests from different devices and delivers them to the CPU one at a time via a IRQ line connecting the PIC to the CPU. Devices connected to your PC sometimes require attention from the CPU to complete certain actions. In order for the Device to get the CPU attention, it must send an Interrupt ReQuest on an IRQ Line or Level. The lines flow from actual pins that are 'hard-wired' directly to the CPU and when a hardware Device requires servicing it informs the CPU via its assigned IRQ. The CPU assigns a Priority to each Device depending on the IRQ Level assigned. Like the I/O address, the setting is often set by software, or switches or jumpers on the Devices Controller Card.

• Library File

A pre-compiled file (x.LIB) containing procedures or functions which may be statically linked to the executable and utilised by a prog (compare with DLL).

• Linked Object

To create a linked object, technically speaking a 'place holder' or representation of the Object is inserted into a destination doc. Unlike an embedded object there is no copy made so when the object is edited the changes are also reflected in the source file, not a copy. An object in a source doc can be updated or edited directly, or in the destination app, you can 'double click' on it or go via the menu. In any other app, any instances of the object which are linked are updated to reflect the changes, either automatically or when given authority by the user, manually (a reminder is given about any discrepancy between the two versions whenever you open a doc that contains linked info not updated since the last time the doc was opened). The advantage of linking is that you can link info from the source doc to as many other docs as you need to. Any changes will be reflected in all linked destination docs (when allowed), as they all refer to the source, and changes can be made to the source from any linked instance of it. You can change the name of the source doc or change the name of the location of the source doc from inside apps so that they will know where to look for the linked info. N.B to link from a source doc, (outside of the destination) first name and SAVE the doc, COPY to the Clipboard, switch to destination doc or app and PASTE SPECIAL. Select the required format and then PASTE LINK. to link from inside the destination doc from the INSERT menu choose OBJECT, CREATE FROM and then type or select the name of the file to be linked (up to this point you can actually create an embedded object), choose the LINK check box and then OK.

• Lost Cluster.

A Cluster that contains current data but, because of errors in the FAT or other directories, the File that owns it cannot be determined.

• Low - level languages

Represented by Assembly Language. In practical terms, a proger must write out the equivalent of every m/c language instruction (ones and zeros) that the finished prog will perform, using a mnemonic code. In a High-level language, the prog can be written in terms of larger steps, steps that will be later translated into many individual m/c language instructions. In keeping with this distinction, the Translators for Ass. Lang. are called Assemblers and for the HLL's are called compilers and they convert the 'source' code into m/c lang. instructions or 'object' code.

• MDI (child / form) (Multiple Document Interface.)

In an MDI app, the forms contained within the MDI forms are child forms. An MDI form is a 'window' making up the background of an MDI app. The form is used as the 'container' for any child forms in the app. A 'container' is a parent object that contains child forms or controls.

• Master Boot Record.

The first physical Sector on a HDD. It contains the Prog that directs the PC to load the disk's boot record Prog, as well as info on how the disk is Partitioned.

• Metafile

A file that stores an image in terms of graphical objects (lines, circles, polygons) rather than pixels. When resized, a Metafile tends to preserve an image better than a Bitmap does.

• Media Control Interface. (MCI)

The Windows component that allows 'multimedia' devices, such as CD Rom drives and videodisk players to be programmed using high-level function calls that insulate the software from the nuances of the hardware. You can use the MCI 'play' command to play a song on an audio CD or a video-clip on a videodisk player. MCI drivers provided with windows translate the play command into low-level commands specific to the intended output device.

• Memory Manager.

Used to oversee Memory activity within the PC. Memory Managers exist that manage Ext. Memory (Himem.sys), Exp. Memory (EMM386.exe) and both. QEMM/386 is a Wins compatible Memory Manager by Quarter-deck Office Systems, Santa Monica, CA.

• Modes of CPU Operation.

The introduction of the x386 meant that now three basic CPU Modes were supported, Real Address Mode, Protected Mode ( introduced on the x286 including Wins modes of operation Standard Mode and on an x386, Enhanced Mode) and Virtual 8086 Mode (V86 Mode). The basic proging model of the 8086 is still intact in the latest Pentium devices. Basically, all of the app level resources such as registers, data types and addressing modes have simply been extensions to the original 8086 set of resources, primarily to support larger data types and addresses.

• Musical Instrument Digital Interface (MIDI).

A specification that standardises the interface between computers and digital devices that simulate musical instruments. Rather than transmit bulky digitised sound samples, a PC generates music on a MIDI synthesiser by sending commands just a few bytes in length characterising the pitch and duration of sounds (and the instruments that produce them) through a unidirectional serial cable. Each channel of a MDI synthesiser corresponds to a different instrument, or 'voice', and you can program several channels simultaneously to produce symphonic sound.

• Multiple Document Interface (MDI) Application

Typically, the main window in a GUI app either supports opening multiple documents (MDI- for example, text files, DBs or spreadsheets) or just a single doc (SDI, is not as common). An MDI app is structured around the presentation of multiple docs simultaneously in many windows. It typically uses a shell window as the main, or 'owner' window. The docs that are opened in the shell window are typically child app windows or data windows. A Wins proging convention which allows an app to manage several docs, or views of docs, each in its own child window, all in an app framework window. Child Window An MDI doc window displaying a doc or view within the main app window. Single Document Interface An SDI app is structured around displaying one app at a time, and it typically uses a 'top' app as the main window. In this case, the child window is also a child app window or data window.

Multithreading & Multitasking.

Multitasking has come to be a nebulous term, a 'task' is essentially an app that is running and there are several 'housekeeping' apps getting work done when you start Wins. For example 'Explorer' or 'Prog Manager' is considered a task and so is a screen saver a task. There are numerous 'system' related tasks such as the Wins kernel. The terms 'process' and 'task' are often used interchangeably to refer to an app or thread (a thread being one 'route' of many possibilities that a prog is following) that is running.

In Wins 3.x you can associate every task with a single app, and a single thread of execution. The definition of task doesn't really stop here for Wins'95 and NT. Some 32-bit apps use a technique called Multithreading that enables them to perform more than one task at a time within the same app e.g you could recalculate a spreadsheet and print at the same time, the spreadsheet starting another task called a thread to take care of printing. One way to look at threads is a sub-task under the app that is running.

A basic definition of multitasking says "several tasks (or processes) running at the same time on one m/c" (or so it would appear to the user). This is done by 'switching' from one task to another at short time intervals (usually less than a second) and how the O>S allocates time between tasks is an important consideration. Wins 3.x introduced a technique of non-pre-emptive multitasking or Co-operative multitasking. which waits for a task to complete its operations before giving control of the CPU to another task.

However, Wins NT and Wins'95 are noted for their use of Pre-emptive Multitasking, which works closer to the idea allocating a set time interval and transfers control of the CPU to another task every time that interval has elapsed, which is much more efficient and beneficial to the user.

Multitasking and Multithreading are two terms often used together to describe 32-bit versions of Wins and OS/2. A multitasking O>S allows two or more apps to run concurrently by dividing CPU time between them, in the pre-emptive fashion. Multithreading means that the O>S supports multiple concurrent threads of execution within a single app, if the app is written to enable flow along possible multiple threads of execution.

In the Win32 environment progs are no longer thought of in terms of tasks, but rather in terms of processes and threads. A process is one instance of a running app and all the memory and other resources associated with it. A thread is one path of execution through the app code. A process can consist of one thread or many. Additionally, processes and threads are pre-emptively