0

I am writing an application for POS systems and need a bit of understanding of them. I know that all POS systems have some OS platform on which they work either a normal OS like windows XP/7 or a small footprint one like Windows CE or so. As much as I know, there can be different peripheral hardware units like printer or cash drawer and they can be of different kinds (different manufacturers and models). So I considered that usually these peripherals say printer have its driver installed on windows which is being used by the POS software to trigger printing.

But as I have searched and have seen several POS systems (deployed and not from close), i may very well see there are POS systems which are fully integrated and the print is triggered by payment say, through a swipe of card on card swipe machine. The hardware seems to be of same company (for peripherals and POS) and so I doubt the mechanism does not involves the installation of drivers on OS platform. Rather in such cases, the POS software itself contains the drivers of peripherals and trigger them. There is no call to default printer on the OS but a direct call to the thermal printer attached. This may be happening using some ADK/SDK to control peripheral or APIs exposed by peripheral manufacturer or simply drivers wrapped up in POS software itself.

My question is, is my understanding here correct or does everything goes via OS drivers only? If I am thinking write, then can somebody tell what kind of mechanism such POS systems use (i mean sdk or API or driver wrapped in POS software or what)?

Nirvana
  • 65
  • 10
  • 1
    Please be more concise about your main problem question. – gavioto Apr 07 '17 at 15:01
  • well, one way to put my query is that I want to know are there such POS softwares which can print receipts using thermal printer without printer's driver installed on the OS platform on which POS software is running? – Nirvana Apr 10 '17 at 13:26
  • There is no magic here, you are over-complicating this. Your computer has the same issues, display, mouse, keyboard, internet, printer. And you solve those problems. Sometimes the printer is wired in and you have an os specific driver which you talk through often using generic operating system printing calls, but sometimes printer specific. Sometimes it is ethernet or serial or other and you use the generic drivers for those interfaces (network card) and at the application level generate the tcp/ip stream. – old_timer Apr 19 '17 at 20:00
  • You can buy/use rfid and nfc and credit card and chip readers plug them in usb or whatever interface they offer and write software for them, POS has little to do with it other than the POS printers are often, but not always using different printers than say an office computer. – old_timer Apr 19 '17 at 20:02
  • The printer, and card reader, these are not your problem, simple matter of programming, the security is your problem. POS machines made by folks doing it forever are getting compromised left and right, so that is what you need to bring to the table if you want to compete. – old_timer Apr 19 '17 at 20:04

1 Answers1

0

Yes, such POS systems exists. E.g. our own POS software talks directly to peripherals using the native protocols of the respective devices. Of course you must then understand the protocols and, in the case of printers, their emulations, e.g. ESC/POS, ESC/Label, Fingerprint etc.

Marc Balmer
  • 1,780
  • 1
  • 11
  • 18
  • so how does that work, does the POS creates a data suitable for emulation of printer and send it to the printer directly through configured port? can you elaborate more as to how does it works? you can explain in terms of thermal printers – Nirvana Apr 12 '17 at 09:10
  • Yes. Assume you have a thermal printer that has an ethernet interface and listens on tcp port 9100 for incoming connection. Then your software opens a tcp socket and connects to port 9100 of that device and then sends data to the printer, and when done, closes the socket. – Marc Balmer Apr 12 '17 at 09:15
  • Thanks, I got that. What about printers connected locally through USB? And how does the POS recognize what kind of data is to be sent as printer can be of any company any model? Does the POS uses any library or SDK provided by printer manufacturer or is there any market standard for POS systems to interact with any thermal printer connected through USB or network? – Nirvana Apr 12 '17 at 14:20
  • Of course you have to know what peripherals are connected (e.g. by using a config file) and then send the right commands. USB is no different, it is just a different transport channel. Talking to USB devices is OS dependent (we use Linux/Unix). – Marc Balmer Apr 13 '17 at 07:11
  • What do you mean by OS dependent? Also, what is the most common/standard way to connect to printers, via a network/Ethernet or via USB? or there isn't any standard way at all? – Nirvana Apr 13 '17 at 10:48
  • With OS dependent I mean that each OS has it's own way of talking to peripherals. In Windows it's done differently than on Linux, e.g. And no, there is no standard way, you can use the network (ethernet), USB, serial ports and so on. – Marc Balmer Apr 14 '17 at 08:12
  • ok, so if i understood right, to communicate through USB, the POS has to go through the OS and cannot completely bypass it, right? Also, how does POS identifies if printer is connected or not and whether its the right printer (and not any other USB device connected)? In case OS responsible, OS queries identity strings from a USB device which it then matches to get right driver installed. But what happens when POS is talking directly to printer and driver is not installed on OS, how POS approaches the same issue (of identification and availability of printer)? – Nirvana Apr 14 '17 at 11:15