Um, isn't FTP considered insecure and obsolete? 😕
It's also very primitive. Browsers dropped support for it nearly a decade ago.
If speed is not a problem, just use a nullmodem connection.
Here are some DOS utilities that provide network drives via serial:
Re: 386 , what can I do with it?

Anyway, I think another problem might be that FTP usually requires a copy operation.
Other types of networks/network drives can read files partially, without the need for complete file transfer.

For example, let's take an 500 MB MPEG file.
FTP would require a complete local copy for playback, while NETBIOS/Novell IPX+SPX/NFS/LAN Manager etc. drives allow streaming parts of the file.

Edit: Just double-checked. FTP does not support multiple concurrent file transfers per connection, apparently.

Here's an interesting FTP client.
Re: Connecting DOS Machine to LAN

Also found FTP Drive, for Win XP+.
http://www.killprog.com/fdrve.html

Hm. Maybe some commercial software such as Desqview/X, PC/TCP or Novell Netware had some FTP tools? 🤷‍♂️

Edit: FreeDOS has some networking guide.
http://wiki.freedos.org/wiki/index.php/Networ … e_TCP-IP_Kernel

Jo22 wrote on 2022-09-25, 06:30:

Anyway, I think another problem might be that FTP usually requires a copy operation.
Other types of networks/network drives can read files partially, without the need for complete file transfer.

The copy operation could just be to a buffer in RAM rather than to disk, and I imagine that with FTP one could do a partial read by using the REST command and then closing the transfer connection once you've got the data you want, but it might be pretty inefficient compared to a protocol designed for random access that doesn't require you to establish a new connection for each transfer. Sometimes convenience is more important than efficiency though.

Edit: Just double-checked. FTP does not support multiple concurrent file transfers per connection, apparently.

A client could establish multiple connections, or alternatively maybe it could just not keep more than one file open at a time.

On the other hand, I used some "nice" FTP clients in Windows 95 that integrated with Windows Explorer but they never worked properly like NcFTP did (a console-mode port of a *nix tool). FTP is a hard protocol to get "right" because there are so many different servers that don't behave the same, and I think the developers that spent time putting nice GUIs on their clients didn't spend the time to get the protocol right, so if there are any DOS clients that present the FTP server as a drive letter, I wouldn't get my hopes up that they work very well.

Jo22 wrote on 2022-09-25, 06:59:

Hm. Maybe some commercial software such as Desqview/X, PC/TCP or Novell Netware had some FTP tools? 🤷‍♂️

Novell LAN WorkPlace certainly includes an FTP client but not one that works as a TSR - its just the usual sort of FTP client same as you'd get with other DOS packages.

keenmaster486 wrote on 2022-09-24, 20:25:

Does anyone know if there exists an FTP client for DOS that installs itself as a network drive?

I am aware that there are other more established ways to do this. Right now I am asking about FTP.

While I'm sure you could probably build an FTP client that ran as a TSR and presented itself as a network drive under DOS I'd be surprised if it would be possible to make it work well enough to be practical given the way FTP works. My guess is no one has ever bothered given there is already a selection of off-the-shelf solutions that will work better than any hypothetical FTP TSR ever could (EtherDFS, NetWare/Mars NWE, various NFS options, SMB).

Is there some unusual problem you're trying to solve? Or are you just after a network drive and hoping you can get away with your existing FTP server rather than setting up something extra?

davidrg wrote on 2022-09-25, 23:48:

Or are you just after a network drive and hoping you can get away with your existing FTP server rather than setting up something extra?

Bingo lol

It doesn't look like there's really something out there that does what I want. I'll probably have to use some other solution.

One possibility is to have an intermediate machine which translates protocols, e.g. a Linux machine which mounts the desired FTP server(s) (see e.g. https://en.wikipedia.org/wiki/FTPFS) and then re-exports them to the DOS machine via a protocol it does have a client for (e.g. EtherDFS, Mars NWE so you can use the NetWare client, Samba so you can use MS Client).

Jo22 wrote on 2022-09-25, 06:30:

Um, isn't FTP considered insecure and obsolete? :confused: It's also very primitive. Browsers dropped support for it nearly a de […]
Show full quote

Um, isn't FTP considered insecure and obsolete? 😕
It's also very primitive. Browsers dropped support for it nearly a decade ago.
If speed is not a problem, just use a nullmodem connection.
Here are some DOS utilities that provide network drives via serial:
Re: 386 , what can I do with it?

Anyway, I think another problem might be that FTP usually requires a copy operation.
Other types of networks/network drives can read files partially, without the need for complete file transfer.

For example, let's take an 500 MB MPEG file.
FTP would require a complete local copy for playback, while NETBIOS/Novell IPX+SPX/NFS/LAN Manager etc. drives allow streaming parts of the file.

Edit: Just double-checked. FTP does not support multiple concurrent file transfers per connection, apparently.

You should be quite thankful that FTP, and its quirkiness of using separate per-file data connections in addition to the control connection, existed. If not, a carrier-grade NAT-like setup (outgoing connections only) would have been forced by all residential ISPs long ago. FTP's existence would have made the tech support calls resulting from this, especially in the late 90s when active-mode FTP also needed to work, impractical.

There was a thread about retroprogramming on here a while back. It could be an interesting task for someone to design a UDP-based (for simplicity) network drive protocol that makes the DOS TSR side as small and simple as possible.

As far as other solutions go, EtherDFS is almost certainly the simplest and easiest though I've heard it doesn't like encountering long filenames. Mars NWE (I have some setup notes) may be worth considering too as the NetWare client is quite robust and available for more than just DOS. I wouldn't bother looking at the MS Client - it uses an absurd amount of conventional memory compared to the other two options.

Quick summary of conventional memory requirements for DOS network drive options I've looked at:

• EtherDFS: 8K conventional memory (can be loaded high) plus whatever your packet driver needs
• Microsoft Client, Basic: 123KB (22KB of which can be loaded high) excluding your NDIS driver. This configuration is probably not very useful as it can't really talk to anything modern.
• Microsoft Client, Full: 211KB (38KB of which can be loaded high) excluding your NDIS driver
• NetWare Client32, default configuration: 4K (all of which can be loaded high) including your 32bit ODI driver (regardless of NIC) and optional resident TCP/IP stack.
• NetWare Client32, using a 16bit ODI driver: 22K (all of which can be loaded high) including the optional resident TCP/IP stack but not including the 16bit ODI driver itself (requirements will vary based on driver)
• NetWare VLM client, default configuration: 73K (63K of which can be loaded high) plus whatever your 16bit ODI driver needs.
• NetWare VLM client, minimal configuration: 50K (all of which can be loaded high) plus whatever your 16bit ODI driver needs.
• NetWare NETX client: 69K (21K of which can be loaded high) plus whatever your 16bit ODI driver needs. This client is ancient and not recommended except on an 8086/8088 or MS-DOS 3.0
• B&W NFS Client from Novell LAN WorkPlace 5.0: The NFS bits need 49K of conventional memory. When run on top of the 16bit VLM stack, the TCP/IP TSR needs 28K. Unsure what, if any, of it can be loaded high.

Requirements are:

• EtherDFS needs at least DOS 5.0+ and an 8086 or 8088 CPU plus a packet driver
• Microsoft Client: Not sure but apparently it works on DOS 3.3+ on an 8086 or 8088
• Novell Client32 needs a 386 or better, 4MB RAM, DOS 5.0+ and a memory manager (HIMEM, EMM386). It can use either 32bit or 16bit ODI drivers (16bit requires more conventional memory)
• Novell VLM client needs a 286 or better and DOS 3.1+. I've heard it may also work on an NEC V20. 16bit ODI driver required, or perhaps an NDIS or packet driver via shims.
• Novell NETX needs at least DOS 3.0 and an 8086 or 8088. Apparently there are older versions for DOS 2.x but I've never seen or tried these before. 16bit ODI driver required, or perhaps an NDIS or packet driver via shims.
• B&W NFS Client: 386 or better, 4MB RAM, DOS 3.3+ (requirements for LAN WorkPlace 5.0)

The basic MS Net client can talk to anything the full one can. I'm able to use it to map shares on 95/98/NT/XP, even win 10

It's also not as heavy as you say, only using about 58k of conventional for me

This is the MS Client 3.0 mind, not LANMAN

Might depend on how large the particular NDIS driver is - perhaps with a smaller driver more of the MS Client could fit into upper memory though that would still be taking memory that could have been allocated to other TSRs.

Total memory use for the basic redirector below the 1MB line when I gave it a go in a clean DOS VM was 123KB excluding NWLINK (which adds 10K) and the NDIS driver (PCnet, adds 27K). So total memory consumption was 150K of which 49K loaded high leaving only 46K of upper memory for other TSRs, and 516K of conventional memory for software. Pretty heavy, though I guess it can be slimmed down by about 65K by running it over IPX instead of TCP/IP. It would still be using 54K more RAM than Client32 and 50K more than EtherDFS though.

1Modules using memory below 1 MB:
2
3  Name           Total       =   Conventional   +   Upper Memory
4  --------  ----------------   ----------------   ----------------
5  MSDOS       16,733   (16K)     16,733   (16K)          0    (0K)
6  HIMEM        1,120    (1K)      1,120    (1K)          0    (0K)
7  EMM386       4,144    (4K)      4,144    (4K)          0    (0K)
8  IFSHLP       3,968    (4K)      3,968    (4K)          0    (0K)
9  COMMAND      2,928    (3K)      2,928    (3K)          0    (0K)
10  NWLINK      10,144   (10K)     10,144   (10K)          0    (0K)
11  PROTMAN      2,560    (3K)      2,560    (3K)          0    (0K)
12  UMB            960    (1K)        272    (0K)        688    (1K)
13  TCPTSR      76,784   (75K)     76,784   (75K)          0    (0K)
14  TINYRFC     18,496   (18K)        272    (0K)     18,224   (18K)
15  NMTSR        6,160    (6K)      6,160    (6K)          0    (0K)
16  BASIC       13,760   (13K)     13,760   (13K)          0    (0K)
17  PROTMAN        400    (0K)          0    (0K)        400    (0K)
18  PCNTND      27,968   (27K)          0    (0K)     27,968   (27K)
19  NDISHLP      1,440    (1K)          0    (0K)      1,440    (1K)
20  TCPDRV       1,328    (1K)          0    (0K)      1,328    (1K)
21  NEMM           672    (1K)          0    (0K)        672    (1K)
22  Free       562,832  (550K)    516,432  (504K)     46,400   (45K)
23
24Memory Summary:
25
26  Type of Memory       Total   =    Used    +    Free
27  ----------------  ----------   ----------   ----------
28  Conventional         655,360      138,928      516,432
29  Upper                 97,120       50,720       46,400
30  Reserved             393,216      393,216            0
31  Extended (XMS)    32,408,736      275,616   32,133,120
32  ----------------  ----------   ----------   ----------
33  Total memory      33,554,432      858,480   32,695,952
34
35  Total under 1 MB     752,480      189,648      562,832
36
37  Largest executable program size        516,336   (504K)
38  Largest free upper memory block         46,400    (45K)
39  MS-DOS is resident in the high memory area.

jakethompson1 wrote on 2022-09-26, 01:01:

[..]
You should be quite thankful that FTP, and its quirkiness of using separate per-file data connections in addition to the control connection, existed.

Hm. I don't know. I always felt kind of sad that X.25 was effectively replaced by TCP/IP. 🙁
If we hadn't have had FTP and TCP/IP, the digital world would have been different perhaps, but also the same. E-mail also existed in the form of X.400, for example.

You were much more helpful 4 years ago :PPPPPP Re: Mount an FTP share as drive in DOS

Jo22 wrote on 2022-09-25, 06:30:

Um, isn't FTP considered insecure and obsolete? 😕
It's also very primitive. Browsers dropped support for it nearly a decade ago.

thats what they (google) want you to think. Just like they (google) killed ability to load local resources (files from your own effing hard drive). Now you need to spin localhost server ...

Jo22 wrote on 2022-09-25, 06:30:

Anyway, I think another problem might be that FTP usually requires a copy operation.

it does https://www.rfc-editor.org/rfc/rfc3659.html#page-13 Works exactly like http range headers.

Jo22 wrote on 2022-09-25, 06:30:

Edit: Just double-checked. FTP does not support multiple concurrent file transfers per connection, apparently.

Doesnt matter, nothing stops your client from making multiple connections simultaneously.

I used FTP Drive for a while on windows http://www.killprog.com/fdrve.html and it worked pretty smooth, so the concept is sound. Main attraction is no need to enable all obsolete insecure SMB quirks to allow older windows to see modern shares. There is also https://www.ferrobackup.com/map-ftp-as-disk.html, never used this one.

rasz_pl wrote on 2022-09-29, 14:32:

You were much more helpful 4 years ago :PPPPPP Re: Mount an FTP share as drive in DOS

+1

I really was, yes. I noticed that, too. Sorry. I assume it's related to stress, lack of concentration or psychological issues, not quite sure. 🤷‍♂️
I think my English went down hill, too in the past years. It's no longer as eloquent, as it once was. I need more practice again (I'm a non-native Speaker). 🙂

Edit: The AppleTalk/LocalTalk workaround was my favorite 4 years ago.
It was fun having Windows 3.1/WfW and Mac OS in same network. ^^

Edit: Here's some one's blog entry about this weird adventure. Also mentions drivers for DOS.
It's really fascinating seeing different OSes interacting with each other in obscure networks.