> CUPS

Hmm...CUPS came way after NeXTStep, way after the NeXT's acquisition of Apple acquisition in fact (wikipedia says 1999). NeXT itself just used lpr/lpd, that was it.

Of course, being Unix, you could hook into the lpd system and add your own filters. NeXT itself did this, using the on-board DPS to RIP for the NeXT Laser Printer (a Canon laser engine) and the NeXT Color Printer (a branded version of the Canon 360 dpi bubblejet). There was a quite a bit of trickiness involved, contacting the WindowServer from a background process and using high-resolution/high-bit-depth rasterising, but it was doable.

Third parties could also do this, for example I made drivers for anything from low-end Epson, HP and Canon ink jet printers (including a more advanced driver for the NCP) all the way to high end proof printers, film recorders and color laser copiers ( $50-90K items at the time). Others hooked up phototypesetters. So you definitely could print to anything as well, and everything would then come out in beautiful Postscript Level 2, with amazing WYSIWYG fidelity.

While the straightforward approach of doing this did require a printer with a raster interface, most low-end printers had that and when there was a print-head, a line of buffering was sufficient. It was more the mid-level laser printers that were a problem, because lasers required a full-page buffer and some just didn't have that much memory.

One time there was a Mission Critical Custom App (MCCA) deployment at a large pharmaceutical company that was in peril because they had several hundred (or thousand? I don't remember) IBM laser printers that did not have enough memory for a raster bitmap...and no-one had thought of that beforehand. Oops. No worries, I created a driver that extracted the text (they were only interested in the text) and precise positioning information and then sent commands in the printer's command language (not PCL or anything else that was well-known) to position/output that text.

Of course, Adobe didn't like all of that printing, and so they continued to tighten the license agreement and hike the fees for print-use of DPS.

OS X didn't start using CUPS until 10.2. I don't remember if the 10.0/10.1 printing architecture was a carryover of the NeXT stuff or something new, but I don't remember it being well liked.

I'm a bit dismayed to hear backwards compatibility - solving problems of an organizations own making - compared favourably with new functionality.

Consumers like being able to run their old software, and in the nineties (and more recently) that meant running software dating back to the 16-bit era of computing. "Solving problems of an organizations own making" is a very goofy way of characterizing that.

I was commenting specifically on Windows 95, and the idea that its ability to run its predecessor's software as being an achievement rather than something one should just naturally expect. Especially considering many of the successive difficulties in this respect were due to short-sightedness in design of the original APIs and then successive generations of API changes, each set meant to replace the last

I've used Quickbooks for my business accounting since 1998. Double entry accounting hasn't changed but I upgraded to Quickbooks 2004 when TurboTax stopped importing older versions with the 2003 Federal Tax season [but that's not where I am going with the API thing]. I still run TurboTax 2004 [see the aforementioned nature of double entry accounting][1].

Anyway where I was going is that as a user, I don't give a shit about API's and the quality of their design. I care about working software. The agile manifesto didn't invent the idea. Just pointed it out in order to change a world where "there are two types of people: programmers and their victims."

But as Faulkner might say, the past isn't even past.

[1]: It gets its own Win2k VM since it has some 16k code for backward compatibility. The VM doesn't connect to the internet because the world has changed.

I see your point about API design, but it's worth pointing out that everybody else was fighting a new revolution every five minutes and leaving behind heaps of the compatibility dead during that era. I imagine NeXT was probably the best of the lot when it came to making a lasting API and not breaking backward backwards compatibility, but perhaps someone who used it (and OS X) more could comment on that.

From the standpoint of business logic, existing working systems tend not to reduce to values equivalent to problematic. Conversely, spending money to replace one system with a more expensive system that provides equivalent value often does reduce to such values.