I kow this was the general consensus, but I reached out to the author of
mTCP for this question: can I use etherDFS for a multi-node BBS?

His answer:

"I'm not entirely sure of what you had in mind, but in general DOS just
sees this as a local hard drive or a RAM drive. As far as DOS is
concerned it's not a network device.You can use SHARE.EXE to coordinate
several programs (a parent process and a child process) on the same
machine accessing the same file, but you can't safely share a network
drive that is read-write with another machine. Sharing is only safe when looking at things read-only because even with SHARE, one machine changing
the FAT can ruin it for the other machine."

I'm moving on to MSCLIENT...

But I'd much rather use mTCP (for TCP/IP) and XFS (for NFS v2) under MSDOS 6.22, but not sure how to "share" the packet driver? I've seen PKTMUX mentioned, but it seems like the use case is DOS + Win3.11 packet drivers.

I've been down the VOGONS rabbit hole trying to dig up answers, but maybe
I'm approaching this problem wrongly -- how to have TCIP and NFS (or SMB)
on DOS at the same time (RIP conventional memory)?

|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

I kow this was the general consensus, but I reached out to the author of mTCP for this question: can I use etherDFS for a multi-node BBS?

Thanks for getting a conclusive answer on that. I wonder how correct record locking for network access would work - maybe we could add that on the server side?

I'm moving on to MSCLIENT...

Overall MSCLIENT has been working well for me, but I am having problems where after some time the network drive becomes inaccessible with "Too many open files" as an error in DOS. If I do a 'net logoff' and 'net logon' and 'net use' to remount the share then it works again.

It's been a frustrating problem and I am having trouble finding the cause (or more importantly, a solution). It's happening under both DOSBox-X and 86Box, running MS-DOS 6.22 in both.

Other than this "it stops working eventually", the setup has worked well. (multiple nodes of the BBS are sharing message bases, etc, without corruption)

But I'd much rather use mTCP (for TCP/IP) and XFS (for NFS v2) under MSDOS 6.22, but not sure how to "share" the packet driver? I've seen PKTMUX mentioned, but it seems like the use case is DOS + Win3.11 packet drivers.

I haven't run XFS, I am curious how well it works and if SHARE.EXE record locking works.

PKTMUX looks interesting, I am a bit nervous about the extra complications it may bring, getting stable networking can be tricky enough, combining network stacks seems like a bold move. :)

The limited conventional memory is definitely an issue (for sure with MSCLIENT), I am finding it workable but not exactly luxurious. I am running QEMM to get a bit more conventional memory but it's still tight.


Chris/akacastor

--- Maximus 3.01
* Origin: Another Millennium - Canada - another.tel (21:1/162)

I kow this was the general consensus, but I reached out to the author of mTCP for this question: can I use etherDFS for a multi-node BBS?

There's always NFS. DOS probably won't like filesharing much but the server
end will take care of it.

But I'd much rather use mTCP (for TCP/IP) and XFS (for NFS v2) under MSDOS 6.22, but not sure how to "share" the packet driver? I've seen PKTMUX mentioned, but it seems like the use case is DOS + Win3.11 packet drivers.

Nothing to stop you using PKTMUX with crynwyr drivers.

SHARE
VIDRAM ON (QEMM Option, extends base memory into the lower video ram.)
PCNTPK -n INT=0x7a
PKTMUX 2 (I want to use it twice)
PKTDRV (expose driver on int 0x7b)
XFSKRNL 0x7b
... assorted xfstool commands ...
PKTDRV (expose driver on 0x7c)
RLFOSSIL

Share will be doing its thing, file locking is really doing its thing on the server though. Not had a problem with this setup, it just runs day in, day out. Using MS-SOD 6.22 in VirtualBox.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: A camel is a horse designed by a committee. (21:3/101)

Nothing to stop you using PKTMUX with crynwyr drivers.

SHARE
VIDRAM ON (QEMM Option, extends base memory into the lower video ram.) PCNTPK -n INT=0x7a
PKTMUX 2 (I want to use it twice)
PKTDRV (expose driver on int 0x7b)
XFSKRNL 0x7b
... assorted xfstool commands ...
PKTDRV (expose driver on 0x7c)
RLFOSSIL

Share will be doing its thing, file locking is really doing its thing
on the
server though. Not had a problem with this setup, it just runs day
in, day
out. Using MS-SOD 6.22 in VirtualBox.

Fantastic, just what I was looking for -- thank you.

|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

Share will be doing its thing, file locking is really doing its thing
on the
server though. Not had a problem with this setup, it just runs day
in, day
out. Using MS-SOD 6.22 in VirtualBox.

Thanks again, just made your suggested changes and it works! Running
MS-DOS 6.22 on ProxMox... Thinking about trying in FreeDOS next.

I haven't optimized memory yet but I'm left with 548k (ouch). XFS is just
a hog and won't load high, so I guess I'll load everything else.

But, I've got network accessible storage AND TCP/IP to run RLFOSSIL now.

What version of QEMM are you running?

thanks!

|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

I haven't optimized memory yet but I'm left with 548k (ouch). XFS is just a hog and won't load high, so I guess I'll load everything else.

But, I've got network accessible storage AND TCP/IP to run RLFOSSIL now.

I couldn't get QEMM's OPTIMIZE to run properly with this setup. It'd go through the motions, say its done its thing and then when you tried to
restart and check it out, the drivers wouldn't load into the locations
optimize set them for. Result was even more loaded low.

Shelling out of frontdoor shows my setup has 496k free, so its probably somewhere over 500k pre rlfossil load.

I found RLFOSSIL a little persnickety in the way I wanted to use it vs how it would actually run for me.

c:\rlfossil\rlfossil 0 1 "path to bbs batch file"

I first tried loading FrontDoor with rlfossil, but this failed with a no
fossil error out of FD, and SuperBBS. I had to take it outside the regular batch file and run the batch file from the rlfossil command line.

I don't know why the foibles are the way they are. Might be virtualbox, could be some other oddity. But within the limitations, this setup is solid. I was able to unreliably load command.com from the rlfossil command line. FD and
SBBS weren't always happy, but you could have a look at memory and see what
was left this way.

For what its worth the only thing I've got loading high is ANSI.SYS But the only other items I have in config.sys is, ramdrive, smartdrv and power.exe
for releasing timeslices.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: A camel is a horse designed by a committee. (21:3/101)

What version of QEMM are you running?

Missed this, 6.00


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: A camel is a horse designed by a committee. (21:3/101)

I couldn't get QEMM's OPTIMIZE to run properly with this setup. It'd
go
through the motions, say its done its thing and then when you tried to restart and check it out, the drivers wouldn't load into the locations optimize set them for. Result was even more loaded low.

Same! Getting strange QEMM warnings, freezes, then no upper memory at all,
etc. and finally realizing ProxMox just isn't a great platform to run DOS VMs... May have to switch to VirtualBox, which is kind of a bummer
because all my other stuff is on my ProxMox PVE and it would be super convenient...

That said, I still want to chase down Dosbian on my Pi and give that a go,
as well as physical hardware (my old school NIC and GOTEK floppy eumlator arrive next week). Making progress!

Thanks for your help, Spectre.

|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

j0HNNY a1PHA wrote to Spectre <=-

Same! Getting strange QEMM warnings, freezes, then no upper memory at
all, etc. and finally realizing ProxMox just isn't a great platform to
run DOS VMs... May have to switch to VirtualBox, which is kind of a
bummer because all my other stuff is on my ProxMox PVE and it would be super convenient...

Have you tried any of the other architecture settings? I've run DOS 6.22 and
freeDOS in PXE, but not doing much more than running Microsoft Word for
DOS and a QWK reader.


... Walk without rhythm and you won't attact the worm.
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

Same! Getting strange QEMM warnings, freezes, then no upper memory at all, etc. and finally realizing ProxMox just isn't a great platform

EMS or Upper memory is there, I can load, SMARTDRV and RAMDRIVE, with copious memory with no functional issue.

Have you tried any of the other architecture settings? I've run DOS 6.22 and freeDOS in PXE, but not doing much more than running Microsoft
Word for DOS and a QWK reader.

Maybe there's something I'm missing, what architecture settings? I didn't do
a lot other than look at some vids to get the VM to a workable stage then
just cloned it. So I don't really know much about it, but, I only recall
seeing processor performance options nothing about how it behaves though.

If'n I recall right, there was some value in using QEMM's loadhigh without
any specifications, and having some things manage to load high. Like my ANSI.SYS... and just in case... don't load SHARE high, it all looks good, but isn't doing anything :)

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: A camel is a horse designed by a committee. (21:3/101)

Re: Re: EtherDFS and record locking is no-go for BBSs
By: Spectre to poindexter FORTRAN on Sun Mar 03 2024 07:34 am

Maybe there's something I'm missing, what architecture settings? I didn't

When you create a VM, there's setting for machine type under system (440bx or Q35) and under CPU you can pick the type. One of those settings might be more compatible.
--- SBBSecho 3.20-Win32
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

When you create a VM, there's setting for machine type under system (440bx or Q35) and under CPU you can pick the type. One of those settings might be more compatible.

Ponder. I don't know what I did now.. Not even sure how I created the
original VM.. just that I cloned it for all the rest. 440BX off hand is
going to be a roughly PIII Mobo, I could understand QEMM had problems with that.

Is there a way to check the settings in an active VM?

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: A camel is a horse designed by a committee. (21:3/101)