|
Post by vince on Aug 8, 2020 0:51:36 GMT 1
I am trying to avoid having to convert my RBase for DOS accounting system which has been a lot of years in the making. The vDos environment looks good and most of the programs function correctly but a fair amount kick me completely out to the desktop without any kind of warning or error message. At first I had the software on a local PC and databases/apps on our server like all of our 32-bit Windows 7 machines but not knowing what I'm doing I ended up putting everything in the same directory on the server to get the system to work on the 64-bit Windows 10 test machine. I have not yet registered the product in hopes I can get everything to work correctly first. My gut feeling is it's a memory issue but like I said, I'm very much a novice at this.
|
|
|
Post by Jos on Aug 8, 2020 9:05:37 GMT 1
Could you start vDos with the log option by adding "/log" to the Target property of the shortcut that starts vDos and your program. That will generate a vDos.log file in the vDos directory. Then submit that file after vDos quits by selecting one of those functions. Perhaps it will show what’s going on.
Jos
|
|
|
Post by vince on Aug 8, 2020 16:13:45 GMT 1
Jos,
It looks like the problems are a result of the memory manager RBase uses (Dos4gw) and temporary files it creates (.$$$). The Getprint errors are expected.
vDos 2020.03.01 C: => (Local) C:\vDos\ M: => (Remote) \\ROCO-SVR\SYS\
Execute: RBASE95.EXE - -R -Z250 STARTRB Int 0 => 19e:0a4e OpenFile failed: RO\5F2EBDD8.$$$(2) => \\ROCO-SVR\SYS\RO\5F2EBDD8.$$$(2)
Execute: dos4gw.exe - M:\RO\RBASE95.EXE -R -Z250 STARTRB -e0M:\RO\5f2ebdd8.$$$ OpenFile failed: RO\DOS4GW.ETX(2) => \\ROCO-SVR\SYS\RO\DOS4GW.ETX(2) Int 15 unhandled call BFDE Int 2f unhandled call 1687 Int 15 unhandled call BFDE Int 15 unhandled call BF01 0.03 Int 15 => b6d:12cc 1.00 Delayed logging, set w/o DOS call: Int 15 => d6e:12cc Int 1B => d6e:1168 Int 22 => 19e:2e9b Int 23 => d6e:1188 Int 24 => d6e:118c 2.17 OpenFile failed: RO\5F2E93AB.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AB.$$$(2) OpenFile failed: RO\5F2E93AB.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AB.$$$(2) 2.23 OpenFile failed: RO\5F2E93AC.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AC.$$$(2) OpenFile failed: RO\5F2E93AC.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AC.$$$(2) 2.28 Record locking verified for DOS M: 2.32 FindFirst failed: NET.exe (18) FindFirst failed: NET.com (18) OpenFile failed: GETPRINT\PRINTER1(2) => C:\vDos\GETPRINT\PRINTER1(2) FindFirst failed: C:\GETPRINT\PRINTER1 (18) OpenFile failed: GETPRINT\PRINTER2(2) => C:\vDos\GETPRINT\PRINTER2(2) FindFirst failed: C:\GETPRINT\PRINTER2 (18) 2.34 FindFirst failed: NET.exe (18) FindFirst failed: NET.com (18) 5.75 OpenFile failed: RO\5F2E93AF.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AF.$$$(2) OpenFile failed: RO\5F2E93AF.$$$(2) => \\ROCO-SVR\SYS\RO\5F2E93AF.$$$(2)
|
|
|
Post by Jos on Aug 8, 2020 17:53:01 GMT 1
I don't think any of the reported remarks are actually related to the problem.
What if you use attached DOS32A.EXE instead of DOS4GW.EXE?
Jos
|
|
|
Post by vince on Aug 9, 2020 0:24:05 GMT 1
Jos, I'll try Monday - I'd love for it to work. 3rd Party industry specific software costs an arm and a leg and would be extremely time-consuming to learn. I'd much rather spend the money getting my current program to work in vDos. Thank you very much for the help.
|
|
|
Post by vince on Aug 10, 2020 18:14:57 GMT 1
Unfortunately that file (when used via vDOS) results in repeated DOS/32A fatal (0007): could not enable A20 line. It works fine on the Windows 7 32 computers.
|
|
|
Post by Jos on Aug 10, 2020 21:38:31 GMT 1
It was just an idea: I knew Alpha4 also uses DOS/4GW, saw no DOS4GW.EXE but that DOS32A.EXE file in its directory. And assumed it was used as a replacement for DOS/4GW. It however isn’t, DOS/4GW is linked with Alpha4.
So we forget about DOS/32A. There would be a .VMC file containing DOS/4GW configuration settings. Perhaps tweaking the MINMEM, MAXMEM and SWAPNAME settings will fix the memory issue. Eventually submit that file.
Jos
|
|
|
Post by vince on Aug 12, 2020 23:28:40 GMT 1
Turns out it was an error with the rights and location of the "Scratch" files RBase uses. Once that was corrected the program works great so I just submitted a credit card payment to register our Network ID. Thanks again - great work with the emulator.
|
|
|
Post by Jos on Aug 13, 2020 8:11:03 GMT 1
Thanks for your registration and compliment.
Strange that the rights/location mishap of the RBase "Scratch" files isn’t reported in the vDos log file. Like the "OpenFile failed:..." entries, one would expect similar entries for "CreateFile failed: DOS path (DOS error code) => Windows path (Windows error code)".
Jos
|
|