Projanglez wrote on 2026-07-09, 23:15:

FTP4DOS v0.9.6 released — Once more, thanks to everyone for your feedback! […]
Show full quote

FTP4DOS v0.9.6 released — Once more, thanks to everyone for your feedback!

Download v0.9.6

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:

Copy code to clipboard

1FTP4DOS_TCP_BUFFER 16384     (512-16384, default 16384)
2FTP4DOS_FILE_BUFFER 32768    (512-32768, default 8192)

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.

Thanks!

There is a blank space using "full" mode (see attached image). Could be used to show more characters of the files?
It's possible to add a command line switch to show site manager at start?

On real hardware:
- Download speed has been improved since v0.9.5 but it's inconsistent. Starts at more than 100 KB/s, drops to zero, continues to 100 KB/s or so, drops to zero and so on. The disk activity shows pauses during download. The average it's better than v0.9.5 (20 KB/s vs 50 KB/s).
- Cancel a transfer leaves the download dialog on screen for about 10 seconds without any disk activity.
- After a few minutes connected to a server, I get a "PASV refused (257)" message and I get disconnect from server. No matter if I have downloaded a file a few seconds ago. Refresh does not reconnect, I have to disconnect and connect again.

FTP4DOS 1.0.0 is out — the official full and stable release:
https://github.com/Projanglez/FTP4DOS/releases/tag/v1.0.0

This release is almost entirely driven by your feedback on v0.9.6 — thanks fly_indiz and ntalaec! Everything below was verified in VMs (MS-DOS 6.22, and MS-DOS 7.1 + DOSLFN 4.2) and on my real 386 with a genuine LAN card.

UTF-8 localized filenames display correctly in file lists but incorrectly in folder path headers (thanks fly_indiz):
Fixed — the remote path in the pane header is now codepage-converted like the file lists already were.

Long filenames not displaying correctly on DOS 7.1 with DOSLFN 4.2. (thanks fly_indiz):
You found a real can of worms there — the LFN support had only ever been tested on plain DOS. Three separate bugs: detection used an undocumented probe that only Windows 9x answers (now it's the documented Get Volume Information call), the find-data record layout and attribute mask were wrong (garbage names, missing directories), and file operations didn't actually go through the LFN API. All rewritten and tested on DOS 7.1 + DOSLFN 4.2: you can now enter long-named directories, view/copy/delete/rename long-named files, download to long names and create long-named directories.

Support for the MS Network Client 3.0 TCP/IP stack? (fly_indiz)
Not in this release, sorry — FTP4DOS is built directly on mTCP, so a second TCP/IP backend would be a big undertaking. But there's a practical route: keep your NDIS2 driver and load Joe Doupnik's DIS_PKT shim on top of it — that exposes a packet-driver interface mTCP (and thus FTP4DOS) can use, so both stacks can even coexist. Happy to help with the CONFIG.SYS/PROTOCOL.INI details in the thread if you want to try.

Download speeds fluctuate between 100+ KB/s and zero, with disk activity pauses (thanks ntalaec):
Found and fixed — the big buffered disk writes (new in 0.9.6) were blocking the packet driver long enough to lose frames, so the server backed off into retransmission timeouts. The buffer is now flushed in slices with packet processing in between. Curious what speeds you see on your hardware now — that burst/stall sawtooth should be gone.

The download dialog persists for ~10 seconds after canceling a transfer; After a few minutes connected: "PASV refused (257)", and I have to disconnect/reconnect manually. (thanks, ntalaec!)
Fixed — cancel now sends ABOR while the data connection is still open (like uploads already did), so the dialog closes right away.
Fixed — stale replies from aborted or timed-out transfers were desyncing the control connection, so later commands read the wrong answer. And when the server side drops an idle connection (421), FTP4DOS now reports a clean "connection lost" instead of failing on the next command.

A command-line switch to show the site manager at startup? And the blank space in full mode could show more filename characters. (ntalaec)
Both in: /SITES opens the site manager directly on startup, and full-screen mode (Alt+F8) now uses the full available width for long file names.

Full release history is now also in the repo: https://github.com/Projanglez/FTP4DOS/blob/master/HISTORY.md

As always: FTP4DOS.EXE plus the unmodified mTCP sources (GPLv3) are attached to the release. Feedback welcome — especially from real hardware.

Projanglez wrote on 2026-07-18, 14:49:

FTP4DOS 1.0.0 is out

Great work!
It turned out to be the best FTP client in my 30 years of acquaintance with MSDOS!

A small suggestion for the next version 1.0.1:
If LFN support is detected in the local system, then disable forced conversion of folder names to uppercase and file names to lowercase on local panel.

Latest release gives an error for me when downloading files (with DOSBox-X): "Cannot create local file". It is creating 0 byte files though. Uploading is still working. Previous versions did not have this problem.

Would it be possible to save your default startup options somehow btw? Would be nice to get "/sites /q" as default (without creating batch files or aliases).

Projanglez wrote on 2026-07-18, 14:49:

Download speeds fluctuate between 100+ KB/s and zero, with disk activity pauses

It keeps doing this. Download speed has been reduced since v0.9.6.

Projanglez wrote on 2026-07-18, 14:49:

The download dialog persists for ~10 seconds after canceling a transfer

Now the dialog persists for about 20 seconds.

Even using /EXMEM parameter I have problems with folders with lots of files (this one has 2784 files) with long file names. Also, time is always 00:00.

Is there any reason not to use extended memory by default?

I would expect a program running in a single-tasking system to use all available resources by default - and only provide options to avoid using certain resources for troubleshooting.

v1.0.1 is up:
https://github.com/Projanglez/FTP4DOS/releases/tag/v1.0.1

Thanks for all the reports and feedback — motivated
me a lot to improve the application! The short list of what changed:

Several fixes regarding downloads and transfers
- Fixed: Downloads could fail with "Cannot create local file" on systems with long filename support — or, worse, report success and write a 0-byte file.
- Recursive copies no longer abort at 400 entries per directory (2048 now, memory permitting)
- Cancelling a transfer is down from up to 20 seconds to well under one

Much better ETAs
- Overhead caused by multiple smaller files is now calculated more precisely
- Directory copies also show the total remaining time, not just the per-file one

Better Long Filenames support
- "550 No such file" on entries plainly visible in the pane is gone
- Name storage now lives in XMS/EMS — a 2800-entry directory keeps every name, and anything that still will not fit is marked

Extended memory is on by default
- /NOEXMEM opts out entirely.

/LASTCON connects straight to the last used connection** on startup

Full change history here: https://github.com/Projanglez/FTP4DOS/blob/master/HISTORY.md

ntalaec wrote on 2026-07-25, 09:47:

Projanglez wrote on 2026-07-18, 14:49:

Download speeds fluctuate between 100+ KB/s and zero, with disk activity pauses

It keeps doing this. Download speed has been reduced since v0.9.6.

I could not reproduce the sawtooth; all my test setups are running at constant speed.

I have added a transfer logger to v1.0.1, so you can capture a trace:

Add to `MTCP.CFG`:

1FTP4DOS_XFERLOG C:\XFER.LOG

And before starting type in DOS prompt:

1SET LOGFILE=C:\MTCP.LOG
2SET DEBUGGING=0x1

Then run one download that shows the sawtooth and post `C:\XFER.LOG` and
`C:\MTCP.LOG`. Also useful: CPU, drive (and whether a disk cache is loaded),
packet driver/NIC.

Cheers!

Projanglez wrote on Yesterday, 13:35:

v1.0.1 is up: https://github.com/Projanglez/FTP4DOS/releases/tag/v1.0.1 […]
Show full quote

v1.0.1 is up:
https://github.com/Projanglez/FTP4DOS/releases/tag/v1.0.1

Thanks for all the reports and feedback — motivated
me a lot to improve the application! The short list of what changed:

Several fixes regarding downloads and transfers
- Fixed: Downloads could fail with "Cannot create local file" on systems with long filename support — or, worse, report success and write a 0-byte file.
- Recursive copies no longer abort at 400 entries per directory (2048 now, memory permitting)
- Cancelling a transfer is down from up to 20 seconds to well under one

Much better ETAs
- Overhead caused by multiple smaller files is now calculated more precisely
- Directory copies also show the total remaining time, not just the per-file one

Better Long Filenames support
- "550 No such file" on entries plainly visible in the pane is gone
- Name storage now lives in XMS/EMS — a 2800-entry directory keeps every name, and anything that still will not fit is marked

Extended memory is on by default
- /NOEXMEM opts out entirely.

/LASTCON connects straight to the last used connection** on startup

Full change history here: https://github.com/Projanglez/FTP4DOS/blob/master/HISTORY.md

Hi,
While previous versions worked this new version displays an empty pane in place of the remote files after connected to remote server.
Maybe the problem is conventional memory related since I have only about ~450K free conventional memory (Both MS network stack and packet driver are loaded).

Falcosoft wrote on Yesterday, 14:25:

Both MS network stack and packet driver are loaded

You mean you're using the Microsoft Network Client with NDIS driver, plus DIS_PKT for mTCP, right?
But how can the two TCP/IP stacks coexist? Using two IP addresses, or what?

Grzyb wrote on Yesterday, 15:56:

Falcosoft wrote on Yesterday, 14:25:

Both MS network stack and packet driver are loaded

You mean you're using the Microsoft Network Client with NDIS driver, plus DIS_PKT for mTCP, right?
But how can the two TCP/IP stacks coexist? Using two IP addresses, or what?

Yes, and the 2 stacks can coexist since network client apps use either the MS stack or packet driver but never both. So even the same ip address can be used.

Falcosoft wrote on Yesterday, 17:07:

Yes, and the 2 stacks can coexist since network client apps use either the MS stack or packet driver but never both. So even the same ip address can be used.

Can you post your config?
I want to hurt myself by downloading a file via FTP onto an SMB share...

Downloading works again. Nice! Also played with the /LASTCON option. Works okay but it if you don't save the password it will connect without a password. Maybe by design but think it would be better to just show the connection window instead of directly connecting. Or are there any people who do anonymous connections?

Grzyb wrote on Yesterday, 17:52:

Falcosoft wrote on Yesterday, 17:07:

Yes, and the 2 stacks can coexist since network client apps use either the MS stack or packet driver but never both. So even the same ip address can be used.

Can you post your config?
I want to hurt myself by downloading a file via FTP onto an SMB share...

Of course, but I have just tried and when the starting folder is an SMB share then FTP4DOS fails to load. Just a blue screen and no reaction to any keys. Although Ctrl +Alt + Del works.

CONFIG.SYS

1...
2[DOS_RAMDrive_NET]
3DEVICE=C:\win98\command\HIMEMX.EXE /MAX=64M
4DEVICE=C:\win98\command\UMBPCI.SYS
5COUNTRY=36, 852, C:\win98\command\COUNTRY.SYS
6DEVICEHIGH=C:\win98\command\DISPLAY.SYS CON=(EGA,,1)
7
8DEVICE=c:\net\ifshlp.sys
9DEVICE=c:\net\PROTMAN.dos /I:C:\Net
10DEVICE=c:\net\e1000.dos
11DEVICE=c:\net\dis_pkt.dos
12DEVICEHIGH=c:\net\NEMM.dos
13DEVICEHIGH=c:\net\TCPDRV.dos

AUTOEXEC.BAT

1IF %RAMDRIVE%==YES C:\NET\net initialize
2IF %RAMDRIVE%==YES C:\NET\netbind.com
3IF %RAMDRIVE%==YES C:\NET\umb.com
4IF %RAMDRIVE%==YES C:\NET\tcptsr.exe
5IF %RAMDRIVE%==YES C:\NET\tinyrfc.exe
6IF %RAMDRIVE%==YES C:\NET\nmtsr.exe
7IF %RAMDRIVE%==YES C:\NET\emsbfr.exe
8IF %RAMDRIVE%==YES C:\NET\net start
9IF %RAMDRIVE%==YES SET TZ=CET-1CDT
10IF %RAMDRIVE%==YES lh C:\WIN311\TRUMPET\WINPKT.COM 0x60

Falcosoft wrote on Yesterday, 21:27:

Of course, but I have just tried and when the starting folder is an SMB share then FTP4DOS fails to load. Just a blue screen and no reaction to any keys. Although Ctrl +Alt + Del works.

Oh, so there's no miracles after all - two independent stacks can't use one NIC at the same time...

Anyway, I need your PROTOCOL.INI as well - there must be some [PKTDRV] section there, but I can't figure out what exactly.

Grzyb wrote on Yesterday, 21:58:

Falcosoft wrote on Yesterday, 21:27:

Of course, but I have just tried and when the starting folder is an SMB share then FTP4DOS fails to load. Just a blue screen and no reaction to any keys. Although Ctrl +Alt + Del works.

Oh, so there's no miracles after all - two independent stacks can't use one NIC at the same time...

Anyway, I need your PROTOCOL.INI as well - there must be some [PKTDRV] section there, but I can't figure out what exactly.

Here are all the other relevant config files for both stacks:
PROTOCOL.INI
SYSTEM.INI
HOSTS
WATTCP.CFG (Waterloo)
SAMPLE.CFG (MTCP)

Thank you for the wonderful FTP client, which many have been waiting for years! I have a question. How do I specify a drive for the left panel using launch parameters? Is it possible to add such a key?
P.S. I get download speeds from the FTP server around 600 KB/sec using 3Com509 on a 486 AMD 133 MHz PC. This is fantastic!

Falcosoft wrote on Yesterday, 22:09:

Here are all the other relevant config files for both stacks:
[...]

Thanks, got it to work... kind of:

f: - that's my SMB share
ftp... - connects to the server normally
get testfile nul - works, but slowly
get testfile - fails with "Local error writing to file testfile - disk full?"

So, as expected - the only way to make this work would be to write an FTP client for the Microsoft Network Client API...

Downloads to NUL:

FTP.EXE, MTU 1500 - 10972 KB/s
FTP.EXE, default MTU - 8070 KB/s
FTP4DOS.EXE, MTU 1500 - 11.1 MB/s
FTP4DOS.EXE, default MTU - 753 KB/s

Is it just me, or there's something in FTP4DOS that really hates the default MTU ?

Interesting discussions... I'll come back to that later.

But in the meantime:

FTP4DOS v1.1.0 is out!

• New feature: Self-Update function
  • Downloads latest binaries from GitHub
  • Optional automatic update check (opt-in)
  • Updates are cryptographically signed using RSA-2048, preventing man-in-the-middle attacks and compensating for the lack of HTTPS support on retro platforms

Download here:
https://github.com/Projanglez/FTP4DOS/releases/tag/v1.1.0