|
[ Go to April 1997 Table of Contents ]
Think Small If you're tired of bloated desktop programs, you can develop tiny ones for Windows CE and the Newton.
Ever since I wrote Advanced Windows Programming (Wiley, 1992), I've been associated with the API-level school of Windows programming. And with good reason-Windows programming is my specialty. So it was with some consternation that, over the last few years, I watched the rise of "soft" programming-the use of inherently fat languages like Visual Basic, and padded application frameworks like MFC. I was concerned, with some justification, that new Windows programmers weren't learning the guts of the system. Despite my concerns, most of the other programming gurus seemed to believe that code bloat didn't matter, because hardware would always get bigger, faster and less expensive. Well, it's payback time. Finally, some of the new devices aren't bigger and faster. Sure, the dual Pentium Pro desktop machines with 64MB of RAM and spacious hard disk storage that people are buying for development are bigger and faster. But hand-held PCs (HPCs) are not: They have 2MB or 4MB of RAM, a low-power processor, no disk and a small screen with four shades of gray. They run Windows CE, a system that looks a lot like a stripped-down version of Windows NT, and they run the system and their built-in software from ROM (see What's Hot, December 1996) Riding Pegasus To program for WinCE (which was code-named Pegasus), you currently need a copy of Visual C++ 4.0. You also need to apply for a free WinCE software development kit beta by sending e-mail to wcedev@microsoft.com. Soon, the shipping WinCE SDK will work with Visual C++ 5.0. (I don't know how it will be priced.) WinCE programmers must work at the 32-bit Windows API level, in C or possibly C++. Forget MFC, Visual Basic and the like-for now they are simply not supported. And since an HPC includes little memory, you'll need to conserve it; be prepared for memory allocations to fail and expect system notifications that ask you to release memory. WinCE supports only a subset of Win32. Some of the omissions are obviously justified: OLE support, for instance, would probably have doubled the ROM needed in an HPC. And multimedia support would hardly have been appropriate-although there is some support for playing 8-bit wave sounds. Other choices are not so obvious: The ancient MoveTo and LineTo GDI calls have disappeared in favor of Polyline, and 8-bit ANSI character sets have been dropped in favor of 16-bit Unicode. GlobalAlloc is gone, but LocalAlloc, HeapAlloc and Virtual Alloc are fully supported. Naturally, WinCE (http://www.microsoft.com/windowsce/. ) contains some new goodies; it also has a whole bunch of parameter changes and restrictions in otherwise familiar functions. Remember, this is a stripped-down system. For instance, you can use BitBlt, but only with the four most common ROP codes. There's no default menu and only one kind of window, so the parameters to CreateWindow are a little different than in other Win32 systems. There's no support for sizing windows: Most applications will run full-screen, which isn't quite the hardware screen size because the system taskbar is permanently visible. There are no cursors except for the hourglass. Of course, cursors aren't really necessary because pointing with a stylus is quite direct. Instead of having a title bar, menu bar and toolbars, WinCE applications may have a single command bar that appears at the top of the screen. New command bar APIs let the application create (add menus, buttons, combo boxes and separators to the command bar) and destroy the command bar. Since the command bar is optional, the application has to adjust its working client area when the command bar is displayed. Memory management The new WM_HIBERNATE message lets the system request that your application release some memory. It's critical to do so, because the whole device has limited RAM, which for lack of a hard disk includes files and databases, as well as what you normally think of as belonging in memory. If your application doesn't release memory when it receives WM_HIBERNATE (and perhaps even if it does), the next message you receive is likely to be WM_CLOSE, and you'd better be able to shut down without allocating any more memory. Otherwise, there might not even be enough available to allocate a dialog box. Files, databases and the system Registry are kept in an object store in RAM. The file and Registry APIs are familiar. The database APIs are new, and allow for the creation and manipulation of tables with integer, string, time and BLOB item types, and up to four active sort orders. Hand-held PCs need to conserve power aggressively. The WinCE system tries to switch the CPU to a low-power idle state whenever it sees that all applications are blocked. Applications that use PeekMessage loops to do background processing defeat that strategy. The WinCE development environment runs on a Windows NT host in the familiar Microsoft Developer Studio. As I mentioned, the beta tools are add-ons to Visual C++ 4.0; the final tools will work with Visual C++ 5.0. Basically, you get a WinCE desktop emulation environment, remote debugging tools and cross-compilers. You can design on the desktop, do a certain amount of debugging and testing in the emulation environment, and then do your final debugging and testing on a production WinCE device (I used a Cassiopeia) connected to the development PC with a serial cable. The current WinCE devices use Hitachi and MIPS processors; devices with a number of other processors, including low-power Intel CPUs, are in the works. There are no desktop machines made with some of these CPUs, so cross-compiling is the only possible way to develop for them. Cross-compiling is also the right thing to do-developers fill their cubicles very quickly if they need multiple computers to support multiple platforms. If there had been Intel-hosted cross-compilers for Windows NT MIPS and PowerPC targets, those platforms might have attracted enough applications to be viable. Familiar territory Developing for WinCE is enough like developing for Win32 that I took to it in a matter of hours. I have to admit that I'm still discovering subtleties, but there haven't been too many nasty surprises. If you have a WinCE device, check out my Web page (http://www.winmag.com/people/mheller) to see the little CE application I've developed. Apple Newton Of course, WinCE-based HPCs are hardly the first programmable hand-held computing devices to reach the market: Apple's Newton has been available for years. What's new about Newton, though, is that you can now program it from Windows (see http://devworld.apple.com/dev/newton/tools. html) and also program your Windows applications to talk to it. If you're interested in developing applications for palmtop computers, you might consider developing for Newtons as well as for WinCE devices. The Newton Toolkit (NTK) for Windows is a complete cross-development environment for all Newton devices; to use it you need a PC running any version of Windows, a Newton (I used a MessagePad 2000) and a serial cable linking the two. The NTK includes a compiler. By default, NewtonScript programs are compiled into machine-independent byte codes, but individual functions can be compiled into native code for the ARM (Advanced RISC Machines) chips that power Newtons. The terms used in Newton-land differ from those used by Windows programmers. You'll find that designing templates and views is no harder than designing windows, dialogs and controls, and that Newton-Script isn't bad as an object-oriented programming language. But the language! What's a soup? (It's a persistently stored object containing an indexed series of frames.) Newton programmers already know that-we have to learn. If you can program Windows, you'll be able to learn to program Newton with a little effort. On the other hand, there's very little actual carryover from Windows programming to Newton programming. Knowing the intimate details of a thousand Windows API functions didn't help me at all when I went to build Newton applications-suddenly I was a newbie again, albeit not as wet behind the ears as some. If you decide to take the Newton plunge, check out Programming for the Newton Using Windows by Julie McKeehan (AP Professional, 1996). You can read portions of the book on Apple's Web site. Visit http://www.apple.com/ and do a search for Programming for the Newton Using Windows. Data exchange Even if you don't want to program Newtons directly, you might want to give your Windows programs the capability to exchange data with Newtons. If so, there are Newton Desktop Integration Libraries, or DILs (also available from http://devworld.apple.com/dev/newton/tools.html), which give you both a basic communication capability and a high-level frames interface. The DILs provide several dozen C-language functions for talking to the Newton. The basic functions address opening a serial port with MNP support and making the connection to the Newton look like a pipe. You can listen to this pipe, write to it and read from it. Once you have a working low-level pipe, you can get or put high-level frames, which correspond directly to Newton objects. You know, I think an Apple just fell on my head ... Martin Heller programs computers of all shapes and sizes. Check out Martin's Web page at http://www.winmag.com/people/mheller or send him e-mail at mheller@cmp.com.
|
