Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Windows' print subsystem was one of the ways it became so dominant, by having a standard hardware abstraction layer desktop software like word processors and spreadsheets could advertise "compatible with Windows printing" and buyers wouldn't have to shop around for software and printer models which were compatible with each other, and developers wouldn't have to . Jeffrey Snover talked about this as part of his design for PowerShell, to have a standardised management interface that admins could learn for scripting and automation, and third parties could present an interface to for managing their products and services.

The print subsystem is one of the backwards compatibility limits on redesigning parts of the classic control panel - I'm fairly sure Raymond Chen has written about it - because so many print drivers depend on the way it works to hack in pages and popup dialogs for specialist configurations for their printers.

It also integrates decently with Windows' granular permissions, file and printer sharing on networks, logging, has tons of specialist printers like label printers, receipt printers, etc and is used by a ton of 3rd party management and configuration tools. I would be hugely surprised if it's unsupported in 2031.

> "*"I bought windows (server) because of the print subsystem"?"

When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"?



Thank you for taking the time to write this!

When using CUPS in my previous posts as an example of "Standard OpenSource component that could be a drop-in replacement in a vast majority of deployments/installations", I was hoping, that somebody knowledgeable would reply with some details about the (speciality-use) features/use-cases of the Windows Print-System.

You mentioned a few points, that I'll try to itemize, and respond to:

* Specialty hardware setup, and UI's for that: In these times(for non-ancient devices/deployments), is that not easily solved by the [WEB-]UI of the printer?

* Speciality hardware runtime control for printjobs (staples, binds, folds, glue, mailing, ...): I thought, all of these are commonly abstracted into "verbs" in the PCL/PJL, and just need to be "included" in the PrintJob.

* Decent integration into enterprise setups. In what ways do you find CUPS lacking here? I find CUPS+AD-Auth_to_Samba4AD works great, and all the RSAT tools are functional from a domain member workstation

* Driver support: Is that really still a problem these days?

* Availability of paid support for Windows Printsystem for X amount of money in 2031: If commercial interest is there, I have no doubt, that MS will offer something like for WinXP and Win7 years after the normal EOL of Srv201{6,9}. I just thought, It was already visible now, that the "commercial interest" for this was going to be small, but then again I might be underestimating the (future) size of the "Seriously large-scale paper printing" market.

> "When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"? "

Admittedly, never, but I can probably count in years the paid time, that I have worked helping clients with their Windows Print problems, many times calming them down to get the screaming and crying under control. So maybe a replaced print-system (In WinServer) could (by some) be seen as net positive, while the average Windows Home user wont notice/care. ;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: