Projanglez wrote on 2026-07-30, 15:07:

Interesting discussions... I'll come back to that later. […]
Show full quote

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

It is expected but I'm telling anyway: this new version still fails to load the remote server pane after a successful connection on my PC. There is no error message only an empty blue pane and an <empty> label at the status area.

Falcosoft wrote on 2026-07-30, 15:44:

It is expected but I'm telling anyway: this new version still fails to load the remote server pane after a successful connection on my PC. There is no error message only an empty blue pane and an <empty> label at the status area.

Yes, I can confirm your problem - it's due to insufficient conventional memory.
I tried to eat various amounts of RAM using RAMDRIVE.SYS, and found when FTP4DOS begins to fail:

1Memory Type        Total       Used       Free
2----------------  --------   --------   --------
3Conventional          640K       162K       478K
4Upper                   0K         0K         0K
5Reserved              384K       384K         0K
6Extended (XMS)     64,512K        68K    64,444K
7----------------  --------   --------   --------
8Total memory       65,536K       614K    64,922K
9
10Total under 1 MB      640K       162K       478K
11
12Largest executable program size       478K (489,472 bytes)
13Largest free upper memory block         0K       (0 bytes)
14MS-DOS is resident in the high memory area.

Grzyb wrote on 2026-07-30, 17:13:

Yes, I can confirm your problem - it's due to insufficient conventional memory. I tried to eat various amounts of RAM using RAMD […]
Show full quote

Falcosoft wrote on 2026-07-30, 15:44:

It is expected but I'm telling anyway: this new version still fails to load the remote server pane after a successful connection on my PC. There is no error message only an empty blue pane and an <empty> label at the status area.

Yes, I can confirm your problem - it's due to insufficient conventional memory.
I tried to eat various amounts of RAM using RAMDRIVE.SYS, and found when FTP4DOS begins to fail:

Copy code to clipboard

1Memory Type        Total       Used       Free
2----------------  --------   --------   --------
3Conventional          640K       162K       478K
4Upper                   0K         0K         0K
5Reserved              384K       384K         0K
6Extended (XMS)     64,512K        68K    64,444K
7----------------  --------   --------   --------
8Total memory       65,536K       614K    64,922K
9
10Total under 1 MB      640K       162K       478K
11
12Largest executable program size       478K (489,472 bytes)
13Largest free upper memory block         0K       (0 bytes)
14MS-DOS is resident in the high memory area.

Thanks!
Yep, as I said before I only have about ~450 KB free conventional memory after both network stacks are loaded.

Falcosoft wrote on 2026-07-30, 17:55:

... as I said before I only have about ~450 KB free conventional memory ...

It is kinda funny how we've come to count/rely on "lots" of memory being available.

--- Sorry - kinda going on about a subject I feel strongly about ---

This is partly due to modern multi-tasking operating systems which often have operating conditions exceeding the actual RAM in the system, "virtual memory" (which pages actual RAM to disk to "fake" more physical memory).

Modern programming environments also tend to include large "libraries" in a programs in-memory code footprint as well (so much so that OS vendors often go away from the traditional "linking" of library code into an executable and toward loading library code dynamically - this still needs as much memory, but the size of the program executable is smaller, taking up less disk space.

And all of this has become "normal" because advances in hardware have made "small" systems have MUCH more physical memory, storage space and processor "power".

Worth a look: Re: How do todays CPUs compare over time, even back to the 1970s and 80s?

---

My first computer was a homebuilt 8080 - it had a whopping 1k of RAM (soon upgraded to 8k) and used solenoid controlled reel-to-reel magnetic tape drives for automatic save/load long-term (NOT fast).

My next was an Altair 8080 - 62kRAM(64-2kIOspace) and "NorthStar" SSSD floppy drives (unbelievable 90k per disk - what would you ever do with all that space)

64k was a "natural" upper-boundary for "personal" computers - almost all 8-bit processors had 16 bits of address bus (64k)

Then Intel made the 8086 - a combination 8/16bit processor with 20BITS of address bus (a whole megabyte of memory)

DOS built on this platform continued to follow the common memory use - Gates upped the usable RAM by 10x (640k vs 64k) ... and lots of early PCs didn't have "full" memory - so DOS software initially generally fit and ran in DOS memory.

But the expectations of more modern system and "advanced" programming languages crept in - and more and more DOS stuff relied on full conventional memory and more and more "extended" memory (above 1M).

This is especially true when you have to have network "stacks" loaded and rely on one program on top of another to get an user interface you like.

---

So I'm not really surprised than you run into problems with multiple networks and layered applications having "only" 450k RAM available.

---

Just to give an idea of what's possible: My ImageDisk is a fairly popular way to preserve/restore non-PC floppy disks. But it runs under DOS (because it accesses the Nec765 FDC directly and in somewhat non-standard ways "modern" OSs don't like).

As more and more people wanted to use ImageDisk but didn't have DOS on their systems, I created a boot floppy which boots DOS, makes a RamDisk and has ImageDisk which can read/write images to that RamDisk.

Then the problem became "how to get images on/off" the system?

I created DDLINK, a split-screen file transfer tool which could use Network, Serial or Parallel interfaces.

DDLINK.COM runs in 64k - it allocates 128k for file selection buffering etc. It needs no dynamic libraries, but for network it does use a "packet driver" (I mostly use NE2000s - I know NE2000.COM memory "footprint" is <2k).

So: total of 64+128+2 = 194k "free" memory needed - and easily fits on a floppy disk DDLINK.COM=17k, PKTDRV.EXE(collection of nearly 100 packet drivers)=700k

---

It all really depends on what you want - if you just want to move files DOS<>DOS or DOS<>DosBox - something minimal (like DDLINK) can fit most any DOS system - if you want to do FTP or SAMBA you'll need a system that can accommodate a lot more (and be prepared to deal with lots of stuff hanging around in memory) - but for that you will be able to interface to many more "far end"s!

Projanglez wrote on 2026-07-29, 13:41:

I could not reproduce the sawtooth; all my test setups are running at constant speed. […]
Show full quote

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`:

Copy code to clipboard

1FTP4DOS_XFERLOG C:\XFER.LOG

And before starting type in DOS prompt:

Copy code to clipboard

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!

Now I use a RAM drive and almost all the write issues have been gone. I'm using an old 1 GB USB stick to boot MS-DOS 6.22 from and I'm not using SMARTDRV for memory problems (not enough free conventinal RAM). It was due to slow disk access I think.
Anyway, the required log files are attached. CPU: Intel Atom N280, LAN (wired): Atheros AR8132, RAM: 1 GB (using vanilla HIMEM.SYS so 64 MB RAM available), OS: MS-DOS 6.22.

I've been using FTP4DOS v1.2.1. The update feature is a nice feature, considering GitHub downloads don't work with Links Web Browser. Many thanks for this.
It keeps doing the pause (about 30 seconds) after canceling a download. Don't matter if you pause the download with P and cancel afterwards or cancel with Esc.

I can't test the view image feature, it complains about not enough memory available:

Not enough memory to decode this image.
44 KB free; a picture needs about 100 KB.

This is my free memory after loading the packet driver and before loading FTP4DOS (RAM drive uses 32 MB):

1Memory Type        Total  =   Used  +   Free
2----------------  -------   -------   -------
3Conventional         638K       74K      564K
4Upper                 48K       37K       11K
5Reserved               0K        0K        0K
6Extended (XMS)    64.464K   32.400K   32.064K
7----------------  -------   -------   -------
8Total memory      65.150K   32.511K   32.639K
9
10Total under 1 MB     686K      111K      575K
11
12Largest executable program size       564K (577.552 bytes)
13Largest free upper memory block        11K  (11.168 bytes)
14MS-DOS is resident in the high memory area.

Now I can't edit any text file, I get an Out of memory error. Viewing images can be a nice feature, but if it takes too many resources, I will consider removing it.

I have found that in some files only year is show instead of date and time, but I can't reproduce now. I will check latter.

ntalaec wrote on 2026-08-06, 09:43:

I can't test the view image feature, it complains about not enough memory available:

Yes, I've experienced it, too - viewing an image only works with very clean config.

It may be the time to stop adding new features, and focus on optimization.
Or perhaps it would be a good idea to split the project into two builds: BASIC - guaranteed to work even on 640 KB machines, with only the essential features; and FULL - for those with plenty of extended memory?
Non-essential features would be the image viewer, auto-update, and LFN support - I don't think anybody uses LFN in DOS on low-memory machines, right?

The command line FTP client in mTCP requires about 220KB to transfer a large file. This program is up around 480KB. You get some ease-of-use from the interface and Unicode translation, but it is quite a heavy program now.

I suggest removing the secure auto-update feature. People who need a secure download can use a modern machine and get it straight from Github. I don't think that DOS is a huge target for man-in-the-middle attacks anymore, which makes the secure auto-update feature kind of a solution looking for a problem.

You might also want to tell the AI to start figuring out how to save space ... it would be interesting to see what it comes up with. Overlays might be a great solution here, and would also let you keep all of the features at the expense of disk space.

mbbrutman wrote on 2026-08-08, 22:36:

I suggest removing the secure auto-update feature. People who need a secure download can use a modern machine and get it straight from Github. I don't think that DOS is a huge target for man-in-the-middle attacks anymore, which makes the secure auto-update feature kind of a solution looking for a problem.

I think the update feature in DOS it's quite useful but only if it does not require many KB of RAM.

Just put the update feature in another executable (if that is the memory hog). Didn't have any memory issues myself but I had a couple of times that the download suddenly stopped. Didn't investigate it further yet but I don't have that issue when using MTCP FTP server or using EtherDFS. Maybe it's one of the FTP buffer settings or so (which I set to the max a couple of years ago). This is when copying a couple of games of around 100 files or so. It runs for some time and than it stops and in the end (after a long time) it gives a network error.

Hey guys,

just a quick note that FTP4DOS v1.3.0 is out:

- Optimized memory usage, allowing for larger buffers, should smooth out transfers
- For those who still run into out of memory: Proper out of memory error messages
- Cancelling a download no longer freezes for ~30 seconds when the server ignores ABOR
- And much more...

Download and full notes: https://github.com/Projanglez/FTP4DOS/releases/tag/v1.3.0

PS: Auto-Update via Alt+F10 in the program picks it up too 😀

Thanks again for all the testing and reports.

Projanglez wrote on 2026-08-21, 22:54:

Hey guys, […]
Show full quote

Hey guys,

just a quick note that FTP4DOS v1.3.0 is out:

- Optimized memory usage, allowing for larger buffers, should smooth out transfers
- For those who still run into out of memory: Proper out of memory error messages
- Cancelling a download no longer freezes for ~30 seconds when the server ignores ABOR
- And much more...

Download and full notes: https://github.com/Projanglez/FTP4DOS/releases/tag/v1.3.0

PS: Auto-Update via Alt+F10 in the program picks it up too 😀

Thanks again for all the testing and reports.

FTP unavailable - not enough memory (457 KB is available at start).
So it seems FTP4DOS v1.00 remains the last version that I can use.
BTW, increasing PACKET_BUFFERS from 20 to 40 costs about 30 KB additional conventional memory. And this is not a configurable option. This step alone questions that this release is really meant for systems with lower available conventional memory...

Projanglez wrote on 2026-08-21, 22:54:

just a quick note that FTP4DOS v1.3.0 is out:

Thanks for continue updating this software.

Tested v1.3.0. Big improvement when cancelling a transfer. The delay seems to depend on the FTP site. Now, in some sites it last 5 seconds, in others 1 second. Related with SSL or with folders with thousand of files?
Download speed still fluctuates between 150 KB/s and 4 KB/s even downloading to RAM drive. When downloading to permanent storage (live USB stick) it happens more frequently.
In this release, apart from being unable to edit a text file, now I'm unable to view it. I always get an Out of memory error.
There are files where only appears the year as file date. Again, related with SSL or too many files? I get this error in a FTP folder with more than 4000 files with long file names.

Projanglez wrote on 2026-08-21, 22:54:

Hey guys, […]
Show full quote

Hey guys,

just a quick note that FTP4DOS v1.3.0 is out:

- Optimized memory usage, allowing for larger buffers, should smooth out transfers
- For those who still run into out of memory: Proper out of memory error messages
- Cancelling a download no longer freezes for ~30 seconds when the server ignores ABOR
- And much more...

Download and full notes: https://github.com/Projanglez/FTP4DOS/releases/tag/v1.3.0

PS: Auto-Update via Alt+F10 in the program picks it up too 😀

Thanks again for all the testing and reports.

I hope there will be no hard feelings but I have created a 32-bit protected-mode version using DJGPP and Watt-32: FTPDOS32. I just needed a version that works better with my modern but conventional memory constrained PC.
FTPDOS32 requires 386+ and at least 4MB RAM but honestly it was not tested on older hardware. Its primary targets are more modern DOS PCs.
It is very much inspired by FTP4DOS but it is rather a rewrite than a port. As much as possible it is compatible with the current version of FTP4DOS.
The biggest difference is that it uses a different network library since mTCP is mainly intended to be used with 16-bit software.
So for the network configuration you need WATTCP.CFG. An example WATTCP.CFG is included in the package. Actually you only need to change these lines:

my_ip = 192.168.0.55 (real IP or dhcp)
hostname = "Falco3"
netmask = 255.255.255.0
nameserver = 192.168.0.50
gateway = 192.168.0.50
domain.suffix = .hu

The following features are deliberately not implemented:
1. German etc. localizations. I think the ones who use DOS in 2026 can understand basic English.
2. Remote update. I will not support this feature with a server backend.

In compensation you have the following extras:
1. Norton Commander style mouse support
2. JPEG, ICO, TGA picture viewers.
3. VESA support for image viewers.
4. Much more available memory 😀

Sources and binary included:

Falcosoft wrote on Yesterday, 23:46:

I hope there will be no hard feelings but I have created a 32-bit protected-mode version using DJGPP and Watt-32: FTPDOS32.

Grzyb wrote on 2026-06-15, 22:08:

"you can never have too much of a good thing"

But I think it deserves a separate thread...

Grzyb wrote on Today, 09:17:

Falcosoft wrote on Yesterday, 23:46:

I hope there will be no hard feelings but I have created a 32-bit protected-mode version using DJGPP and Watt-32: FTPDOS32.

Grzyb wrote on 2026-06-15, 22:08:

"you can never have too much of a good thing"

But I think it deserves a separate thread...

Hi,
In theory you are completely right. It would deserve a new thread. But the truth is that on one hand I do not want to steal the show on the other hand I do not want to maintain this version.
Even in its current form it can do what I want from it. It will not get the same effort and full support from me as FTP4DOS gets from Projanglez.
It's not a successor of FTP4DOS. it's only for the desperate ones who are as unlucky as me and cannot use the latest FTP4DOS versions because of the conventional memory requirements.

The source code is available so if someone wants to continue developing it he/she can do it.
From the previous package the license was missing ( of course it has the same GPL3 license as FTP4DOS). I have added it and also added the missing date/time columns from the commander panels. But most likely this will be the final version from me:

Zoltan, @Grzyb is right. Make a new thread for your DOS FTP utility, since it has nothing in common with FTP4DOS from this thread. I can't get why you're spreading your DOS/win software tools and utilities through multiple non-dedicated threads. If you make yours own thread about your FTP for DOS 32-bit software, it will be easier to be found and tracked for new versions i.e. updates.

aVd wrote on Today, 13:35:

Zoltan, @Grzyb is right. Make a new thread for your DOS FTP utility, since it has nothing in common with FTP4DOS from this thread. I can't get why you're spreading your DOS/win software tools and utilities through multiple non-dedicated threads. If you make yours own thread about your FTP for DOS 32-bit software, it will be easier to be found and tracked for new versions i.e. updates.

Hi,
1. I have already agreed that Grzyb is right 😀
2. Telling that FTPDOS32 'has nothing in common with FTP4DOS' is an exaggeration a little bit. From emotional point of view it was this very utility that caused the frustration (it cannot work for me) that made FTPDOS32. From technical point of view it was the starting point and the role model. That's why FTPDOS32 tries to mimic the behavior of FTP4DOS from the command line arguments to shortcuts.
3. I feel your judgment that I spread my utilities to 'multiple non-dedicated threads' is also not fair. For the projects I want to concentrate on I have my dedicated topics. Just a few examples:
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
x86 microarchitecture benchmark (MandelX)
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)
Thinkpad T430 LCD Brightness and Aspect Ratio Control from DOS (an AI experiment)

But the FTPDOS32 project is definitely not one of them. I just shared it so someone with the same problem can have an alternative solution. But I do not have the time and mood to maintain it.
The point is that there will be no further updates from me as I wrote before. That's why I think that a dedicated topic started by me for FTPDOS32 is pointless.
BTW, I don't expect you to agree with me. But I do expect you to accept my decision.
Bye.

Don't get me wrong, Zoltan. I'm not "attacking" you for advertising your software in someone else's similar software thread.

To me 16-bit (real mode) DOS software has nothing to do with 32-bit DOS software, since the latter can not be executed on pre-386 machines and in this particular case the common FTP functionality does not justify mixing them, sorry. I'm respecting your (retro) software work very much, but still can not get why you're not more organized, when it comes to sharing new tools, utilities and their versions, except for your "main" projects.

Your FTPDOS32 deserves a new thread, since it is not intended for XT machines. Don't be lazy 😉

As a solo dev who's touched some DOS-era code myself, I really relate to Falcosoft's dilemma here. That conventional memory ceiling forces such brutal tradeoffs - every feature you add is a KB you're stealing from someone's ancient rig. Kind of admire that FTPDOS32 didn't try to replace FTP4DOS, just quietly solved one guy's own problem and shared it as-is. That's a very real way solo projects grow, not every fork needs its own roadmap and dedicated thread on day one.

aVd wrote on Today, 14:54:

Don't get me wrong, Zoltan. I'm not "attacking" you for advertising your software in someone else's similar software thread.

To me 16-bit (real mode) DOS software has nothing to do with 32-bit DOS software, since the latter can not be executed on pre-386 machines and in this particular case the common FTP functionality does not justify mixing them, sorry. I'm respecting your (retro) software work very much, but still can not get why you're not more organized, when it comes to sharing new tools, utilities and their versions, except for your "main" projects.

Your FTPDOS32 deserves a new thread, since it is not intended for XT machines. Don't be lazy 😉

1. I was not advertising anything. I just shared something. But you are right, next time I'll think twice before doing such a thing.

2. We absolutely disagree here. I think your radical point of view is overly 'technical', and I'm not even sure that it can be justified even from a technical point of view.
And from a user's point of view who has problems with one version your point of view is not relevant at all.
Even in the DOS era there were software with both real mode and protected mode versions in the same package. E.g. Borland Pascal and Turbo Assembler/ Linker contained both versions.
Nowadays many Windows software package contains both 32-bit and 64-bit versions of the 'same' software. If you were right then these versions would have to be separated as things that 'have nothing to do with each other' since the 64-bit version cannot run on e.g. on a Pentium.
In case of my Midi Player I had to open a separate topic for the 64-bit version since it has nothing in common with the 32-bit version... I think this is absurd.

3. Then please, open a topic for it and then spend your time with user requests. Do not be lazy 😀. Thanks.

sgard wrote on Today, 15:06:

As a solo dev who's touched some DOS-era code myself, I really relate to Falcosoft's dilemma here. That conventional memory ceiling forces such brutal tradeoffs - every feature you add is a KB you're stealing from someone's ancient rig. Kind of admire that FTPDOS32 didn't try to replace FTP4DOS, just quietly solved one guy's own problem and shared it as-is. That's a very real way solo projects grow, not every fork needs its own roadmap and dedicated thread on day one.

Thanks for the empathy.