Crank Starting the Model-T on a Cold Morning

Setting up a Windows CE programming system

By Everett Kaser

The King is dead! Long live the King!” This old saying always confused me as a youngster. It seemed so self-contradictory. But as I started trying to wrap my mind around Windows CE programming (and all that it entails), a similar statement kept coming into my head: “Programming is easy! Programming is never easy!” If you’ve written Windows programs before, then writing a Windows CE program should be easy, and it is…sort of.

Setting up a computer to program for Windows CE

The first thing I had to do was set up a desktop computer on which to write Windows CE programs. (You can’t write programs on a handheld PC.) My task was to first set up a desktop PC running the Windows NT 4.0 operating system. On top of that I had to install Visual C++ 5.0, and then Visual C++ for Windows CE (VCCE). Finally I had to get the NT computer to talk to the CE handheld. Each of those steps was “easy”… and not so easy.

Anyway, once Windows NT was setup, then the Visual C++ installation went smoothly (although slowly). The installation of Visual C++ for Windows CE also went smoothly until the very end. One of the last things the VCCE installer tries to do is to set up the networking Remote Access Services (RAS) between the NT machine and the H/PC. It recommends letting it remove the current Remote Access setup so that it can re-install it “correctly” for use with the H/PC. Being a trusting soul, I clicked on OK and restarted Windows just like it told me to … sigh!

Windows NT patiently told me that a service had failed to start, and to consult the Event Viewer to find out what was wrong. The Event Viewer is not user-friendly, but steadfast foot soldier that I am; I managed to corroborate my hunch that the Remote Access Services setup was messed up somehow. I hadn’t a clue what might be wrong or how to go about fixing it. But, I figured that Microsoft’s advanced, high-tech Help system could help me troubleshoot the problem. To make a long story shorter, after clicking through lots of questions, I made it into the networking setup screens and made some changes suggested by MS-Help. But no matter what I did, I couldn’t get RAS configured properly to access the H/PC from the desktop. Finally, I started over with a completely reformatted hard drive. I tried the whole thing again, and got the same results … sigh!

I realize I was probably doing something terminally unintelligent, but couldn’t figure out what it was. Finally, I started over one more time. At the very end of the installation process, when Visual C++ for Windows CE recommended that I let it remove the current Remote Access setup and re-install it correctly, I told it to keep its filthy fingers off of my RAS (i.e., I clicked on “No”). After installation was done (and VCCE had warned me that things might not work properly since I hadn’t let it setup the RAS for me, thank you) I then ran the HPC Help system and followed its steps for manually setting up the RAS. Magic-presto, alakazam! It worked fine … finally!

Revving up the engine...Smaller is better

The next step was to get a handle on using Visual C++ and Visual C++ for Windows CE in the Developer’s Studio environment to create a Windows CE application. My first big concern was the size of the programming code I’d have to generate. H/PCs have limited memory compared to a desktop or notebook PC. The size of the executable and the amount of the computer’s memory and CPU resources needed to run it are critical. I decided to build a “trivial” program in several different environments and compare their sizes. A trivial program is a very simple program written to test to see if all the components of a programming system are working properly. The classic C-language trivial program is Hello World. Run it and it simply displays “Hello world!” on the screen.

The DOS version of the Hello World program takes about 28 bytes, using INT 21 function 9 as an assembly language .COM program. Using Microsoft C 6.0, the program takes just under 5400 bytes. Charles Petzold saved me the trouble of writing a Windows 3.1 version of Hello World. The first sample program in his classic book “Programming Windows 3.1” is a version of this program, called HelloWIN. I grabbed its source code off of the diskette included with the book, compiled it (using VC++ 1.52, running on Windows 95) and got a 4512 byte executable file.

The next step was to move HelloWIN over to Visual C++ 5.0 on my Windows NT machine. Maverick’s Pappy always said, “We learn from our mistakes.” Well, I’m learning very fast! I first tried to just import the Win 3.1 source files into the Developer’s Studio environment, but got way too many errors and warnings, due to changes in code syntax and structure between the two development environments. There weren’t that many differences, but I didn’t feel like trying to patch things up. I wanted to start things from scratch, “the right way,” in Developer’s Studio.

Dynamic Link Library

I changed tactics and created an MFC application. (MFC stands for “Microsoft Foundation Class” — a library of “classes” for Microsoft Visual C++ that provide C++ class-interfaces to the standard Windows programming functions.) Quickly, I had a Windows CE version of HelloWIN. The only problem was that it was around 180 Kb when compiled, with MFC linked into the EXE. You can run MFC as a separate DLL file on your H/PC and reduce the size of the HelloWIN executable to only a little over 17 Kb, but the MFC DLL file takes up about 288 Kb — both executable and DLL total 305 Kb! Many people will wind up with the MFC DLL on their machine, because there will be applications that they want to run which require it. It only has to be there once, and then multiple applications can use it. But when I’ve only got between 2 Mb and 6 Mb of RAM that has to be shared between file storage and system RAM, I’m not too happy about giving up almost 300 Kb of it. Even discounting the DLL, the Windows CE version of HelloWIN, at almost four times the size of the Windows 95 version, is way too large!

Finally I created a non-MFC (Win 32) version of HelloWorld for Windows CE. At 4 Kb, it was more reasonable in size. So, as much as I like programming in MFC, I’m afraid I’ll be sticking to non-MFC projects for Windows CE for a while.

Different programs for different processors

Another interesting fact that most HP/C users and many programmers don’t realize is that the different processors in the H/PCs require slightly different versions of a program. Actually, you write the same code, and just compile it differently. End users don’t know this because the installation portion of programs marketed for the H/PCs senses the type of processor the H/PC has and installs the appropriate version of the program.

The last thing I was curious about before starting work on a “real” project was to see how the sizes of the executable files for the different processors compared. As a test case, I opened a sample project from the Developer’s Studio (DevStudio\WCE\SAMPLES\REVERSI) and compiled the release version for the SH3, MIPS, and x86emul (Intel WCE emulation) environments. The sizes of the executables are as follows:

I expect this to be fairly typical, as several times during my experiments I tried this on my test programs, and the MIPS executable always came out larger than the SH3 executable. I don’t know how the speed of the two processors compares (since I don’t have a MIPS-based machine currently), but the SH3 certainly seems to have a more efficient instruction set for size of the executable.

Driving away in first gear

One of the first things I did when I got my H/PC was compare it to other handheld devices I’d used, specifically the Hewlett-Packard Palmtop PCs (the 95LX, 100LX and 200LX). One thing I sorely missed on my H/PC that the early HP Palmtop PCs provided was a native programming language. To write even a simple program for Windows CE you have to have an NT platform with layers of programming tools. I’m a programmer, and what good is a computer if you can’t program on it?

Now I realize that Microsoft has a “vision” of the H/PC as a companion to the desktop computer. Some at Microsoft might even think that a desktop-only programming system for Windows CE makes sense. However, I’m an ornery, individualistic cuss, and if I’m going to have a computer, then by Geek! I’m going to program on it! Even if it means boot-strapping my way there. (That’s always more fun anyway.) Unfortunately, there is one small hitch in my plans — with the current batch of H/PCs, we’re no longer in Intel-land, Toto. In fact, we don’t know what land we are in because Windows CE is designed to (and does) run on different CPUs. This means that:

What we need to solve this painful situation is to develop an interpreted language for (or modify an existing one to work with) Windows CE. True, programs using interpreters are slower than compiled programs. But you only have one program to recompile for different CPUs, and that’s the interpreter itself. Then any program written in the interpreted language would run fine on any H/PC. Ideally, the interpreter should be small, yet contain as much functionality as possible. Such a language would fill the shoes of batch files on MS DOS machines, yet support the development of quick, simple Windows applications as well.
The first interpreted language that popped into my head was JAVA. But I threw it out the “window” very quickly because of the heavy resource requirements of the JAVA compiler. No, what we need is something similar to “Tiny BASIC,” only targeted at the Windows CE environment. It should compile the source into “byte codes” to make the executable as small as possible and its execution as fast as possible. It also should support the creation of a main window, dialogs, and basic file operations. Ideally, besides a standard “windows” operating mode, it should also be able to present a “command-line” interface of some sort.

WindowsCE Webring