by Peter Wone - GUI Computing

The Evolution Blues

Windows 95 has often been cruelled as Mac87. This is both fair and ridiculous. Yeah, sure, the Mac did all the same sorts of things in 1987. But Apple achieved this via rigid control of the context in which their software operated. This is like comparing a manís mind to the software controlling an industrial robot. Itís much easier to build the robot software because the context in which it must operate is vastly simpler. When the chips are down and the rules change, I know where my money is.

Mac87 was the result of design. Win95 is the result of evolution. The former is lean and mean, and can only operate in clean-room environs. The latter is ungainly and full of apparently irrelevant junk related to what it once was, performing unimaginable functions generated out of indeterminate interactions between unpredictable conditions. A Mac has to be redesigned to become anything else. But an enormous pile of junk can be converted into anything. A PC is such a mishmash it can adapt... The software controlling such a mobile junk-pile can only be the result of evolution.

To have a future you need a past, and the richness of that past governs the potential of the future. I canít wait to see what new roles the PC will take on. Even now, ask yourself, "what is a PC?" Then ask "what is a man?" You will find that neither question can be answered out of context. A PC can be anything from a fax machine to a games console to a fancy typewriter to a smart filing cabinet. It is all of these things. It is answering machine and accountant, design assistant and confidante. It is also several more things we havenít thought of yet.

Sadly, by the time it wiggles when it walks I may be too old to care.

More Evolution Blues

VB4 is VBA is Access95 Basic is the universal scripting language for Win95 and NT. Itís totally 32-bit in every sense. This is my pleasure and my pain in VB4.

So whatís traumatic about that? Unicode for starters. An n character string is no longer an array of n bytes. But the Len function still returns n because itís counting characters not bytes. It gets worse. Word alignment on 32-bit word boundaries means that the number of bytes returned by Len may not reflect the number of bytes occupied in storage (RAM or disk) by a user defined type. For example, a struct containing an int and a long will occupy eight bytes due to word alignment but will be reported as occupying six bytes.

All this wouldnít be so dire if this didnít impact file I/O. Think about it. Reading a string from a text file isnít gonna work anymore. Youíll have to read it as an array of bytes (this is now supported) and use Chr$() to convert on a byte by byte basis. Maybe thereís a better way, but I havenít seen it yet. Actually, I support this code break. Iíve always found the assumed interchangeability between strings and byte streams disturbing.

So I/O is going to break a lot of code. I could be totally unsympathetic and say get real and store everything in databases, but not everyone has that luxury. Thank goodness it isnít my problem.

VBXs donít work in the 32-bit version. Personally I donít care because the only VBXs I ever used were Spyworks and Truegrid. I already have the Spyworks OCX beta, and the people who did Truegrid did the data-bound grid that ships with VB4. And more to the point, thereís now the capability to create my own objects. One of the major drawbacks with VBXs was the fact that you had to rely on somebody elseís quality control and somebody elseís version control.

Itís not so bad.

A lot of things works in fundamentally different ways now. I like VB4 far more than previous versions. Itís now much more like C++. Weíve got user definable objects with user definable methods and properties. We can put these objects in user definable collections. The only things weíre missing now are callback, function parameters (a variety of callback) and compiler support for inheritance. (You can support it in code, but then itís hardly inheritance in any conventional sense.) The latest rumours suggest that VB5 will be a true compiler. Callback, at last.

Caveat Emptor

Just a parting word. One thing you shouldnít buy into is the registry. I heartily recommend using the registry for your own information, but donít fiddle with anyone elseís. The registry is is now the backbone of Windows. If it breaks, youíre dead. Here are some rules for registry survival:

  1. Back it up, by making a new startup disk after every installation of new software.
  2. Donít play with it (the registry).
  3. Absolutely DO NOT try to uninstall OLE objects, especially OCXs, by manually hacking the registry. There is a program supplied with VB4 that with do this for you. It gets it right. You wonít unless you have a map of the registry entries. If you mess this up, you wonít be able to re-install it.

So, when you build your objects, have a care, and make sure you provide for their clean removal. An uninstall method would be nice. Also fairly unambiguous.

Salut, mes ames.

Written by: Peter Wone
Aug 1995