Updated: March 12,1996

Go To TechNet Home Page

Why Port Windows Applications to Win32?-Contents

by John Jacobs
7/31/95

ABSTRACT: This document compares the costs and benefits to MIS that result from porting Windows applications to the Win32 API. Most of the emphasis is on the benefits and costs of running Win32-based applications on Windows 95 and Windows NT.

Introduction
Running Windows Applications on 16-bit Windows
Running Windows Applications on 32-bit Windows
Running Win32-based Applications on 32-bit Windows
Offsetting Port Costs
Conclusion

If you browse the game titles at your nearest software store, you'll find a variety of simulations, which let you control anything from an ant nest to an ecosystem, from a city to a civilization. However, you won't find a "Sim-Port" game, where you take control of a virtual software porting lab, scheduling people, time, and resources to port an imaginary company's applications from one platform to another. The reason seems clear: the job already exists for real, and if you're reading this article, it's a good bet that this is your job, and you're in it for the money rather than for the fun. To help you do that job, this article compares the benefits and costs of porting your company's applications from the Win16 Application Programming Interface (API) to the Win32 API, as well as the costs of not porting them.

First, we should discuss briefly these two APIs.

Win16

Win16 is the native API set of 16-bit Windows 3.x. It was initially designed in the late 1980s and delivered with Windows 3.0 in 1990. At that time, a large segment of the PC market was based on 16-bit Intel 80286 processors, and Windows 3.0 needed solid support for the 80286 in order to succeed. For simplicity and size, little of the Windows 3.1 code is processor specific: Windows loads most of the same system components on an 80286 as it does on a Pentium. Like Windows itself, the Win16 API still reflects the need to support 16-bit processors. In short, the compiled code of a Windows application largely assumes that it is running on a 16-bit processor, and it does not exploit many of the features of 32-bit processors. The exception is the Kernel (KRNL286.EXE and KRNL386.EXE).

On the one hand, its enormous popularity today shows that it had met many needs. Unfortunately, as users become more familiar with the potential of the Windows environment, their expectations and demands increased. Microsoft has put the time and effort into developing Win32 to meet these demands.

Win32

Win32 is the native API set of Windows 95 and Windows NT. Win32 is designed to assume a 32-bit processor, and it takes advantage of the processor to overcome many of Win16's limits, and provide new features. The limits that Win32 overcomes include inefficient handling three-byte and four-byte values, a segmented memory model, single-threaded applications, and non-preemptive multitasking. Win32 imposes one new limit: it will not run on an 80286 processor.

The remainder of this document discusses how the benefits and costs of ignoring the improvements in Win32 by staying with 16-bit applications on 16-bit Windows, of upgrading to 32-bit Windows without porting your applications, and of running 32-bit applications on 32-bit Windows.
Document Table of Contents

One option is to leave the applications and operating systems alone. While this doesn't impose any tangible, new costs, it doesn't give you any new benefits, either.

Benefits

The short term benefits of running your existing Windows applications on 16-bit Windows:

· You don't have to port the applications

If you don't port the applications, then you don't need to take people away from other projects, you don't have to wait for those people to produce anything, and you don't need to spend money on the resources they would need to perform the port.

· You don't have to upgrade the operating system

If you stick to Windows 3.x, then your staff doesn't need to spend time upgrading people's operating systems, or upgrading their 16-bit computers.

Costs

By not upgrading, you restrict yourself to the inherent limits of Windows applications and Windows 3.x itself.

· Windows 3.x and Windows applications often restrict data structure sizes to 64k to ensure they can reference any element of the structure using a 16-bit number, because referencing a value in a larger data structure would require using two 16-bit values, and this increases overhead and decreases performance.

· Windows applications share a single input queue. If one application fails to yield control of that queue, all other Windows applications that are waiting for input will hang.

· Windows applications share a single memory address space. If one application improperly references memory owned by another application (or by Windows itself), one or both applications can crash.

· 16-bit Office-based solutions may not function correctly on Windows 95 systems running Office 95. This can be problematic if some of your corporate users do not upgrade to Windows 95 and Office 95, while other users (such as those with computers at home) do upgrade.
Document Table of Contents

You might decide to run your existing Windows applications on Windows 95 or Windows NT. You can gain some operating system benefits this way, but the drawbacks of Windows applications don't go away just because you move to a 32-bit operating system.

Benefits

· You don't have to allocate time, people, or resources to porting your applications.

· You can take advantage of operating system features.

For instance, you can use most Windows communications applications with PCMCIA modems, because Windows 95 and Windows NT provide the necessary hardware support. Also, you can share data files created by Windows applications with the user-level security provided by Windows 95 and Windows NT.

If you use Windows NT, you can run Windows applications in their own memory address spaces, so that they can't corrupt each other, and those Windows applications will benefit if they are memory, floating-point, or graphics intensive.

Costs

The costs in this scenario aren't much different from the last one. Many Windows application limits are imposed by the Win16 API, not by Windows 3.x. For example:

· Windows applications are inherently single-threaded, so they can only do one job at a time, even if you run them on a multithreaded operating system.

· Their compiled code still loads registers with 16 bits of information, even though any computer that can run 32-bit Windows by definition has a 32-bit processor (or better).

· Windows applications interact with a 32-bit operating system through a translation layer, and the resulting overhead can slow their performance.
Document Table of Contents

The greatest benefits appear when you run Win32-based applications on Windows 95 or Windows NT. At the same time, you need to account for the costs of porting your applications, and you need to expect that some applications will benefit more than others.

Benefits

The benefits of running Win32-based applications on Windows 95 or Windows NT are compelling. The reasons break down into three categories: decreased downtime, increased efficiency at the application level, and improved user productivity.

Decreased Downtime

Win32-based applications can take advantage of structured exception handling, which improves their overall robustness.

· Preemptive multitasking, along with multiple input queues, keep any single Win32-based application from interrupting other applications.

· Protected memory address spaces keep errant Win32-based applications from corrupting other applications' memory spaces.

These features minimize the impact that application bugs have on the system as a whole, and thereby save time and money for your users and your MIS department.

Increased Application Efficiency

Win32-based applications running on Windows 95 or Windows NT can outperform their Windows counterparts in several ways.

· Multithreading

Win32-based applications can maintain multiple threads of execution, each of which can do work independently of the others. For instance, one thread in a client application can start a query against a database server, while another thread accepts the user's input, and a third composes a report.

· Faster Operation

Win32-based applications can more quickly and easily manipulate three-byte and four-byte values. Also, they can reference memory locations more efficiently. Finally, many compilers create tighter assembly-language code when you compile high-level languages for a 32-bit processor than for a 16-bit processor. I need to get more hard info on this topic.

· Larger Data Sets

Win32-based applications can manipulate larger data sets more easily than their Windows counterparts because they can reference any memory address in a 4 gigabyte range with a single 32-bit register. 64k limits no longer apply. I need to get more hard info on this topic, too.

Improved User Productivity

Win32-based applications receive the same benefits as Windows applications when they run on Windows 95 and Windows 95, such as hardware support and security. In addition:

Preemptive multitasking lets users move between Win32-based applications without delay;

Win32-based applications can use long file names;

Win32-based applications can take advantage of the Windows 95 user interface.

Costs

There are several costs in this scenario:

· The time, resources, and labor needed to port the applications (including programming tools, such as compilers);

· The time, resources, and labor needed to upgrade the operating system.

In addition, you should be aware that several factors affect the performance of a Win32-based application, relative to a Win16 equivalent, and some applications will benefit more than others. Finally, some Windows applications may rely on low-level hardware access (for example, writing directly to ports, drivers, or absolute addresses). These applications may not be portable because they cannot run on Windows NT.
Document Table of Contents

Porting applications involves time, people, and resources. Fortunately, the porting applications from the Win16 API to the Win32 API is relatively simple.

· Familiar API

Win32 is a superset of the Win16 API, which minimizes the code you need to completely rewrite, and because the naming conventions are the same, your familiarity with Win16 will pay off when you want to find and use Win32-specific calls.

· Solid Tools

Numerous porting tools are already available. For example, the PortTool application helps identify code fragments that need to change, and the Windows API Profiler (WAP) helps you identify spots where optimizations will pay the greatest dividends. Both tools ship with the Win32 SDK, and as demand for commercial Win32-based applications increases, so will the number of porting tools.

· Gradual Rollout

Windows 95 and Windows NT will run Windows applications, so you don't need to port all of your 16-bit applications at once.

Porting from Win32 to other platforms is relatively easy as well. Win32 is source-code compatible across platforms that support Windows NT, so if your Win32-based application is compiled for the Intel x86 platform, and you want to run the application on a RISC system running Windows NT, just recompile. Also, Microsoft supplies a tool to let you cross-compile Win32-based applications to run on Motorola-based or PowerPC-based Macintosh systems.

Variable Porting Benefits

People often ask, "How much will my Windows application benefit from a port to Win32?" No two applications are exactly alike, so there is no single answer to this question. In general, you will see less benefit from the port if the following are true:

1. Your application rarely manipulates values larger than 16 bits.

One of the key benefits of 32-bit code is the ability to manipulate values up to four bytes wide in a single register. Code fragments that don't need to manipulate three-byte or four-byte values won't benefit very much from the port, because a one-byte or two-byte value fits into a two-byte register as easily as it fits into a four-byte register.

2. Your application uses small data structures, whose elements can be referenced with a 16-bit value.

Again, a 16-bit index value doesn't gain anything by residing in a 32-bit register.

3. Your application spends most of its time making Windows API calls.

The implementations of many Win32 calls are cleaner than their Win16 counterparts, but these speed improvements aren't very noticeable.

4. Your application has been fine-tuned for a 16-bit environment.

If you've fine-tuned your code to work really well with 16-bit registers, it won't run any faster just because it's running in 32-bit registers.
Document Table of Contents

Document Table of Contents

Click Here to Search TechNet Web Contents

TechNet CD Overview

Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information.

Go To TechNet Home Page

©1996 Microsoft Corporation

Go To Microsoft Home Page