I have a semi-commercial application developed in Foxpro and I use foxprox.exe to run it.
I've been using various versions of vDos and vDosplus to run it for about 3 years.
First of all, congratulations on creating a very useful product. I've noticed a performance boost in the 5/18 version and it seems even easier to implement.
The only error I've ever gotten from vDos or vDosplus was Page Faults. Currently the latest version of vDosplus crashes more frequently and more reproducably than the latest version of vDos; maybe by a factor of 5 to 1. But it still does it. And since many of my clients use it, it occurs on many machines, not just mine, and from Windows 7 to 10.
The product is perfect for me and my clients aside from this.
The only clue I can offer is that it seems to happen when a file is opened (during backups), or sometimes when a new window is opened by a keystroke and a file is opened concurrently. But I can't create a reproducable scenario with vDos like I can with vDosplus.
If you could address this one last thing, me and my clients would be so grateful.
My best regards, and thanks for a wonderful product, Walt
That Page Fault error has been around since vDos supports virtual memory mapping as used by the Phar Lap DOS extender linked to FoxProX. Check if vDos.exe is dated May 30, I was under the impression this problem was finally fixed by a late silent update.
We are seeing a lot of "page fault: directory or table entry not set" crashes from foxprox as well. It appears to be when opening up a record from a file. I cannot reproduce it reliably but the circumstances seem to be when opening a record from our largest file. Unfortunately VDos logging is not picking anything up and our foxprox appliction isn't producing an error file. The file that I believe is being used contains just over 300,000 records, if that is relevant?
The original poster didn’t come back, so I assume his problem was solved by using the latest vDos release.
The number of records in a database shouldn’t matter since a program typically only holds one or two records of the same database file in memory. To investigate a problem still with FoxProX, I would need some testcase to reproduce the error… If your application can run with FoxPro (real mode), use that.
Thanks for the quick reply. The application is a compiled executable which won't even start in Foxpro.
I'd help in any way I can with testing. I did get the problem to repeat this morning, opening and closing the same record, after 3 or 4 opens it would serve up the page fault. However neither VDOS nor Foxprox log anything at that point so I have nothing to go on and I don't know what underlying calls the program is making to open/close the records to attempt to recreate it as a test.
Page fault errors are very hard (impossible complex) to track down. vDos can only quit the moment it’s confronted with that. And it’s beyond the scope of the program to report about that (it’s just killed).
Can you reorganize (compact/optimize…) that 300,000 record file, or delete records that can be missed.
If not, contact me directly to come to a solution.
No further forward I'm afraid. Reducing the file by half and reindexing hasn't helped at all. I've checked for the same error in normal DOS and I can repeat the sequence many, many times with no errors at all so I don't think it is a file error, just something awry with the extended memory in VDOS.
I've tried starting the app and Foxpro different ways in VDOS and cannot get it to recognise more than the 10k EMS reported above which is not sufficent. I have some of the original installation instructions which implies it should run under either EMS or XMS OK.
I’m still afraid FoxPro not able to run your application is due to conventional memory not being sufficient to run it. To confirm: What when you try to use FoxPro in Windows 32-bit/NTVDM (normal DOS?).
The 10KB will be what’s available to other programs, since your application already claimed all EMS memory (except that 10KB). Eventual MEMLIMIT parameters in the FoxPro/FoxProX configuration file are ignored by FoxPro, even by FoxProX in vDos since it doesn’t provide a DPMI server and EMS 4.0 (just EMS 3.2).
For the page fault errors: Contact me directly at firstname.lastname@example.org (change the "a" to an "o").
vDos.exe of 5/30/18 included the last silent update for this version. Besides you, only the previous poster, al, reported still getting page faults with FoxProX. Like him, contact me directly for these at email@example.com (change the "a" to an "o").
I'm sorry to say that we also continue to get page faults using vdos dated 5/30/18. I should have continued to report them, but I couldn't offer a reliable way to reproduce the fault for testing.
So far the page fault has not caused a corrupted file in production use, but I don't use vdos for re-indexing or compiling if I can help it. In testing if vdos crashes when compiling it usually corrupts the project file.
In any case it's still a great program and has saved me from having to re-write our entire invoicing system. But it would be great to not have the page faults, and if there is anything I can do to help please let me know.