that NTVDM creates separate instances for each .exe/.com that is run

Try a batch file, that is create some "run.bat" that executes the
tsr first, then the program (in the same session).
Like

@echo off c: cd\where\is\my\tsr thetsr.exe cd\where\is\that\prog theprog.exe […]
Show full quote

@echo off
c:
cd\where\is\my\tsr
thetsr.exe
cd\where\is\that\prog
theprog.exe

I have done this in two ways.

If I run the batch file natively it will run the both tsrs (one fails with an error message not enough memory, so i'm only testing the one that didn't give a failed to load message) and in WPDos hitting ctrl-d doesn't bring up the TSR.

If I make a shortcut and PIFs for all programs involved, and my shortcut is to "command.com /P /E:4096 /c mybatchfile.bat" it just craps out when loading either TSR.

I've been through pretty much every fix on this site to try to get things running natively:

http://www.columbia.edu/~em36/wpdos/

I've also tried loading the TSRs in my config.nt file using INSTALL=C:\SEMD15\SEMD.EXE and INSTALL=C:\PPLUS2\PRD.COM but then command.com and cmd.exe just crash out when I try to start them. They instantly close.

I also found the following "dosonly" setting for config.nt, but it doesn't seem to help in any of the above configurations:

http://www.microsoft.com/resources/documentat … y.mspx?mfr=true

And actually, the following page has fixes for both my programs (Stedman's Medical Dictionary and PRD+) that don't seem to work either:

http://www.columbia.edu/~em36/wpdos/medtrans.html

note: I did not try that MoSlo 4Biz program.

A fine site, that one. I was just going to recommend it. I was also going to suggest Bochs, but there's no way you're going to be able to access the network shares from within Bochs. I don't suppose WP5.1+ or WP6 are out of the question?

It sounds to me like the real issue should be finding out what causes WP to hang when trying to access these network drives mounted in DOSBox . Have you observed this behavior with non-Novell network shares, maybe? Does the freezing still happen in DOSBox if you don't load up the TSRs? Are you trying to access some deep subdirectory of drive o: (or whatever), or something in the root of drive o: ? Are there long filenames involved? Is write-access to the shared drives permitted? Does the problem happen with the WordPerfect Library Shell on this page ?

We had another poster with a similar problem - very slow access to networked drives. I think Qbix looked at the code trying to determine what could be causing this (multiple look-ups, unnecessary caching, ...) but I don't remember if any conclusion was ever found.

Edit: Found the thread:
Slow network drive reading using DOSBox 'CAD edition'

Might be better off running the program in Virtual PC. Since it's a DOS program you can just install FreeDOS and not have to worry about buying license's for Windows 98 for each virtual machine.

Only problem is that Virtual PC 2007 doesn't official support MS-DOS anymore. (Although it does work).

What cycles/core options are you using for DosBox? Perhaps these shares have alot of directories/files and since DosBox cycles/core is set to a non-optimal setting then they may take longer to parse.

MiniMax and DosFreak,

This re-inforces my point about adding the NTVDM EMS (fix) support into another release of the VDMsound code. The WinXP NTVDM is actually the correct business answer for this in-over-his-head 'consultant' and his customer's WPDOS problems.

The use of the word 'inject' said TSRs 'into' WPDOS was my first clue that the original poster might not have a good handle on solving the problem. 🤣 The other hint was his impression that seperate NTVDMs are launched for each executable in a batch file. 😖 The WordPerfect for DOS Updated website has all the information necessary to run said applications, however the problem is, of course that these applications require EMS memory in DOS, DosBox or the NTVDM to function. Since he is probably getting no EMS memory in the NTVDMs of the client's WinXP (SP2) based PC workstations - he turned to Dosbox, which unfortunately is not the fix for his customer's business application problems because of the requirement for access to a remote directory accessed over a VPN.

I wonder how hard it would be to re-create Vlad's production environment? 😢 Anyway, something for later. I've got to finish my WinXP (SP2) VGA.SYS fix, so I can then release my SYSTEM SHOCK (floppy version F1.5S) installer and finally get back to finishing my proposed DosBox coding changes for hardware MT-32 rev00 SYSEX delay support and MIDI timing fixes.

dvwjr

dvwjr: My terminology sucks, that I know. I'll be the first to admit I know nothing when it comes to programming / memory address ranges / etc. I have no idea how half this stuff works on the inside. I'd love to but I can only cram so much in to my brain each day. I'm generally only a network and telecom consultant, I hate dealing with these kinds of software issues.

Anyhow, progress update. I've worked a bunch through that site in more detail, and I have PRD+ and WPDOS51 working just fine with the help of the recommended "Tame" application and a lot of PIF memory settings. I cannot get Stedmans to work in the same fashion, presumably due to the "machine too fast" issue they talk about. Tame's documentation seems to have information about controlling CPU speed and such, I'm going to begin investigating that.

dvwjr wrote:

The other hint was his impression that seperate NTVDMs are launched for each executable in a batch file.

While I didn't explain what I thought correctly, it is how it appeared. SEMD would run, PRD would run (once I fixed the memory errors), but neither would function inside WPDOS. I'm curious how this really works technically.

Windows uses the same memory space / etc. for each shell open I would assume from your comments, and from the fact that I *can* get it working now. At least now I know my problems actually (seemingly) stem from other issues.

DosFreak wrote:

Might be better off running the program in Virtual PC. Since it's a DOS program you can just install FreeDOS and not have to worry about buying license's for Windows 98 for each virtual machine.

Only problem is that Virtual PC 2007 doesn't official support MS-DOS anymore. (Although it does work).

What cycles/core options are you using for DosBox? Perhaps these shares have alot of directories/files and since DosBox cycles/core is set to a non-optimal setting then they may take longer to parse.

I had things set up in a VMWare player, but gaining access to locally mapped network shares wasn't very clean at all. Plus, while a virtual machine is easy for you and me to use, it will be fairly difficult for someone less adept to use. Maybe VirtualPC is more user friendly, though. I may still give it a shot.

I have the default settings for cores and cycle:

core=normal
cycles=3000
cycleup=500
cycledown=20

I'll attempt playing with this a little bit, though I'm not sure it will make a difference.

Okay I was able to get all of this working natively in Windows. Thanks for confirming my suspicion that it's what I should have worked on from the beginning.

For those interested; these were the steps I took. The short version: Followed the Medical Transcriptionist's Survival Guide (linked above) with a couple tweaks since they did not have the right combination of TSRs configured and working with WP5.1. Long version follows.

I needed to use TameDOS to get WP working the way the customer liked. WP would work without, but I can change screen resolutions and stuff as easily without it.

I was able to get EMS working in Windows. Making .PIFs for each .exe/.com involved did not seem to be enough, but I didn't take good enough notes to know exactly what fixed it, as I did the EMS stuff and TameDOS stuff all at once. I also modified the _default.pif in the system32 folder for a catch all, since these machines have a very specific use. I do not know if this was necessary.

From the start I had a batch file that ran my two TSRs with appropriate command line options (SEMD.EXE and PRD.COM) but SEMD would never load. Tame's diagnostics reported how SEMD was functioning, and a created a Tame settings file to attempt to eliminate giving SEMD extra time slices as my reference site said it did not like fast computers. This did not help. I then ran prime95 at higher priority and loaded it, it loaded one out of about 7 tries, not nearly reliable enough.

I then checked in to the Mo Slo 4 Biz, and the settings provided there did not work. I was able to play with the methods and durations enough that eventually I got it working reliably. My command line options for MoSlo ended up being for my three test machines:

MoSlo.exe /s2000/m3/du8 C:\wp51.bat

wp51.bat ended up looking like this:

c:
cd \semd15
semd.exe
cd \pplus2
prd.com /b40 /e1200
cd \wp51
wp.com

Each related .com/.exe had a .PIF with EMS and Initial Environment Maxed, everything else set to Auto.

Config.NT was modified to include the line "EMM=RAM"

Now the slowdown will need to be tweaked for each model/speed of machine this will go on, as it doesn't work at all on my faster box here unless I really pump up the slow down.

I know the detailed information is not particularly relevant for this forum, but in case anyone else has the same idea for using DOSBox as I did, I hope this post helps.