Microsoft admits to yet more printing problems in Windows as back-at-the-office folks asked for admin credentials Microsoft's brand new operating system, Windows 11, appears to be just as iffy when it comes to printing as its predecessors. The latest problem turned up in the Windows Release Health dashboard last week and warned that a prompt for administration credentials might pop up when the print server and client are in different time …
Who remembers the cartoon in either Personal Computer World or Computing magazine (who even remembers that magazine??) which showed a guy towing several large trolleys each loaded up with a moutain of paper.
A colleague stopped him and asked "What's that lot?"
Answer: "It's the documentation for the new paperless office"
And the latest update ignores the workaround for the previous update.
https://www.bleepingcomputer.com/news/microsoft/new-windows-10-kb5006670-update-breaks-network-printing/
"When the September cumulative updates caused printing issues, it was possible to fix them by allowing non-Admins to install printer drivers or disabling the 'RpcAuthnLevelPrivacyEnabled' Registry value.
However, this Registry key is no longer working for the problems caused by the October updates, and users are required to fix it using other methods."
Perhaps the workaround d'jour is to reset your timezone to match that used by your printer? Or, what the hell, put the whole damn organization on UTC. Tell anyone who asks that using UTC gives a 13% a improvement in security and efficiency.
Not like I haven't had issues with Windows not keeping the correct time between restarts ...
Two or three decades ago that used, most often, to be due to the battery powered motherboard aka "CMOS" or "BIOS" clock. Those things used to be, and probably still are, designed to be cheap, not accurate. It wasn't at all uncommon for them to drift seconds a day. Adds up. Plus, the batteries that provide them with a tiny trickle of power when they PC is off, like batteries (almost) everywhere and always, wear out even if they are rechargeable. I believe many (all?) PCs still use those clocks. Sometimes the batteries are easily replaced. And sometimes they aren't.
I’m looking at you, HP…
I had a client with some HP laptops which were written off due to needing new CMOS batteries fitted. The battery was cheap enough, but the fact you needed to remove each and every component from the chassis to change the battery made it an uneconomic fix, sadly.
If anyone is interested, the battery was in the centre, directly under the keyboard tray, and you could see it with the keyboard off, but had to remove base, main board, drives, screen assembly, keyboard, trackpad, kitchen sink to get it out…
By any chance an Elitebook 820 G1?
I know one of their small machines had a plastic area under the keyboard where most other Elitebook ProBook models relied purely on the keyboard (Only one occasion that might of helped as the user had buckled the chassis of a 6730b so much so the cd drive wouldn't eject)
Did a friend a favour by replacing his laptop battery. The base top had several holes under the (eventually) removed keyboard - but not one above the battery. The base halves were held together mostly by fragile friction clips. Eventually managed to prise the base apart enough at one end to get the battery out.
Fortunately it had a 2mm 2 pin plug. Ordered up an apparently standard replacement - then warning bells rang in my head. The replacement had the red/black wires on the opposite keyed pin polarity.
I found that my network printer connection failed with about every Windows 10 update. Fired up a 12 year old dual core Celeron and loaded Netrunner Linux with the appropriate printer set to share. All six of my home office computers recognize my shared printer (HP Laserjet 4!) and it has worked with no drama through power outages, reboots and updates. Cheers.
As a penguin-fancier I always for for network printers that support postscript as they usually work OK. Generally look for compatibility with Apple and it gives you that. While they are not usually the cheapest choice, the reduction in pain and suffering in getting it to print and continue printing is usually wroth it.
Yes. Pixma *they have a MG7720) is triple-supported -- cups itself has direct pixma support. It's supported again by 2 driverless modes (Aren't industry standards grand? There are *4* "driverless" mode printing "standards", Apple uses 1 (Airprint) and there's 3 others, Ubuntu supports all 4.) Finally, Canon supplies a driver, it has a bit better color accuracy than the others so I have their computer using that.
(This Canon driver annoyingly is a x86 binary blob style -- I did actually install it on an ARM Chromebook I had Ubuntu on.. installed qemu-user-static, this adds some "binfmt" hooks so non-native binaries are *automatically* run under qemu. I added x86 and x86_64 architectures in I think /etc/apt/sources.list, and when I installed canon driver it installed some x86 libs, and it actually ran fine. A bit CPU-intensive (emulating x86 bin on ARM) but it stayed ahead of the printer so no ill effects compared to native.
------------
The advice to check for Mac support is spot on -- even in the prehistoric days, Mac support generally indicated a printer with mutli-platform support in general and avoided "winprinters". More recently, OSX and Linux distros both use cups so printer support is virtually identical between the two.
Yes. At least PCLinuxOS does support my Canon Pixma ip4500.
It seems as if, unlike sound, Linux has got a grip on handling printers as I have never had any problems using the likes of Brother, HP, Canon and so on. Scanners on the other hand are a nightmare for me at least.
I'm not a fan of HP but I'll always get their printers. Clearly some devs over there are Linux guys because their Linux drivers are top notch even with fun features like network scanning.
The real kicker is I think the fully featured Linux driver download is about 8mb. The Windows driver was 350mb.
Yeah for real. The Linux HP driver, there's HPLIP (a thing that notifies if printer is out of ink or paper, so optional really); and the cups printer driver and sane (scanner access now easy) scanner driver, these drivers tend to be quite small and HP's are no exception.
I think in Windows, there's GUI components for both of these so the actual print & scan drivers are far larger; a photo management app, scanner program, probably a banner and poster maker, some application to guide through buying ink from them, and so on.
Hmm, that is rather remarkable. We have a Samsung laser here, and it has worked without a hiccup since the day it was put on the corner of the desk. Both cable and over wifi.
Did you also have a look with HP? Because, if I remember well, the Samsung printer division was taken over by HP, who now supply the (CUPS) drivers for those Samsung printers...
For example...
They don't want to kill off CUPS. What they want to do is make it driverless, such that it will only work with IPP or IPPS printers (which, in case you don't know, have a PDF interpreter in the printer, so that you just send the PDF and the printer itself does all the heavy lifting of rendering the page).
But completely removing the GhostScript or GutenPrint formatters is a while off yet, according to a developer thread I stumbled across when I was researching a problem, although it may be removed from the default CUPS installation.
For years I've found CUPS to be reliable and easy to use and set up, but I have to admit that I'm finding the new default preference to use IPP for older printers hung off remote Linux systems (I have a couple of low-power Linux systems acting as always-on servers for various things) rather problematic. I would prefer the page to be rendered on my more powerful laptops or workstations and transferred across the network pre-rendered, rather than run the rendering on the lack-luster print servers. And I just can't get my head around UNC printer addresses in the CUPS configuration files. It seems that everybody wants to make what was once simple and easily understandable, complicated.
Were you really there in the days of MS-DOS 1.0?
If you were, you will remember that MS-DOS did absolutely nothing with printers apart from providing a way of getting bytes to whatever port the printer was connected on.
Back then, the application you were running had to know about the printer, and how to format data for it. All MS-DOS did was to queue the bytes up, and send them to the printer (although I believe that some versions of MS-DOS shipped with a print spooler). And there was no common format for printer definitions, so you would need one for your printer, for each of the applications that you wanted to print.
But printers themselves were much simpler devices. Generally, they were character oriented devices, with embedded codes to select the limited fonts that the printer had and the special effects like bold, underline, super and sub script. This made it fairly easy to write a printer definition file, as programs like WordStar used embedded attributes that you could map one-to-one with the codes for the printer.
Printers that had proportional width fonts needed much more complicated printer definition files for applications, and some applications could not use these printer features because they could not store the and calculate individual character widths, and were restricted to fixed-width fonts.
The types of printer that were around with MS-DOS 1.0 were things like the Epson MX-80 dot matrix printer, which were very simple devices, although daisy-wheel and golf ball printers were available.
The concept of rendering a page in the computer, and sending it as effectively a bit-map to the printer is a much more recent development than MS-DOS 1.0. It appears that it was introduced with GDI+ in Windows XP. I don't know how printers worked in previous versions of NT, but I think that Win95 required that programs knew how to drive printers, like MS-DOS.
Printing has always been the unfashionable end of Microsoft's hap hazard development strategies.
The Printing API alone demonstrates Microsoft's utter inability for any form of consistency, giving a flying crap about anyone other than North American users (because everyone on the planet uses inches and US only paper sizes, right?) and as for the tortuous API level machinations required just to get or guess basic printer capabilities let alone perform some printing... argh.
They had a real opportunity to do it well, the OS could have easily provided print preview which all applications could have benefitted from, but Microsoft probably wanted to keep that to their Microsoft Office suite rather than have the OS do anything useful. The OS printer system could have been expanded to cater for modern printers, but instead they left it in a limbo for printer driver manufacturers to expand in their own bespoke and non-standard and non-interoperable ways. It's brainless decisions like this that led to print drivers being as extensive they are now, simpler drivers and more standard systems tend to have less exploits.
So now, because of Microsoft's wilful abandonment of the printing system for years, on top of unstable and badly written drivers and hacks on top of the operating system, we have a series of exploits. Exploits targetting drivers that passed Microsoft's tests (when this used to be a thing).
Now drivers require administrator level access to install when they should be simple. Drivers deployed from a damn trusted server require administrator level access to install, which is disruptive as hell, but we're back to the same dumb stupidity when much of Microsoft still thinks that all users should be give local administrator access to the system they use - the fucking installation process pretty much dictates it.
As for Windows 11 having the same problems being a surprise? No surprise at all, Windows 11 is just a reskin of Windows 10 with a PITA installer that insists on fictitious hardware "requirements" to install.
/rant :)
I have always been fascinated with Borkzilla's addiction to admin-access-required drivers to do just about anything, when , under Linux, you can basically update just about everything without rebooting your computer, including the graphic drivers.
A printer driver needs admin access ? WTF for ? It's a printer, for fuck's sake. It's an OUTPUT. It's not like the printer is going to access the hard disk or RAM, it just takes whatever the program feeds it and prints it out.
Jesus Christ in a basket, why all the complication ?
why all the complication?
Just guessing because I gave up on Windows a long time ago. But my GUESS would be that the problem(s) isn't/aren't drivers so much as print queue management. Queues for shared printers can contain files from multiple users with differing access privileges. Can't let just anyone tinker?
Last time I looked CUPS required some credentials in order to tinker with print queues -- restart jobs, clear problem jobs, etc. Windows is probably similar? I had to create an lpadmin user and add said user to my list of printer administrators when I set up printing on my personal linux machine many,many years ago. And I need to claim to be good old L P every now and then to persuade CUPS to do what I want. But maybe there is a better, simpler way. It's not like I'm a super qualified Unix system administrator.
Just as likely it is a remnant of bespoke printer drivers that required admin access. Let's look past the common "blame Microsoft for everything" and look at actual circumstances.
All too often (and quite sadly) some printer manufacturers force their printer driver install to need admin access because *they*, the printer manufacturer, decide to require the installation of a proprietary port driver during the initial install of the printer software.
And, as usual, I get to show proof that this has been occurring in the Windows ecosystem for a long time. My tech support reply to a user in 2002, 19 years ago:
https://www.tek-tips.com/viewthread.cfm?qid=321796
Both Seiko AND Canon are STILL using proprietary port drivers 2 decades later. Windows 7 and later just isolates printer drivers from the spooler subsystem in order / hopes to avoid the issue I supported 20 years ago.
https://docs.microsoft.com/en-us/windows-hardware/drivers/print/printer-driver-isolation
And, understand, I've been supporting this issue, figuring out three problems of proprietary printer port drivers, since Windows 3.11.
So Windows' printer subsystem gets broken...because all too damn often the printer MANUFACTURERS intentionally break the system, and have been doing so for decades.
MS have had many opportunities to fix that though. If they'd added a better printer subsystem and required all new printers to use it, if they wanted WHQL status, we'd now be in a situation where most of them do.
Unfortunately it's very clear that MS don't understand anything about printing. Eg the Photos "app" can't print a decent photo at all - it has no settings whatsoever to fix the ludicrously dark output.
Gimp does a far better job at defaults.
For well over a year the Microsoft Photos app in Windows 10 just crashed immediately every time print was pressed - the only way to print an image was to use the old Windows 7 Picture Viewer - or use Microsoft Word or some horror like that. It was a way around the problem, so can't really fault users for doing that at this time.
it's a problem with Microsoft at the root cause of it all.
Not that this excuses the printer manufacturers from developing some of the worst abominations of software developer this side of Samsung, but Microsoft really did not help whatsoever.
Even when Microsoft eventually bothered to put in place standard TCP/IP print driver port, the printer manufacturers (who would typically make a room of monkeys mashing keyboards look like a highly talented room of developers) still needed to support the older OSes. As a result they are not going to create what would essentially be entirely new drivers to link to the new MS provided print driver port and maintain these separately to the support for older OSes. Some did, of course, but not many and they also were highly unlikely to go through their back catalogue of printers and create new drivers for all of them.
Exactly. And then for inkjets they install ink and printer monitoring software, again NOT a standard on the Windows platform and needing admin rights. They do it because they can, so they do....and break things. But then most people yell at Microsoft.
Linux will not stand for any of those games, the kernel is server-based and bypassing the system drivers with their own, plus installing system-level background apps, would have heads rolling. Fooling around with CUPS, to the same level as these clowns do to Windows, would be outright WAR.
But Windows is a client OS and the manufacturers know the can get away with miserable designs under the guise of "enhancing user experience".
I don't know where to start.
I think I'll take the "It's a printer, for fuck's sake".
If you were to go back to the MS-DOS days, where applications themselves formatted prints, then you would be correct. The OS is just shuffling bytes, But that required every application to know how to print to every printer. If you were there, this was never pretty, and would never cope with today's high function printers.
Of course, it would be possible to use filters and intermediate printer languages, like we did with troff on older UNIX systems, so you would get a line such as "eqn file | tbl | pic | troff -Tpsc | psdit | lp -d postscript_printer", but that was never popular then, and certainly would not be popular now.
So the move was to make the printing system more intelligent. On AT&T System 5, you had the concept of printer filters built into the print system itself, so you could set up a named printer to take a file of a particular format, and do the required filtering without the user seeing what was happening. Other UNIX vendors did similar things, but I can assure you that the administrators needed to install the software for the filters, and set up the printers to call the filters in the correct manner.
Microsoft opted for a different model. After a couple of attempts, around Windows XP they decided to use WDDM to accept an intermediate print description, and allow the OS to determine how render this into a form that the printer would use, according to a printer definition file proviced initially by the printer vendor, but increasingly from a database that MS maintained. It's true that they could have put this processing into user-land, but they decided (from NT4.0) to put this processing in kernel space, using kernel processes. This meant that the printer vendors only had to write one printer definition, for windows itself, and the application writers did not have to bother with anything other than the intermediate language for WDDM.
Because of this, it is again important to limit the setting up of this to authorized users.
CUPS on Linux is really no real different. Although there are a large number of printer definitions installed by default, if you need to add some more, you need admin rights.
I don't understand your "under Linux, you can basically update just about everything without rebooting your computer" comment, because we're not talking about rebooting the computer, we're talking about needing admin rights to change the printer definitions.
Of course, if we end up with a single print model, like IPP/IPPS, then the OS will only have to understand how to shuffle the bytes to the printer again, but although we're getting there, we're still a little way off that just yet. But be prepared to ditch all your old printers when we get there!
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
