Well, the good news first: I experimented a bit more with your mTCP and especially the ping utility and my conclusion is:
Just leave it alone. With a little bit trickier configuration, LANSTAT can perfectly interact with mTCP's ping. Here's the configuration:
Code:
GTEST "c:\mtcp\ping -count 1 0.0.0.0" imeout
PTEST "c:\mtcp\ping -count 1 \a" reply
The first statement GTEST defines something i call global test. LANSTAT performs this test only once at program start-up. In this case it issues a ping to address 0.0.0.0. If this ping times out, then everything is OK because it means that no error of the type "You must set the MTCPCFG environment variable" or "packet driver not found" ocured. If it did, than further processing is pointless and LANSTAT would terminate.
The only minor annoyance is, that the ARP timeout spells the word as "Timeout" while the actual ping time-out is spelled "timeout". To cope with that, the statement just searches for "imeout". So if you absolutely want to improve something, then take care of a uniform spelling.
The second statement is the actual ping that regularly polls the different hosts. The "\a" wil be replaced by the actual ip-address and the result is positive, if the word "reply" can be found in the answer.
I think about the constant loading the command processor, having it invoke another program, redirecting the output, and parsing the output and I cringe. That's going to limit how many times per second you can call out to ping.
I think, the time for loading the command processor and have it invoke another program, is still neglectable compared to the time ping takes for itself, especially when running into a time-out.
(Well, running it on a floppy based system might not be such a good idea) Furthermore, it is not desirable to "flood" the net with ping requests, rather the extra network load caused by LANSTAT should be kept as low as possible. Therefore it even provides for the ability to define additional delays.
In the ping program I can add a flag like you suggested to test for the presence of a correctly configured network stack, or I can 'trap' the loopback address at a high level, presume that it is meant to test for the presence of a correctly operating stack, and fake a result. I actually prefer the separate command line option, because it is explicit. In my past post I was speaking in more general terms about proper loopback support for the stack, which would require the stack to detect the loopback address ranges and do a memcpy to an input buffer that is normally used by the receiving code. I might make this a configurable option using #defines so that the applications that don't need it don't have to pay for it. It might be useful.
Well, as already written above, it is not really needed. On the other hand, it might be a good idea anyway, to have some kind of self test, some software, be it a special switch to ping, be it a separate utility, that clearly and relyably tells "configuration OK, network operational" (or not) and that other software can depend on.
Extreme addresses .. split your IP addresses into two fields, network and host
Network = 0, Host = 0: This network, this host (An alias for loopback)
Network = 0, Host = x: A host on this network, but the network is not specified
Network = all ones, Host = all ones: Broadcast to the local network
Network = x, Host = all ones: Broadcast to network x
Network = 127, Host = x: Loopback to this machine
The first two are generally considered invalid. I support broadcast to both the local network and to a different network. I don't support loopback because none of the apps use it yet.
I'm not sure what happens if you do a broadcast ping. My code might not parse the incoming responses correctly. But, that might be a more efficient alternative than calling out to command.com and ping for each machine in the list.
As i just wrote, i experimented a bit. I didn't use a network sniffer though
(even though i once wrote one myself) i only observed the external consequences. The address 0.0.0.0 is not rejected, it just runs into a time-out. I don't understand though, why it's sometimes already the ARP that times-out while in other cases it seems to be the actual echo-request that timed-out. I wonder who could have answered an ARP rquest for 0.0.0.0. The host's own address (not the loopback address 127.0.0.1) also runs into a time-out.
On the other hand, a ping to the braodcast address 255.255.255.255 was anwered. As already stated, i did not explore by whom, but there was only one more active host on the net at that time. I wonder what might have happened if 10 or maybe 100 more hosts would have been active and i could imagine that you will have a hard time if a network administrator finds out, that your program is the originator of such a broadcasted ping.
Lastly, I'd look into spawn again. Watcom doesn't say what happens to stdout, but it might go to whatever file descriptor 1 is pointing at right before the spawn. Which would give you a way to catch output on stdout without having to go through command.com. And you get a return code, which is missing from the 'system' method of doing it.
Yes, i also looked into some code using spawn, i once wrote. It doesn't seem to be as hard to do, as i originally was afraid of. But it wouldn't have solved the problem anyway as i'm not just interested in the fact that
something went wrong, i rather want to know, did it go wrong due to some external cause like e.g. host currently not responding, which might go away all by itself, or did it go wrong due to some fatal internal error, like unaccessable packet driver, which makes any further operation pointless.
