I remember getting that error in the old days, when COMSPEC pointed
to a different COMMAND.COM than was used to boot the system. But

Yeah now you mention it I recall something like that too, between 3.3 and 5.0 not long after swapping to 5... But everything here is 6..

Hmm, my old DOS system ran Binkley, but I had it all setup so that
I would exit the mailer to run the tosser. No need to shell.

That is how its running here too, but occasionally I'll shell FD and run it manually because I want to! :P But it was just an example of the memory it was
complaining about ~390k and ~540k the first shelled the latter exited to a batch file. I went to the horses mouth for this one, and was pointed at the dpmi version to which I said, I don't know anything about that fangled new stuff. However it does seem to have put the issue to rest.

Back in the day, I used to run CGA on my BBS machine for a while,
which was a good way to get more conventional RAM with QEMM.

There used to be a couple of dodges, I don't recall which way around vidram is,
I think its reallocating memory that would've been video allocated normally, by saying we're not using it. There also used to be a way of using the ram on the video card itself as well, provided you weren't doing anything fancy with it. Can't remember how that was done now. So I tended to run budget VGA cards and use the card memory.

What are you loading? I used to be able to load almost everything
high with QEMM. Of course, I was using real, not virtual hardware
then.

For whatever reason I've never found network drivers good candidates for loading high. Aside from those, theres really precious little I'm loading... I'll pop an archive up somewhere, you can have a look if you like. With this virtual setup QEMM's optimize appears to have no idea whats going on, it says its going to load everything high, as soon as you restart you get nothing but invalid ram regions specified errors. So aside from giving me EMS its not really helping at all

Spec


--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)

At present, I have config.sys loading QEMM, and setting some specs like lastdrive, stacks etc. Thats all thats in there, autoexec.bat is more convoluted but in essence still only loads,
share - we all know and love or loathe share
pcntpk - crynwr packet driver for emulated NIC
pktmux - to allow more than one proggy to interface to the packetdriver
pktdrv - pretend driver that goes over pktmux to provide the interrupr vector xfskrnl - The heavy lifting portion of the NFS client
rlfossil - which is another loathe or despise. serial to tcp/ip

aside from DOS=HIGH,UMB none of it will load high at all. Manifest says I have some 353k available, dos says I have 409k.

Spec


--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)

I could never get that working in a stable manner, back in the day.

Funny I've seen that said before. I didn't use it back in the day either, because despite the crynwyr drivers being around there wasn't much to use on top of them. Or not availabel to me.

Hmm OK, so you mount a NFS share on the DOS system?

You betcha. I replaced the old IPX network with a fancy scmancy tcip one.

Sure there isn't another way?

There is always another way :) But this was the first I could get to work at all.

What host OS are you using? And what virtual machine environment?

Ubuntu 16.04 with Virtualbox.

I wonder if there's ways to make the host OS do more of the
networking heavy lifting. For example, a Linux host can use tto0tty

Quite probably, however I'll go back to the earlier comment the first thing that worked is what I've stuck with. To be honest I've never had tcpser working, and I would really like to have had it work with the AII hanging off one end.

Spec

--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)

I tried, but all that happened when I tried sharing the packet driver
was the system crashed. :D

Sounds like bad interrupt vectors. It was something I found tricky to get my head round the first time I encountered it. But once you realise what its for,
its fairly easy. Sometimes in a fullish DOS system it can be tricky finding free vectors to use.

IP on DOS is a memory hog. I'd use IPX or NetBEUI to sabe RAM, if

Ok, I have precisely 1 driver loaded for tcp, the crynwyr driver. If I try IPX
I need about 6 drivers loaded... it was a far worse memory hog. I started trying IPX drivers when I first fired this thing up, then gave it away for TCP and NFS.

I had it working on my Linux Mint box along with tty0tty. Even
tested it using minicom to call BBSs over telnet. :)

All I can get is the sound of one hand clapping...

Spec


--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)

Sounds like bad interrupt vectors. It was something I

Oh, I had my IRQs sorted. That was something get right, because

Easy to mix, but the vector is the memory it hits after the interrupt is triggered, its the starting address of the interrupt handler if you like.. You can have all the IRQ's right but if the vectors are out it won't fly.

There usually described as interrupt vectors and have an address that looks like 0x60 or similar. 60 through 70 or so is usually freeish.

Spec


--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)

https://www.lazybrowndog.net/freedos/virtualbox/

No idea, but always happy to have a look see. I believe freeDOS ought to be able help get the load avg on the host machine down a bit. But i didn't really
look at it initially. I tried the usual emulators and settled on ms-dos in a VM.

Spec


--- SuperBBS 1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/105)