Volume Number: 15 (1999)
Issue Number: 4
Column Tag: From The Factory Floor

A Chat With Steve Kiene

by Steve Kiene and Dave Mark, ©1999 by Metrowerks, Inc., all rights reserved.

This month, the Factory Floor visits with Steve Kiene, founder and CEO of MindVision. There's something for everyone in this interview, a chance to visit with someone who has grown up in, and helped shape, our industry.

Steve Kiene is the CEO of MindVision Software. He has been paying his bills by writing software for over 14 years, 12 of those years writing Mac software. However, over the last two years his hair has grown in a decidedly pointy fashion and he has been heard in meeting saying things like "We must centralize our efforts to achieve enhanced intra-personnel communication structures." Recently he managed to control his hair and is now back among those considered contributors to society.

His claims to fame are: 1) he is rumored to be single-handedly responsible for keeping Jolt Cola from overflowing store shelves, 2) he is a regular contributor to the policeman's ball, 3) and has managed to evade traffic authorities with even more flair and panache than even Jorg Brown.

Dave: Installer VISE has been the heart and soul of MindVision for some time. Can you tell me a bit about the history of both the company and the product?

Steve: I started MindVision 11 years ago along with my friend Rod Magnuson when we were juniors in high school. Over time Rod and I went our separate ways. He's now a bigwig at Symantec and we're still really good friends.

We originally just wanted a company name behind the shareware we were writing. After our senior year we decided to write software full time instead of attending college (even though we were already programming 50-60 hours a week). Prior to starting MindVision, we worked at a local software company, writing Mac software for $3.50 an hour. After writing various programs like MaxWrite (the first color word processor for the Mac) and TomINIT (the first tear-off menus INIT) we started work on a HyperCard based product. It was pretty innovative for the time. XCMDs in HyperCard are simply standalone code resources (like INITs) which have various callbacks into HyperCard. At the time, a code resource was pretty much limited to 32k of code. We knew our product would be much larger so we had to invent some new stuff. RAM was also scarce, I think we had about 90k of free RAM to work with (our code was in the HyperCard heap). We designed our own dynamic segment loader to swap small pieces of code in and out based on usage. We also had to deal with the fact that a code resource had no global variables. Some of the tricks we used were to put a bunch of code in WDEFs, CDEFs, and MDEFs. Our WDEF had a menubar in it (like Windows) and handled scrolling, updating, etc. automatically. This cut out a bunch of code from the main segment. The MDEF handles option-command key sequences as well as on-the-fly menu item changing. When we were done it was about 400k of code that managed everything in less than 64k of RAM. And almost all of it was written in a high level language.

I then started working on compression-related things. My first compression product was called Application VISE. It allowed you to compress an application in such a way that it would decompress needed data on the fly into RAM. It basically compressed each resource, then patched into the jump table so it got called as the first thing when the app was launched. It then patched the Resource Manager so it could grab resources when they were loaded and decompress them. At the time, many products were distributed on floppy and they were getting to be larger than 800k, so this allowed developers to cut the size of their program by about 40% with zero code modifications. When we developed the compression algorithm, the 68000 processor was still used in many machines so it had to be fast. Most compression algorithms stored data as bit streams. This was too slow on a 68000 (bit operations were very slow on that processor) so we developed a word (16 bits) sized compressor. One of the other design requirements was that the decompressor had to fit in the 256-byte processor code cache of the 68030. I think the decompressor ended up being like 62 instructions. It was very fast on a Mac Plus it decompressed 160 kbytes per second. On a Mac IIfx (the fastest Mac at the time) it decompressed 2100 kbytes/second. I think I was 20 years old when I wrote it.

Next I wrote some extensions to Apple's Installer to allow compressed files to be installed. This was the predecessor to Installer VISE. In between, however, I came up with the idea of using compression to transparently compress all of the data on a hard disk. The idea was to patch in-between the Device Manager and the SCSI driver. When the OS wrote data, we compressed it and then sent it to the SCSI driver. When the OS read data, we got it from the SCSI driver and decompressed it. We sold the rights to the product to Stac Electronics and they released it as a product called Stacker. During the development of Stacker is when I hired my first real employee, Brian Sutter, who is still the lead engineer on Installer VISE and is the main reason MindVision is where it is at today.

After Stacker shipped we started work on Installer VISE, although at the time we called it Developer VISE for some dumb reason. I think I have a knack for picking the stupidest name for products. To this day most people don't get the VISE part. A vise is used in a workshop to squeeze (i.e. compress) things.

That's when things started to really get fun. We had a real competitor and a real product we were going to ship. After a year of development, with Brian writing nearly all the code for Installer VISE and with me developing the compression algorithm, we shipped Developer VISE 3.0 (1.0 and 2.0 were add-ons for Apple's Installer). As a tiny three person company (we also hired a tester) we knew we were going to have to work hard to compete against a big competitor like Aladdin Systems. We focused on working closely with each individual customer, no matter how big or small. If a potential customer needed a particular feature, we added it. Sometimes on the same day. We quickly developed a reputation as a group of people who would go the extra mile for anyone. That's a reputation we still have today, although we have more people behind the scenes making things happen.

Dave: You've been shipping the Windows version of Installer VISE for about two years. How much work is it to go from a Mac installer script to its Windows counterpart?

Steve: We get this question a lot. It's an interesting question. The reason that we embarked upon the task of writing a Windows installer was that our Macintosh customers kept asking for one. They had decided to make the cross-platform effort only to discover that the installation tools on Windows were either under-powered or overly difficult to use. For one thing, unlike Installer VISE for Macintosh, the "common-wisdom" approach on Windows is to write a bunch of scripts. There's no good reason to have to do that! One after another, our customers called us up and asked if we had a Windows installer. So we decided to address the need, and we set about writing a Windows installer.

In the process, it was clear that we needed to meet the expectations of Windows users and Windows developers. Just as Macintosh users have certain expectations about Macintosh software (nobody likes a badly-ported Windows title), Windows users have certain expectations, too. So we put a lot of effort into making the tool have the ease-of-use of Installer VISE for Macintosh, but with a decidedly Windows flavor to it. We wanted Windows developers to say, "Hey, this is easy!" not "Hey, this was a Mac program..." And, just as building software for Windows is a different experience, building an installer for Windows software has its differences, things like registry entries, shortcuts, auto-registering DLLs, and so forth. But Mac developers will find the experience very familiar if they've also used Installer VISE for Macintosh.

Based on the reception that Installer VISE for Windows is enjoying, we believe we've opened some eyes to a much easier way to package and deliver software. And Mac developers are relieved to be able to avoid the "common wisdom" solution!

Dave: What kinds of technical roadblocks did you encounter in creating Installer VISE?

Steve: Mainly "quirks" and "features" in the OS. Our installer has to support a wide variety of machines and operating systems. For example, you can still build an installer that will run on a Mac Plus running System 6.0.4, and still run that same installer on a G3 Mac running Mac OS 8.5. It's very difficult to add enhancements to the installer and continue to keep it stable on all those platforms. Many OS calls have various bugs on various machines on various OSes in various languages.

One that comes to mind is in detecting the language of the OS. There is a bug in one particular version of the OS when running on one particular Mac in which two of the language IDs are reversed. Or, when performing the seemingly simple operation of creating a file. For example, let's say you want to create a file and set the type/creator. Well, on a G3 running Mac OS 7.6 or 8.0, if you create a file on the desktop, the error code returned from _Create is the trap number of _Create, rather than zero for noErr. And, there are some nasty bugs in various versions of the OS and the Finder when setting the type/creator of a file when that file is visible on the desktop. In some older versions of the OS, if you set the type/creator right after creating the file, then write out the resource fork and in the process call WaitNextEvent to give time to other apps, the Finder will open the resource fork of the file (if it is an app) and try to get bundle info, etc. Well, the resource fork is in the middle of being written and it's not valid. So, the Finder chokes. No problem you say, let's wait to set the type/creator until after the resource fork is written. Well, then under 8.0 and 8.1 you will run into other bugs introduced with the threaded Finder. After creating the file, the type/creator is blank, or whatever. It doesn't matter. While you are writing the resource fork the Finder decides to get the type/creator, etc and cache that info. It sees that the file is busy so it doesn't bother checking if the file has a bundle at that time. Once the file is closed and we have set the type/creator to the correct values, the Finder now does its work on the file. But it has cached the initial (and incorrect) type/creator and writes that bad data back out to the file, thereby messing up the file info.

Something that we get to contend with is that Apple sometimes tries to fix these bugs on their own, and sometimes ends up making matters worse. In 8.0 they made changes to the 'fupd' AppleEvent which caused it to be substantially (sometimes 40x!) slower than before. We use that AppleEvent to update the desktop database for newly installed files. Apparently they never bothered to test those changes with the install of a product like CodeWarrior. That's why it took so darn long with the "Finishing Installation" phase of a CodeWarrior install. We send one AppleEvent to the Finder, and users end up sitting there for 15 minutes while the Finder chugs away handling the "enhanced" 'fupd' event.

Many people think an installer is just something that copies files. That couldn't be farther from the truth. There are hundreds of things going on behind the scenes as a result of our years of dealing with bugs like the ones I just described, all to make sure software is installed perfectly no matter what circumstances it encounters.

Dave: How do you see installer technology evolving over the next few years?

Steve: When personal computers first shipped, software consisted of a couple of files that were copied on a floppy. Over time software grew both in size and number of files. In addition, those files needed to be installed in different locations on the user's hard disk. That's when installers became useful. End users could not be relied on (nor expected to) copy all of the files into the right places. An installer was useful for two reasons: 1) it compressed the data, thereby reducing the number of disks required, and 2) it automated the process of putting the files in the correct location.

Now software has grown out of control, both in size and number of files. Using an installer to install the files only solves one of the problems created by the size of today's software. Once the software is installed, moving one file can break the software. Installers need to become more than just tools to install files. They need to become tools to make sure software stays installed correctly. We are working on many new technologies that we will release in 1999 to further change the definition of an installer. You'll be able to install software simply by dragging the main application from a CD onto your hard disk. When you launch the application, it will automatically install any other needed files. Later on, if a file is removed, it will automatically reinstall that file. And, if you release an update for your product, the application will automatically detect the update and install it for you.

Uninstallation of software is a much more complicated process. Managing the removal process of shared components is not simple. While we are working on solutions for this, it won't be anytime soon.

Dave: What's next for MindVision?

Steve: Well, every year I look back at the past year, and see what has changed. Not only with MindVision, but also with the industry as a whole. In 1998 we focused on making sure that we continued to make our customers our #1 priority, even as we were growing. We succeeded in that. In 1999 we will be rolling out our new web site which I hope will set the standard for usefulness and flexibility in the entire industry. With customers all over the world, I would like to be able to provide 24 hour technical support. However, we can't do that by having someone sitting by the phone 24 hours a day. We can do it by making our web site our customer's #1 resource for information on our products. In addition, we will be rolling out more new versions of Installer VISE, with 6.0 shipping around the time you read this, and 7.0 in the near future. 8.0 is a ways off, but I can faintly see it.

We've always focused on solving real problems with great technology. We've developed expertise in a number of areas, and opportunities keep presenting themselves to put our expertise to work in new ways. That's how we got to Installer VISE for both Mac and Windows, and that's where new products will come from.

Dave: In the early days of the Mac, it was very possible for a smaller company to get a product on the market. As the Mac market has grown, the players have gotten larger and the cost of getting in the game has escalated. How do you think the growth of the Internet has affected this model?

Steve: We shipped the first version of our installer in May of 1994. Now, we have a good piece of the installer market and nearly every major software company uses our installers exclusively. We did it through innovation, hard work, and honesty. Not with lots of money and lots of people. We're still a tiny company (14 people), yet we effectively compete with companies many times our size. When we first started shipping Installer VISE, the Internet was unknown to most developers, so we had to use AppleLink for email communications. We also had to spend a lot of money sending snail mail packages to potential customers. Slowly, the Internet emerged and now we do nearly all our business through the Net. This has saved us tremendous amounts of time and money. If someone wants to see information on our products, they simply visit our web site. In 1994 if someone wanted information, they had to call and talk to me. I love talking to customers, but I'm only one person, so it really limited how many customers we could reach.

In 1999 you will see many smaller companies, including shareware developers, making money because of the Internet. You can advertise on the web, ship your software electronically, gather registration information electronically, and provide product support via the web. All of this drastically reduces the number of people you need to run a company. And it reduces the amount of cash you need to spend up front. No more three month lead times on ads (and three months of payments before your ads hit), no more rooms full of printed boxes for your product, no more stacks of printed manuals. All of this costs significant money, consumes a lot of staff time, and is very costly when you need to make a change. The actual process of writing the code for a product is more complicated than 10 years ago, but every other aspect is now much cheaper, easier, and faster than before.

I think we'll see a continued influx of new players coming in, and some surprising competition even in areas where big players have long been established. This is good news for smaller players and good news for consumers.