Perhaps they are trying to avoid breaking 3rd party code.
I've spent quite a lot of time poking around in the print spooler and my gut feeling is it's probably riddled with issues like this.
I've spent quite a lot of time poking around in the print spooler and my gut feeling is it's probably riddled with issues like this.
It's not going to increase in relevance or take over the world, but it is probably satisfying.
As opposed to Apple, who just assumes you don't use printers older than 2 years and liberally breaks old printers and scanners.
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)
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.
And stump upon sb else code that you have no permission to modify
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 don't think parallel ports connected directly to the bus, there was always an interface chip like the Intel 8255.
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.