Can't give VirtualBox guest OS access to host physical LPT1 port

Question

Preface:

I've just put a 64-bit Windows 10 machine (a Dell Optiplex 760) in an office to replace an old 32-bit Windows XP PC.

The PC needs to be able to print to a very old dot matrix printer - a Star LC100. No 64-bit drivers are available - only a 32-bit one. It emulates an Epson EX-800 (not XP-800). This printer is required as it prints to fabric labels that are washed. The impact of the dot-matrix means the ink does not fade.

I've tried using the Generic Text-Only driver on the host but it gives me an error and fails to print.

---

So I've installed VirtualBox and 32-bit XP on the host, which does have a Star LC100 driver. I'm now trying to give the guest OS access to the physical LPT1 port.

Following this guide, I've ran the following commands:

cd "c:\Program Files\Oracle\VirtualBox"
VBoxManage modifyvm "XP" --lptmode1 "LPT1:"
VBoxManage modifyvm "XP" --lpt1 0x378 7

But now when I try to start the VM, I get the following error:

Parallel#0 could not open 'LPT1:' (VERR_FILE_NOT_FOUND).
Parallel device 0 cannot attach to host driver (VERR_FILE_NOT_FOUND).

Result Code: E_FAIL (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

I've also tried running CMD and VirtualBox as Administrator with the same result.

How can I give the guest XP OS access to the physical host OS LPT1 port? The port shows up on the host OS' Device Manager.

Solution

While the linked to guide shows examples such as the following:

VBoxManage modifyvm "My VM Name" --lptmode1 "LPT4:"
VBoxManage modifyvm "My VM Name" --lpt1 0x378 7

And the original poster then ran these commands:

VBoxManage modifyvm "XP" --lptmode1 "LPT1:"
VBoxManage modifyvm "XP" --lpt1 0x378 7

It seems based on this bug ticket and this specific comment the command should be as follows; note how the : is dropped from the --lptmode1 "LPT1":

VBoxManage modifyvm "XP" --lptmode1 "LPT1"
VBoxManage modifyvm "XP" --lpt1 0x378 7

That said, the original poster solved their own issue by switching to VMWare. But this kind of bug seems pesky enough that it is worth clarifying a solution for any VirtualBox users that might stumble across this in the future.