Thanks for the heads up on this ultra useful tool!!!!

[Thread moved to Releases Section...]

Sorry about that .. I saw "Announcements" in Milliways and my brain turned off there ..

No worries mate. 😁

Just a warning - a user reported to me that Netcat was not working correctly in this version. It turned out to be a build script problem. Nothing else was affected.

I have placed a new version of the executables on the web site with a new version number. Please update if you use Netcat or ever thing you might want to use it.

My apologies go out to anybody who was caught by this. I try to test everything using the same Zip files that I make available for download to others, but I missed this one.

I have a small question, if I transfer a .txt from my pc using either flashfxp or filezilla, the txt that gets written to the target pc has those "note symbol" (line break symbol?) that is invisible when you do a "type readme.txt" but when you edit it (or run it if it's a batch file) you see them (and batch files produce the unknown command error) , it looks like this:

now if I make a .zip of the txt , send it over and unzip it, then it looks fine and clean....
My question is if this behavior is something that mtcp does ? and if yes, is there an option to turn it off?

I first noticed that because I transfer Ecstatica to a 486 and it did not run, it produced some errors... normally I would transfer the zip file with the pre-installed game btu this time I chose to extract on my main pc and just transfer the files... because of this line-break symbols the game's files became corrupted and assets could not be found... 😒
I know the game is 100% correct because I used my own original copy to install it once and archive it . Transfering the zip and extracting it on the target pc worked fine... I really hope that's an option somewhere to cure this...

Naively speaking, this looks like a newline encoding issue which can affect ASCII-mode FTP transfers between platforms - an extra CR being perfixed to CR+LF?
Depending on what you're trying to do, forcing binary mode in your ftp client may or may not help...

This is a simple error .. you need to use binary mode for the transfer.

According to the FTP specifications, systems are supposed to translate the "newline" character to whatever makes sense for them locally. Unix systems traditionally use just a line feed (0x0A) for a newline character. MS-DOS systems use carriage return and line feed (0x0D 0x0A).

What exactly are you using on the client side, and what exactly are you using on the server?

Mike

hmmm I just used latest mTCP on my 486 build (with DOS7.1) and on win7/x64 I just used either FlashFXP or Filezilla. Transfer settings were set to AUTO in both clients, did not really mess with any kind of setting... is there any more detailed info I can provide?

I did notice though that FlashFXP gave the file transfer error again, I filled a report some time back, the author fixed it but it seems it appeared again... 😒

"Auto" on the clients really doesn't tell me enough.

The mTCP FTP server defaults to "binary" transfers, so no translation should be done. If a client sets the transfer mode to ASCII for you because it thinks it is doing you a favor, that will change the interpretation of the newline character.

FileZilla with binary mode works. FileZilla with auto mode specifies an ASCII transfer for a text file, which mucks with the new line character.

Use binary mode.

^ thanks, will make the clients always use binary mode 😀

I have been testing the latest version for a couple of hrs.
I finally have been able to set up a working ftp server on one of my 486 systems. For a long time, I could only use my 486 as a client as it turned out that there was a fundamental error in the packet driver provided with the card (AT-Lantic NE2000 compatible). Now that I found working and compatible (although much older) genuine Novell NE2000 driver, mTCP works like greased lightning. Transfer speed rarely drops below 680 kb/s even with small files. That is on a DX4/100.

BIG THANKS, MIKE!

I also encourage others with exotic network cards to experiment with alternative packet drivers. One might eventually work...

IBM sold some variants of those AT-Lantic cards. They have two operating modes. The NE2000 mode might not have the advanced features that the other mode has, but it at least works ...

Although the rate of updates has slowed I am always looking for suggestions for improvements ...

Enjoy,
Mike