Andrew K
Guest
|
Post by Andrew K on Apr 29, 2019 0:39:54 GMT 1
How can I run multiple instances of a DOS app with vDOS? We have an old Foxbase 2.0 DOS app. I can have several instances of it open using NTVDM on 32b and it works perfectly. Trying to see if we can move to 64b Win 10 and use vDOS but I cannot seem to be able to run multiple instance of an app? (single instance runs just fine)
|
|
|
Post by Jos on Apr 29, 2019 5:53:04 GMT 1
|
|
Andrew K
Guest
|
Post by Andrew K on Apr 30, 2019 1:33:58 GMT 1
Thanks Jos, but perhaps I don't understand? I am not getting errors as in that thread, the second instance just doesn't open at all. Nothing is written to a log upon failed attempt to load the 2nd instance either.
|
|
Andrew K
Guest
|
Post by Andrew K on Apr 30, 2019 2:09:54 GMT 1
maybe my setup is wrong? I have a folder myapp with a shortcut to vDOS.exe (which is in C:\vDOS directory). The shortcut is set to "Start in" the myapp directory. The myapp directory has an autoexec.txt file with just the following:
USE C: C:\ USE F: F:\ USE G: G:\ PATH C:\FOX (8 these are where the Fox 2.0 files reside)
G: CD SL2 FX CS
EXIT
The above works fine for the first opening. Trying to open any more times does nothing.
If I open multiple vDOS.exe windows from the vDOS directory and then type in the above commends ant the c:\ prompt... all of the windows run the app concurrently without issue. So what am I missing?
Thanks!
|
|
|
Post by Jos on Apr 30, 2019 7:15:57 GMT 1
Something must be off between your autoexec.txt file and typing the commands at the command prompt.
What if you add a PAUSE command before and after FX CS. So you’ll see what’s going on, what error FX CS produces.
BTW, USE C: C:\ is no good. Better to put the directory FOX in some other directory, and assign that to vDos C:. Also preferably use something like USE F: \\server\share\ instead of the roundabout of referring to Windows mapped drive letters.
Jos
|
|
Andrew K
Guest
|
Post by Andrew K on May 2, 2019 8:58:13 GMT 1
Thanks Jos. I changed to autoexec to following only:
USE C: C:\FOX
USE F: \\server\shareA
USE G: \\server\shareB PATH C:
G:
CD SL2
FX CS
EXIT
Same issue as before. Also, even when I manually type in each line item - aside from the first use (which comes right up!) - I need to run the "FX CS" command repeatedly on the subsequent instances before the app comes up.
|
|
|
Post by Jos on May 2, 2019 9:42:49 GMT 1
You could remove or rem-out the EXIT command, so the vDos window doesn’t close and you only have to enter FX CS. Though puzzling why this behavior: I would expect it to run the first time, if not, display some error message. Certainly not silently quit and start after a number of tries.
Start vDos with the log option (“…\vDos.exe” /log), perhaps the generated vDos.log file will show what’s going wrong.
Jos
|
|
|
Post by jakndaxter on Jul 6, 2022 15:22:49 GMT 1
Hi, I know this thread is old. I am having a similar issue with a slight difference. I have vDos running on multiple PC's and accessing the .BAT file on an old PC that has the file and all of the computers are mapped to its F:. When one user is on, it works great. When there are multiple users, it works but will freeze either at startup or in most cases it will have an error while using it that states "Library read error". It seems to be having a problem with locking files for multiple users, possibly. Any idea what might be causing this? Whether it's vDos or our system?
|
|
|
Post by Jos on Jul 6, 2022 16:35:17 GMT 1
vDos checks file region locking is actually supported by Windows or the remote OS. Locking a file is mostly exclusively opening a file But that doesn’t fit in a multi-user setting.
More likely the setup of your program is incorrect. Eventually run vDos with the log option (….\vDos.exe /log). Perhaps the generated vDos.log file will clarify what’s going on/wrong.
Jos
|
|
|
Post by jakndaxter on Jul 13, 2022 15:29:09 GMT 1
Thank you for the reply. How exactly do I run the log option on vdos? I'm pretty green with this stuff and I've been trying and I don't think I'm doing it right. It opens a new vDos window but that's it.
|
|
|
Post by emendelson on Jul 13, 2022 15:37:31 GMT 1
Jos's earlier message has the answer. Open a Windows command line, navigate to the directory with vdos and type:
vDos.exe /log
and press Enter. A log file will be written to the same directory.
|
|
|
Post by jakndaxter on Jul 13, 2022 19:42:46 GMT 1
Thank you! From what I am seeing, it doesn't look like any errors are being registered by vDos. I'm thinking it's a problem with our system or the host computer.
|
|
|
Post by Jos on Jul 13, 2022 20:35:03 GMT 1
The vDos log doesn’t show logical program flow deviations.
Suppose the program has two distinct modes of operandi, single and multi-user. In the first it would open a file exclusively, in second shared. And if required, use record (file region) locking to get temporary exclusive access to some part of the file. If however two program instances start in single-user mode, the latest started won’t be able to open the file exclusively since the first already got those rights. You would have to check if a DOS environment variable or program command line switch is missing in the vDos setup.
If you didn’t replace any of the workstations, the old PC would not be to blame. If you however got one or more new PC’s, and perhaps even still have a XP PC running, it is more complex. Windows XP and later versions don’t always mix that well. Furthermore is a (old or new) Windows PC not really suited (I also hope no one uses that meanwhile) to act as a fileserver. Modern Windows optimistic locking scheme could cause problems in such situations.
I would advise you in any case to get a basic (one-drive) NAS to replace the old PC. That would also eliminate possible optimistic locking issues.
Jos
|
|
|
Post by jakndaxter on Jul 21, 2022 19:46:50 GMT 1
Hi again. I looked into the NAS. In doing so, I learned some things about our system. We remotely connect to an XP computer because of a security device plugging into a Db25 port. The system can be run from any computer that can run a DOS program. However, it then won't see the security device. But anywho, the important thing is that I found out that the vdos setup works flawlessly on our old computers with windows 7. I may have mentioned before, that the IT guy who originally wrote this specific program in 1982 set it up this way: the win7 PCs use Windows Virtual PC to connect to that XP computer. It's set up so that every user has a different node and doesn't eff each other up.
So, why does it function perfectly on Windows 7 PCs and not Windows 11? Is it a vDos compatibility with 11? Is it a compatibility issue between 11 and 7? Or is it because the setup for the Windows Virtual PC is indirectly giving vDos a more complete path or sharing ability?
Just hoping that someone might be able to help with this. I'm currently looking into it now, but I'm really just an IT guy on the fly and learning as I go.
|
|
|
Post by Jos on Jul 21, 2022 20:29:30 GMT 1
Basically vDos doesn’t use Windows version specific functions, the host system only has to be Windows 7 or later.
I’m puzzled by the security device. What is its function?
No idea why it would work in Windows 7. Perhaps the latent Windows Virtual PC still connects a local COM port to that of the XP machine. You could review the Device Manager for that.
A surprise that then works with vDos, it has only basic serial communication support. Though if so, that may be good news. You would have to connect a vDos/DOS (COM1?) serial device to that central security device. I don’t know how it is published, you could experiment with the COMx = "Windows device or file": ["Error caption" "Error message"] directive (see Printing.pdf).
Jos
|
|