Also I suspect nobody wants to work on it because who wants to do printing.

I actually think working on printing infrastructure might be fun. There is image processing, font rendering, etc. which are fun niches. And you can see something physically tangible from your work.

It's not going to increase in relevance or take over the world, but it is probably satisfying.

I strongly suspect it's a haphazard, under-tested mess of compat hacks to work with thousands of models of printers, with thousands of quirks and bugs that Microsoft has painfully worked around to take care of their customers.

As opposed to Apple, who just assumes you don't use printers older than 2 years and liberally breaks old printers and scanners.

App compat hacks can be a fun sport for the right kind of person. I was on the Windows team for a few years and I sometimes looked at those or saw posts about them on mailing lists. It can get interesting.

Printing was complicated in those days because a computer couldn't hold a bitmap of a printed page in memory and still do anything. Early PostScript printers were also much more powerful than the PCs that drove them, often with 32 bit RISC CPUs, dozens of megabytes of RAM and some even had SCSI disks.

Now that most computers can hold a page in their L2 caches, it's easy and much faster to render in-memory and send a bitmap over to the printer driver to let it print with whatever options it wants. All the driver needs is to accept a bitmap and print it as well as it can and you can safely ignore most of the printer's own PDL.

Most of the thorny issues in printing are with special-purpose printers - thermal, barcode, embedded text only, etc.

Apple uses CUPS and it should work fine with older printers. Last time I checked, CUPS could handle an HP Deskjet 500 (if you have the parallel port)

Fun story I heard from an aerospace engineer - they were running some heavy simulations and producing graphs.

He found the printer that was emitting the graphs was actually more powerful than the (very expensive) machines running the simulations, to the point that converting the simulation to postscript (or some variant thereof) and running it directly on the printer was some orders of magnitude faster.

Indeed. I've seen printers churn out beautiful fractals at a fraction of the time it took 68K Macs to do it.

> There is image processing, font rendering, etc.

And stump upon sb else code that you have no permission to modify

That must be some kind of purgatory where developers goes to slowly die inside.

I said it somewhat tongue in cheek because I have been working with printing technologies for my whole career.

I’ve been working on a printing related project at my job and it’s been awful. Printers are the worst.

In the 1980's with MS-DOS you started out printing without a print spooler.

When IBM chose the I/O ports for the PC, they used a parallel port compatible with early office printers from Centronics, but used a female DB-25 connector (previously seen mainly on external serial RS-232 modems) on the PC. The printer end of the cable had the Centronics type connector.

By that time Centronics and other pre-DOS printers were already issued with standard or optional serial RS-232 input, or parallel.

Serial printers most often still used a DB-25 like modems, and parallel the Centronics connector. The only bidirectional communication was logical handshaking which had dedicated conductors in the cable, serial only needed one conductor plus ground for the data and 2 or 3 more conductors if you were even using handshaking. Parallel uses 8 data conductors and about half a dozen logic lines.

The early IBM PC offered an optional serial RS-232 I/O card having a male DB-25 (9 pins is actually more than enough for serial but the DB-9 connectors didn't show up much until you got 2 COM ports on a single card) then once people started using a mouse they were serial DB-9 and built into the mainboard. This was the bidirectional port to communicate with modems and send to printers. Or anything else, the RS-232C standard specifies you must be able to short any of the conductors or connect them to anything within +/- 25VDC without damage, whether the hardware is powered on or not. Not everything meets the full standard.

OTOH, parallel connects directly to the bus and can be very sensitive to incorrect connections or plugging cables while powered. Often damaging motherboard chips for a while there if a stray DB-25 serial modem cable were plugged into the parallel port of a PC. Which might contain jumpers between pins in either or both RS-232 connector hoods to effect self-handshake.

The printer was conceptualized to be the one _peripheral_ that every office was going to surely have or the PC could not function like a typewriter, so the printer has actually always been part of the PC which you connect first before powering them up as one.

Anyway, DOS would only do one thing at a time, so for paperwork you would have to wait for the printer to finish before you could move on. Some printers were slower than others. Fast was not in the vocabulary for early-adopting offices.

Within a couple years at Radio Shack you could get a print spooler to come between the CPU and the printer. An external hardware print spooler of course.

What a time-saver! When you hit PRINT your data went into the spooler much faster than the printer could accept it, within a few seconds you had your command prompt back and the printer could finish the task on its own, however long it took.

Eventually significant buffers came inside the printers themselves, plus Windows became accepted in mainstream offices and it had a software spooler.

With printing handled within Windows at the actual DOS layer for the first decade while Windows was only a shell around whichever DOS you installed it over.

I remember writing a print spooler for the Apple II. It only worked with RS-2332 because the Centronics interface didn't support interupts.

I don't think parallel ports connected directly to the bus, there was always an interface chip like the Intel 8255.

You're right, just not as well isolated as RS-232.

How bad could it be? It's about assigning people to the task and if necessary increase the pay. If it's a bigger mess make it a priority and have your best people fix it asap. Printing and security are important.

From my knowledge of the horrors of printing and being the 'printer guy' for a Drafting department where we dealt with all kinds of interesting printers...

The scenario I'm theorizing, is that there's probably at least one major vendor who's drivers are dependent on this behavior, and Microsoft is trying to avoid the flack that could result from an update 'breaking usability'. Working around that behavior could be complicated. I feel like if this is the case, I know the vendor.