Choosing Between API Sets

The number of Win32 implementations the application designer might be considering is growing. At present these consist of Windows NT and Win32s™. As you certainly know by now, Win32s is implemented on top of 16-bit Windows so that Win32s applications can gain the benefits of a 32-bit address space, but still execute on existing 16-bit Windows systems. The existence of these two flavors of the Win32 API complicates the design decisions for the application programmer primarily in the performance arena. This is because Win32s offers the application the advantages of the 32-bit address space, but continues to be subject to the internal restrictions of 16-bit Windows (and to some extent, MS-DOS).

Therefore optimizations made for Windows NT will not always port to Win32s, and vice versa. Here we'll summarize which optimizations apply to which Win32 implementations.

The following table lists the various optimizations and tools presented in this chapter, and indicates where they apply. (Many of the tools listed at the end of the table are discussed in Chapter 10, "Tuning Windows NT Applications," and Chapter 11, "Tuning the Working Set of Your Application.") The abbreviations used in the table are:

Yes	OK to use in this implementation
N/A	Not applicable, does not apply to Win32s
No-op	You can do this without effect on Win32s
No	No, don't do this on Win32s

Optimization	Windows NT	Win32s
Kernel optimizations:
Large address space	Yes	Yes
Discard old custom virtual memory schemes	Yes	Yes
Use memory-mapped files for file access	Yes	Yes
Reserve large data address spaces, but commit only what you need	Yes	Yes
Use named shared virtual memory	Yes	Yes
For sequential I/O, use 4K or 8K blocks	Yes	Yes
Use threads to enhance concurrency	Yes	No
Keep files open	Yes	No
Global and Local allocation are the same	Yes	No
Real-time priority for data communications	Yes	No
Page-Locking API is provided	Yes	Yes
Use new data type MULTI_SZ in Registry	Yes	No
Write the application using Unicode	Yes	No
No disk cache tuning required	Yes	No
Graphics:
Client-server protection dominates	Yes	N/A
Batching of calls amortizes cost	Yes	N/A
Caching of values on client side reduces cost	Yes	N/A
Mapping of server data read-only to client	Yes	N/A
Batch output functions that return a Boolean result	Yes	N/A
SetPixelV and MoveToEx are batched	Yes	No-op
New APIs Gdi{Get\|Set}BatchLimit, GdiFlush help	Yes	No-op
Set batch limit as high as possible while avoiding jerky display	Yes	No-op
Most "user" (that is, Windows management) calls flush the batch	Yes	No-op
GDI calls that return a number or a handle flush the batch	Yes	No-op
Selecting fonts, brushes, and pens do not flush the batch	Yes	No-op
Selecting bitmaps and regions flush the batch	Yes	No-op
SetWorldTransform and SetMapMode flush the batch	Yes	No-op
GdiSetBatchLimit(1) only to see errors, or	Yes	No-op
GdiSetBatchLimit(1) only to profile API calls	Yes	No-op
Use new Poly calls as much as possible	Yes	Yes
Avoid Create, Select, Use, Select former, Destroy	Yes	No
Create, Create, Create; Select and Use, Use, Use...	Yes	No
Richer structures to hold unlimited objects	Yes	N/A
Group attribute usage: gray, gray, gray, red, red	Yes	Yes
Grouping avoids cache lookup for pens, fonts, colors, palettes, brushes	Yes	Yes
Use CS_OWNDC in RegisterClass	Yes	No
CreateWindow, Get(Own)DC set DC attributes only once	Yes	No
Timers are no longer precious	Yes	No
Less need to use PeekMessage frequently	Yes	No
Write to Unicode	Yes	No
RISC:
Be sure to align data	Yes	No
Compiler pragma for handling file/net data	Yes	Yes
Exception handling for data alignment not supported	varies	N/A
Tools:
Win32 API Profiler	Yes	Yes1
Win32 Call/Attributed Profiler	Yes	No
Working Set Tuner	Yes	2
VADump	Yes	2
PView	Yes	No
Debugger wt command	Yes	No
Performance Monitor	Yes	No

1 There are two Win32 API Profilers: one for Windows NT, and another for Win32s.

2 Working set tuning done on Windows NT will apply without further effort to the same application running on Win32s.