Phil Da Lick!
2008-05-10 16:46:19 UTC
Here's the deal:
I've got an app I've been maintaining for 14 years now that writes raw
data down the serial ports to specialist printers. No big deal, hardly
rocket science. Quick call to CreateFile() with the port name, job done.
At least, that was the case.
Now, as parallel ports are disappearing from laptops and the like we're
starting to see the rise of USB-parallel leads.
No problem I thought, the driver for the cable must include a port that
can be used as normal.
Boy was I in for a shock. You see, the driver does indeed install a
port. Sort of. You see, it depends on which API function you ask.
EnumPorts() does indeed list the port (USB001). Promising start.
However, CreateFile() fails with a port does not exist code.
A quick play with the printers app in control panel shows that windows
itself has no trouble writing to this port via its spooler so off I go
onto a very frustrating search on google in which I encounter many
people who are having the same problem but no solution.
Fearing a hidden api situation I do a little more digging and find that
I might be able to get at the port via its print monitor. No problem, it
uses the USB Printing Monitor DLL although to implement it properly and
generically so as to take account of any possible new tech in the future
I get it into my head to use the EnumMonitors() function to dig through
in a proper fashion. Guess what. The USB Printing Monitor doesn't exist
according to windows' EnumMonitors() function. Well that's a bit strange
seeing as Windows itself can find it for its spooler service!
I'm now forced to hit USBMON.DLL myself direct if the port name starts
with "USB", however if a port ever comes along that doesn't follow this
convention I'm back to square one.
What a POS from a complete bunch of half arsed fuckwits. They don't mind
supporting things properly themselves but screw anyone else. They're too
busy abandoning the APIs that have worked perfectly well for over a
decade to implement new stuff in a totally weird (and sometimes
undocumented) fashion.
And they wonder why their users are getting disenfranchised. Too much
shine too little substance just lately methinks.
Cue the shills.
I've got an app I've been maintaining for 14 years now that writes raw
data down the serial ports to specialist printers. No big deal, hardly
rocket science. Quick call to CreateFile() with the port name, job done.
At least, that was the case.
Now, as parallel ports are disappearing from laptops and the like we're
starting to see the rise of USB-parallel leads.
No problem I thought, the driver for the cable must include a port that
can be used as normal.
Boy was I in for a shock. You see, the driver does indeed install a
port. Sort of. You see, it depends on which API function you ask.
EnumPorts() does indeed list the port (USB001). Promising start.
However, CreateFile() fails with a port does not exist code.
A quick play with the printers app in control panel shows that windows
itself has no trouble writing to this port via its spooler so off I go
onto a very frustrating search on google in which I encounter many
people who are having the same problem but no solution.
Fearing a hidden api situation I do a little more digging and find that
I might be able to get at the port via its print monitor. No problem, it
uses the USB Printing Monitor DLL although to implement it properly and
generically so as to take account of any possible new tech in the future
I get it into my head to use the EnumMonitors() function to dig through
in a proper fashion. Guess what. The USB Printing Monitor doesn't exist
according to windows' EnumMonitors() function. Well that's a bit strange
seeing as Windows itself can find it for its spooler service!
I'm now forced to hit USBMON.DLL myself direct if the port name starts
with "USB", however if a port ever comes along that doesn't follow this
convention I'm back to square one.
What a POS from a complete bunch of half arsed fuckwits. They don't mind
supporting things properly themselves but screw anyone else. They're too
busy abandoning the APIs that have worked perfectly well for over a
decade to implement new stuff in a totally weird (and sometimes
undocumented) fashion.
And they wonder why their users are getting disenfranchised. Too much
shine too little substance just lately methinks.
Cue the shills.