Installing the drivers for an HP LaserJet 6P on Windows

From the time where printer manufacturers were still producing near indestructible models. Plus, 5 years on, and I'm still using the toner cartridge that came with the printer. Add a USB → IEEE1284 adapter, plug into a NAS or plug computer, and enjoy your network printer.

Now, I did spend some time getting cups going, but I found it a bit flaky, so I reverted to direct samba access to the raw device. But that means the need for a driver on Windows, and Windows 7 considers that the HP printing dinosaurs are too old to be supported by default. On the other hand, that probably means you'll be able to find a cheap one on ebay.

Now, for those of us who know better and still want to do our Windows printing through a trusted HP LaserJet, the procedure to obtain the drivers is as follows (should work for the whole range of old HP printers, and not just the 6P):

1. Open IE (won't work in Firefox or Chrome)
2. Go to http://catalog.update.microsoft.com
3. Search your model, e.g. "LaserJet 6P". This should list a set of drivers for Windows 7, Windows Server 2008, etc. that are also of course compatible with Windows 10. Gotta wonder what the "search for drivers online" feature of Windows is really used for.
4. Select the most relevant driver, e.g. "Microsoft driver update for HP LaserJet 6P"
5. Click "View Basket"
6. Click "Download"
7. You'll get something like X86-all-XXXX.cab or AMD64-all-XXXX.cab file that you need to save. Be mindful that if you try to use the AMD64 package on a 32 bit version of Windows, or X86 on 64 bit, it will not work, so make sure you get the right one.
8. Open the .cab file you just saved using 7-Zip, and extract all the files into some directory.
9. Install your printer and select "Have Disk" when prompted for a driver. Then point to the directory where you extracted the files.
10. Enjoy another many years use of your LaserJet printer. In all fairness, the early LaserJet printers are so indestructible that you'll probably die long before your printer does.

Virtual Store, Windows 7 and HyperTerminal

Let's do things in order then.

1. In Windows 7 (I think it started with Vista), Microsoft locked down the ability for executables to write into system directories like C:\Windows, C:\Program Files, etc., unless they run as admin. This is probably a good thing.
   
2. However, backward compatibility tells us that there are plenty of programs that want to store settings or write files into their installation directory, which is most likely located in C:\Program Files (x86)
   
3. To avert this issue, Microsoft created the Virtual Store directory, which is located in C:\Users\myuser\AppData\Local\VirtualStore\ which the system uses for write access to restricted directories by overlaying it into system calls. For instance, let's say a copy of XP's HyperTerminal is installed on Windows 7 x64 into C:\Program Files (x86)\HyperTerminal\ with an HT session file called mysession.ht residing in the same directory, with this session file having been previously created and installed into C:\Program Files (x86)\HyperTerminal\ as admin. Having been developed up to XP (and yanked on later versions - more about this later), HyperTerminal saw no qualms about updating session files that reside in C:\Program Files (x86)\HyperTerminal\. And HyperTerminal needs to update your session file, whenever you exit the program, to update the terminal buffer log and other things, so it needs to write the session file every time it is used. What transparently happens the first time HT tries to update the session file is:
   
   1. An exact duplicate of mysession.ht is created as C:\Users\myuser\AppData\Local\VirtualStore\Program Files (x86)\HyperTerminal\mysession.ht, to which "myuser" has R/W access.
   2. On subsequent access from HT, this is the file that is being read and written, the original file from C:\Program Files (x86)\HyperTerminal\mysession.ht being left completely untouched from how it was when first copied there.
   In essence this means that there exists differing duplicates of the same file on your system, which, if you are using programs that have not been updated for Win7/Vista, is something you want to be aware of. For instance, in case you spent a lot of time creating conf/settings files in an application, and thought that a backup of the C:\Program Files (x86)\Some App\ would be enough, you might want to reconsider. This can be quite important if you want to back up application settings (IDA Pro comes to mind) as any app that was designed to store data in C:\Program Files\ will effectively store it in the Virtual Store, and simply backing up the app dir won't be enough.
   
4. What does the above has to do with HyperTerminal then? Well, HyperTerminal was yanked from Vista and Win7, which is bad news if you're working with embedded devices, and say, want to transfer data using a serial console through X/Y/Zmodem... The thing is, the HyperTerminal files from XP work just fine on Win7 (even on Win7 64 bit), but they have a few limitations:
   • if you place your HT session file into a different directory than the one where HT is installed, you will have trouble opening it through a shortcut, and will get prompted about creating or opening a session file every time you run HT. Of course, this constant nagging about creating session files gets old really fast.
   • you cannot change the default startup directory to something you have R/W access to without HT getting into other issues.
   • if you receive data through X\Y\Zmodem and didn't change the directory, it'll end up in the Virtual Store by default, which is why you might want to know where exactly that directory is located.

As a bonus, if you have an XP machine available, here are the files you want to copy to reinstate HyperTerminal in Windows Vista/7:

• C:\Program Files\Windows NT\hypertrm.exe
• C:\Program Files\Windows NT\htrn_jis.dll
• C:\Windows\System32\hypertrm.dll
• C:\Windows\System32\hticons.dll

Copy all those into  C:\Program Files (x86)\HyperTerminal\ and you should be good. And yes, one could solve the Virtual Store problem by installing all these files somewhere other than Program Files, but some people might want to keep their system organized.

A service installation section in this inf is invalid

If you've been banging your head against the wall on this error, and you are trying to install a 64 bit driver on Windows 7 x64 or Windows Vista x64, the problem might simply be due to the ServiceBinary property of your inf file referencing the 32 bit driver (.sys) rather than the 64 bit.

Make sure then that you have something like:

ServiceBinary = %12%\mydriver_x64.sys

and try again. Might work better this time around.