Bailey O.H.Embedded systems.Desktop integration.2005

Windows Application Programming

Layers

The Dynamic-Link Library (DLL)

Microsoft has taken a unique approach to distributed computing. First, they introduced the dynamic-link library (DLL). This is a shared code library that allows a single instance of code to support many applications at the same time. This conserves the use of memory in exchange for the overheard of switching between different application stacks that may be using the library simultaneously. In short, you save memory at the expense of speed. Since time-critical portions of code normally run at the driver or OS level, this usually has little effect on overall program performance. A counter keeps track of how many applications are using the library, and when the count reaches 0 the library is closed and eventually released from memory.

The Visual Basic Control (VBX)

Because of the amount of labor it took to build good Windows code, Microsoft responded with the VBX control architecture. This allowed developers to write controls that could be used in any language that supported the VBX package architecture.

While it didn’t reduce the amount of labor it took to build program components, it did allow the components to be included in other programs while not permitting the original code to be tampered with. The architecture was slow to be accepted by the development community due to its complexity.

Chapter 4

over the years. .NET compiles code at run time rather than at compile time. Until .NET, most development languages for Windows generated machine-executable code. With .NET, however, an intermediate file is generated. This intermediate file is then translated into machine-executable code when the program is executed. One obvious advantage of this is the ability to create a single intermediate program file that can be run on any system with a .NET framework installed. This means that you can distribute your program to any system that supports .NET and it will run. Linux, Solaris, UNIX, and even mainframe systems will eventually support the .NET framework. While this is an advantage, there are also a couple of disadvantages. First, the intermediate code can be easily reverse-engineered so anyone can see your program and intellectual property. There are, however, tools available to encrypt the intermediate file so the code cannot be seen. It also takes longer to load the program since it has to be compiled at run time. Not all systems have .NET integrated yet, so your program may also run slower after it has been compiled to machine language.

Using .NET means the compiler vendor will parse their language file and send the resulting code to the Microsoft intermediate compiler. This will all but eliminate some of the advantages that other compiler vendors have gained over the years in speed and performance. When an update is made to the current .NET framework, programs will be able to take advantage of the features immediately and without a new distribution of the program from the vendor. All in all, the .NET strategy does make sense if implemented properly. There are two development projects currently going on to implement .NET on UNIX and Linux. When completed, you should be able to take your Windows program and execute it on UNIX and Windows (if all works as expected). Currently the .NET framework is available for Windows 98, ME, NT, 2000, and XP as a download. Windows Server 2003 and later operating system releases will have .NET integrated into the core OS. The following diagram illustrates how

.NET integrates into existing systems.

Chapter 4

In the early 1980s, MIT introduced the UNIX world to X Windows. Since UNIX was not originally designed as a graphicsbased system, its graphic desktop implemention was developed in layers. The lowest level layer was the display manager or server. The display manager was combined with a graphic server with the task of collecting input from users (keystrokes and mouse data) and responding with the data for those requests. To display the data in a display-independent graphic format, the client was written as a separate program that could be run either on the local machine or on a remote desktop. Separating the display manager and display client allowed a single display manager the ability to handle multiple displays of different height, width, and color depth. The client in this case was responsible for the display parameters and the server was responsible for seeing that input and output requests were handled in an orderly fashion.

A layered approach also provides more of a building block type approach to user application development. Each layer can build upon the previous layers, which allow high-level user interfaces and developer libraries to be implemented. This architecture also allows cross-platform tools and libraries to be more easily developed as shown in Figure 4-2.

Remote Access Methods

Hardware Layer

Figure 4-2

This figure breaks down the different layers of the UNIX display management system. There are many desktop managers

Chapter 4

Figure 4-3

As you can see, a display manager can serve clients on remote machines as easily as it can on the server machine. The UNIX or Linux server task manager communicates with the X Server layer, which is located in the same layer as the physical transport layer. The physical transport layer handles both local and remote clients in addition to keyboard, mouse, and network communications.

Chapter 4

the same application as the client. The available X Window client/server products have a wide variety of price ranges and features.

Alternatives to the X Windows Approach

There are alternatives to using the X Client/Server approach. Now you may be asking why a developer would want to use an alternative if this approach is truly efficient on resource usage. The answer lies in how much time you can afford to spend setting up the X environment for remote access and how familiar you are with X Windows setup and administration.

Setting up a suitable X Windows client/server environment can be a very time-consuming task. It requires the altering of setup files on the client and server machines and additional network setup as well. If you are going to use this feature across the Internet, a secure socket layer is strongly recommended, which adds even more complexity to the setup process.

One alternative to X Windows is the Virtual Network Computing product (VNC). VNC was originally developed by Bell Labs of the UK (the former Olivetti development center). VNC also requires some setup on the client and server but is easier to learn and does not require an understanding of how X Windows works. VNC displays an entire desktop rather than a single application window. If you use Secure Sockets, the difference is running a single application versus displaying and accessing an entire desktop session as a client. If user security is an important issue, providing access on an application basis is worth the additional effort and learning curve of X Windows.

Chapter 4