Page 1 of 1

The limitations of DOS? Or POS?

Posted: Wed Jan 28, 2004 2:33 am
by Tats
I am in the retail industry too and have been exposed to DOS and WIN POS systems. I still can't understand it when you guys say that you have approached the limits of what DOS can do for DHPOS. Are you referring to the QBasic or DOS? I've evaluated POS applications programmed in DOS by CanadaPOS & Retail Plus v5.1 (DOS version) by True North Computers. Except for the fact that their apps are not freeware, they do offer a lot of features that can be used in a variety of industries! Frankly, their apps are loaded.

:?:

Tats

Posted: Wed Jan 28, 2004 4:36 am
by eli
Hi Tats!

I'm familiar with those applications so I know what you mean. 8)

Posted: Wed Jan 28, 2004 5:20 am
by Guest
I have several DOS applications where hard disk space is the only limitation. :lol:

Posted: Wed Jan 28, 2004 7:38 am
by peewee3ie
if some you have old computer running dos memory managers for dos is not loaded by default and on some old computer you may neet to have 6MB of ram before you can run memory managers. if you have a computer running windows and are using a dos box you do not have memory problems because windows loads a memory manager and there are some limits in Qbasic but the main problem is that some computer cannot run memory managers.

Limits

Posted: Wed Jan 28, 2004 8:43 am
by Dale Harris
While it is true that there are things that can be done so that DOS software can use all the available memory on a hard drive is does so by switching things in and out of memory. This takes time.

While I do use these methods when switching to different functions the thing I do not want to do is to switch out modules while ringing a sale. Therefore all the code that I need to ring up a sale is in the POS.EXE program.

The other limitation, forced by QB, is the size of arrays. Since I want to sort things in memory and not on the disk, again for speed, I limit the stock table to eventually 13,000 items because, 1 that is almost the max I can sort in memory and 2. that would be the largest stock table that would fit on a floppy without compressing the file.

I am sure that there are ways around both of these constraints however I am just one guy, who taught himself to write software, sitting at his desk at home, doing the best that he can, who gives his stuff away. I guess that I am not too smart, particularly on that last thing.

Last night on chat we estimated that there have been 50,000 downloads of this software in the last 2+ years from my site alone. It is also available for download from other sites and is on several compilation CDs. From my email I have learned that it is used all over the world. It must not be totally crap, someone must like it. Maybe two people even?

I am sure that there are better POS programs out there, you could buy them instead of using mine. Or you could hire professional programmers to write a better one for you. Or you could use your superior programming abilities to write one of your own.

There, 3 solutions to the problem. I feel better now. :)

Posted: Wed Jan 28, 2004 8:59 am
by eli
I'd feel good, too, if I could write an app half as good as your POS! :lol:

Posted: Wed Jan 28, 2004 9:14 am
by Guest
While I do use these methods when switching to different functions the thing I do not want to do is to switch out modules while ringing a sale. Therefore all the code that I need to ring up a sale is in the POS.EXE program.

If a menu of features/options is given to the user before system configuration of the POS is installed, then switching of modules during actual operation is avoided.

Maybe this could go around the limitations of QBasic...

Splitting-Up POS.EXE

Posted: Wed Jan 28, 2004 3:38 pm
by ChrisKraus
Well, It's just an idea but if you really needed to, You could split POS.EXE or another file into two files so that way eact file gets 640K of memory. The only thing is that this would take a <B>Major</b> re-write of that file and you would also have to ba able to get the two files to work together.

- Chris :)

<HR>
Dale Harris wrote:While it is true that there are things that can be done so that DOS software can use all the available memory on a hard drive is does so by switching things in and out of memory. This takes time.

While I do use these methods when switching to different functions the thing I do not want to do is to switch out modules while ringing a sale. Therefore all the code that I need to ring up a sale is in the POS.EXE program.

The other limitation, forced by QB, is the size of arrays. Since I want to sort things in memory and not on the disk, again for speed, I limit the stock table to eventually 13,000 items because, 1 that is almost the max I can sort in memory and 2. that would be the largest stock table that would fit on a floppy without compressing the file.

I am sure that there are ways around both of these constraints however I am just one guy, who taught himself to write software, sitting at his desk at home, doing the best that he can, who gives his stuff away. I guess that I am not too smart, particularly on that last thing.

Last night on chat we estimated that there have been 50,000 downloads of this software in the last 2+ years from my site alone. It is also available for download from other sites and is on several compilation CDs. From my email I have learned that it is used all over the world. It must not be totally crap, someone must like it. Maybe two people even?

I am sure that there are better POS programs out there, you could buy them instead of using mine. Or you could hire professional programmers to write a better one for you. Or you could use your superior programming abilities to write one of your own.

There, 3 solutions to the problem. I feel better now. :)