PDA

View Full Version : A new mTCP is available! (mTCP 2015-07-05)



mbbrutman
July 5th, 2015, 01:14 PM
After two very busy years in that place we call "real life" I am happy to announce that a new version of the mTCP TCP/IP programs for DOS is available!

Some of the more notable improvements and changes are:


Incredible new format for documentation featuring things like boldfacing and italics ... (PDF!)
New program: HTTPServ, a web server than will run well on your oldest PCs
New program: PktTool for querying packet drivers and tracing packets on your network
Detection of IP address conflicts
Telnet: 132 column support and proper handling of the TCP socket when closing the session
FTP client: mdelete support, removed some filename/path length restrictions, and new code to work around misconfigured FTP servers.
FTP server: the log file is now optional
Several small TCP/IP library fixes
Bug fixes or small improvements in every program ... too numerous to enumerate.


The packaging for this version is a little different. There are three files:


A zip containing the binaries and sample files
A zip containing UPX compressed binaries and sample files. Use this for you machines without hard drives; everything works the same, but they take up less space.
A PDF file with the new, consolidated documentation


And if you get a spare moment, I'd like to start collecting packet drivers to make them available in a central place. If you are so inclined, please send me your network card model number, the packet driver you use, and any installation files and utilities for the Ethernet card. (Diskette images work great for this kind of thing.) I'll try to make a sensible page with what I collect so that others can stop flailing around looking for this stuff.

Everything can be found at http://www.brutman.com/mTCP/


Enjoy!
Mike

SkydivinGirl
July 6th, 2015, 10:35 AM
Hey Mike,

Thanks so much for the update! I really appreciate the effort you've put into this project. I have all my old network boot disks that have packet drivers for multiple cards. Let me know where to send the drivers and I'll get them to you. :)

Heather

mbbrutman
July 6th, 2015, 06:55 PM
Hey Mike,

Thanks so much for the update! I really appreciate the effort you've put into this project. I have all my old network boot disks that have packet drivers for multiple cards. Let me know where to send the drivers and I'll get them to you. :)

Heather


I'm flexible - email (mbbrutman at gmail dot com) will work if you send an encrypted zip file with the password set to something obvious, like password. (The encryption just keeps the mail scanners from flipping out.) Google drive works well. Basically any of the file sharing services that do not require me to click through spam work well. ; - 0


Mike

deathshadow
July 7th, 2015, 07:56 AM
Are you no longer providing source for newer versions?

I was actually starting to dig into it as I'm integrating your HTGET into a... project I've been playing with.

Also rewriting some bits of it in x86 ASM as there are a few things that C is grossly inefficient at on a 8088... and the host program is turbo pascal so I was more porting the code than using it as is.

mbbrutman
July 7th, 2015, 11:48 AM
This latest version is not open source (yet). I don't think there were any significant changes to HTGET that you need so the existing open source code should be fine for your uses.

But are you really porting over all of the program including the TCP/IP code, or are you using another TCP/IP library already written in Turbo Pascal?

deathshadow
July 7th, 2015, 05:00 PM
This latest version is not open source (yet). I don't think there were any significant changes to HTGET that you need so the existing open source code should be fine for your uses.

But are you really porting over all of the program including the TCP/IP code, or are you using another TCP/IP library already written in Turbo Pascal?

I'd like it to be self contained as a single executable, not piecemeal; it's bad enough I'm mixing TP and ASM without mixing the disaster that is C++ into the mix. Early tests were calling HTGET via a shell exec, but I'd like to do it "in house"

I'm also doing it as a learning experience to get a better handle on what really goes on under the hood.

Though dealing with some parts of that code REALLY reminds me of why I absolutely HATE C syntax languages, C++ in particular. Makes me want to find Ritchie and pimp slap him with a wet trout. Though to be fair, I'm STILL not convinced this is a joke. (http://www.gnu.org/fun/jokes/unix-hoax.html)

As I've said many times the past 30+ years, I'd sooner hand assemble 8k of Z80 machine language than try to deal with 100 lines of C code.

kb2syd
July 7th, 2015, 05:52 PM
As I've said many times the past 30+ years, I'd sooner hand assemble 8k of Z80 machine language than try to deal with 100 lines of C code.

Any language can be abused with sufficient effort. I've written and read many hundreds of lines of very elegant c code. I'm also guilty of producing one off garbage.

ahm
July 7th, 2015, 06:42 PM
I absolutely HATE C syntax languages, C++ in particular. Makes me want to find Ritchie and pimp slap him with a wet trout.
Dennis passed away in 2011. And anyway, C++ is by Bjarne Stroustrup.

mbbrutman
July 7th, 2015, 06:45 PM
The current mTCP source code is 55603 lines of code. Somewhere around 500 to 600 lines of that are assembler or inline assembler. The rest of it is C++ code. (That is a raw line count; it includes comments and blank lines.) I use assembler where speed counts or where I know the library has some horrible bloat and I can cheat by using a DOS or BIOS function call directly.

I certainly hope it is not my code that is giving you a bad impression of C or C++. I'm not using inheritance or polymorphism. There are no templates. The data structures are pretty clearly laid out, and methods are provided for the more complication manipulations. My TRACE macros are pretty nice; they were not straightforward to implement but I think they keep the code readable. As far as C or C++ code goes, you are going to have a hard time finding much better. And most C++ programmers would not recognize it; they'd say it was C.

HTGet is only around 1100 lines. Good luck trying to port all of that to Pascal or assember; it's going to take a while.

gepooljr
July 7th, 2015, 07:25 PM
Hi Mike,

Thanks for newest release of mTCP. The PKTTOOL is really nice; wish I had it when I was getting my old 3com 503 working.

Any hints on your next project? Are you still working on the telnet BBS project for IBM PCjr?

Geoff

deathshadow
July 8th, 2015, 06:59 AM
I certainly hope it is not my code that is giving you a bad impression of C or C++.
No, I've had a bad impression of C syntax languages since the first time I encountered them in '82, then HAVING to work on projects written with them in the 1990's only further soured me on it. Admittedly, my having spent over a decade using other languages (including assembly) before I ever even HAD a C compiler didn't help that impression any. (since up until the late '80's even encountering C outside the mainframe world was a serious case of "Yeah, right!")

It's a needlessly pointlessly cryptic language that honestly should have gone the way of the dodo with big iron; more specifically once we got past connecting to mainframes at 300 baud or less.

It is intentionally obtuse, and seems to have been created for the sole purpose of perpetuating the idea that programming is hard. It teaches sloppy development habits, and every major description of the language seems full of ****. See the perpetuated lie that C is "closer to machine language" than other languages, something that was only ever true on early DEC mainframes. It's about as far away from x86, AM64, ARM or MIPS machine language as you can get.

The mere existence of some of its constructs like the various "printf" annoys me no end... or how some commands take () and others don't. It's willy-nilly inconsistent, relies on way too many obscure symbols, seems to be "memory leak by design" in mentality, and on the whole is HARDER to deal with than machine language. Apart from portability and that you are more likely to find a good compiler for it on any platform, I just don't get why it ever caught on... well, excepting perhaps effete elitist ivy league types perpetuating ignorance in the same way they always manage.

But I'm a Wirth kind of guy at heart.

sgifanatic
July 8th, 2015, 03:10 PM
Mike,

Thank you very much for the new release. I've used mTCP on my Gateway 486 (http://www.vintage-computer.com/vcforum/showthread.php?44930-Restoring-a-Gateway-2000-4DX2-50-80486-Desktop-(Warning-Lots-of-images)&highlight=), am looking forward to getting it going on the PC-10 8088 (http://www.vintage-computer.com/vcforum/showthread.php?47387-Advice-needed-on-add-on-purchases-for-Commodore-PC-10-8088) and maybe it'll even work on my newly acquired Jr (http://www.vintage-computer.com/vcforum/showthread.php?48226-Picked-up-a-new-PCjr-in-good-condition-except-that-it-doesn-t-boot!)?

Also look forward to getting HTTPServ to run under Desqview.

Appreciate your significant contribution to keeping old machines fun and useful.

mbbrutman
July 8th, 2015, 08:00 PM
Hi Mike,

Thanks for newest release of mTCP. The PKTTOOL is really nice; wish I had it when I was getting my old 3com 503 working.

Any hints on your next project? Are you still working on the telnet BBS project for IBM PCjr?

Geoff


Next project? A BASIC interpreter with some extensions to make it easy to do network programming. Think about opening a socket as easily as you open a file.

And the Telnet BBS is still floating around, but I've not worked on it in about three years now. Now that I have functional FTP and Xmodem/Ymodem code I can probably dust it off and start working on it again.

mbbrutman
July 8th, 2015, 08:23 PM
Mike,

Thank you very much for the new release. I've used mTCP on my Gateway 486 (http://www.vintage-computer.com/vcforum/showthread.php?44930-Restoring-a-Gateway-2000-4DX2-50-80486-Desktop-(Warning-Lots-of-images)&highlight=), am looking forward to getting it going on the PC-10 8088 (http://www.vintage-computer.com/vcforum/showthread.php?47387-Advice-needed-on-add-on-purchases-for-Commodore-PC-10-8088) and maybe it'll even work on my newly acquired Jr (http://www.vintage-computer.com/vcforum/showthread.php?48226-Picked-up-a-new-PCjr-in-good-condition-except-that-it-doesn-t-boot!)?

Also look forward to getting HTTPServ to run under Desqview.

Appreciate your significant contribution to keeping old machines fun and useful.

Thanks - it's been a great project, and I've learned a lot from it too.

Good luck getting the Jr running. I used to be the resident expert but there are so many people with them now that help is much more plentiful than it used to be.

sgifanatic
July 14th, 2015, 11:07 AM
Next project? A BASIC interpreter with some extensions to make it easy to do network programming. Think about opening a socket as easily as you open a file.


That would be very cool. I was thinking of using your mTCP utilities in less efficient ways (SYSTEM) with QBASIC programs, but inbuilt extensions will be so much better.

In my early teens, I wrote a BBS application in QBASIC that performed I/O over COM ports. The other thought in my head was to see if I could change all that I/O to STDIN and STDOUT and then connect the program with your implementation of nc to basically echo socket to console, and console back to socket. That would make for a quick way to run my old BBS code over telnet.

fadiaz
July 19th, 2015, 06:11 PM
That would be very cool. I was thinking of using your mTCP utilities in less efficient ways (SYSTEM) with QBASIC programs, but inbuilt extensions will be so much better.

In my early teens, I wrote a BBS application in QBASIC that performed I/O over COM ports. The other thought in my head was to see if I could change all that I/O to STDIN and STDOUT and then connect the program with your implementation of nc to basically echo socket to console, and console back to socket. That would make for a quick way to run my old BBS code over telnet.

That sounds very interesting... a vintage BBS program converted from Comm Port to TCP/IP... Good luck there...!!! :D

Francisco

cr1901
March 27th, 2016, 12:15 PM
Mike, what is the status on using mTCP safely in a TSR or device driver?

Let me discuss my potential use case:
When developing for DOS, I'd like to get rid of using DOSBOX completely. It's not a real DOS, and setting it up honestly tends to take more effort than I save from its debugging functions (more of a printf guy, tbh). But using solely a PC running DOS is not an option; I do not have the room to actually put a desk to develop comfortably, and I am kinda spoiled by modern tools, PDFs, and the like. Watcom and NASM don't run on 8088/286-class machines, my intended target.

It would be nice to somehow run a batch file in a loop that either intercepts the CON device driver or create a block device driver whose sole purpose is to wait for a program to be uploaded over TCP, release resources run the program, and then reacquire resources. So in a sense, I treat DOS programming like I would an embedded target. Is such a setup even feasible w/ mTCP in its current state?

EDIT: I guess I should look into creating a debug server, now that I think about it...

mbbrutman
March 27th, 2016, 01:23 PM
I think the easiest thing you could do would be to set the target PC up so that it automatically loads the packet driver and runs the Netcat program from the AUTOEXEC.BAT file. The netcat program would be set to listen on a port and to write whatever it gets to a file. The next line in the batch file runs the contents of that file. After that, it reboots the machine to start everything from scratch.

The only time it would not be automatic is if you crash the machine and the batch file can't run to reboot the machine. There are watchdog TSR programs that might be able to help with that.

I don't use the debugging functions of DOSBox. I use trace driven debugging, hence all of the trace points in mTCP. DOSBox is still really hard to beat overall.

cr1901
April 29th, 2016, 04:40 AM
Mike, is it possible that future versions of the UDP API contain a function that in addition to sending the UDP header and packet also send the IP header? I'm writing a simple command-response application using UDP (more lightweight, don't mind if client has extra logic. I'm not even compiling in TCP or DNS), and when my server machine (IBM 5150/5170) executes a UDP callback, well...

It doesn't know where to send the response other than to broadcast it :D. For my purposes, this isn't a huge deal; probability of me having two computers simultaneously waiting for responses on the same UDP port is low. The original UDP RFC mentions (https://www.ietf.org/rfc/rfc768.txt) on page 3 that there should be a mechanism to figure out the source IP from a UDP receive.

EDIT: I just learned the hard way that the UDP callback in fact DOES return the whole packet and not just the data payload... oops o.0;

mbbrutman
April 29th, 2016, 07:50 AM
It's there already ...

The function that you provide for the callback gets two pointers - a pointer to the raw packet and a pointer to the UDP header. Since this is Ethernet you can just add the size of "EthHeader" to the packet pointer to get to the IP header.

cr1901
April 29th, 2016, 08:03 AM
You responded the moment I realized that I screwed up lol. To get directly to the data, point to packet + sizeof(EthHeader) + sizeof(IPheader) + sizeof(UdpHeader), presumably?

Al Kossow
April 29th, 2016, 12:40 PM
Next project? A BASIC interpreter with some extensions to make it easy to do network programming. Think about opening a socket as easily as you open a file.


http://www.rebol.com/what-rebol.html

Uniballer
April 29th, 2016, 01:21 PM
To get directly to the data, point to packet + sizeof(EthHeader) + sizeof(IPheader) + sizeof(UdpHeader), presumably?

Beware of IP header options. You should really read the 4-bit IHL field from the IP header to get the total header length in 32-bit words, including options. This is normally 5 for an IP datagram with no IP options, and this is also the minimum value. RFC 791 explains the IPv4 header.

mbbrutman
April 29th, 2016, 02:01 PM
Beware of IP header options. You should really read the 4-bit IHL field from the IP header to get the total header length in 32-bit words, including options. This is normally 5 for an IP datagram with no IP options, and this is also the minimum value. RFC 791 explains the IPv4 header.

Which is why I give both a pointer to the start of the Ethernet frame and a pointer to the UDP header directly. The IP header can be computed by starting at the beginning of the frame and skipping passed the fixed length Ethernet header. The pointer to the UDP header is correctly computed after inspecting the IP header.

Great Hierophant
June 9th, 2016, 10:23 AM
I don't suppose that a no-CGA snow mode may be (re)added in the future? For many of the applications, it does not rear itself or it does not matter because you aren't looking at the screen. However, for programs like Telnet and ircjr, it gets annoying. I could see someone trading off speed for snow.