Downloading files with multi-dot / long names (e.g. apack-1.00.zip) no longer fails. The local target is now mapped to a valid DOS 8.3 name (e.g. APACK-1~1.ZIP) instead of failing to create the file. Applies to both the F5 single-file download and batch copy.
Ctrl+C now works as a shortcut for "compare panels" (the numpad + action).
Date and Time sorting merged into one "Date/Time" criterion.
Oh, and I've found that "Compare directories" is under Gray+ , which is a serious discrepancy from other NC-alikes.
No shortcut in the original NC, but it's Ctrl-C in Volkov Commander.
Pretty sure it's numpad-+ also in original nc, but let me check that again.
Numpad+ a.k.a. Gray+ is for selecting files according to a mask.
It's been like this for 40 years - it's already there in the NC 1.00 from 1986, and it's there in pretty much every NC-clone.
It's very confusing to suddenly find under such an important key a completely different function...
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
My case is the opposite. Using mFTP I'm able to download at 200 KB/s but with FTP4DOS my speed is 10 KB/s. Same FTP site, same file.
My network chip is an Atheros AR8132. It's possible to get more speed with FTP4DOS?
My case is the opposite. Using mFTP I'm able to download at 200 KB/s but with FTP4DOS my speed is 10 KB/s. Same FTP site, same file.
My network chip is an Atheros AR8132. It's possible to get more speed with FTP4DOS?
Well, I would suggest replacing the PD with NDIS+DIS_PKT or ODI+ODIPKT, but for such a modern chip it may be impossible to find *any* good driver for DOS...
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
My case is the opposite. Using mFTP I'm able to download at 200 KB/s but with FTP4DOS my speed is 10 KB/s. Same FTP site, same file.
My network chip is an Atheros AR8132. It's possible to get more speed with FTP4DOS?
I can't help about FTP4DOS, but it may be possible to improve the speed in mTCP FTP client...
See the conclusions at the end of this thread - Quality of packet drivers: Intel
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
It would be great if you could implement Unicode support for file names in FTP, converting them to the current DOS code page for correct display in panels and saving files to your computer non-latin filenames.
It would also be great if you could convert the current code page to Unicode when uploading files from your computer to FTP.
A similar open-source FTP2P program already has this functionality.
My case is the opposite. Using mFTP I'm able to download at 200 KB/s but with FTP4DOS my speed is 10 KB/s. Same FTP site, same file.
My network chip is an Atheros AR8132. It's possible to get more speed with FTP4DOS?
I can't help about FTP4DOS, but it may be possible to improve the speed in mTCP FTP client...
See the conclusions at the end of this thread - Quality of packet drivers: Intel
For those of you who want the quick answer, the buffer sizes chosen for the TCP receive buffer and the file write buffer can have a much larger impact on faster machines. If you have a faster machine (Pentium or better) you might want to run some experiments to see if you can get faster performance by changing two values in the mTCP configuration file.
It's probably better to reference that as a dependency or fork it and add your files to the fork. That way you can see when mTCP changes and update accordingly.
For those of you who want the quick answer, the buffer sizes chosen for the TCP receive buffer and the file write buffer can have a much larger impact on faster machines. If you have a faster machine (Pentium or better) you might want to run some experiments to see if you can get faster performance by changing two values in the mTCP configuration file.
I'm using the same configuration file for FTP4DOS, FTP utility from MTCP and Links web browser: MTCP.CFG
1DHCPVER DHCP Client version Jan 10 2025 2TIMESTAMP ( 1760930237 ) Sun Oct 19 23:17:17 2025 3 4# This is a sample mTCP configuration file. These lines are comments. 5# Uncomment options that you want to turn use. 6# 7# Please read the PDF documentation for the full details on how to 8# use this file. 9 10 11# Settings for my machine 12# 13# Be sure to load your packet driver first. My packet driver lives 14# at software interupt 0x60. 15# 16packetint 0x60 17 18 19# Standard MTU is 576 and should be safe for any Ethernet. 20# MTU for SLIP and PPP might be even smaller. 1500 is the max 21# and works well for LANs and broadband access. Uncomment this 22# if you can and get better performance. 23# 24mtu 1500 25 26 27# Be sure to pick a good hostname! 28hostname MyDOSMachine 29 30 31# IRCjr options. The first three are required and the rest are optional. 32# 33ircjr_nick Zoidberg 34ircjr_user JZoidberg 35ircjr_name John F Zoidberg 36 37#ircjr_pass secretGoesHere 38#ircjr_connect_timeout 45 39#ircjr_register_timeout 60 40#ircjr_backscroll 300 41#ircjr_backscroll_chat 75 42#ircjr_backscroll_server 100 43#ircjr_color_scheme cga_mono 44#ircjr_timestamps on 45#ircjr_logging_default on 46#ircjr_log_dir e:\data\irclogs\ 47#ircjr_nick_updates server 48#ircjr_quit_updates server 49 50 51# FTP options to play with 52# 53ftp_connect_timeout 10 54# 55#Set these for even better performance 56# 57ftp_tcp_buffer 16384 58ftp_file_buffer 32768 59# 60#
…Show last 51 lines
61#Set this if you are doing mget and mput with lots of files 62# 63#ftp_mlist_buffer 8192 64 65 66# Telnet options 67# 68#telnet_virtbuffer_pages 8 69#telnet_connect_timeout 20 70#telnet_autowrap 1 71#telnet_sendbsasdel 1 72#telnet_termtype pcansi 73#telnet_send_newline auto 74 75 76# FTP Server parms 77# 78# Required parameters 79# 80#ftpsrv_password_file c:\ftppass.txt 81# 82# 83# Optional parameters 84# 85#ftpsrv_log_file c:\ftpsrv.log 86#ftpsrv_motd_file c:\ftpmotd.txt 87#ftpsrv_session_timeout 120 88#ftpsrv_ext_ipaddr some.ip.addr.here 89#ftpsrv_control_port 21 90#ftpsrv_pasv_base 2048 91#ftpsrv_pasv_ports 1024 92#ftpsrv_clients 10 93#ftpsrv_filebuffer_size 16 94#ftpsrv_tcpbuffer_size 16 95#ftpsrv_packets_per_poll 2 96#ftpsrv_exclude_drives AB 97 98 99 100# DHCP generated settings will appear here. If you are using DHCP 101# then these will be updated automatically by the DHCP client (dhcp.exe). 102# You can use the same lines to do a STATIC network setup; just alter 103# them and don't run the DHCP client 104# 105#LEASE_TIME 3600 106IPADDR 192.168.1.102 107NETMASK 255.255.255.0 108GATEWAY 192.168.1.1 109NAMESERVER 192.168.1.1 110#LEASE_TIME 3600
My speeds are:
FTP4DOS 10 KB/s, FTP from MTCP 200 KB/s, Links web browser 40 KB/s. With Total Commander in Windows 3.1 and using Trumpet Winsock I get around 20 KB/s.
Maybe could be something CPU related? With FTP4DOS the CPU fan spins at max speed when I start downloading. With the FTP utility from MTCP the fan spins at normal speed during download.
My computer is an Intel Atom N280, 1 GB of RAM and Atheros AR8132. I'm using MS-DOS 6.22.
Looks wrong to me - for my Pentium III 800, the optimal setting is:
FTP_FILE_BUFFER 2048
But you may need to do your own experiments to find the optimal values of FTP_TCP_BUFFER and FTP_FILE_BUFFER for your hardware.
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
On an older system with a slower disk the larger ftp_file_buffer size is a good thing, as disk writes are relatively expensive on older machines.
FTP4DOS hard coded those configuration settings, so you are stuck with that speed until something gets changed in the program. (The current code is probably doing 1400 byte writes and at most it can write 4KB.)
Looks wrong to me - for my Pentium III 800, the optimal setting is:
FTP_FILE_BUFFER 2048
But you may need to do your own experiments to find the optimal values of FTP_TCP_BUFFER and FTP_FILE_BUFFER for your hardware.
I have tested this on an even newer PC (i7-4770K + integrated Intel I217-V + Sandisk SSD) and with FTP_FILE_BUFFER 2048 and default FTP_TCP_BUFFER I got 980 KB/sec with a 30 MB copy. When I changed FTP_FILE_BUFFER to 32768 and FTP_TCP_BUFFER to 16384 I got 2800 KB/sec. Both cases were tested with FTP2P.
So it seems this is not simply as slower PC/faster PC difference and it is not true that smaller FTP_FILE_BUFFER sizes are always better on faster PC.
Can you also measure the speed of downloading a large file to NUL, using the CLI FTP client?
Are you using native PD, or NDIS/ODI with some shim?
Anyway, it seems that big speed difference between download to NUL and to disk asks for experiments to find the optimal combination of FTP_TCP_BUFFER and FTP_FILE_BUFFER.
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
Grzybwrote on 2026-06-30, 17:30:Can you also measure the speed of downloading a large file to NUL, using the CLI FTP client?
Are you using native PD, or NDIS/OD […] Show full quote
Can you also measure the speed of downloading a large file to NUL, using the CLI FTP client?
Are you using native PD, or NDIS/ODI with some shim?
Anyway, it seems that big speed difference between download to NUL and to disk asks for experiments to find the optimal combination of FTP_TCP_BUFFER and FTP_FILE_BUFFER.
It's rather counterintuitive but downloading to NUL, or to a RAMDRIVE results in almost exactly the same results (a few KB/sec faster but within 5%). So it seems the bottleneck in my case is not the storage system.
I use the NDIS2 driver e1000.dos with dis_pkt.dos. I have not found working native packet driver for this integrated NIC.
It's rather counterintuitive but downloading to NUL, or to a RAMDRIVE results in almost exactly the same results (a few KB/sec faster but within 5%). So it seems the bottleneck in my case is not the storage system.
I use the NDIS2 driver e1000.dos with dis_pkt.dos. I have not found working native packet driver for this integrated NIC.
Looks like we can safely blame it on poor quality of the driver, common for DOS drivers for such a new hardware.
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
Faster transfers + tunable buffers
@mbbrutman: You're right: FTP4DOS was doing small per-packet disk writes (~1.4 KB each). Downloads now collect data in a dedicated file buffer and write to disk in large blocks, and both sizes are configurable in your mTCP configuration file — same idea as in the mTCP FTP client:
The mTCP FTP client's FTP_TCP_BUFFER / FTP_FILE_BUFFER are read as fallbacks, so if you already tuned your MTCP.CFG (TCP_BUFFER, FILE_BUFFER without the FTP4DOS prefix), it just works in FTP4DOS too. This is advanced stuff and totally optional — the defaults are fine out of the box. But @ntalaec, I'd be curious whether this fixes the 10 KB/s you were seeing on the AR8132.
UTF-8 file names (@fly_indiz)
File names from modern servers (RFC 2640) are now converted to the active DOS codepage (CP437, CP850/858, CP866 — override with FTP4DOS_CODEPAGE) for the panel display and for local file names. Uploads to servers that announce UTF8 in FEAT are encoded back to UTF-8 (OPTS UTF8 ON). Tested with umlauts and Cyrillic names against pyftpdlib.
Long file names (LFN) in the local panel
On systems with an LFN API (Windows 9x DOS, MS-DOS 7.x, or DOSLFN on plain DOS) the local panel now lists and handles long names natively.
mTCP as a git submodule
@mbbrutman: done — the project now references your official GitHub repo as a submodule, pinned to the 2025-01-10 release tag, instead of carrying an unpacked source zip. Thanks for putting it up!
As always: GPLv3, source on GitHub, the release includes the exact mTCP sources as a separate zip.
UTF-8 file names (@fly_indiz)
File names from modern servers (RFC 2640) are now converted to the active DOS codepage (CP437, CP850/858, CP866 — override with FTP4DOS_CODEPAGE) for the panel display and for local file names. Uploads to servers that announce UTF8 in FEAT are encoded back to UTF-8 (OPTS UTF8 ON). Tested with umlauts and Cyrillic names against pyftpdlib.
This is amazing!
Localized names in the file and folder lists in the panel are now displayed correctly!
But if you open a folder with a localized name, the path to the folder you're in is shown at the top of the panel, and the name is displayed incorrectly.
Long file names (LFN) in the local panel
On systems with an LFN API (Windows 9x DOS, MS-DOS 7.x, or DOSLFN on plain DOS) the local panel now lists and handles long names natively.
My system: DOS 7.1 with DOSLFN 4.2
Dos Navigador - correct displayed LFN, but FTP4DOS 0.9.6 no 🙁
