Accessing USB Receipt Printers RRS feed

  • Question

  • I'm trying to print directly to a USB Receipt Printer from a WinRT app on Surface 2 (Windows 8.1 ARM.)

    I've tried the old RawPrinterHelper trick to send bytes via the "winspool.drv" but I guess that route is blocked now as print jobs generate Error 372 on Surface. Looking at how much Surface is locked down I didn't see much point in investigating USBPrint.sys.

    I've looked into Windows.Devices.Usb but the documentation explicitly states this is not to be used for certain classes of device of which printers are one.

    There is some support for POS solutions in WinRT apps as there's code in there for Bar Code Scanners and Magstripe readers but nothing for line printers.

    How exactly is one supposed to print bills and receipts with no access to a printer? And no, the page based system for document printing doesn't count :) Am I reduced to wasting my clients' money on unnecessary Ethernet receipt printers?!

    Best Regards,


    Saturday, November 30, 2013 5:39 PM

All replies

  • Hi,

    There is no part of API for receipt printers currently.

    However, if the receipt printer is directly attached to the device, you can control it by accessing it directly and treating it as a line printer. You may be able to send raw data to such a printer from a Windows Store app using the modern USB API. Please see the Custom USB device access sample: 


    Best Wishes!

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey. Thanks<br/> MSDN Community Support<br/> <br/> Please remember to &quot;Mark as Answer&quot; the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Monday, December 2, 2013 7:21 AM
  • Thanks for the reply but I looked at:


    Which says:

    Do not use the namespace for these USB device classes:

    Note  Instead, use other relevant APIs. These USB device classes are blocked by the namespace to prevent conflict with other APIs. For example, if your device conforms to HID protocol, use Windows.Devices.HumanInterfaceDevice.

    • Audio class (0x01)
    • HID class(0x03)
    • Image class (0x06)
    • Printer class (0x07)
    • Mass storage class (0x08)
    • Smart card class (0x0B)
    • Audio/video class (0x10)
    • Wireless controller (such as, wireless USB host/hub) (0xE0)

    And unfortunately my printers do actually declare themselves as printers :)

    As you stated, there is no API available for receipt printers so we're in Catch-22 land :(

    Two major problems I see:

    1) I respect ambition: if someone at Microsoft were to think "let's own every market!" for a change you'd have the whole Point of Sale market sewn up! Seriously though, Point of Sale has seen the value of touch screen interfaces for decades. Now everyone else has caught up, clients are expecting tablets to also be Point of Sales systems. They are getting very bored of the minor technical and marketing reasons why this can't happen.

    2) How does one do the age old task of firmware updates? Forget receipt printing or line printers for the moment. How does HP, Dell, Lexmark, et al perform a firmware update of one of their models on Windows 8.1? I can't see how it's possible.

    Of course, if there's some way to achieve this by writing a custom printer driver or any other cunning but legal method of bypassing the security restrictions I'd love to know!

    Best Regards,


    Friday, December 6, 2013 5:39 PM
  • Hmm... sorry to be mean, Pavel, but this is what I'm talking about when I say "lack of ambition" I know that's really really rude, my apologies, but bear with me:

    The Surface RT tablets have a nice touch screen, form factor, kick out stand, the list goes on. As a "first attempt" at a tablet I think Microsoft did an amazing job. Compare to the rubbish being churned out for Android. You have to pay iPad prices to get something nice and then still be afflicted with Android :(

    Let's look at the operating system (forget ARM and x86 for the moment) the WinRT model is light years ahead of iOS and Android especially in the Windows 8.1 flavour.

    And development? Two words: Visual Studio.

    Anyone looking to develop a Point of Sale application right now, without bias of numbers, and just looking at quality is going to pick WinRT based devices every time. It's like the operating system was made for the job!

    So back to Surface RT. The device is ideally suited for Point of Sale saying "there are other, non-RT devices available" is like someone at Microsoft saying "we don't want that market, let's be charitable and give the money to Asus and Dell, they need it more than us!"

    Obviously a inflammatory exaggeration but what really ticks me off, what really gets my goat is that only Microsoft were decent enough to put a full sized USB port on their devices and separate charging. Almost every other tablet on the market, whether Windows RT or Windows 8, has those god-awful Micro-USB sockets.

    Oh yeah, you can use On-The-Go or you can charge... choose wisely!

    /RANT:OFF ;)

    Saturday, December 7, 2013 12:52 AM
  • Yes, Surface RT was not designed for Point of Sale but as with most great designs it has potential for other applications.

    Don't get distracted by the form factor though. When you talk about non-RT versions you're really talking about legacy Win32 applications. The processor, manufacturer and model are actually irrelevant. What I'm saying is I can't write a full Point of Sale application solely for WinRT: I have to use Win32 "hacks" to get around problems.

    Maybe the guys didn't have time to add line printers to the Point of Sale device namespace? Fine, then someone needs to tweak the Windows.Devices.Usb namespace to allow access to the Printer Class.

    The alternative is to acknowledge continued use of Win32 to plug programming holes. Technically I have no problem doing that but, and I'm not sure this is quite the right word, morally I'd prefer to just use WinRT.

    Back to Surface RT. I admire the bravado of restricting access to Win32 on Surface RT while at the same time tacitly admitting Office can't run without it. However, without a complete tool set for WinRT - the reason for Win32's continued existence - I can't see why non-Microsoft developers shouldn't also use it.

    The jailbreak for Surface RT shows that people still have a fondness for Win32 and, what's more, are using it for free! Surely the sensible thing would be to charge for a third developers licence to the existing personal and business ones. For example, "Extreme Developer: allows access to Win32 subsystem." I'd even go further and lock out apps using Win32 from the Store even for non-ARM Windows.

    You say "use non-RT tablets" but this really means "use less-secure tablets." People aren't so much avoiding Surface RT and Surface 2 devices because of the ARM processor. They're avoiding the security model, not good :( More needs to be done to encourage people to embrace security not run away from it because it's inconvenient.



    Sunday, December 8, 2013 1:15 PM
  • Hi POSitality,

    You wrote nothing rude or inflammatory, but I just respectfully disagree. Surface RT was designed with anything but POS in mind, its peripheral options are deliberately cut down in favor of security and managed power consumption.  It is well known that many unaware users returned truckloads of Surfaces and other RT tablets, so it may be very tempting to re-purpose them...  Good luck if you can.

    In 8.1 support for custom USB devices is greatly improved, bus, as you've found, this does not extend too far (or sideways).

    On a full (non-RT) version of Win8 3rd party developers can tweak the USB drivers so that your printer would appear to the OS as something else, that Metro apps could use.

    -- pa

    and let the IOS and Droid developers make POS apps for the iPad and droid tablets?   they are doing it.

    they were not designed for that use but apple and google are not locking them out of doing it.

    Wednesday, March 25, 2015 12:18 PM
  • and let the IOS and Droid developers make POS apps for the iPad and droid tablets?   they are doing it.

    they were not designed for that use but apple and google are not locking them out of doing it.

    Ok, POS apps exist for iPads -  but have you tried to connect a custom device to it  not thru Bluetooth or wi-fi? Even a simple flash drive? Good luck. (but this by the way makes iPads more secure and robust). 

    Wednesday, March 25, 2015 1:06 PM
  • And the method that those developers are using to do it are available to Windows developers as well (e.g. Ethernet Connected Printers). It's pretty much a necessity to do it that way on those devices as they also either don't offer USB connectivity at all or also make you decide wether to charge the device or to use the USB connector for something else (single port).

    Looking at Apple that's now even extending to their Laptop formfactor as the new MacBook only has a single port for everything (Display, Charger, USB-Sticks, etc.)

    Wednesday, March 25, 2015 1:53 PM