Future use of your DOS program

[barndweller]

The company I worked for almost 30 years ago hired a company to set up their computers and create a inventory control system. At the time my sister and I worked for them. At that time the cast registers were not computers but real cash registers. One of the registers took a big surge during a storm (yes they had protection) and they were told they were obsolete (4 years old and cost 5,000$ each and had 3 of them). we were told we would have to start over with everything. I had learned a little programming in FoxBase and later FoxPro and I had made hundreds of modifications that my sister and I had come up with to make our lives easier (we both managed a store). 17 years ago I purchased the company and my son was pushing me to get something more modern and we almost purchased one for 11,000$ but as we drilled down into the details of how the system worked it did not work anywhere as well as what we already had.

We then decided to keep what we have and I will keep it running as long as I can. I am 62 now. I tried DOSBox and it worked almost perfect and having some keyboard issues. With all my reading on forums for DOSBOX someone suggested to someone else the vDOS so I Downloaded it and tried it out. It runs my app fine so far. I need to figure out how to make shortcuts for each thing but that ill just take some time and reading. I am very impressed with the printing already built in. I am in the USA and I did a conversion and it looks like the license fee is only around 50$ each. That in my book is a bargain! I for one will continue to use the DOS software for as many years as I can.

[Jos]

Switching to a genuine Windows program is preferred, though your story will be familiar to many.
Good you didn’t take on DOSBox, would have caused more ‘big surges’ going live.
The expected end-of-live of vDos is 2099, that of Windows. I reckon no more DOS users at that time…

Jos

[rodeminy]

Firstly I would like to say how impressed I am with vDOS, and by the dedication and effort it must have taken to develop it - thank you.

I have been dreading the move to Windows 10, because I have so many DOS applications which I rely on, but especially dBase, as though I've tried several Windows versions over the years, I've found them lacking features which I've come to rely on.  I've also tried running it in DOSBox, but found it taking too long to start, and had a tendency to crash, when I tried to run another application at the same time.

So I expect to be using dBase for DOS for the next few years at least.

And again, thank you for your time and effort in developing vDOS.

Rosemary

[accuutje]

Vdos is een prettig programma. Oude DOS programma's lopen perfect. VP-info (VPI) en VP-planner (VPP); programma's welke volledig compatible waren met Clipper, DBase I t/m IV en Lotus 1-2-3.
Mijn ervaring is, dat voor kleinere ondernemingen effectieve DOS-programma's perfect zijn, dus niet vervangen resp. verbeterd behoeven te worden.
De programma's werken tot aan de printerpoort perfect. Dan begint het wat moeilijker te worden. Printen naar PdF (ik gebruik Foxit Phantom PdF) gaat erg goed, maar de printercode's werken slechts beperkt. Dat zal in de toekomst de bottle-neck zijn. Is het mogelijk een dbase-bestand met printercode's, welke WEL werken mee te leveren? Daarmee kan vDos een overlevend programma worden.

Vdos is a pleasant program. Old DOS programs run perfectly. VP info (VPI) and VP planner (VPP); programs that were fully compatible with Clipper, DBase I to IV and Lotus 1-2-3.
My experience is that for smaller companies, effective DOS programs are perfect, not replaced or replaced. need to be improved.
The programs work perfectly up to the printer port. Then it starts to get harder. Printing to PdF (I use Foxit Phantom PdF) is going very well, but the printer codes work only to a limited extent. That will be the bottle neck in the future. Is it possible to supply a dbase file with printer codes, which DO work? This makes vDos a surviving program.

[Jos]

Can’t comment on DOSBox crashing. It needs some tweaking to run optional, at full speed. DOSBox (error prone) file caching can outperform NTVDM, so certainly vDos.
Though even at optimal settings, its emulated CPU will bite the dust compared to vDos. Always running at full speed, no speed related options.
I posted a video to demonstrate that at: www.youtube.com/watch?v=wSo7hYFHA7g.

Jos

[Jos]

The best way is to replace DOS programs by Windows ones. If that’s no (practical) option, vDos comes in place.
Printing in vDos is rather versatile. Though its internal print processor is mainly targeted at text output.
Obscure and graphic commands will be missing. For a list of supported commands, I have to know what printer type you use in the DOS program.
If vDos comes short in supporting printer commands, you can always use an external print processor.

Jos

[accuutje]

Jos,

Ik begrijp, dat het printercode's moeten zijn van/voor een eenvoudige DOS-printer zoals STAR NL10. Met vDOS kunnen uitstekend PdF-bestanden gemaakt worden, welke via een printer prima afgedrukt kunnen worden.
Maar het gaat mij om code's als 27,108,n (Left margin n characters). Moet ik voor de printercode's bijvoorbeeld denken aan die van www.printfil.com/manualen/c5-1.htm of www.fidcal.com/printercodes/index.htm ?


I understand that they must be printer codes for a simple DOS printer such as STAR NL10. Excellent PDF files can be created with vDOS, which can be printed with a modern printer.
But for me it's about codes like 27,108, n (Left margin n characters). For example, should I think of the printer codes from www.printfil.com/manualen/c5-1.htm or www.fidcal.com/printercodes/index.htm?

Thank you for your response

[Jos]

As I took on to implement an internal print processor, it had to differentiate from those external programs already available.
One such difference is scaling and positioning of the print output. Especially being Dutch, you should appreciate this functionality. In the past it was a crime (if not impossible) to get decent formatted output based on inches while using metrics oriented output.
To be able to fully scale and position, vDos intentionally drops all printer commands related to setting margins and the like. So at encountering for instance the Epson 27,108, n code sequence, vDos recognizes it as a valid command, but just ignores it. You probably should spend more time at reading the Printing.pdf document.

Jos

[barndweller]

For me and our company (my children run the day to day operations I am semi retired and just handle payroll and paying the bills). I wrote our software in the late 90's and it seams Microsoft has been trying to kill it ever since. I was happy with Windos 7 but my son wanted Windoz 10 so here we are. Our visa processing company would have sooner or later dumped any computer on our networks that ware not being updated my the manufacturer.

I started our conversion with DosBox and it seemed to work, was a little bit of a job to set it up and use it because we were using bat files that would call different things, some in Dos Box and some windows programs. I then found the vDOS and its perfect in my opinion. It is worth much more than the 250$ I paid.

My Son and I were at one of our shows we go to every year (Pet Industry) and they were trying to get as many of the retailers that would go to it to buy something they had and it would make ordering easier (for that vendor only) and it was 11,000$ and that is just the software for our 2 stores no hardware. My son was being shows the cast register part of it and it was confusing and slow. He has a collage education in accounting so he is much smarter than I. After he played with theirs for over an hour he came to me and said he did not release how good ours is and how easy it is to use. We did not buy and 2 years later that computer vendor was no longer associated with that supplier so the benefit would have been short lived. My cast register is simple and we can stick a new employee on it with 10 min of training and they can run it with standard sales. The finer points like refunds, discounts, ect are learned in a few days (they do not happen very much to have them as examples to show them). This system talks to the main office and it does our ordering with a human always verifying it. It adjusts the amount of onhands we keep for each item automatically according to the sales on that item. I am not bragging I am saying I have never seen a canned piece of software that will do anything close. It may be pretty and have lots of pictures but as far as function not even close. So as long as I am alive and can keep it going for my children (and grand child that also works in our stores now) I will. When I am going one of them will have to step up and learn it. I have put as much information and I can think of in a directory of \Info on our fileserver and have found as many books about FoxPro 2.6 for Dos. Hopefully my Daughter can pick up where I end up leaving off or someday my Son will find some one that have created something that works as well in Windos or Linux. I would prefer Linux I am tired of Microsoft selling me things and then killing them.

I will now get off my soap box.

[Jos]

You can’t compare a “canned piece of software” to something developed and finetuned over years for specific circumstances by an end user (you), knowing in dept what is needed, and how. Nothing can come close, or at the cost of extensive time and dollars. It’s not Windows to blame, it just wasn’t around as the DOS program was developed. Though many (still) find programming in Windows (or Linux) too complex to write a to-the-point program.

Jos

[oneillph]

I am using an old Dos program called Javelin. Over the years, since the 80s, I developed a set of 'models' which I use for financial analysis. These models contain historical financial transactions and various custom reports. I really do not want to try to find a commercial replacement, or somehow convert everything, so I hope to keep it up and running.

[caminomick]

I'm an almost retired civil engineer, and have dos versions of Quickbooks, two structural programs, and a survey program that I use. So far, with the exception of Quickbooks, I haven't found a comparable windows program that works quite as well. I have two windows versions of Quickbooks, but like the dos version much better. I kept my older computers, including two really old ones I built in the '80s using NT4, but am trying to get vDos to work with a 64 bit computer so I can retire those old dinosaurs.



Earl

[andersostling]

I have a client that is stuck for some years to come with an VBDOS app developed in the early 1990's. So far it has worked well on Windows 10 32-bit with NTVDM, but the client is also dependant on using CAD software that now only support 64-bit. Until he has found a way to migrate a lot of data in the DOS app to a modern CRM solution, there is no alternative.

I have tried the vDOSPlus in combo with Printfil, and it worked (sort of). Some printing issues and a more complex setup than vDOS. To my big surprise, vDOS handled printing perfectly without any third party software, and the setup is much cleaner in my opinion.

With vDOSPlus, I found a showstopper. The client need to run multiple instances of the app. I found, after much digging, that running the app under vDOSPlus created a "lockfile" in the working directory that prevented the second instance from running. The scary thing is also that the lockfile is named PHQGHUME, and a google search tells me that this is well knwon virus. This is not the case with VDOS luckily.

Can someone clarify the record locking thing in vDOS? As I said, we are using multiple instances and there are 4-5 users that may access the MDB datafiles concurrently. Will this be a problem? I read about RL in the FAQ but it is not clear to me how this works.

Thank you for an excellent development effort. As soon as we decide to go live, we will register the software for the client network.

[Jos]

vDosPlus is based on an older version of vDos. Its ‘useful’ additions can be confusing and complicate the setup.

No worry about the PHQGHUME file, it’s a bug in the DOS API implementation of old vDos versions, creating random file names. The (incorrect public) algorithm for that just was the same as that virus program used. The program will always try to create a so called lock file. That’s mostly an addition to the locking capabilities of the underlying OS (NTVDM/DOS/vDos). To display who (by name or workstation id) is eventually keeping you from editing something, or for license purposes.

Essentially RL is not done by vDos itself, but by the OS managing the drive on which the files are stored. That OS is the ONLY ONE that can keep track of what file regions are effectively locked. It is not something that is recorded on the disk itself. vDos part in RL is rather modest: It will check RL is indeed supported for a DOS/vDos drive letter, take care of timeouts, but mainly pass on the RL request to Windows. That will then forward the request to the OS managing the drive. As said in the FAQs, RL as used by (the database engine of) a DOS program is more complex. For instance the program will not lock the actual record since that would of course put all other instances of that program in need of the same record on hold. DOSBox (and mods) problem with accessing (MDB) datafiles is more that logical pages of database files are cached in local buffers at the workstations. So that is destined to overwrite updated (by others) data on disk, especially index pages are extremely vulnerable due to their complex structure/logic and compactness.

Jos

[andersostling]

"Essentially RL is not done by vDos itself, but by the OS managing the drive on which the files are stored. That OS is the ONLY ONE that can keep track of what file regions are effectively locked. It is not something that is recorded on the disk itself. vDos part in RL is rather modest: It will check RL is indeed supported for a DOS/vDos drive letter, take care of timeouts, but mainly pass on the RL request to Windows. That will then forward the request to the OS managing the drive. As said in the FAQs, RL as used by (the database engine of) a DOS program is more complex. For instance the program will not lock the actual record since that would of course put all other instances of that program in need of the same record on hold. DOSBox (and mods) problem with accessing (MDB) datafiles is more that logical pages of database files are cached in local buffers at the workstations. So that is destined to overwrite updated (by others) data on disk, especially index pages are extremely vulnerable due to their complex structure/logic and compactness."

Does this mean, in plain words, that multiuser access to MDB files on a shared network drive is risky when using vDOS and DOS appls?