I found out from my user that they're just dealing with large database files 1.2GB or larger which is a different issue that gets fixed when we remove data not needed to get the operation done. So my problem is not related to sleep/idle.
Thanks for the update. If a program doesn’t indicate it’s actually doing something (taking longer), one could be fooled vDos isn’t responsive, while it’s the DOS program. BTW, the size of a (indexed) database shouldn’t be the real issue. Fragmented and out of balance indexes mostly are.
That leaves two reports of vDos freezing. While I first should have instructed smpettit to disable DataPerfect optimization (an undocumented switch), and see if vDos still freezes. Major parts of the DP engine/core are executed by vDos itself, could be I missed something there. I also have two vDos instances running, dBase V and DP, for the whole day. Occasionally activating those to test their responsiveness, no luck so far to reproduce vDos freezing.
2018.05.01 seems to work fine (although DataPerfect is a bit slower). I can also reliably reproduce the 2019.05.01 lockup.
In the attached screenshots, I opened both 2018.05.01 and 2019.05.01 and began using them, they both work fine initially. I left them open for ~5-10 mins and as you can see the 2019 window eventually becomes unresponsive and no amount of clicking/typing wakes it up. The 2018 window continues to respond fine. I have also tried leaving the 2019 window alone while it's locked up but it doesn't seem to come back to life.
My setup is a Windows Server 2019 virtual machine running on Azure cloud. VM size is a F4s, but I've tried lots of sizes of VM's though when I was trying to track down why it was locking up so I don't think it's related to the VM size.
You mentioned in your last post a DP optimisation but I don't think this is related either as I'm not evening running DP at the point of the lockup.
You get me confused, the vDos nag was problematic in 2018.05.01 if vDos was minimized. Didn’t care that much, though that was fixed in 2019.05.01. That nag should only popup the moment networked files are actually accessed by a program. No program started/running in your screenshot, would be the DIR command. Isn’t supposed to trigger the nag, will look into that. Though, who does a DIR on a networked folder before starting a program…
DOS programs in vDos mostly don’t run noticeably slower compared to running in real DOS or Windows NTVDM. As long there’s user interaction, the program will still mostly just wait for (user) input. With DP you’ll notice vDos being real slower with (large) reports and re-indexing (no/little user interaction). vDos 2019.05.01 has a somewhat proof-of-concept: A simulated CPU doesn’t have to be slower than the real thing. DP programs in vDos 2019.05.01 should only run some 10% slower. By executing major parts of the DP core directly (not run in the emulated CPU). In a network environment probably even faster, by limiting network traffic caused by some DP quirks.
Oops, missed your PC is in a domain. Then ‘enabling’ the nag is not trigged by a program accessing networked files. vDos freezing only occurs when the nag is displayed? That’s then unrelated to hibernate mode. vDos at that moment just dismisses all Windows messages and waits for a keyclick in the nag.
Not much changed with that, except that 2019.05.01 first forces the vDos window to the foreground so the nag can actually be clicked, even if the window was minimized or not in view (a mishap in 2018.05.01). I tried several situations, vDos window minimized, inactive, DP running, but can’t reproduce vDos freezing.
Though probably there’s more to it than just starting vDos and doing nothing for some time?
I deleted your screenshot because of possibly sensitive data.
The freezing occurs even if I click the nag away as soon as it comes up. As it stands all the DP databases seem to be working great on 2018.05.01, but when I swap to 2019.05.01 they return to locking up after a few minutes.
I don't suppose there's an undocumented switch that would allow me to disable the hibernation behavior?
To make sure: vDos 2019.05.01 always freezes after some time (running DP), even when no nag is involved/displayed?
There’s no (undocumented) switch to disable hibernation. Don’t like options that shouldn’t be needed.
Don’t see how hibernate mode could freeze/stall vDos, it uses the Windows WaitMessage() function. That proved to also return w/o any message pending, so a non-destructive PeekMessage() was added to keep it ‘active’.
The only thing that comes to mind is the nag, dismissing all Windows messages. While there’s some monitoring program running, probing vDos to be active. Just to return “I don’t/can’t handle” that message/request.
Yes it always freezes after a few minutes. The nag screen comes up almost immediately on opening vDos and I click it away, begin using DP, then return to DP a few minutes later and it's locked up. I haven't purchased the network license yet, I will be purchasing it but need to finish proving the entire project is viable first.
2018.05.01 is working fine even with the nag screen so at the moment I'm happy to carry on with the previous version for the sake of getting this project approved and perhaps once I've got approval and bought the license then I can try 2019.05.01 again and if it still locks up without the nag screen we can revisit it?
Ah well, the early nag screen is because your PC is in a domain. Detection of accessing networked files is just skipped. I enforced vDos establishing the PC joined to a domain, couldn’t get it to stall. At the command line, or running a program, like DP. The latter would really benefit from 2019.05.01, running as fast as natively in NTVDM. Can’t imagine a registered vDos would do anything to resolve this issue.
You could however: Start DP by the autoexec.txt file.
If that doesn’t solve the issue: Start vDos with the log option (“…\vDos.exe” /log). Run DP until vDos stalls, and post the generated vDos.log file.
I'm attempting to run a DOS hotel reservation program off a network drive of a Windows 2008 R2 server set up in a workgroup configuration. It was freezing on the nag screen so we purchased a single license but it still freezes after a few minutes of inactivity. We have 3 workstations that will access this program once we get it working and will purchase 2 more licenses. This is on a Windows 7 PC. Let me know what type of testing I should do to determine the issue. Could it be related to our reservation program.
The mishap with the nag was that vDos then only reacts to a click within the nag. If for instance the vDos window was minimized, you of course couldn’t click the (invisible) nag, but neither could activate the window since vDos simply ignored all Windows messages except that click.
vDos freezing after some minutes of inactivity is more complicated. At that moment the WaitMessage() API function is called. According to Microsoft: “Yields control to other threads when a thread has no other messages in its message queue. The WaitMessage function suspends the thread and does not return until a new message is placed in the thread's message queue.”. Great, vDos should be deactivated (‘hybernate’). But WaitMessage() actually returns even if no message is pending, like with notifications “You got mail…”. So WaitMessage() operates within a loop with PeekMessage() to ensure there’s actually a pending message to wake up vDos. Then it becomes weird, PeekMessage() modifies the state information of the message queue so the subsequent WaitMessage() doesn’t return at all. Either Windows shouldn’t end the first WaitMessage() if there’s no actual message pending, or better synchronize WaitMessage() and PeekMessage().
Both problems should be fixed with the 2020.03.01 version, they aren’t related to your program.
Will the 2020.03.01 version be available on that date? We are still running the program natively on Windows 7 32 bit on the workstations I want to replace. I'd like to get them replaced as quickly as possible.