POS development on windows: OPOS via COM? OPOS for .Net? UnifiedPOS? ...?

Question

I plan to develop a POS system from scratch, which will be based on windows (currently XP SP3). I tried to get an overview of which API to use to work with POS devices. So far I found OPOS which is implemented as a set of COM objects, a .Net library which seems to be based on the COM objects and an upcomming standard called UnifiedPOS.

The problem is, that the COM objects seem to be quite old and the .Net stuff has not been updated since .Net 1.1. But I was not able to find an implementation of the UnifiedPOS specification.

Does somebody know something like a UnifiedPOS SDK for windows? Or could somebody recommend the usage of OPOS or any other API?

Pituri

I think this depends on what POS device are you going to use and what API does that support. – Ehrman

The software will be running on win XP with SP3 and I want to talk to POS printers and such kind of devices. My understanding of such a "standard" and API is, that I'm more or less independent from special devices!? – Pituri

Moore's law does not apply to POS. Avoid assuming that "old" equates to "outdated". The .NET OPOS wrappers support UPOS since 2003. – Poised

monroecs.com/posfordotnet/opos_dotnet.htm appears to be built against .NET 2.0 – Ophthalmologist

@Hans: I was not aware of that. Would you create an answer which I could accept? – Pituri

OPOS is the Windows (ActiveX) implementation of UnifiedPOS. UnifiedPOS is only abstract - the real libraries are OPOS/JPOS/POSfor.Net. You can use them for barcode scanners and cash drawers - sometimes for POS printers. However, it is good idea (even recommended) to support native protocols/libraries because many devices do not provide UPOS support. – Tiliaceous

Answer 1

OPOS really started all the POS APIs with a standard agreed on by a board of member companies to help make POS specific computer hardware more interchangeable. OPOS Info This was if you purchased a POS software you wouldn't necessarily experience vendor lock due to the way the software was coded.

JavaPOS specification simply turned the outdated OLE based API into Java which may be some people's preferred development environment. JavaPOS Info

Of course not everyone loves Java, Enter POS.net, another child of OPOS but built on .NET framework by Microsoft.POS.net Info POS.net is backwards compatible with OPOS drivers. So any device that works with OPOS also works with POS.net. (Many hardware vendors even claim POS.net compatibility when they only supply OPOS drivers.)

The point of ALL of these libraries is to standardize access to hardware devices from different vendors. Your choice of library will be mostly dependent on your choice of development environment. It is worth noting that the influence of some major hardware vendors in the standards organizations that formed these libraries makes them not really 100% vendor agnostic. For that reason many POS developers build their own hardware abstraction layer, that can then in turn call on POS.net or talk directly via RS232 or TCP/IP to their POS hardware.

Also the POS industry in general lags behind in technology and is driven by low cost and the general lack of a need for the latest powerful hardware. The POS.net SDK doesn't need any of the features of a .NET 3.5/4.0 and hence won't be recompiled against it. Instead POS vendors often want to run their software on low powered commodity hardware. These systems often run Windows XP or Windows XP Embedded (XP without the consumer stuff) for its lower memory footprint both on storage and in RAM and general speediness compared to Vista (Win7 may change that, but as I mentioned the POS industry has a lag in software adoption compared to other industries).

Monoploid