• Please review our updated Terms and Rules here

The next mTCP update is coming soon ... last call for bug fixes and ideas!

I hate to say, I didn't watch much futurama, but it did look like fun.
I didn't get the reference, but I can live with it.
My question is, can that futurama reference and the NTP's line "aye aye aye...greater than 10 minutes!" be turned off via a switch?
I am running this on computers without clocks and batteries.. it is noise in that case
But really, I can live with it.. it's all well, done, Mike! :0)
Features to switch-off stuff may just fatten up the product.. it'll be fat like MS in no-time! lol ;)
 
I think you are referring to SNTP and not NTP, and the actual quote should be "Difference between suggested time and system time is greater than 10 minutes!"

I think that one line of warning text is not a great burden. If the text is bothering you then you can probably get rid of all of it by redirecting it to NUL: and checking ERRORLEVEL inside of a DOS batch file. ERRORLEVEL 0 means the time was set, and anything else means it was not set.
 
Naw, it's no burden. As I said, it's all done very well and I can't think of any missing features for your products which I use. That's probably why krille and I mentioned very minor aesthetics.
mbbrutman said:
If the text is bothering you then you can probably get rid of all of it by redirecting it to NUL: and checking ERRORLEVEL inside of a DOS batch file. ERRORLEVEL 0 means the time was set, and anything else means it was not set.
Click to expand...
I've never done something that. I look forward to tinkering with that idea as soon as I can. It might me challenging for me. :D
 
Unicode / UTF-8 support in IRCjr (maybe also in the telnet app) :)
Goofy suggestion: An MPD client, (started thinking about doing something simple like this myself).
 
Unicode support has been on the todo list for a while; as I explained over at Vogons it's just basically a mapping problem. For CGA and MDA the mapping problem is simple given the limited choice, but for EGA and VGA with loadable fonts and DOS codepage support it becomes more interesting. As a US English native speaker I've never had to deal with that complexity, so I have to learn the DOS codepage support to make this happen.

MPD? I don't think that anything is going to sound too good on my PCjr's three voice sound chip, or on an XT speaker.
 
mbbrutman said:
Unicode support has been on the todo list for a while; as I explained over at Vogons it's just basically a mapping problem. For CGA and MDA the mapping problem is simple given the limited choice, but for EGA and VGA with loadable fonts and DOS codepage support it becomes more interesting. As a US English native speaker I've never had to deal with that complexity, so I have to learn the DOS codepage support to make this happen.

MPD? I don't think that anything is going to sound too good on my PCjr's three voice sound chip, or on an XT speaker.
Click to expand...
Wait... Unicode support is possible in MSDOS, without an libiconv port (I'm convinced that the GNU Project wanted to pretend MSDOS didn't exist!)?
 
Unicode is just a character encoding. Anything can support Unicode. The tricky part is actually trying to render the characters.
 
I am guessing you know about the MPD (music player daemon) and commenting about sound chip and PC speaker was just being silly back at me :)
It could be done quite easily though, adapting the telnet client for example, because controlling MPD is just sending text commands "play [song_ID]", "volume [nn]", over a TCP connection to the MPD server (usually to port 6600).

The unicode is a different thing, more serious :) and a bit more complex depending on the ambitions. Just being able to recognize the multi-byte sequences and mapping where possible would help a lot though. Even just using CP437 for rendering wich all display adapters have, I think it would take care of most European languages.
 
TJ_Mossman said:
how about traceroute?
Click to expand...

Traceroute is possible, but not for the next release. I was planning on pushing new code out in the next few weeks. I'll add traceroute for the longer term list. (It is a good idea ...)
 
Hey Mike, I've got what looks to be the April 2013 release of MTCP on my PCjr, and I just noticed today that the applications don't work if your DHCP lease time is less than an hour. Any specific reason for that? All the network equipment I'm using now was set up for 3600 second lease times by default, so I had to change all of those to longer time periods to get on my network today.
 
In the first post in this thread:

DHCP: add an option to deal with short lease times


Mike
 
Last edited:
mbbrutman said:
In the first post in this thread:

DHCP: add an option to deal with short lease times


Mike
Click to expand...

Agh, I read that and then it completely slipped my mind by the time I got to the end of the thread.

(I will go ahead and say I read this thread several days before I noticed it was an issue for me, though.)
 
Last edited:
mbbrutman said:
The "Good news everyone!" is a reference to Professor Farnsworth from Futurama - it is an integral part of the program and it can not be removed without causing a rip in the fabric of space and time.
Click to expand...


Yay, that's my favorite part of booting up! :]


mbbrutman said:
Traceroute is possible, but not for the next release. I was planning on pushing new code out in the next few weeks. I'll add traceroute for the longer term list. (It is a good idea ...)
Click to expand...

Ooh, that'd be nice. Any chance of an mTCP SSH client?
 
I seem to recall reading that SSH would be too CPU intensive on XT class systems, then again, 8088 MPH was a thing that happened so...

Mike?
 
I don't know what the CPU overhead would be. I'm sure it would not be pretty.

The bigger problem is that the necessary libraries are not available or out of date. Without some code to reuse the task becomes too large except for a team of people.
 
With the way the Internet is going- how everything is becoming HTTPS- soon there may not be a choice but to add SSH support- lest MTCP's utility be limited to LANs. We either will need custom hardware that transparently does SSL encypt/decrypt (which is cheating, IMHO), or just have to take the performance hit.

The modern Internet just isn't friendly to old or slow devices. I personally think its ridiculous.

Matrix SSL is an embedded SSL library that'll most likely fit on an 8086 though.
 
You must log in or register to reply here.
Back
Top