Inside the shareware era: Features, bugs, and programming in DOS

Inside the As-Easy-As story: How shareware was revolutionary before app stores and open source.

In the early days of personal computing, developers built software by hand from first principles because they had to. This series shares the story behind As-Easy-As, the spreadsheet built from scratch, and the lessons learned along the way.

How did you create As-Easy-As? What was the process to design and create a spreadsheet application?

The process was very simple. Dave and I would meet at his desk during lunch or after work. We’d review the current version of the program, with the changes we decided to make the day before, make any adjustments, we’d discuss any new features that needed to be added, I would compile a list of tests that I needed to run to validate (a) the user interface, and (b) more importantly, the built-in functions.

You have to realize that all built-in functions in the program were programmed by us using first principles. Whether it was building amortization functions, or linear optimization functions, or trigonometric functions,… we had to come up with the base analytical formulas, write the code representing those formulas, implement them, and then independently verify them. And, this was done for every function in the program!

Sometimes we’d have differing opinions with Dave and that would result in lengthy discussions later at night, usually at my house.

The program was written in Turbo Pascal and eventually in Delphi. Portions of the code were embedded assembly code and some even optimized in-line hex code. We’d prototype routines that needed speed optimization in Assembler, compile it, then extract the hex code and insert it in Pascal routines. We re-wrote many of the graphing functions to bypass the operating system and write directly to display memory for increased efficiency. Our motto was “produce the smaller footprint and most efficient code you can.” Given the limitations on RAM, storage, and distribution media, it made sense.

Compatibility with .WKS files was an early goal, because every spreadsheet program at the time was using .WKS files.

Our focus was on physics and engineering because of our background in science/engineering and because of the need to use the program, as I mentioned earlier, for some of the Chernobyl analyses.

What were some standout features in As-Easy-As?

Standout features? It’s like asking a parent “which one of your children do you love more?” I’ll just list a couple that come to mind…

A very powerful macro programming language, which was only used by maybe 2% of As-Easy-As users, but for those who used it, was irreplaceable. Most users didn’t even know that the built-in macro language could be used to model powerful apps with a UI. My comment about being irreplaceable for some, was based on the feedback we were getting from users (a benefit of shareware – the direct communications with the developers). Users let us know that they had used macros to model loading cargo ships, real time monitoring of hundreds of stocks, optimizing floor layouts of new homes, thermodynamic analyses of new design engine blocks, and leasing scenarios for dealerships across the USA.

The ability to define your own functions. This feature was used by many users to write functions that were specific to their graduate studies fields, their businesses, etc. And, since they were stored in an external file, once built, they could be imported and used in any worksheet.

There are many more, but if I don’t stop here, I’ll end up listing every feature of the program.

By the way, this is not known (how could it be), but before the decision was made to stop development on As-Easy-As, we were a long way towards developing a spreadsheet SDK that would allow transparent use of spreadsheet capabilities integrated within other applications and had also started work on a built-in programming language (much more powerful than macros).

As-Easy-AS received a number of awards from magazines of that era (PC Magazine, Computer Shopper, etc.), but for us the most prestigious awards were:

• Shareware Industry Awards – Best Application (1992) (DOS Version)
• Shareware Industry Awards – Best Application (1999) (Windows Version)

I don’t think that As-Easy-As would compare favorably with today’s Excel, in terms of features and capabilities that exploded with the new development environments that were not available to us. However, up until a couple of years ago, we used to get messages from users telling us that they were able to run As-Easy-As for Windows, using the wine emulator on Linux, and they liked the small footprint, meager memory requirements, and simplicity of use.

Programmers are the best at spotting their own bugs after-the-fact. Are there any bugs in As-Easy-As that you look back on and think “I wish we’d fixed that?”

I don’t want to say there are no bugs in the program (which I have not used in a while). I’m sure someone can find some. However, believe it or not, we spent a lot of time testing and correcting and re-testing before a new release.

As you most likely realize, our testing was not just the user interface – that was the easy part. In those early days we didn’t have the luxury of “function libraries,” in the context of what’s available today. For example, If we wanted to add a function to calculate mortgage payments, we couldn’t just call some Payment function from some library. We had to come up with the mathematical formula from base principles, program the calculations needed directly into Turbo Pascal, and once implemented, we had to then use the function in As-Easy-As multiple times and perform hand-calculations to verify the results. Lots of very long nights, in particular for some of the more complex functions.

We had a small group of users that had been using the program from the early days and they’d help us with beta testing every new release. They were a great asset! I know this was not part of your question, but even beta testing was executed as a process. Every beta tester had a signed agreement with us outlining their responsibilities and their benefits, including an NDA.

We wouldn’t use this group for minor releases, we would use them for major version releases that included testing over a few weeks and they would make a significant time/effort investment. For minor maintenance releases, we used a sub-set of the group made up of users that were willing to intensively test over 2-3 days. And, for complete transparency, if the release only included a couple of minor changes, we’d sometimes rely only on our internal testing. Luckily, this did not get us into any major trouble (which it had the potential to).

Thanks to Paris for this deep dive into the As-Easy-As spreadsheet and how it was developed. Paris shared more details than I could fit into one interview, and you can get more details in my interview at Technically We Write about writing the manual, and in my interview at Coaching Buttons about growing TRIUS Inc as a company.

---

In the next part, we dive into the code itself: Turbo Pascal, hand-rolled functions, and the hacks that made it all work.

Read the entire interview series

• Part 1: The nuclear engineer who became a software founder
• Part 2: Building As-Easy-As: A spreadsheet born out of scientific need
• Part 4: Lessons from DOS, Turbo Pascal, and hardware constraints

More from We Love Open Source

• Command line magic: Extracting links with awk, grep, and tr
• How I built a Markdown-to-HTML tool on a 5MB FreeDOS system
• Explore the five steps of the FreeDOS boot sequence
• A throwback experiment with Linux and Unix
• How to write your first FreeDOS program