doshea wrote on 2025-08-29, 12:02:

• Use Git to manage the source code for the server I'm working on (the Git repo's .git directory wouldn't live on the DOS filesystem, instead I'd mount the DOS filesystem inside the Git repo)
• Use DOS as a development environment because it's fun

Sounds great, actually!

doshea wrote on 2025-08-29, 12:02:

NetWare Lite: ncpfs was removed from the Linux kernel some time ago.

As far as I know, NetWare Lite is not really NCP, but Personal NetWare (the sucessor of NetWare Lite that was bundled with Novell DOS 7) is. One telltale sign is that for diskless boot, you need to load an 8K TSR (BOOTNCP) on an NetWare Lite server, but just a 500 byte TSR (NEARSERV) on a Personal NetWare server. NEARSERV just responds to the "get nearest server" broadcast sent by the boot ROM first to find an NCP server that can be booted from.

doshea wrote on 2025-08-29, 12:02:

Would anyone else find this useful? What would you want to use it for?

I would definitely find this useful, and use it for the use cases you mentioned above.

mkarcher wrote on 2025-08-29, 12:24:

Sounds great, actually!

Thanks!

As far as I know, NetWare Lite is not really NCP, but Personal NetWare (the sucessor of NetWare Lite that was bundled with Novell DOS 7) is. One telltale sign is that for diskless boot, you need to load an 8K TSR (BOOTNCP) on an NetWare Lite server, but just a 500 byte TSR (NEARSERV) on a Personal NetWare server. NEARSERV just responds to the "get nearest server" broadcast sent by the boot ROM first to find an NCP server that can be booted from.

Oh wow, thanks for the info, I'm glad I didn't spend time trying that option out then - lucky ncpfs was already removed from the kernel 😁 Interesting, https://tldp.org/HOWTO/IPX-HOWTO-9.html says:

The ncpfs package will work with Novell fileservers of version 3.x and later, it will not work the Novell 2.x.

I figured NetWare 3.x and NetWare Lite were from around the same time, and I think I used ncpfs with NetWare 3.x in the past, but I suppose NetWare Lite may have been based on NetWare 2.x then.

I would definitely find this useful, and use it for the use cases you mentioned above.

Thanks for the feedback! I hope you don't mind some more questions, so I can see if I'm on the right track:

I forgot to mention that I plan for this to be a DOS server that accepts just one connection at a time, with the intent that nothing else is running on the DOS machine - it's not a TSR, but something more akin to the server for InterLink or some other serial/parallel file sharing server in my mind. To be fair I've done most of my testing with it running under DESQview - since that's my development environment - but I haven't tried to do anything like access the same file from both DOS and the Linux client. Does that sound okay? Really I just don't want to have to pass through file locking requests to DOS, at least not yet - it's probably not actually that hard, but I don't think I need it yet.

Another limitation: no Long File Name support yet, although it probably wouldn't be too hard to add.

Also, you might know something about a problem I was trying to deal with in the last few days - from my work-in-progress README:

1Character set for directory and file name encoding
2--------------------------------------------------
3
4`-o charset=NAME` may be used to request that the character
5set/encoding `NAME` be used for decoding names received from DOS and
6encoding those sent to it.
7
8The default is `cp437`.
9
10FIXME: For what cases is this suitable?  Original DOS?  US English
11DOS?  DOS without COUNTRY= or something?
12
13The Linux kernel's `msdos` filesystem has `codepage` and `iocharset`
14mount options, but these seem to be broken in recent Linux kernels.
15To get behavior equivalent to a recent Linux kernel, use
16`-o charset=ascii`.
17
18FIXME: show examples

I don't really know much about this, since I'm lucky enough that all the characters I ever cared to put in a filename were ASCII; do you have experience with using non-ASCII characters in filenames?

All I know is that I have some old Windows 98 SE installation where I found that the "sendto" folder's short file name for the shortcut for sending to floppy disk showed up as "3½flop~1.lnk" when using my client with cp437, but when I mounted the drive using the kernel's FAT support (sudo mount -t msdos ... /dev/loop0p1) it showed up as "3\#253flop~1.lnk". I was able to get the same result when I got my client to use Python's ASCII encoding with the "surrogateescape" option. My assumption is that DOS would have just displayed characters found in filenames using whatever the current character set was, and the default is CP437, so that is a sensible default for my client, but I'm not totally sure on this.

Thanks again!