I received the following email and I have no ideas about this. Do you?
==================================================================================================
First I want to say I like your website. It's easy to read and all the information is right there laid out very nicely. So many sites these days are just so full of things and links and you can't find anything you're looking for so its very refreshing to see a nice clean easy to navigate site.
I had a question and maybe you have had this question before. I wasn't able to find the answer in documentation but with your skills in programming I thought you may know the answer to this.
I just aquired several WYSE text terminals from a papa johns pizza store that upgraded. No server came with these, but all the connections cables and such are included. I was wonder if you know of a way, or perhaps any of your users have found a way to run your program using terminals? Right now I am only testing it for use in a thrift store (mountain mission) because we only have a donated cash register that isn't much more than an adding machine. I would love to be able to have two or more registers and these terminals would be perfect as they have cash drawers and receipt printers that attach right to the terminal. But what I wasn't sure of is if the software can be setup in a way to run on terminals. I saw the networking section but this is a little different than eithernet. I know their server used linux and your software is dos, however I have successfully been able to control a DOS computer with one of these terminals using the CTTY COM1 command but when I type the command to run the pos software, it just displays the software on the monitor physically connected to the computer instead of the terminal.
Thanks for your time and thanks for your program!
Johnnie Christian
DHPOS on WYSE text terminals
Moderators:daleadmin, Dale Harris, Alan, Andrew
Re: DHPOS on WYSE text terminals
I've actually been playing with using DHPOS in a terminal configuration for several months and have been planning on posting this before, but never found the right thread. Do bare with me on this post, I will get on to text terminals as well!
ATM I'm using the Kpym server in combination with the PuTTY client (first as a Telnet configuration, more recently I've switched to SSH as it's much more secure). I've then set up a multi-station system where depending on what you log in as you end up on one of 4 till screens, the kitchen display, or the back office 'server POS'. This has 4 advantages as I see it:
Firstly, because the complete system all runs on a single physical machine, it is irrelevant to DHPOS what computer you are actually using to work on. This means that a failed machine can be swapped out for another one (you only need to make sure the printer is networked back to your server so that Aprint can print to it from there - Aprint is quite happy to print to a network printer, and it's quite happy for multiple instances of itself to be open at once, sending the print stream from difference instances of DHPOS to different printers), or a supervisor/manager can pull up the global register from anywhere to check what the entire store has done (or log onto a normal register from the office to perform supervisor tasks without having to go out onto the shop floor).
Secondly, remote access is now a possibility. If you're managing the shop, you can log in from outside and check figures or run reports just as if you were there. One of the coolest things I did (I think so anyway) was to download the Symbian port of PuTTY onto my N97. Now, I can get access DHPOS from that. True remote access to the real live system from a phone. Even most commercial EPOS systems can't do that, the best you can usually hope for is to get to a website with some basic statistics on it.
Thirdly, going hand in hand with remote access is the possibility of multi site use. DHPOS obviously isn't really designed for this, but nevertheless if your needs are relatively modest (say you have 2 or 3 shops which only use 1 register each) and are creative with how you set up your stock table you can have all your shops running on the same system, letting you check stock at each location.
Finally, getting DHPOS out of the native NTVDM environment is a big plus to me. The NTVDM emulator which gives NT-based versions of Windows it's DOS support (even Windows Vista) hasn't changed since Windows NT 3.1 from 1992 - even down to only being an emulation of DOS 5 despite the fact that mainstream DOS got up to Version 6.22 (you can even still get it to say 'MS-DOS Version 5.00' if you known what to type) and it is a HORRIBLE way to run applications on a modern system. Either a program runs full screen which takes away all the little things you take for granted in a modern Windows system (the taskbar, the clock, being able to easily start another program etc) or you run in a very restrictive window. By default it's small, 'maximising' it merely sends it to the top of the screen rather than making it bigger. Resizing the window doesn't resize what's in it, it just adds or takes away scroll bars. The only way to make it bigger is to play around in the settings menu, and do the same if you want to make it smaller. Accessing it through PuTTY straight away makes it so much easier to 'live' with a DOS program alongside everything else - you can maximise the window and it gives you a big display without completely taking over the screen. You can run it in a smaller window and stretch it to whatever weird and wonderful proportions you like and the program display changes with it.
Now, the issue of text terminals. I did get hold of an old Axel Platine terminal from work. Switching Kpym back to Telnet mode, I got it to connect fine but had issues with the terminal sending a line feed at the end of each line of the display - the result was the screen scrolling by leaving you seeing only the bottom half of the screen, spread over the entire screen with a black line in between each displayed line. Eventually I got it to work properly in VT50 mode (a VERY old standard) but then only in black and white (but then, if your money doesn't care about being processed through a DOS program I doubt it cares about being processed in colour either lol). I think this though was a limitation of the Telnet server and the particular terminal I had. However, screen update over the terminal was quite slow with full screen refreshes taking a good couple of seconds to happen - this was a limitation of the video hardware in the terminal rather than a bottleneck anywhere on the system so there is nothing that could be done about this (indeed this is why my work changed from dumb terminals to PCs - the PCs just run a client program to access the same EPOS system that we've always had only now it's much quicker to use because you don't have the screen lag). Old WYSE jobbies like those you've mentioned are likely to have the same problem.
With regards to connecting the printer and cash drawer directly to the terminal - Kpym won't support this. There are though much better Telnet servers for Windows available (sadly though they tend to cost money). These feature IP printing - you install a special printer driver on the host system which adds a virtual printer into your printers folder. Then when something prints to this printer it sends the print data to an IP address on your network. Although the printer isn't real, because it appears in the printers folder it will still be real to Aprint. In theory, there should be no reason why a printer plugged in to the parallel port of the terminal wouldn't print in this configuration. If you have a cash drawer plugged in to your receipt printer, then (again in theory at least!) there is no reason why the cash drawer shouldn't open.
Although I have little interest in using traditional text terminals with DHPOS (not unless I can find some with fast screen update anyway - and some of the WIndows CE based thin client machines look interesting), I am still actively looking at getting IP printing working - being able to print to a printer not connected physically to the server without using Windows networking means that if you dial in from home you'd be able to print reports locally, and of course being able to print outside of 'official' network printers is essential if you're trying to get a multi site configuration up.
One HUGE problem I'm having with this whole experiment is with the timeclock. Apart from a few exceptions (like Control-C or shifting letters or numbers) Telnet and SSH don't support more than one key being pressed at a time. This means makes it impossible to clock in or out because Control + Insert isn't recognised. I've not yet found a server without this limitation.
If there is widened interest in running DHPOS in a client/server environment is there any chance at all that clocking in/out be modified to require only a single key (maybe with an 'Are You Sure' prompt in case you've done it by mistake, which I guess is why you ended up with the double keystroke in the first place)?.
ATM I'm using the Kpym server in combination with the PuTTY client (first as a Telnet configuration, more recently I've switched to SSH as it's much more secure). I've then set up a multi-station system where depending on what you log in as you end up on one of 4 till screens, the kitchen display, or the back office 'server POS'. This has 4 advantages as I see it:
Firstly, because the complete system all runs on a single physical machine, it is irrelevant to DHPOS what computer you are actually using to work on. This means that a failed machine can be swapped out for another one (you only need to make sure the printer is networked back to your server so that Aprint can print to it from there - Aprint is quite happy to print to a network printer, and it's quite happy for multiple instances of itself to be open at once, sending the print stream from difference instances of DHPOS to different printers), or a supervisor/manager can pull up the global register from anywhere to check what the entire store has done (or log onto a normal register from the office to perform supervisor tasks without having to go out onto the shop floor).
Secondly, remote access is now a possibility. If you're managing the shop, you can log in from outside and check figures or run reports just as if you were there. One of the coolest things I did (I think so anyway) was to download the Symbian port of PuTTY onto my N97. Now, I can get access DHPOS from that. True remote access to the real live system from a phone. Even most commercial EPOS systems can't do that, the best you can usually hope for is to get to a website with some basic statistics on it.
Thirdly, going hand in hand with remote access is the possibility of multi site use. DHPOS obviously isn't really designed for this, but nevertheless if your needs are relatively modest (say you have 2 or 3 shops which only use 1 register each) and are creative with how you set up your stock table you can have all your shops running on the same system, letting you check stock at each location.
Finally, getting DHPOS out of the native NTVDM environment is a big plus to me. The NTVDM emulator which gives NT-based versions of Windows it's DOS support (even Windows Vista) hasn't changed since Windows NT 3.1 from 1992 - even down to only being an emulation of DOS 5 despite the fact that mainstream DOS got up to Version 6.22 (you can even still get it to say 'MS-DOS Version 5.00' if you known what to type) and it is a HORRIBLE way to run applications on a modern system. Either a program runs full screen which takes away all the little things you take for granted in a modern Windows system (the taskbar, the clock, being able to easily start another program etc) or you run in a very restrictive window. By default it's small, 'maximising' it merely sends it to the top of the screen rather than making it bigger. Resizing the window doesn't resize what's in it, it just adds or takes away scroll bars. The only way to make it bigger is to play around in the settings menu, and do the same if you want to make it smaller. Accessing it through PuTTY straight away makes it so much easier to 'live' with a DOS program alongside everything else - you can maximise the window and it gives you a big display without completely taking over the screen. You can run it in a smaller window and stretch it to whatever weird and wonderful proportions you like and the program display changes with it.
Now, the issue of text terminals. I did get hold of an old Axel Platine terminal from work. Switching Kpym back to Telnet mode, I got it to connect fine but had issues with the terminal sending a line feed at the end of each line of the display - the result was the screen scrolling by leaving you seeing only the bottom half of the screen, spread over the entire screen with a black line in between each displayed line. Eventually I got it to work properly in VT50 mode (a VERY old standard) but then only in black and white (but then, if your money doesn't care about being processed through a DOS program I doubt it cares about being processed in colour either lol). I think this though was a limitation of the Telnet server and the particular terminal I had. However, screen update over the terminal was quite slow with full screen refreshes taking a good couple of seconds to happen - this was a limitation of the video hardware in the terminal rather than a bottleneck anywhere on the system so there is nothing that could be done about this (indeed this is why my work changed from dumb terminals to PCs - the PCs just run a client program to access the same EPOS system that we've always had only now it's much quicker to use because you don't have the screen lag). Old WYSE jobbies like those you've mentioned are likely to have the same problem.
With regards to connecting the printer and cash drawer directly to the terminal - Kpym won't support this. There are though much better Telnet servers for Windows available (sadly though they tend to cost money). These feature IP printing - you install a special printer driver on the host system which adds a virtual printer into your printers folder. Then when something prints to this printer it sends the print data to an IP address on your network. Although the printer isn't real, because it appears in the printers folder it will still be real to Aprint. In theory, there should be no reason why a printer plugged in to the parallel port of the terminal wouldn't print in this configuration. If you have a cash drawer plugged in to your receipt printer, then (again in theory at least!) there is no reason why the cash drawer shouldn't open.
Although I have little interest in using traditional text terminals with DHPOS (not unless I can find some with fast screen update anyway - and some of the WIndows CE based thin client machines look interesting), I am still actively looking at getting IP printing working - being able to print to a printer not connected physically to the server without using Windows networking means that if you dial in from home you'd be able to print reports locally, and of course being able to print outside of 'official' network printers is essential if you're trying to get a multi site configuration up.
One HUGE problem I'm having with this whole experiment is with the timeclock. Apart from a few exceptions (like Control-C or shifting letters or numbers) Telnet and SSH don't support more than one key being pressed at a time. This means makes it impossible to clock in or out because Control + Insert isn't recognised. I've not yet found a server without this limitation.
If there is widened interest in running DHPOS in a client/server environment is there any chance at all that clocking in/out be modified to require only a single key (maybe with an 'Are You Sure' prompt in case you've done it by mistake, which I guess is why you ended up with the double keystroke in the first place)?.
Who is online
Users browsing this forum: No registered users and 125 guests