vetz wrote on 2025-04-02, 08:00:

Could it be an idea to have a switch to force overwrite the interrupt location like the 3c503 packet driver does? The same bytes exist at 180-184 and they are overwritten once the packetdriver is run. It doesnt care what exist there before.

I agree that it's a bit of a *pain* having to set up/keep a debug script for things like this...

If Mike doesn't want to put an override switch into mTCP, it would be dead-easy to
write a very small program to zero out interrupt vectors you specify!
(You could also have it optionally warn if the vectors you are zeroing aren't already
zero or point into the BIOS code area)

Hi Dave:

Binaries and source code can be found at https://www.brutman.com/mTCP/mTCP.html . Right now that's redirecting to a PCjr so that I can get a little extra testing on the code, so don't be alarmed at the redirect. (The PCjr is running the web server on top of NetDrive. It has no local hard drive.)

Also, I'm a big fan of your work.

Vetz:

I'm not a big fan of stomping on existing values in memory locations; I view that as a bug in the 3C503 packet driver. I might provide a separate utility to make this kind of problem easier to diagnose, but I really don't want to make it easy for people to just force things. While you understand what is going on, others won't, and then they'll complain that their bad usage of my software crashes their machine. ;-0

mbbrutman wrote on 2025-04-02, 15:48:

Hi Dave:

Hi Mike,

Thanks - been wanting to play with a more recent one.

Also, I'm a big fan of your work.

Thanks, It has been a while since I used it, but I'd have
to also say "I'm a bit of a fan of your mTCP"

Vetz:
I'm not a big fan of stomping on existing values in memory locations...

Unfortunately when doing low-level stuff like this, you have to contend
with whatever "decisions" others have made - it would be nice if available
vectors could be indentified by 0:0 - but as we see, some other vendors
decided to "do something else". Which can confuse our users (who might not
know the low level details)

This is why a command line option might be useful. Default this to OFF
(same as now) and state in your docs that this problem may happen, and
that you might need -Force but doing so disables some protection checks
and you do so at your own risk!

--

Btw - a little "project" you might to be able to pull off fairly easily
as you're much more into TCP than I.

I tend to like "raw packet" networking - yes, they don't "route" but for
local communications over a common network I find it easier - no setup,
DHCP or any of that... just broadcase one packet to find your target,
get a directed response - then each end knows how to send to the other
directly.

But one sometimes annoying aspect is that almost all routers with both
Cables and WiFi on the "local" side - seem to do some sort of
"routing" between them - raw packets don't go between Cables and Wifi.

So something I've been planning to do "someday" is a packet driver
that instead of talking to an actual network card, talks to another
packet driver and does very simple TCP message .. just like "raw
packets", no need to detect errors/retry etc.. just pack the data
into the simplest TCP message possible.

That PD shim is activated on "NETDRIVE.EXE CONNECT", isn't it?

So that would be the right moment to do either of the following if the address is non-zero:
- use the specified INT anyway, and simply display a warning that it may already be in use
- refuse to use the specified INT, with a clear error message

If I understand it correctly, the current behavior is that "NETDRIVE.EXE CONNECT" seems to accept the specified INT, but actually doesn't.
The problem is only visible later - which is misleading.

The message now says that it couldn't setup the packet driver. I'll add some text to say why ("There is something already there but doesn't look like a packet driver.")

DaveDDS wrote on 2025-04-02, 20:55:

So something I've been planning to do "someday" is a packet driver that instead of talking to an actual network card, talks to a […]
Show full quote

So something I've been planning to do "someday" is a packet driver
that instead of talking to an actual network card, talks to another
packet driver and does very simple TCP message .. just like "raw
packets", no need to detect errors/retry etc.. just pack the data
into the simplest TCP message possible.

Oh - a relay.

You definitely don't want TCP for that, as it's a bit heavy to do in a small program and it's connection oriented. UDP would work well for that.

Grzyb wrote on 2025-04-02, 21:48:

That PD shim is activated on "NETDRIVE.EXE CONNECT", isn't it? […]
Show full quote

That PD shim is activated on "NETDRIVE.EXE CONNECT", isn't it?

So that would be the right moment to do either of the following if the address is non-zero:
- use the specified INT anyway, and simply display a warning that it may already be in use
- refuse to use the specified INT, with a clear error message

If I understand it correctly, the current behavior is that "NETDRIVE.EXE CONNECT" seems to accept the specified INT, but actually doesn't.
The problem is only visible later - which is misleading.

No, it's activated when DHCP is run successfully.

mbbrutman wrote on 2025-04-02, 21:54:

The message now says that it couldn't setup the packet driver. I'll add some text to say why ("There is something already there but doesn't look like a packet driver.")

That's nice! Hopefully with that message and this thread it will be possible for others to easier figure out what is going on.

I did some more testing, and on the Olivetti M28, it doesn't seem to matter how your boot is setup. Even a clean boot with the bare minimum still has the values filled by the BIOS. For me though as a fix I plan to run DEBUG with input scriptfile (

1debug  <script.txt

) in autoexec.bat before DHCP is called.

vetz wrote on 2025-04-02, 22:02:

No, it's activated when DHCP is run successfully.

But it doesn't make sense - there may be no DHCP at all, everything configured statically.

Grzyb wrote on 2025-04-02, 22:07:

vetz wrote on 2025-04-02, 22:02:

No, it's activated when DHCP is run successfully.

But it doesn't make sense - there may be no DHCP at all, everything configured statically.

Sorry, what I meant is that when you run DHCP there is a check to see if the INT is available, but it's actually utilized (memory updated) when Netdrive is launched. For static config I'd guess the packetdriver error you get in DHCP would be shown in netdrive.

Ah, OK, I think I already got it...

DHCP.EXE only uses the real PD INT, but also checks the secondary INT, and displays the error if the secondary seems in use.
NETDRIVE.EXE CONNECT is when the secondary INT gets activated.

The flow is basically this:

• If there is only one software interrupt specified, everything uses it.
• If there is a second software interrupt specified the programs will try to use it.
  • If it specified but not in use that means NetDrive didn't install it's shim packet driver. When that happens programs fall back to using the first listed software interrupt.
  • If it is specified, and in use, the programs check to see if it is a packet driver. If that fails they just stop. (Which is what happened here.)

This makes it easy for a program to get to the real packet driver if that is needed; just disconnect NetDrive if it is connected.

If the message is made more verbose this will be easier to detect and work around.

It's not just a DHCP thing either. DHCP is normally just what runs first. All of the programs have this logic in them.

mbbrutman wrote on 2025-04-02, 21:56:

Oh - a relay.
You definitely don't want TCP for that, as it's a bit heavy to do in a small program and it's connection oriented. UDP would work well for that.

Yes.. thank you - It's been so long since I looked at this stuff, I couldn't remember exactly what it was called.
I did write a TFTP at one time, and IIRC it did use UDP.

That's what I was trying to get at with "super simple", "no error detection/retries" just base transport in what I
tend to think of as TCP frames. - just enough so that it could cross the WiFi<>Cables bridge in the router.

Hola @mbbrutman .. I'll be bold and suggest another improvement that will help with the session expiry thing. I may have mentioned it before in another forum:
Make sure the '-ro' flag is passed to the server, and then the server enforces read-only. It can then allow multiple connections to the same image, as long as all of them are read-only. Any client trying to do a read-write mount should, of course, fail. This would make at least my life a lot easier..

Optionally, for those of us who have the server far away and out of reach, an option to forcefully disconnect other clients would be handy. It would need to be enabled in the server (disabled by default), and the evil bit must not be set. ;)

Last request - stretch goal, I'm going overboard here ;) : If the image is modified server-side, the netdrive server could signal the (read-only) client that it needs to flush its FAT cache. This would be similar to the RESCAN command in dosbox. I don't even know if this is possible..? And it would only be "safe" if on a DOS prompt, I presume.

Take care,
/Eirik

Hi,

Passing the -ro flag to the server is fine to express the intent to not allow writes on the client side, but that begs the question - should the server believe it? If you intend to have an image be read-only, then the proper way to handle that is just to mark it read-only on the server side. What you are asking for is basically to have the server mark images as read-only dynamically if all of the clients are read-only, but it's not worth the effort to deal with corner cases. Just declare it read only and move on ...

I'm trying to work out in my head how to change an image on the server side and notify the DOS side safely, but I don't see a good path to doing so. I can send the asynchronous notification to the DOS side; that's not a problem. If DOS is only doing reads the media changed flag will work, at least on the later versions of DOS. But I'm also kind of paranoid about dirty buffers and corruption, and if anything gets added it has to be able to keep people from shooting themselves in the foot.

Doing the media change thing also isn't fool proof - it basically screws any program that has files open. They need to know to reopen the files again. This goes for TSRs to, so even detecting you are at a DOS prompt is not safe enough.

Looking at the bigger picture ...

This is a block level device. DOS manages the blocks, chooses when to flush dirty buffers, chooses the caching policy, etc. Having something else reaching in and changing the blocks is just not something any operating system is designed to handle. The analogy is having a SATA hard drive with two connectors going to two different machines, each able to touch the same areas of the disk.

For the kinds of access you are looking for you really want filesystem level sharing, where DOS can read files but it can't assume complete ownership of the blocks. That's where things like NFS, SMB, and EtherDFS come in. There is also a new program called NETMOUNT that was announced on the FreeDOS facebook page that looks promising; it looks like EtherDFS but it's done using IP and UDP.

(Note: I don't use Facebook. Ever.)

mbbrutman wrote on 2025-04-03, 16:50:

Passing the -ro flag to the server is fine to express the intent to not allow writes on the client side, but that begs the question - should the server believe it? If you intend to have an image be read-only, then the proper way to handle that is just to mark it read-only on the server side. What you are asking for is basically to have the server mark images as read-only dynamically if all of the clients are read-only, but it's not worth the effort to deal with corner cases. Just declare it read only and move on ...

I can think of cases were you might want to mount an image ReadOnly and have the server know, without
actually making the image ReadOnly thereafter (and not having to rely on the server
switching it back)

The server shouldn't allow any other connections to an image mounted Read/Write (unless it implements a
lot more of the filesystem than just passing on block requests) ... but it should allow multiple mounts ReadOnly,
and should block requests to mount ReadWrite if there are ReadOnly mounts.

This is of course assuming the mounted images are maintained as open files
(not closed between file accesses) - the local access as described above (allow only one
write and multiple reads).

If we are talking general mounts to drives- if get trickier. The server would at at least have to
set to OS status of the drive to ReadOnly/ReadWtite to protect against local access... (but it can
certainly make the above restrictions on network clients).

I'm not aware of any reasonable way to notify a DOS application that something "else" has
modified the drive - The only real thing you can do is prevent it - it's been years, but IIRC Microsoft
InterLink (Share a drive DOS<>DOS ran the server without letting other local
DOS stuff run for exactly this reason).
If you think about it - on "normal" OSs (like DOS) the only way for one application
to arbitrarily write to a file opened by another is to do direct sector I/O, bypassing the
filesystem alltoghether)

To do these kinds of things, you really need to implement a full network file system (so
you can access files remotely as files) not just a block drive share..

mbbrutman wrote on 2025-04-03, 16:50:

Hi,

Passing the -ro flag to the server is fine to express the intent to not allow writes on the client side, but that begs the question - should the server believe it? If you intend to have an image be read-only, then the proper way to handle that is just to mark it read-only on the server side. What you are asking for is basically to have the server mark images as read-only dynamically if all of the clients are read-only, but it's not worth the effort to deal with corner cases. Just declare it read only and move on ...

Uhm, I think that's what I said, or wasn't it? :D The basic expectation is that if the client passes -ro, the server enforces read-only. So if the client says so, then the server should not ever accept writes anyway. And if a client connects read-only, there's no reason to not allow a second, or third, or N connections from clients that also request read-only mounts. And if a client requests a write-mount, reject it (as is currently done).

I'm not asking for anything dynamic, so I'm not sure where I've been unclear about that..

mbbrutman wrote on 2025-04-03, 16:50:

I'm trying to work out in my head how to change an image on the server side and notify the DOS side safely, but I don't see a good path to doing so. I can send the asynchronous notification to the DOS side; that's not a problem. If DOS is only doing reads the media changed flag will work, at least on the later versions of DOS. But I'm also kind of paranoid about dirty buffers and corruption, and if anything gets added it has to be able to keep people from shooting themselves in the foot.

Doing the media change thing also isn't fool proof - it basically screws any program that has files open. They need to know to reopen the files again. This goes for TSRs to, so even detecting you are at a DOS prompt is not safe enough.

Kinda thought this would be the case. The fancypants over at Novell and Microsoft and IBM have locking mechanisms for this, so I think this is a pipe dream.

mbbrutman wrote on 2025-04-03, 16:50:

Looking at the bigger picture ...

This is a block level device. DOS manages the blocks, chooses when to flush dirty buffers, chooses the caching policy, etc. Having something else reaching in and changing the blocks is just not something any operating system is designed to handle. The analogy is having a SATA hard drive with two connectors going to two different machines, each able to touch the same areas of the disk.

Yep, I know. Split-brain is always fun to deal with.

mbbrutman wrote on 2025-04-03, 16:50:

For the kinds of access you are looking for you really want filesystem level sharing, where DOS can read files but it can't assume complete ownership of the blocks. That's where things like NFS, SMB, and EtherDFS come in. There is also a new program called NETMOUNT that was announced on the FreeDOS facebook page that looks promising; it looks like EtherDFS but it's done using IP and UDP.

(Note: I don't use Facebook. Ever.)

I'll see if I can find netmount, whatever that is. I also never touch facebook, so it'll have to crop up somewhere else on the 'net before I'll find it..

/Eirik

ltning wrote on 2025-04-03, 20:43:

mbbrutman wrote on 2025-04-03, 16:50:

For the kinds of access you are looking for you really want filesystem level sharing, where DOS can read files but it can't assume complete ownership of the blocks. That's where things like NFS, SMB, and EtherDFS come in. There is also a new program called NETMOUNT that was announced on the FreeDOS facebook page that looks promising; it looks like EtherDFS but it's done using IP and UDP.

(Note: I don't use Facebook. Ever.)

I'll see if I can find netmount, whatever that is. I also never touch facebook, so it'll have to crop up somewhere else on the 'net before I'll find it..

NetMount can be found here: https://github.com/jrohel/NetMount

Yoghoo wrote on 2025-04-03, 21:38:

NetMount can be found here: https://github.com/jrohel/NetMount

Cool! Just submitted my first pull request ;)

Grzyb wrote on 2025-03-31, 18:08:

Can't NETDRIVE.SYS provide its PD emulation at the same interrupt number as the real PD?

That's how my version works. See this.

_Krille_ wrote on 2025-04-06, 14:42:

Grzyb wrote on 2025-03-31, 18:08:

Can't NETDRIVE.SYS provide its PD emulation at the same interrupt number as the real PD?

That's how my version works. See this.

So with your version I’ll be able to mount a drive plus play IPX network games like Command & Conquer at the same time? That would be awesome.

Is there another way to download it? Vcfed wants a username and password 🙁