|
Post by foxpropgmr on Aug 12, 2018 3:33:23 GMT 1
Here are some collective observations:
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
|
|
|
Post by Jos on Aug 12, 2018 7:45:59 GMT 1
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.
Jos
|
|
|
Post by al on Dec 10, 2018 11:41:46 GMT 1
Jos,
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?
We are using VDOS 30/05/18 08:01
Alasdair.
|
|
|
Post by Jos on Dec 10, 2018 11:58:48 GMT 1
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.
Jos
|
|
|
Post by al on Dec 10, 2018 16:19:10 GMT 1
Jos,
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.
Alasdair.
|
|
|
Post by Jos on Dec 10, 2018 16:48:40 GMT 1
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.
Jos
|
|
|
Post by al on Dec 10, 2018 17:30:37 GMT 1
Yes, I was aiming to reduce the file size tonight and reindex to see if it made any difference.
I have had another go at running in Foxpro and have got the program to start, but as soon as it gets opening files it complains it hasn't enough memory and closes.
When running native Foxpro from VDOS it shows over 10MB of expanded memory is available, but from the executable it only shows 10kB, a quirk I presume of the original compiler.
Alasdair.
|
|
|
Post by Jos on Dec 10, 2018 18:51:35 GMT 1
Perhaps the 10KB is what’s not claimed by the program (available to other programs), though strange to leave that behind.
Not enough memory could mean your program is too complex to fully run in conventional memory. So it definitely would need XMS (FoxProX) to run?
Jos
|
|
|
Post by al on Dec 11, 2018 13:01:19 GMT 1
Jos,
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.
|
|
|
Post by Jos on Dec 11, 2018 13:16:35 GMT 1
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?).
Jos
|
|
|
Post by al on Dec 11, 2018 14:42:41 GMT 1
Yes, you're right. Not enough memory, EMM set to 10,485,760 which Foxpro sees but the application only sees 10,240 as in VDOS.
|
|
|
Post by Jos on Dec 11, 2018 17:01:04 GMT 1
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 jas@vdos.info (change the "a" to an "o").
Jos
|
|
|
Post by foxpropgmr on Feb 13, 2019 6:54:54 GMT 1
Hi! I'm the original poster for this thread.
I'm using the vdos.exe dated 5/30/18.
This version exhibits random page faults during backups, re-indexing, and compiles (2%), and rarely (0.01%) when pressing a key that activates a program window (usually ENTER).
Is there a silent update to this? If so, I'd like to try it.
My main concern is page faults during file operations. About 1/4th of the time a file or index is corrupted, and I have to recover it.
Walt
|
|
|
Post by Jos on Feb 13, 2019 10:34:42 GMT 1
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 jas@vdos.info (change the "a" to an "o").
Jos
|
|
|
Post by johngoebel on Feb 14, 2019 3:42:51 GMT 1
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.
John
|
|