Along with some flaws, Microsoft's Visual C++ 32-bit Edition delivers effective programming tools and ways to port 16-bit Windows applications
Oliver Sharp
Programmers currently using Microsoft's Visual C++ will find the new version for NT familiar: The tools and libraries are almost identical. They will also find that Microsoft Visual C++ development system 32-bit Edition for Windows and Windows NT isn't flawless, but it does provide an abundance of tools and on-line documentation that help programmers take advantage of Windows NT's capabilities.
Distributed on a CD-ROM, VC++/NT comes with two complete compilation environments, one that runs under NT and one that runs under Windows 3.1. However, the latter can create only executable files that use the Win32s subsystem, so you can't
build Win16 executables. The full NT development environment is over 70 MB, although you can cut down on the space needed by leaving out some features or by running the compiler from the CD-ROM. In addition, the CD-ROM includes over 70 MB of documentation.
Like its 16-bit cousin, the NT version uses Visual Workbench to integrate tools by providing access to the compiler, debugger, profiler, code browser, and programming aids called application wizards. But VC++/NT improves on its predecessor by including all the tools and API documentation formerly available only in the Windows NT SDK (Software Development Kit).
The Programming Environment
To test the Windows NT programming capabilities, I built a Win32-based telephone database manager that uses the Windows interface. The program allows access to multiple databases, performs various searches, and can output formatted reports. It takes advantage of the new features of the Win32 API by using multiple threads: A thread is spawned to format the
database, and each document has a background thread that keeps an index up to date. Whenever you modify the database, the thread wakes up and updates its information in the background.
The Visual Workbench allows easy access to the definitions of functions and variables, documentation for the operating-system calls, and the debugging and applications development tools. With practice, you'll be able to navigate through the system comfortably.
The Workbench's editor is flawed, however. In any environment, an editor is one of the most important programming tools, and in VC++/NT the editor serves as the glue that binds the entire system together. Unfortunately, it's underpowered and difficult to replace. It is not programmable, doesn't provide flexible control of key bindings, and has a fixed strategy for syntax highlighting. If you're a programmer who spends a long time customizing your favorite editor to make it an efficient tool, you will probably not be satisfied with these shortcomings, and the
environment doesn't provide much support for using an alternative.
You can add your own editor to the tools menu and use it on files. But once you begin debugging, browsing, and navigating through your application to look up definitions, you must switch to the built-in editor, because there is no interface for sending status messages to an alternative one. Windows programming generally requires you to spend most of your time making incremental modifications in the midst of debugging and testing, so you will spend a lot of time in the built-in editor or lose the convenient interaction of the various tools. I hope Microsoft improves the editor in future releases or provides better support for integrating third-party offerings.
Nevertheless, the Visual Workbench has some good features. One is the high degree of control it gives you when you build programs. Menus provide easy access to the different options available in the compiler and linker. In addition, the dialog boxes show the list of corresp
onding arguments that will be sent to the tools.
The Wizards
A distinguishing feature of VC++/NT is the set of wizards--programming tools that generate code you can use as a start toward an application. With practice, you can construct simple applications quickly using wizards. I used them to produce the interface to my multithreaded database browser.
To build an application using the wizards, you first open the AppWizard. It produces a generic application framework by displaying a window with a list of possible menu options for you to invoke or delete, depending on your application. Next, you design dialog boxes, menus, and other graphical resources in the App Studio. Then the ClassWizard allows you to tie these pieces to your code: It produces the appropriate procedure stubs for you to fill in. In the case of the database browser, I used App Studio and the ClassWizard to add dialog boxes (to ask the user for such things as search criteria and output formatting preferences), as well as to se
t various menu options and do some on-screen formatting.
When you write code to handle various events, you interact with the internal state of the application. The world is divided up into documents containing objects, and the user can see any number of views of the document. You can modify objects based on system or user events; periodically, the objects will be asked to refresh their visual representation.
The wizards assume various idioms supported by MFC (Microsoft Foundation Classes) 2.0, which provides class definitions for Windows objects and the connections needed for Windows event handling. If you create your own data structures, you must conform to the wizards' assumptions about idioms. For example, documents are saved by passing a serialize object to every object in the document. Each object in the document is responsible for saving or restoring itself by writing to or reading from the serialize object.
Unlike in some other programming environments, the wizards don't keep the i
nterface and the guts of the application separate. After the wizards produce their code, you live within the application and are not shielded from it in any way. Whether you like that strategy is something of a personal preference; some programmers prefer to have more abstraction, while others like to see all the code together. Given the path VC++/NT has chosen, I found that the code it produced was easy to work with. It is well structured and well commented, and modifying the code is straightforward.
A more curmudgeonly lot of programmers object to having tools build their applications at all. These programmers may accept visual-resource editors, but they want to be in control of all the code. Thus, many of the tools in VC++/NT won't interest them much, but they will find the abundance of source code to be a real help. They can work with or modify it to their liking, using it as a model when they forge their own path. Although the wizards rely on MFC extensively, MFC can still be useful to programmers
who choose to perform their own sorcery. The classes, which come with full source code, provide a variety of useful data structures and access to complicated subsystems like OLE.
Multithreaded Applications
Adding threads to programs that use MFC can be a problem, because the classes are not reentrant; that is, they cannot be used by different threads at the same time. There is a reentrant C library, however, so threads are free to use the standard C functions when that version of the library is linked in. If you want to use threads in a program relying on MFC, you first need to recompile the MFC library itself to use the reentrant C library. Then the threads can use the C library functions and walk over internal data structures, as long as they stay away from the MFC. (Microsoft plans a reentrant version of MFC in the next release of VC++/NT.)
In my case, the restriction wasn't too onerous because I was using threads to handle time-consuming operations on basic data structures. In my applica
tion, some of the menu choices invoke handlers that spawn a thread; they immediately return, leaving the thread to continue working in the background. One separate thread is invoked when each document is opened. The thread hovers in the background until the document is closed, waiting on a semaphore. When it wakes, the thread checks to see if it was awakened in order to terminate; if not, it knows that the database has been modified and the index must be updated. If you have a more ambitious use of threads in mind, such as using them to modify different parts of the GUI simultaneously, you'll need to abandon MFC or wait for a subsequent release.
Other Tools
The VC++/NT debugger is also integrated into the Visual Workbench. It has the usual features for stepping through the source code being executed, and a flexible facility for specifying breakpoints. The debugger allows you to examine data structures and expression values in a dialog box called Quick Watch. You can add a value that you examine in Q
uick Watch to a watchpoint window in Workbench. Expressions in the watchpoint window are updated whenever you suspend an execution. Also, the support for multiple threads is handy. You can suspend and resume them individually and switch the active focus among them.
The on-line documentation in VC++/NT is extensive and very useful, and I found myself spending a lot of time in it. It comes with a browsing utility that is an improved version of the standard help-file browser. The documentation isn't flawless: It's plagued by some unclear language and typos in both text and sample code. Caveats aside, after you have had some experience navigating through the documentation, you'll find it a terrific resource.
Another tool that was much updated in the move to NT is Spy++, which lets you explore the threads, processes, and windows that are currently active in the system. It's a useful tool for seeing how a multithreaded application is executing.
The Compiler
Although you'll spend most of your
time interacting with the programming environment, the heart of the system is the compiler. Microsoft has improved its compiler somewhat by adding support for Pentium optimization, but the main difference is the move to a flat 32-bit address space. As in previous versions of Visual C++, the compiler produces code that is efficient in both space required and execution speed. As the graph shows, compilation speed is on a par with that of Watcom C/C++32, the fastest product in BYTE's recent roundup of C++ compilers (see "C++ Does Windows," September 1993 BYTE). The compiler is also heavily dependent on the amount of memory in the system: I strongly second Microsoft's recommendation of at least 20 MB of RAM.
You also need adequate disk space. The compiler takes up 60 MB to 80 MB, and each application you're working in takes its share. Just the basic application framework, when compiled in debugging mode, chews up 6 MB with all its subsidiary files. When you compile for distribution, the executable file sh
rinks below 150 KB, but if you have several projects in progress at once, you'll use a lot of hard disk acreage.
Microsoft has added some new features to the compiler to better support the NT environment. In particular, it has added direct language support to allow the C/C++ programmer to deal with threads more easily. There is a direct call for creating a new thread (_beginthread) and passing arguments to it; the construct is mapped to the appropriate API calls by the compiler. You can specify that static or global data is to be thread-specific by using the C++ extended declaration facility: Specifying the declaration _decl-spec(thread) int foo tells the compiler that each thread is to have a private instance of the variable. Local variables do not need special treatment because each thread has its own stack.
One significant problem with the compiler is that it does not support strict ANSI compatibility. Microsoft chose to support only the functionality of cfront 2.1, adding exception handling
via preprocessor macros and the compiler. The C++ exception-handling mechanism in cfront 3.0 and the use of templates are not supported. This decision has unfortunate consequences for the C++ programmer who is familiar with the ANSI dialect or who wishes to use sample code that relies on it. Templates are such a useful mechanism that C++ programmers are increasingly encouraged to use them; it's a pity that they're not available in VC++/NT. Microsoft says that an updated version of VC++/NT, due later this year, will support both cfront 3.0 exception handling and templates.
32-bit Changes
In moving from the 16-bit to the 32-bit version, programmers face a variety of changes. Some are caused by the switch to a new API, and some by the updated programming environment.
The Win32 API has a lot of new features, ranging from Bˇzier curves and security to support for multiple threads. An application that uses threads effectively performs time-consuming operations in the background and lets you carry o
n with your programming. But these benefits don't come free: You'll often need to recast the structure of your application to take advantage of threads. The compiler can't do much to help you with that.
The Visual C++ environment has also been upgraded with new features in the NT version. A major improvement is that the package now includes tools and documentation formerly available only in the Windows NT SDK. One of the tools is the help compiler, which converts annotated RTF files that you can produce with Microsoft Word or other tools into the HLP files that the NT help system understands. In addition to the SDK additions, new monitoring tools let you watch the interactions between threads and DDE communication. The profiler has also been improved with a better interface.
Since the Win32 API is the only one supported, you need to recode applications relying on Win16 API features. For example, the Win16 communication API has been replaced; NT programs communicate through a serial port with the
same calls that handle file I/O. All support for DOS has been dropped, and applications can no longer access INI files directly. Most other changes in the API are to functions that formerly returned 16-bit values packed into a 32-bit word. The on-line documentation summarizes the various changes.
Microsoft also dropped the QuickWin environment that supported DOS programmers with a simple Windows API. You must either use the Console API or move entirely into the Windows environment. VBX custom controls are gone, too.
Is the 32-bit Version for You?
Should you switch to the 32-bit version? It depends on what environment you're moving from and whether you plan to take advantage of the Windows interface.
If you currently write programs using simple-stream I/O or full-screen text I/O, the NT version will let you either take the plunge into Windows programming or settle for the Console API's more limited functionality. To test the latter, I ported Unix and Win16 applications. The Unix progra
ms consisted of two-stream I/O filters that manipulated a phone database, performing lookups and converting the database into a formatted form for printing. The Win16 application was a text browser.
I found the consoles fairly simple to manage: The API consists of a few dozen functions that let you create a console, control the cursor, do simple I/O, and catch some kinds of events, like mouse-clicks. Consoles are also handy for debugging GUI applications, because the program can output status messages and accept debugging input even when the primary graphical interface is not working or is incomplete. While it's simple to port applications to the Console API, programmers who don't need more than that from their development environment will have little reason to favor VC++/NT over its competitors. And if strict ANSI compatibility is important to you now, you would be well advised to look elsewhere.
On the other hand, the audience Microsoft is really aiming at is the current body of Windows 3.1 pr
ogrammers. They will find much to like about VC++/NT, particularly if they've been using its predecessor. One of the highest priorities in designing NT was making it easy for programmers to port their 16-bit Windows applications quickly and easily. By following the Win16 API closely and porting MFC 2.0 to NT, Microsoft has done most of the porting work for you. What remains is to get rid of the segmented memory assumptions, fix some data-structure packing issues, and move to a somewhat changed API.
To ease the transition, Microsoft supplies PortTool. It runs through a Win16 program and identifies places where the API has changed or where there are 16-bit declarations that are no longer valid. PortTool is not integrated into the Visual Workbench. To access it, you have to invoke it manually or add it to the Tools menu. You can use it to go through your program interactively, or it can process files and add comments where it found potential problems. Microsoft supplies source code, so you can tailor the
program to your needs if you are planning to use it repeatedly. While it's hardly a panacea, PortTool is a useful tool for finding trouble spots.
The bottom line: VC++/NT is the programming environment to beat--every other NT compiler will inevitably be compared to it. Although there are some flaws and weaknesses, Microsoft has succeeded in delivering an integrated package with the tools and documentation that allow a Windows NT programmer to take full advantage of the operating system.
Microsoft Visual C++
32-bit Edition for Windows and Windows NT $599
Microsoft Corp.
1 Microsoft Way
Redmond, WA 98052
(800) 426-9400
(206) 936-8661
fax: (206) 936-7329
Screen: App Studio, a programming tool that edits resources associated with an application, here is modifying a menu structure (top). You can change menu properties in the dialog box shown in the bottom foreground.
Illustration: Compiler Comparisons
When generating Windows N
T executable files, the compiler in Microsoft Visual C++ 32-bit Edition performed equivalently to Watcom C/C++'s compiler, the fastest one we've tested. Microsoft scores are indexed against Watcom results, which equal 1. The tests consisted of BYTE's portable C benchmarks, with both compilers set to generate speed-optimized 486 code. Tests ran on a 50-MHz Everex 486DX2 with 256 KB of cache and 16 MB of RAM.
Oliver Sharp is an associate at Heuristicrats Research, Inc., an optimization software developer in Berkeley, California. He is completing his Ph.D. in computer science at the University of California- Berkeley, investigating compilation for parallel architectures. He can be reached on BIX c/o "editors" or on the Internet at
oliver@heuristicrat.com
.
NT Programming's Early Leader
