A Conversation with a PenWindows Programmer

We recently sat down with a programmer who has been working on a pencentric application for the Microsoft Windows for Pen Computing platform, and asked about his experiences developing software. Because he is working on an unannounced product, we felt it important to maintain his confidentiality. However, you’ll find his experiences valuable for any type of pencentric development project.

Q: First of all, what can’t you talk about here?

A: I can’t say too much about the specific product that I’m working on, because it is unreleased and the company wants to maintain maximum confidentiality. Secondly, because Windows 3.1 and its pen extension application program interface (API) are unreleased beta products, there are restrictions as to what can be said due to a non-disclosure agreement.

Q: That covers a lot of ground. So what can you talk about?

A: I can tell you about my experiences in writing a pencentric application, and how my preconceptions have changed over the last few months. And of course I can mention things about Windows 3.1 and PenWindows that have appeared in the press.

Q: Shoot.

A: First of all, the trade press has made a lot out of the battle of pen-based environments, namely PenWindows — by that I mean Microsoft’s product, Windows for Pen Computing, which has a horribly long official name — and Go’s PenPoint. This is similar to the faceoff between Gem and Windows several years ago, or Windows versus OS/2 in the desktop area. It sounds like you have a choice between jumping off a cliff into two incredibly deep and murky pools. So to some extent, I was under the influence of an intimidation factor. Both of these sounded large and complex.

Q: And they’re not?

A: Well, I haven’t much to say about PenPoint because I haven’t really worked with it. In my case, the decision to use PenWindows was made by others before I started the project. That is, I did not do a comparative analysis to evaluate the various merits — technical, business, or otherwise — of the two environments side-by-side. For me it was more a case of moving from regular Windows 3 over to PenWindows. But nevertheless, I was somewhat intimidated by all this hype about the clash of the titans.

Q: So what happened?

A: First, I found out that I didn’t really need PenWindows or the Windows 3.1 beta to write my application. I mean, I am using both of them, they are installed on my machine. But I could just as well be using regular Windows 3.0.

Q: Why is that?

A: It turns out that PenWindows doesn’t give you that much over regular Windows, except for character recognition. Or to put it another way, regular Windows provides a variety of graphics and user interface functions, an API for writing graphics-intensive applications. PenWindows adds to this existing set of functions — I believe it’s around 500 for Windows 3.0 and 700 for Windows 3.1— about 40 additional functions that mostly add character-recognition services.

Adding a character recognizer is no mean feat, and I’m sure there are a lot of clever tricks that Microsoft’s programmers had to pull in order to extend Windows in a way that’s compatible with non-pen-oriented apps. So I don’t mean to minimize that feat. But if your application doesn’t rely on character recognition, then PenWindows doesn’t do much for you. You can get by with the plain vanilla version.

Q: And how about Windows 3.1?

A: Well, as Petzold said in his article in Microsoft Systems Journal (September/October, 1991), Windows 3.1 is a fairly large step above Windows 3.0 — in terms of the number of functions added. But, unlike previous improvements to Windows, say from Windows 1.0 to 2.0 to Windows 3, which actually added a smaller number of functions at each step than did 3.1, the extension is done in a way that’s much more compatible. There are a few well-defined areas of functionality which make up the new API. These are things like object linking and embedding (OLE), and dynamic data exchange (DDE), TrueType, common file dialogs, and so on.

Q: And you don’t use those new features?

A: I probably will. But I haven’t had a need for them yet. First of all, I’m still in the process of writing the basic application, so there is a lot of core functionality that I need to add before I worry about things like DDE and OLE. I did look at that stuff over before starting to write the program, and decided that it was not immediately relevant to my application, which is basically a standalone graphics-intensive program that uses the pen as the primary user interface. If I need them later, I can always go back and put it in.

I’ve worked on a number of large complex programs and have had the repeated experience of spending a lot of time doing a careful complete design, only have to rip it out later as my understanding of the problem deepens, or, what is more likely, as the user’s requirements change — or as the Marketing Department’s view of what the user wants changes.

Nowadays I’ve resigned myself to the fact that no matter what I do, my application will evolve and change over time, so I pay a lot of attention to modular programming that can facilitate those changes. There are all kinds of ways of writing modular programs, and every programmer I know claims to write code that is super-modular. Kind of like everyone claims to be a good driver, whether they are or not.

Often I’ve had to come in and work with programs where the original designers have resisted for years modifying their carefully crafted design to accommodate a series of changes. Those changes then had to be made in a form that didn’t fit well into the original architecture, so the result was an unnecessarily complex mess, when it would have been better to bite the bullet and do a redesign instead of trying to preserve the original effort, no matter how elegant it may have been at the start.

Anyway, to make a long story short, I’m not using the Windows 3.1 special features, but I might in the future and won’t resist any architectural changes when that time comes. I’m hoping that my program’s design will be pliable enough to add these changes gracefully.

Also, many of the Windows 3.1 features are added in a way to make them backwardly compatible with 3.0. For example, the new file dialog boxes are done as a dynamic link library (DLL) which can work with 3.0 applications.

Q: How about debugging? Doesn’t the Windows 3.1 environment have special facilities for debugging? Don’t you need those features?

A: Yes, I believe Petzold mentions the TOOLHELP.DLL and an updated version of CodeView for Windows. But I guess I’m basically a curmudgeon when it comes to programming tools, I stick with what’s worked in the past until it’s necessary to change it. This technical conservatism has served me well in the past, working on large complex projects. When I was younger I’d spend unlimited time getting to know a range of new tools and combine the best features of all of them in new and unexpected ways. But I don’t have time for that kind of hacking if I want to get the product out the door. And remember that I’ve been burned by previous versions of Windows.

So I have certain debugging tools which I’ve built for Windows, basically some code that I add to each program that lets me debug portions of it interactively. These tools may be primitive when it comes to a full-featured, well-finished product such as CodeView — I’m assuming the best case here, maybe it’s really buggy, I don’t know. The advantage of my tools is that I have the source code, so I can change them if there’s any special requirement or if a new beta comes out that doesn’t contain an update for the debugger, et cetera. I’ve worked with Windows since Version 1.0, so my mistrust of Microsoft does have some rational basis.

Q: What do you think about the Windows learning curve?

A: It’s definitely non-trivial. Again, my impressions are colored by past experience, using beta versions and primitive tools. I know that Microsoft, along with the rest of the industry, has become much more sophisticated in its logistics, support and training, so the experience of someone new to Windows may be different now. They may have a different approach and use different tools.

Q: What tools do you use?

A: Windows 3.1 and PenWindows, as I said earlier, are installed on my machine. Then there’s what I’ve always used, the Microsoft C compiler, the most recent version in this case.

Q: You don’t use Borland C++?

A: I’ve heard a lot of good things about it from people I respect a lot. And if I weren’t working with beta software from Microsoft, I would definitely consider using C++. I know that a lot of developers are now using C++ to develop Windows 3 apps successfully, without a lot of the pain which would have been expected given the complexity of both systems (C++ and Windows itself). But again, I no longer seek the glamour associated with working with the latest language that will solve all our problems; I just want to get the job done. Or maybe it’s just that the box is too big.

Just to demonstrate that I’m not completely stuck in the past, I have been using QuickC for Windows, and I love it. Also, I just installed Turbo C++ for Windows which I plan to check out, although I will use only the C portion of it.

Q: But QuickC is not a Windows 3.1 product.

A: You are correct in that it was released this past September, which is a long time before Windows 3.1 will appear. But I’ve been using it with no problem.

Q: So how do you manage to use Windows 3 on a PenWindows machine?

A: You can’t. As far as I know, regular Windows 3 will not run on hardware designed for PenWindows. But right now I can’t use PenWindows or Windows 3.1 either, because there are barely any pen-based machines available. There have been a bunch of hardware announcements and a lot of ads, but I’ve yet to see a penbased computer running Windows, never mind what version. The demos I’ve seen from companies like Microsoft and Slate have used the Wacom LCD tablet connected to a desktop machine (Note from the editor: since this interview, we have seen beta versions of Windows 3.1 running on the NCR 3125, Microslate’s Datellite and on the Trigem (Eden Group) VPI386).

Of course, eventually these things will ship. Somebody on Compuserve posted a notice this week that he had just received his NCR machine. And eventually I’ll be able to try my program on a real pen-based computer, but I’d just as soon wait. My suspicion is that this first crop of machines will be obsolete within 6 months. I’m going to line up to buy into the second wave of machines that will replace the current crop of hardware. I imagine these will be much cheaper, too.

Q: Is there anything else you want to say?

A: My main point in this interview is that pencentricity is not something provided for you by PenWindows, but something you have to do for yourself. This may be obvious to some, and I probably also knew this in some form when I started this project, but only recently have I come to realize the full implications of this statement.

This fits along with what many vendors have been saying lately — that character recognition is not the main point of pen-based computing right now, given the technology of handwriting recognizers. Pencentricity means designing your application so that it can accept pen input almost any place and any time, in a way that is most natural to the user. What this means, I’ve found, probably along with many others, is that “ink” is a major datatype. But that PenWindows — and perhaps PenPoint, for that matter — doesn’t really support ink as a datatype. A lot of this support probably has to be application-specific anyway.

To fully support ink, you have to add a lot of code to your application. All that the environment can provide for you is the data points where the pen has moved. Your program has to take this stream of data and do something useful with it. That’s been the main challenge of designing this application — figuring out nifty things to do with ink. I can’t mention what these are without divulging too much about our product. Also, my ideas are changing and I hope to come up with additional new ways of working with ink.

But the basic point is that all of this processing is internal to the application, not something that the environment provides. And that’s why you don’t really need the Windows 3.1 beta and the pen extensions to do a pencentric app. Or at least to get started. Obviously, you’re going to want to test your app on the exact platform that your customer will use. But if you’re a small developer and have a copy of QuickC or Turbo C and know Windows already, you’re in business. The only additional ingredient is your imagination.

Q: How about if you don’t know Windows?

A: I can’t help you there. You’ll probably want to do a comparative analysis and see which platform is best for your requirements, and all of that stuff, before you leap, as has been discussed in the trade press. Because the learning curve can’t be ignored, whatever the platform.

Q: What kind of additional support for pencentric computing would you like to see added to the Windows environment?

A: Three things come to mind, only one of which has to do with pens. The first would be additional support for ink as a datatype. The problem is I don’t know what this really means. I don’t think anyone does. We’re all just now starting to understand how to work with ink.

The second is better support for connectivity and communications. This request is somewhat warped by the needs of my application, which is basically running standalone on the pen computer — as opposed to interacting a lot with other applications resident on the same computer. It’s much more important for my application to communicate with other machines, desktop and otherwise. To do this, Windows needs better built-in support for file transfer, wireless networking, or even just faster serial communications. This is a more important issue for pen computers than for desktop machines.

Third would be some kind of object-oriented database. Again, this request is shaped by the requirements of my application, which will be graphics-intensive and interactive, allowing the user to create and manipulate a whole bunch of objects. I’m going to have implement the data structure myself for now, but in the future I think a certain kind of object-oriented database would help a lot. Some of these databases are basically traditional relational databases in new clothing, and therefore slow and useless to me. I’m thinking more along the lines of what ObjectDesign’s ObjectStore has to offer, which is not yet available for the Windows platform. I understand that product is complex and expensive, so something smaller and cheaper might fit the bill, and that doesn’t require C++, if possible.