March 18, 1996 APPLICATION DEVELOPMENT 32-bit development: paradise beckons, but look before you enter By Alan Radding M icrosoft has been able to make the migration from 16-bit to 32-bit computing nearly transparent for Windows 95 users, but application developers face significantly more hurdles. Building applications for 32 bits requires new skills, different tools, and extra effort to ensure backward compatibility with 16-bit Windows 3.1. That isn't to say it's a world without its own distinct advantages and enticements: 32-bit computing promises to finally put an end to the long-standing limitations of having DOS underlying Windows. "The most important change that developers will see is the bigger address space," says Judith Hurwitz, president of Hurwitz Consulting Group, in Newton, Mass. This address space results from the flat memory model enabled by 32-bit computing. "Going from 16-bit to 32-bit is a great relief. You don't have to sweat the memory management," says Henry Blake, an independent consultant working under the business name Source Maverick, in Mesa, Ariz. When he was building 16-bit Windows apps, Blake spent inordinate amounts of time juggling memory to get around the 64KB limitation of DOS. The arrival of 32-bit Windows computing, with its huge flat memory, comes just in time. "A lot of the things clients want to do these days just use tons of memory," Blake says. Another big change in 32-bit operating systems from a developer's standpoint is preemptive multitasking, which allows multiple applications to be actively processing, one in the foreground and the rest in the background. Win95 (as well as Windows NT) also provides multithreading, allowing developers to divide application processes into multiple threads that appear to run concurrently and, in many cases, enabling much greater application performance. GET YOUR TOOLBOX. To rewrite their applications to take advantage of all these 32-bit attractions, software developers need application development tools that support the Win 32 API. The basic low-level tools, such as compilers and debuggers, have been available for several years; however, the vast majority of higher level development tools have been slower to migrate to 32-bit computing. But that is changing. "We are just seeing the start of a strong movement [of tool vendors] to 32-bit computing. While I wouldn't characterize it as a rush, it isn't a trickle either," says Evan Quinn, research manager, application development tools, at International Data Corp., in Framingham, Mass. Borland International Inc., Powersoft Corp., Centura Software Corp. (formerly Gupta Corp.), Watcom International Corp., and of course, Microsoft Corp. have already moved into the 32-bit Windows space, but others are coming along more slowly. WHERE ARE THE CUSTOMERS? Perception rather than demand is driving the market. "Vendors are concerned that if their tools don't support Windows 95, they will be perceived as falling behind," Hurwitz notes. "But we haven't seen any real user demand yet." Blake's experience underscores this lack of demand. "I'm finding it difficult to convince my clients to look at 32-bit Windows. Most of them are choosing to stay in 16-bit Windows-land, at least until next year, they tell me," Blake says. Tool makers aren't terribly disappointed, because they are already looking ahead. "All of the tool vendors will offer Windows 95 support, but they see Windows NT as more strategic, particularly for the high-end tools," Hurwitz adds. TAKING ADVANTAGE OF THE WAIT. Developers at a company that has chosen to delay its move to the 32-bit world can use the time to get up to speed with 32-bit Windows computing. The benefits don't come automatically. Applications have to be written to take full advantage of multithreading and the larger memory if users are to experience the performance gains they expect. Developers will also need to pay attention to backward compatibility. The huge installed base of Windows 3.1 systems is not going to be replaced overnight by Windows 95. There are several options when it comes to achieving backward compatibility, each with its own drawbacks. Developers can write their applications twice, once for Windows 3.1 and again for 32-bit Windows, or use the Win32s API provided by Microsoft. The first approach -- writing the applications twice -- has obvious drawbacks in terms of development and maintenance time, effort, and cost, but it allows developers to get full native functionality and performance on each platform. The Win32s API offers a more efficient solution, but it requires trade-offs in terms of performance and functionality. The Win32s API consists of code that enables Windows 3.1 to run 32-bit applications in emulation on Windows 3.1 clients. Because it is only a subset of the full 32-bit Win32 API, however, Win32s does not support all Win32 functions. For example, Win32s can't help you with multithreading because Windows 3.1 simply can't do that. "You have to write plain code, skipping all the fancy stuff," Blake notes. But the fancy stuff, such as multithreading, is what makes 32-bit computing attractive in the first place. The compatibility problem doesn't even go away when you develop only for 32-bit Windows 95 and Windows NT. "If you build a high-end application that takes advantage of the operating system specifics, such as security, it won't run across Windows 95 and Windows NT. You have to know the differences between the two operating systems," says Deanne Farrar, product marketing manager at Powersoft's languages division, in Waterloo, Ontario. One source of the compatibility problem is the 16-bit code that is buried in Windows 95. "If you aren't careful, you can get in trouble," Blake warns. He ran into just such a problem when building a mapping application, he adds. It worked fine with Windows NT, which is 32-bit throughout, but had problems on Windows 95, which couldn't handle the 32-bit graphics because the graphic subsystem of Windows 95 still used 16-bit code. Organizations can debate the value of migrating to 32-bit Windows this year. But, similar to the DOS vs. Windows decision that companies were facing five or six years ago, the migration to 32-bit Windows is inevitable for Windows users. By next year or the following year, the decision will be a no-brainer: All new commercial applications will take advantage of 32-bit operating system capabilities and vendors will start dropping support for 16-bit applications altogether. Corporate developers will have to follow suit. Alan Radding is a free-lance writer based in Newton, Mass. Copyright © 1996 by InfoWorld Publishing Company

Return to the Special Report page