I actually have some of this hardware that I can use to test things on
(a pole display on serial and a keyboard/barcode scanner wedge).
However, I'm not really a UI programmer, but I can get the basic OS base
down for you fairly quickly should you want me to.
--MonMotha
R. Scott Belford wrote:
On Thursday, May 23, 2002, at 06:19 PM, Warren Togami wrote:
On Thu, 2002-05-23 at 17:20, MonMotha wrote:
Yes, but SCO != Linux :)
Because SCO was/is a x86 Unix, most SCO binaries run with little or no
modification on Linux when you have the right libraries and Unix
compatibility kernel modules installed. Scott can post more about this.
Yeh, from what I have learned about this program called Counterpoint
that runs on Linux is that it does so through a "hack" of sorts. If you
are using Redhat's 6.2, then you must insmod iBCS in your rc.local file
to be sure that the program runs. In Red Hat's 7.2 distro, you must
insmod abi -machdep
insmod abi -svr4
insmod abi -cxenix
insmod abi -sco
insmod abi -ibcs
insmod abi uw7
insmod binfmt_coff
insmod binfmt_xout
I really don't know what it is doing, but it allows one to execute the
POS application once they ssh in from a remote client. I think some
dealers use Slackware, and I suppose it would run on Caldera's flavor of
SCO. I never got it to work with debian or mandrake.
Our registers access this application through a private network. A
"register" is simply a pc in this case. They connect to the remote POS
application, Counterpoint, with a windows based telnet client. We use
Vandyke's, www.vandyke.com , CRT program. Each register has a keyboard
and scanner for input. In to the keyboard port plug the keyboard and
scanner. They share this port with a wedge or y-adaptor. Keyboards
have a credit card reader which is hardware programmed. The scanner is
also hardware programmed. The telnet program doesn't care where the
data comes from it just takes it from the port. The POS application
doesn't care what OS is used to access it and trade data.
Also attached to the pc are a monitor and parallel receipt printer. The
pole display, that thing on a pole that displays the price, works in
pass-through mode on the parallel port. It can also be plugged in to a
serial port.
So, there you are at the counter and you want to buy some gum. The
cashier positions the cursor in the customer screen, asks your zip code,
and then uses the keyboard to enter a stream of data matching your 5
numbers. The cursor is now positioned in the item entry screen. The
gum is passed over the scanner where its barcode is read. This stream
of numbers travels through the network, is compared to an inventory
file, and a stream of data returns displaying big read for .25 on the
cashiers screen. At the same time, the price of gum has appeared on the
pole display. She scrolls down to the payment entry area, selects
credit card, and swipes your card. That stream of data is read from
your magnetic strip and is passed through the network to the POS
application. Counterpoint engages one of the server's many modems and
dials our processor for approval. The approval is displayed on the
cashiers screen a few seconds later, and the magic begins.
On the server end, peripheral devices can be defined. That pole display
showing the gum, let's say it was a serial port pole. On the server
end, a remote printer is defined where the pole is located. In our
case, because our register pc's run windows, that pole display is known
to windows as a generic text serial printer. It is shared. We setup
this remote windows printer on the server, usually name the queue with
that register's number, and when the application gets your gum data
stream, it knows to print the price data to the user defined printer.
In this case it is a remotely shared windows printer. It can easily be
any printer.
This, so far, may not be too hard to replicate on a thin-client linux
register. Something else happens, though. CRT, the windows telnet
program, is set up to pass through printing to lpt1. When the cashier
got your approval for the gum, she finished the transaction by printing
a receipt. When she printed that receipt, the printer was not defined
the same way as the pole. The printer in this case is a device defined
in Counterpoint called local. Local is a file in the top level of the
Counterpoint, with 777 permissions but root ownership and root group.
In the file are the following magical lines
echo -ne "\\033\133\065\151"
cat $*
echo -ne "\\033\133\064\151"
So, this setup tells the telnet application to print to the local
printer port, it appears. That's how your receipt comes out. Receipt
printers, as opposed to some poles, are not defined print queues. Some
poles are also not defined queues. I mentioned earlier that some poles
are pass through. They plug in to the parallel port with the receipt
printer. They too are defined as "local" In Counterpoint certain codes
are defined for this type of pole display that insert themselves in the
lpt stream and send the right data to the pole and the rest to the
printer. It is this pass through and local file configuration that I am
not certain about, yet, with a pure linux register. I know it is
doable, but I have not tried, period.
If you made it this far, let me share a vision. Next time you are
shopping, realize how many small business are out there struggling to
get by. Many lack any computer integration save for a cash register.
Many use windows pos applications. They, these small businesses, are
generally said to comprise 90% of all businesses. These people need a
linux POS application, and they need YOU to help them do it. I am going
to do all I can to make Pricebusters completely open sourced as I
possibly can, starting with the registers. I will have obstacles, and
there will be problems. When I am done they will serve as a gleaming
example of the benefits of open source. We are a locally owned company
facing formidable mainland competition, so any competitive edge we can
get, we go for. I think that linux is it for us. If you can help in
any way, this project is for you. It is for you because when it is done
you will always have a linux reference. When you are selling that small
hardware company on your service and the reliability of this linux POS
application you have found and are representing, you will have them call
me to attest for the quality and reliability of your endeavor.
scott
_______________________________________________
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
