Fog Creek Software
Discussion Board

Micro Pros WordStar Printer disaster – really?

There is a article right now over at

(It is the front page, thus over time will not be a revenant link).

Anyway, the story is about how Micro Pro developed a new Word Processor (WordStar), but changed the printer “data base”, so the old database format could not be used. The story given was this choice thus sealed the fate of the company, since the old printer database could not be used

(back then, each software developer/product  was responsible for the printers…not the OS like to day). Thus, the concept of this printer database being VERY valuable, and representing a strategic advantage for sure goes without question.

However, the argument put forth is that too much resources would be needed to move the data from the old database system to the new database system.. This to me is 100% hog wash. It would not take months and months to write some routines to move the data from the old structures to the new. In fact, you only need a “bridge”, or an abstraction layer.  In other words, the fact that the new database is some way cool hierarchical binary chop do da BS system does NOT MATTER. The only thing that matters is the fact that you can define a set of fields for a given printer. On the conceptual level, the field codes for bold can then be retrieved from the system.  Once you have the bold field codes, the rest of the code remains the same.

Assuming we keep the existing printer driver code, but load values now from the “new” database I see no reason why this change would take more than a month. The idea that just because the new database is pointer based or other system (hey, how about the post relational system they used for the Mac version of dbase!! the way, that system is still VERY successful to day...just not with dbase!!! – does anyone know which system I am talking about?).

Anyway, the fact of changing the database does not change the simple fact that you eventually get the concept of a record, and you get a set of fields for that record. Once you got those field values for the printer settings….the database is now not relevant.

Thus, why all the fuss about the database change? Can anyone begin to explain why in the world the data base (the printer codes) could not be ported to a new data structure format that the new word processor used? And why this process would take months? There has got to be more then this braid dead idea/exchuse for failure?

If you are telling me they ALSO threw out the old printer driver software code, then perhaps we have real point here. However, if you are saying that they used a new database/structure to store these codes…then I see little reason why this presents a problem?

Anyone care to enlighten me why this is such a hard problem to overcome?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Saturday, December 7, 2002

What I don't understand is why they simply didn't revert the printing code back to the old system?

The inability to revert tells me their code was in worse shape than the printer database. :)

Sunday, December 8, 2002

Probably the fact that back then there was no language capable of doing that easily was a factor. Remember that back in 1998 the only choice was C, and I have the impression that the Wordstar guys were programming in Assembler.

Looks weird, thought.

Sunday, December 8, 2002

Albert, Albert, Albert...

Clearly both you and the WS ver 5 product manager don't understand what was going on...

Don't you remember? It was **Paperless Offices** -- who needed to print anything anymore?

It was 1988... they were dumping print functionality completely, because after all, why would anyone need to print anything anymore? They could just keep it on their computers and move it around electronically, right?

Oh and the paperless office has worked so very well since then, hasn't it? One hardly **ever** sees the printer churning out paper anymore, does one?

< kidding here completely - If I made the sarcasm any heavier my monitor screen would crack >

Seriously - wow. Blast from the past, wayback machine and all. I remember the WordPerfect 4.7, 5.0, and 5.1 for DOS printer db. Well, from the user's perspective anyway. I remember that one of WP's advantages it had was the vast array of devices it supported. ( In fact, cranky old bastard that I am, I'm typing this on my NorthGate Computer systems OmniKey 102, heavy-assed metal-based keyboard with 12 F keys down the left side where humans who cannot palm a basket ball can actually reach them without moving from the main keys, and the green shift, red ctrl, and blue alt keys. Still feels like typing on an IBM Selectric II typewriter... best feeling keyboard I was ever on, and there have been many hundreds since. If I looked, could probably still find my WP function key template. Damn but I loved WP at the time. :-) Winword is clearly king now, though, numerically at least.

Lotus Freelance 3.x for DOS, as I recall, also had an extensive db of drivers for various gizmos, both input and output. They're hierarchical menu structure, for both Freelance and Lotus 123 were fantastic - they were so fast to use. Didn't HAVE to use a mouse and were more accessible than the key shortcuts in Windows are today, IMO, at least.

Ahhh. The good old days, when men were men, expanded memory boards were the only game in town (though they sucked), QuarterDeck was almost essential to get all your crap to load up in the 'lower 640' squish around your page frame, and shoehorn stuff into the himem area... a 10 MB drive was big and a 20 was luxury.

Ok. Timewarp over. Back to the present...

More to your point, I'm certainly not nearly enough of a developer to be able to authoritatively evaluate the complexity of their problem on the WordStar printer db issue, but unless there are important factors not revealed in the article, it doesn't seem like it would be the killer effort the program manager was describing. Doesn't seem like it'd necessarily be worth doing in the first place, though, unless the cost of a floppy across their installed user base really was enough to warrant it.

OK, one last thing - I can't count the times since 88 when I've cussed Microsoft for killing the idea (not a conspiracy thing here, just their choice at the time) that at least WordPerfect had held to of encoding the file type **in the damned file itself** and not in some lame 3 char extension. If you looked at a WP doc file in binary, the first couple of characters were 'WP'. You didn't need any '*.wp' or '*.doc' extension; your WP doc file names could be anything within the limits of 8.3 -- you could store info in what you chose for the .3 extension, and WP didn't care. I sure wish the industry had taken that approach for the wintel PC platform instead of the file extensions approach. Oh well, that's what we get for them not asking me personally first <g>

Too late on a Saturday night. Avoiding doing the work that's got me up this late after UGA spanked ARK. :-) Thanks for the trip down memory lane, though...

'night all.

Sunday, December 8, 2002

Its interesting, but I think incomplete.

Wordstar 2000 was an unmitigated mess.  Wordstar was a small text processor at heart.  Originally it fitted comfortably on one side of an 8" floppy but it managed text as characters and not lines.  That was significant, on CP/M it was significant.

Its ubiquity meant that you learned and applied the cursor controls of WS to other  appications.  This was before cursor controls on a keyboard were likely on anything other than a Techtronics strorage tube (story for another day).

And WS became an OEM product, it had to remain small. 

A couple of usages popped out of the text...

A flat relational table....

What is this strange beast?  Either a table is relational, or its flat.  The WS2000 printer database may well have been relational but at the level of managing printer information there's damn all difference between a simple relational database and a heirachical one.


Referred to as if a pointer were some nameless dread in the Twilight Zone of code.

On the whole it strikes me that the annointed Product Manager having successfully got 2000 out of the door (which in the fullness of time died with the merest whimper), brought his inflated shrink wrap solve the Mother of all Documents problems experience to the smallest, neatest (someone's going to mention Electric Pencil or whatever it was called, but that was crap, it was on Trash-80's so it must have been), programmer's tool editor, and screwed it up.

Well, I suppose it was going to be screwed up anyhow, MicroPro just didn't know when to leave well alone, and most software publishers don't.  When they have a nice tight, well defined application, it succeeds; they get ambition, they want it to rule the world to envelop all problems within its grasp, they add email, they give it a macro language.

So it goes.

Simon Lucy
Sunday, December 8, 2002

>>>Albert, Albert, Albert...

Clearly both you and the WS ver 5 product manager don't understand what was going on...

Gee, you got that one right!! I totally agree!

>>> I've cussed Microsoft for killing the idea (not a conspiracy thing here, just their choice at the time) that at least WordPerfect had held to of encoding the file type **in the damned file itself** and not in some lame 3 char extension. I

The apple mac has always had a resouce file, and does not rely on file extensions. This would have been great for Windows..but compability and lack of design means we use a stupied 20 year old idea of file extesions. The apple way is much better.

I mean to be fair, I was not present at those WordStar meetings!! Thus I have little knowledge to really criticize this decision. In fact, I am not really trying to criticize here, but understand the rational as why everyone on the team thought that the old database of printer codes could NOT be salvaged, or used in the new system? Why?

Perhaps there really is a legit reason here. As Far as I know, most of the WordStar product was written in Assembler (of course so was WordPerfect also). Of course Microsoft word was written in C, and programmers can add about 10 times the amount of features for the same amount of time compared to assembler. As a result, Ms-word started to Eat WordPerfect’s bacon real bad. I am not sure when WordPerfect switched over from Assembler to C, but it sounds like they did the switch a bit too late. By the way, Joel mentions this in the following article:

Converting Capital Into Software That Works

Perhaps the WordStar folks never got so far as to using a high level language like WordPerfect and ms-word do.

Hence, making changes is for sure was harder due to the assembler code (if that is in fact the historic case!!).

However, there is some part of me that cannot grasp why the old database of printer codes could not be salvaged.

I wrote a payroll package many years ago in Pascal. The record structures were of course HARD coded into the application. (as many PC based programs where back then). That simply meant that the application it self had the data structures as “part” of the code. They were defined “types” as follows:

  Employee  = RECORD
          NAME : STRING[35];
          AGE : INTEGER;    
          CITY :STRING[35];

This simply means that if I change the data structures, then everywhere in code, I would have to change the above type def. However, since the type def was global, then it was not too bad! However, today any such applications would have the data structures in a database system. Thus, you get a nice layer of abstraction between the code and the data. Hence, additional fields could be added if I had used a database, and NOT ONE line code would need to be changed. (unless somewhere in the code those additional fields need to be manipulated).

In fact, I later on I got VERY tired of writing routines to copy the old data files (the data structures)  to a new data structures when I added just a stupid field. Note, that this concept of changing the data structure is what the WordStar folks were complaining about.

Of course the WordStar example was that the whole database system "structure" was to be changed, not just a simple addition of a field.

Anyway, I wanted to be able to add fields to the data in my payroll system, and also not have to worry about changing the code. So, I went out and purchased the source code to a database library. No, I was not going to write my own database library this time. It was too much work. The book I purchased  was appropriately called Pascal Programs for Database Management. The book came with a bunch floppy disks and some nice source code.

Ok, so now at this point I simply dumped the above Type definitions, and proceeded to replace all code that referenced the above type def, and changed that code to use the database. Amazing the code change was very easy (I had only two weeks to make the change..since payroll was bi-monthly!). This ease of change was due to the fact that program logic did NOT have to be changed.  Thus, the project was MUCH more of re factoring type project, then a re-engineering. In other words, the given program logic DID NOT have to be changed. This is critical, as I was not re-writing how the interface, or even how all the program logic worked!. In fact, I was not re-writing one piece of the logic. The only thing I was changing was when a reference to the LastName field (for example) was made. All references to LastName simply where changed to a database record ref. Hence, LastName was now being referenced to a field in the database. Some record navigation code was changed, but again things like next, or previous logic still applied to either a database, or a records in Pascal.

Thus, it is my contention, that while the new version of WordStar used a different database system to store printer codes, that is not much of a problem. Again, I see little reason whey the old data could not be salvaged, and simply copied into the new data structures. In fact, this sounds like even less work then when I converted my Payroll system from fixed records to use a database. In other words, the new WordStar system already could work with printer codes, it just simply need to be feed a list of printers.

Again, there is no case made that the old codes could not simply be copied to those new structures.

There is a legitimate argument about testing, but the question still remains as why the old data could not be salvaged here? I mean the new product could use a printer definitions, but only the old format was not good. Right?

I am still at a loss here…..

Perhaps this is historic blunder that is much worse then what in fact is being reported here! The blunder was not that they did not have a printer database. The real blunder was that no one realized that using the old data was not very hard thing to use and salvage?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, December 8, 2002


Agree with you on the file extensions, it is a lot easier if the OS knows what the file is.

Does anyone know if this is going to be a feature in Longhorn?

Prakash S
Sunday, December 8, 2002

I can just see the war now.  Currently in Windows land I can have more than one program open a file of extension .xyz.  I can switch what program I want to be default.  I haven't played mith a mac recently enough to know the ins and outs of file association, but wouldn't changing this on Windows create a war among vendors?

Crusty Admin
Sunday, December 8, 2002

Crusty -

the issue about the extensions is simply that right now, what type of file something is is embedded in the extension. so however many applications would try to open the file or not, they're looking at the file extension. Hell, you can take mysheet.xls, change the file name to mysheet.doc, double click it and winword will try to open it.

The way it was under old WP DOS, and under (apparently??) mac, is that there are some unique characters embedded in the beginning of the binary (drawing/document/spreadsheet/ect) file itself.

The only real difference is that instead of an app looking at the file name to see whether it's a file it can read, it'd look at the first few bytes of the file itself.

Either way it's done, extensions or embedding, as soon as you build the feature like you have in windows to, say, fire off a second action based on an action taken directly on the data file (i.e. double-clicking on mydoc.doc in windows explorer to open winword with mydoc.doc opened in it), you have to store those associations someplace, somehow. The need for that would not change if you want that sort of functionality from the "OS" level.

And the 'war' would exist, therefore, with either approach, as the mapping still has to happen.

Nowadays, the issue isn't as big a deal since we have longer file names possible, but back in the 8.3 days on DOS and early windows, it would have been nice to be able to use those extra 3 characters for some part of the name instead of having to lose them to the file association.

Sunday, December 8, 2002

It might seem that it would be better to have embedded junk in a file to determine the type rather than the extension but at the time it was defined that was about all that was required.

CP/M, not MS-DOS defined the file name and directory structure.  When the MS-DOS port of CP/M 80 was released it ported a deal of the file system with it, replacing FCB extents with the FAT. 

That this made sparse files impossible to create didn't seem to be a big problem, though actually it was and a number of applications depended on being able to create 'large' files.

Whether in MS-DOS 3.0 they should have gone all the way and implemented the Xenix file system the way they intended to do is another interesting cul-de-sac in Microsoft's history.

If they had, networking and large file devices would have been a lot easier to implement and wouldn't have taken so long to bring to market.  As it was every vendor had to solve the problem their own way.

Oh and Posix would have been real and not fictitious until the 90's.

What the 3 letter extension did allow though was both anarchy and standardisation at the same time.  Applications could define their own extension, but you could try and open any file with any application, if it worked fine, if it didn't you got garbage.  But it wasn't such a big deal.

That remains true today, though you can get into all those horrendous run arounds of after installing an application theat just happens to handle JPGs you find you lose all your other associations, etc, etc.

I find it fairly reassuring that I personally can make a stab at knowing what application I have I should use with what kind of file.  If I want to search all .doc and .txt files I can, easily.  Having to search by file content, even meta content, is always going to be more expensive.

Simon Lucy
Sunday, December 8, 2002

good point Simon.

Posix, is somthing I keep reading in books:-)

Prakash S
Sunday, December 8, 2002

WordPerfect allowed you to use all 11 characters of the file name, which was useful, but didn't make any effort to differenciate its files from other file types in the operating system. As long as you kept all your WP files in one directory (or set of directories), this was okay.

Someone mentioned resource forks on the Mac, but I don't think this is where the file type information is stored. As far as I know each file type has a (hopefully) unique 32-bit identifier, which is stored by the file system's directory structure, the same was the filename, date saved and file attributes are stored.

This is, of course, great when the file is on your local box, in the file system. No messy file extensions to worry about. Windows also assigns each file type a 128-bit GUID, but for historical reasons these aren't stored in the file system, they are mapped through the registry from the 3-letter extension. Perhaps Longhorn will move this mapping to the new database driven file system allowing the file extension to be done away with. Or perhaps it will use MIME types instead.

While there would be advantages to this, I can see some potential problems... if file type information somehow gets lost, you're back to square one, trying to figure out how to assign it the correct type information. And mapping Windows types to Mac types would be another issue. And then there's the whole issue of backwards compatability. Perhaps the OS could automatically add/remove extensions for legacy programs.

I suspect we'll have to put up with extensions for another thirty years at least!


James Shields
Monday, December 9, 2002

Actually, Word, Excel, and many other programs use the first part of the file to indicate the file type. That way, the program can really determine whether a file is something it can read. This clearly is necessary since extensions can be renamed.

There is no way that the OS can use this information because it is not standardized.

The difficulty of dropping the dependency on extensions is that a standard file structure header would need to be defined and everybody would have to use it. Additionally, what do you do about older files that lack this information?

Monday, December 9, 2002

The file type information doesn't need to be stored in the file itself.  It can be stored in the file system structure, along with information that is already there such as the file name, size, last modified date, read only flag, etc.  I believe this is how the mac file system works.  The problem you run into here is when reading files off of a different file system, you don't have the appropriate meta-data

Mike McNertney
Monday, December 9, 2002

*  Recent Topics

*  Fog Creek Home