• Please review our updated Terms and Rules here

Call for ideas/fixes for the next mTCP version

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 2, 2003
Messages
6,531
It's that time again! I'm planning another release of mTCP so now would be a good time to let me know what needs to be fixed.

The next version will be fully compatible with mTCP NetDrive so that you can run the standard mTCP programs while a NetDrive remote drive is active. There will be some other small fixes too but the NetDrive compatibility is the big upgrade.

Thanks,
Mike
 
Downloading entire folders in one go with the FTP command, recursively. I am posting this suggestion at the risk of being told that it is already doable with current version.. preparing to get wrecked over here..

mTCP is fantastic. The fact that it is still being lovingly and enthusiastically maintained warms the heart.
 
No wrecking happening here ... recursive get is a common request but it's difficult to implement because of all of the state that needs to be tracked and the error handling. It's also too easy to run out of memory in a large directory tree.

The usual work-around is to run the FTP server on the DOS side, and then use a more capable client on the client side. Windows and Linux clients have the luxury of almost unlimited RAM compared to DOS, so doing recursive operations is much easier in those environments.
 
Makes sense. Figured it must be due to technical limitations, since none of the other FTP clients targeted at common 16-bit machines I've tried do the recursive get.
 
Believe it or not, the next version is already underway ...

Already done:
  • Telnet: fix a line wrapping bug.
  • Telnet: Add support for black and white sixel graphics.
  • TCP library: Fix bug that required a nameserver be set even when using a hosts file.
  • TCP library: Slight improvement on error handling when talking to slow/dodgy packet drivers.
In progress: Prepare the Netdrive source code (device driver and server) so it can be released as open source.

If you have something that is bothering you let me know.

-Mike
 
I might have asked this before but is it possible to have the ftp server write the original file date when receiving an uploaded file?
 
FTP timestamps are in draft RFC that was never approved/adopted. So it's possible, but it's not something I want to spend time working on. It also makes things far more complex because it's not metadata that gets sent with the stream of bytes; it's an entire other command or two that has to run each time you transfer a file.
 
I remember that mTCP would not cross-compile on a Linux system because of file name capitalization inconsistencies. Haven't looked at mTCP source code in a very long time, so maybe you've already fixed that. Otherwise, that would be my request. :)
 
I'm not going to be able to do that work at this time, however there is a very simple solution.

All of the source code uses lower case filenames when referencing a file. So all you need to do is rename the upper case filenames to lower case filenames to make everything consistent. I used the following command two or three times on the source tree to do that:

Code: 
for f in `find .`; do mv -v "$f" "`echo $f | tr '[A-Z]' '[a-z]'`"; done

You have to run it a few times in a row because as it moves directories it breaks the subsequent move commands. After two or three runs everything will be renamed to its lowercase equivalent.

I don't guarantee that fixes it 100% because I don't cross compile from Linux, but that should take care most of the mixed case issue.

Edit: The makefiles need some fixes too, as they reference the TCPINC, TCPLIB, and INCLUDE directories. A simple sed script to edit those files and lower case those lines is needed.
 
Is there any x86 assembly interrupt call to check for the presence of the mTCP stack and know its status?

A bogus example of what I am asking for:

ax=9090h
int 93h

returns:

CH=11 if mTCP is present.
CL=status (according to some table: not connected, connected, no packet driver set, etc.)

Thanks in advance.
 
minidos622 said:
Is there any x86 assembly interrupt call to check for the presence of the mTCP stack and know its status?

A bogus example of what I am asking for:

ax=9090h
int 93h

returns:

CH=11 if mTCP is present.
CL=status (according to some table: not connected, connected, no packet driver set, etc.)

Thanks in advance.
Click to expand...
mTCP in general is not resident. The TCP/IP function is in a library compiled into programs, not a TSR.
 
Thank you for your answer.

So there is no way to even check if such library is currently open from an x86 assembler point of view?
 
This isn't like the print spooler TSR ... these are programs that run, and when the stop running nothing is left resident.

If you had some sort of TSR or pop-up utility that ran in the background it might make a little more sense, but it's not like that pop-up or TSR would be able to call the library to do anything; that would interfere with the state of the program.

What is it that you are trying to do?
 
I am thinking on DOS multitasking environments like: DR-DOS/Open-DOS built-in multitasker, Helix Multimedia/cloaking driver, Quarterdeck's DeskView, IBM TopView, SoftLogic Solutions Software Carrousel, etc. being able to find out some networking job is running.

A real example of what I would mean:

; Checks whether IPX (Internetwork Packet Exchange) services are available.
; Generally these services are provided by Novell Netware products, but were licensed to many others.

mov ax,7A00h ; low-level api (IPX) installation check
int 2Fh ; call the proper function through interrupt 2Fh
cmp al, 0FFh ; AL=FFh mean YES, it is installed
jne IPX_NO

I hope I am making it a bit more clear. Thank you again for your patience.
 
There are no "services" that get installed that a different piece of code outside of an mTCP program can use.

Trumpet, Microsoft, and Novell use a TSR or device drivers to install networking functions that are available for any program on the computer to use. Those are as close to services as one can get in DOS; you try to detect them through the multiplex interrupt (or whatever) and then if they are available you can use them, usually via a software interrupt.

mTCP and WATTCP programs include all of the TCP/IP, ARP, and UDP code that they need and link that code in statically with the application program. There is no extra entry point that a different program can access or use. When you run the FTP program you get access to the networking code because it's directly linked with the FTP program.
 
I see your point, but then what happens if program "Foo" in a DOS multitasking environment that is unaware of the existence of mTCP, assumes network resources are always available and is run alongside mTCP? All hell breaks loose?

Wouldn't it be reasonable in this case to make mTCP place a signature check somewhere whenever its library is opened?

Thanks again for tolerating my stubbornness.
 
No problem at all! I'm just trying to understand the use case here. Most people are not using DOS in a task switching environment and those that are are probably not going to try to run two networking programs at the same time. It's also impossible to cover all of the other existing networking programs that are not being maintained.

The general DOS way is to make it the responsibility of the user not to run two problems that need conflicting access to the same hardware at the same time. If such access can not be allowed then a locking mechanism should be used. There are plenty of examples of filesystem level type locks used to arbitrate access to resources this way.
 
minidos622 said:
Is there any x86 assembly interrupt call to check for the presence of the mTCP stack and know its status?
Click to expand...
The presence of mTCP is very easy to check. If the program you are running has mTCP compiled into it, then it is present - otherwise it is not. In other words, it is always present.

minidos622 said:
I see your point, but then what happens if program "Foo" in a DOS multitasking environment that is unaware of the existence of mTCP, assumes network resources are always available and is run alongside mTCP? All hell breaks loose?
Click to expand...
There is no global copy of mTCP. Each application runs its own, independent mTCP instance.

The Packet Driver interface is not designed to handle multiple concurrent users, but nothing prevents you from running two mTCP applications attached to different packet drivers simultaneously. You could write a Packet Driver 'shim' to provide multiple entry points (interrupts), but you'd need to figure out how to assign incoming packets to them. The easy solution is to set the hardware into promiscuous mode, assign a separate MAC address to each interrupt, then filter by incoming MAC address. Essentially, each application would become its own system on the network. (Note: This is not compatible with wireless networks.)

mbbrutman said:
I'm not going to be able to do that work at this time, however there is a very simple solution.
Click to expand...
Thanks. I know that manually renaming the files should work, but having to change imported source code is always a hassle. The 'unzip' utility also has the "-LL" argument to force lower-casing of all file names when extracting (this is also the most convenient solution for mass-renaming).

If you could consider this at some point in the future, it would be appreciated. Downstream projects often include a copy of mTCP, making them needlessly harder to cross-compile unless the maintainer does the work himself.
 
You must log in or register to reply here.
Back
Top