Tuesday, February 18, 2020

#WorkLife: HP LaserJet P1006 and other old hp printers on Windows 10


After upgrading to Windows 10, my HP LaserJet P1006 failed to work. The printer showed up in my printer list, however it would not process any print jobs. Technically, the queue would process it as if it were being sent to the printer (and thus disappear from  the queue), but the printer would never actually print the job.

Thankfully, I found a working solution (posted below) on the HP Forums. I am copying it here just in case the forums disappear one day and/or to make it easier for me to find the information. Hope it helps someone! (Solution written by Shlomi L)

  • First unplug the USB from your PC.
  • From the Control Panel select Devices and Printers, if you see your printer listed right click it and select Remove Device.
  • next restart your computer.
  • Next right click the start menu and select Run, the Run dialog appears.
  • Type printui.exe /s and press OK, the Print Server Properties opens.
  • Open the Drivers tab.
  • Select any instance of your printer and remove it, be sure to select the 2nd option to remote both the printer and its package.
  •  
  • Once you are done install the software below, only plug the USb once the installation prompt doing so:
  • http://ftp.hp.com/pub/softlib/software12/COL21058/bi-55362-7/ljP1000_P1500-HB-pnp-win64-en.exe
Original post:
https://h30434.www3.hp.com/t5/LaserJet-Printing/HP-Laserjet-P1006-not-working-on-windows-10/m-p/6709444#M346167

Tuesday, January 28, 2020

DEC Pathworks on WFW 3.11 - Group Creation Tool



Way back in the day (circa 1994 or so, I would venture), I worked for a university where they were using Digital Equipment Corporation (DEC) VAX servers. The workstations were a mix of Windows 3.1 and WFW 3.11, though when I arrived, we were moving everyone to WFW 3.11. As part of the general network installation, we installed DEC Pathworks (I believe it was version 4.x), which allowed Windows machines to have file storage access to the servers. While that's all well and good, the real her in this tale is a little program that ran during the installation of the software and drivers.

During the installation, Pathworks created its own Windows Program Groups - a common thing to do for program installations. For some reason, during one install, the creation routine failed with an error about a problem in a BLD file though the actual extension may have been different now that I am trying to recall). Being the nosy characters we are, the tech guys decided to investigate since we had never head of a BLD file.

Turns out, the BLD file, which I believe was called PATHWORK.BLD (or something similar) is just a text file outlining group names and the shortcuts to go into the groups. I have tried to locate the actual file, but can't at the moment, so here is the sample file from the program's webpage:

[CreateGroup(Test Main,TMAIN.GRP)]
[ShowGroup(Test Main,1)]
[AddItem(progman.exe,File Manager)]
[AddItem(control.exe,Control Panel)]
[AddItem(printman.exe,Print Manager)]
[AddItem(clipbrd.exe,Clipboard)]
[AddItem(command.com,DOS Prompt)]
[AddItem(setup.exe,Windows Setup)]

[CreateGroup(Test Accessories,TACCESS.GRP)]
[ShowGroup(Test Accessories,1)]
[AddItem(write.exe,Write)]
[AddItem(pbrush.exe,Paintbrush)]
[AddItem(terminal.exe,Terminal)]
[AddItem(notepad.exe,Notepad)]
[AddItem(recorder.exe,Recorder)]
[AddItem(cardfile.exe,Cardfile)]
[AddItem(calendar.exe,Calendar)]
[AddItem(calc.exe,Calculator)]
[AddItem(clock.exe,Clock)]
[AddItem(pifedit.exe,PIF Editor)]

As you can see, this file contains the structure to build groups. First, the CreateGroup command expects two arguments, the display name of the group ("Test Main") and the actual name of the GRP file for Windows ("TMAIN.GRP"). The next command tells Windows that the group is visible (that is, not hidden) and also expects two arguments: The display name of the group ("Test Main") and a 1 for yes or a 0 for no. Finally, the next series of lines build the items to be displayed within the newly created group. The AddItem command expects two arguments as well. The first is the name of the file to be referenced followed by the display name of the file. Note: If the filename is not available via the PATH statement, the full path to the file must be provided - ex: [AddItem(c:\games\duke3d\duke3d.exe, Duke Nuk'em)].

The BLD file is just the configuration, though. The actual program to run is BUILDGRP.EXE, though again I believe DEC used a custom name instead, if memory servers.

During setup, a:\BUILDGRP.EXE PATHWORK.BLD would be executed, with the EXE referencing the specific configuration.

As you might imagine, this suddenly opened a whole new world to us! We created a slew of custom group installations for the users, running the program from a batch file stored on a floppy disk or on the network itself. You see, once Pathworks was up and running, the WFW machine had access to the network. So, we could call a batch file from the workstation and tell our custom group(s) to install themselves on the client machines.

If you're interested in playing with GROUPBLD, you can find it (along with a help file and the sample configuration above) buried in this Windows 31 DOSBox package.

I have no idea what made me remember all this. Guess it just PoppedInMyHead!