A blog post pointed me to Pete Peterson’s Almost Perfect. The book details the rise and fall of WordPerfect (the software and the company), and is a great testimony to the earlier days of the industry. It’s the story of how a legendary company came to be and how it still shapes the world of word processing to this day.

Consider the state of computer-based word processing in 1977 when WordPerfect was conceived of. Afraid that word processors would interfere with so-called important applications, companies did word processing on dedicated mini-computers and mainframes. These machines were operated by a word processing department of employees that typed up documents. It wasn’t until the IBM PC that corporate users began typing documents themselves.

The early years

Pete’s way into WordPerfect — and his initial exposure to computers — was by way of his brother-in-law, Bruce Bastian. Following Bruce’s computer science degree in 1978, Bruce joined Alan Ashton to realize Alan’s vision of a word processor for a Data General mini-computer. It was then, in 1979, that Pete joined the two as office manager. By 1992, when forced to leave WordPerfect, he’d turned vice president of marketing.

Alan’s unique ideas involved crafting a word processor that didn’t require entering codes to format and layout documents. Compared to HTML authoring of today, contemporary word processors required the author to mix text and codes. Like tags in HTML, the codes described properties of the document, such as margins, line feeds, and emphasized text, and were specific to each product. Alan’s word processor, although character-oriented by nature, was to display the underlying codes using textual effects, creating a rough WYSIWYG experience.

Other innovative features included the ability to scroll through a document line by line, rather than page by page, and non-modal editing. Contemporary word processors required the author to switch between command and text modes the way the Vi family of editors still do. Without menus, modes made it easier to separate commands from text. Nonetheless, WordPerfect was modeless and hence characters could be typed in anywhere and anytime.

In the late seventies, word processors (and operating systems) were largely written in assembler and hence required rewriting for each hardware platform. Up until the IBM PC version, assembler also dominated WordPerfect, which made it a challenge to maintain considering the plethora of supported platforms. Migrating to higher-level languages had been considered, but was discarded on the premise that it would result in slower applications with bigger memory footprints. On that note, it appears we haven’t learned as we keep rewriting the same fundamental applications and frameworks. Not in assembler, but in higher-level languages.

Microsoft catching up

The 1981 introduction of the IBM PC pawed the way for a shift in the way software was developed and marketed. For vendors, the common architecture made lock-ins harder, yet provided access to a size of user base never before seen. WordPerfect was quick to seize the opportunity and released WordPerfect for the IBM PC in 1982.

Although the software marked for the IBM PC was dominated by Microsoft, for years Word (and other word processors) couldn’t keep up with the features and sales of WordPerfect. Two technologies, however, enabled Microsoft to overtake WordPerfect: laser printers and graphical user interfaces. For years WordPerfect had supported a few laser printers and had only a text-based interface. By 1987, though, it had become clear that graphical user interfaces was the future. It just wasn’t obvious weather Windows, of which version 2 had just been released or OS/2, whose development was announced that year, or some other vendor would end up dominating the market.

The final years

Moving from text to graphics posed a challenge for WordPerfect. Under DOS, the operating system provided only rudimentary services for drawing on the screen. For proportional font and image rendering, WordPerfect would itself have to take on rendering or use the services of a graphical user interface. But since it wasn’t clear whether Windows, OS/2, or some third environment were to dominate the future, WordPerfect decided to only augment the text-based interface with a graphical preview page. At the same time Microsoft released its first version of Word for Windows 2.0, relying on Windows for proportional font rendering, image display, and decent laser printer support.

In light of present knowledge, it’s all too easy to pass judgment on past decisions. Nevertheless, it appears that the inability of WordPerfect to keep their eyes on the rolling ball had caused Microsoft to take over by the early nineties. Instead of focusing on WordPerfect for Windows, substantial resources went into developing versions of WordPerfect for other platforms, developing a spreadsheet and a database application, and many more.

For years the availability of WordPerfect on almost any conceivable platform had supported the growth of the company. Now, the inability to cut losses and retain focus dragged WordPerfect into oblivion.

With the ubiquity of wireless routers follow a surprising network instability issue. It turns out that wireless routers at many of the 330 apartments connected to network where I live bring with them rogue DHCP servers that make the network unstable.

Non-authoritative DHCP servers on the network have posed a challenge for years. At first, I attributed the DHCP servers to badly configured Windows machines. However, the number of DHCP servers suggested that another explanation might be closer to the truth. Users accidentally installing DHCP servers are just not that common, and inspecting a couple of machines in question they were acquitted. What else could be the source of the DHCP traffic, then? Common to the machines were that wireless routers sat between them and the LAN.

After much investigation, it turns out that a lot, if not all, wireless routers expose their DHCP server on all ports of the router, when it’s only necessary to expose it on inward-facing ports. I guess vendors don’t bother limiting the exposure because generally it’s of no concern to consumers. ISPs provide the wireless router with the necessary configuration parameters (IP address, subnet mask, default gateway, DNS servers, and so on) in addition to blocking DHCP traffic originating from the wireless router.

On our network — equipped with eight aging 48-port Cisco Catalyst 3500 XL switches — DHCP traffic cannot be prevented from escaping the wireless router and making its way into the switches and onto LAN. The configuration parameters of rogue DHCP servers, intended for internal use only, are transmitted to external DHCP clients. Clients for which the supplied gateway, DNS server, and so on are only internally available. The DHCP client, unable to discern the rogue servers from the authoritative one, passes the parameters on to the network stack, setting itself up for network disconnectivity.

The essence of the issue is that whenever a client requests configuration parameters, it, by definition of the DHCP protocol, broadcasts a message to be picked up by any DHCP server on the network. The client then awaits an offering of configuration parameters from one or more DHCP servers. Then, still according to specification, the DHCP client may use any strategy to accept one of several offerings. I can only guess as to how Windows makes its decision, but randomness and first responder probably play a key role. In any event, Windows may keep accepting offerings from rogue DHCP servers regardless of the number of times I command the IP configuration to “ipconfig /release” and “ipconfig /renew”.

How to counteract rogue DHCP servers? There’re only a limited set of options: hard-coding the configuration parameters of individual machines, establishing VLANs so computers become invisible to each other, or replacing the Cisco Catalyst 3500 switches with contemporary switches that are able to suppress DHCP traffic travelling the wrong way.