Remote control of DOS-Box

[wiwa64]

RMENU is a program to remotely control a computer running (MS-)DOS by a standard TELNET client via TCP/IP. Please feel free to explore it and let us all know, what kind of experience you made with it.

Also available is a new version (1.5) of my former project NTOOL with a slightly improved TELNET function. It can be used as a client for RMENU to remotely control one DOS-box from another one.

 

[Trixter]

By "DOS-Box" do you mean a DOS session running in XP, or DOSBox?

Also, here is a target for you: http://josh.com/tiny/

 

[wiwa64]

No, in this context i mean a "physical" DOS-box, a real computer running DOS.

Thanks for the interesting link. I didn't know about TINY. From what i just read on the referred internet page, it appears to me, that RMENU and TINY are similar in the aspect, that they both do not apply any proprietary protocols.

In my opinion, RMENU does this even a bit more consequently, as it doesn't even need a special (proprietary) client. Rather (almost) any TELNET client can do the job. The price for this is however, that only textmode is supported.

Another difference is the general approach. The TINY server (on the host) is a TSR that sits in the background, directly providing the remote user at the client with a command prompt and thus the "illusion" of sitting right in front of the host. This can be potentially dangerous considering that (MS-)DOS was not designed to be remotely controlled from anywhere on the world. (Imagine some remote user issued the command "format c:/u")

RMENU in contrast runs as an ordinary program, providing an environment in which other DOS programs run. The remote user just sees a menu, from which he/she can pick an item. What theese items actually do, is defined in a configuration file. This file can be set-up in such a way, that one menu item starts a command.com, giving the whole flexibility of the command shell, at the price of the above mentioned risks, but this is not the default. An administrator has the choice to set-up RMENU more restrictively or more liberally, depending on the individual needs.

 

[TNC]

How does it work? Capures the programm the "DOS" output when "standard" routines are used or will it also work when own output routines are implemented? Mpxplay, for example, is using its own routines.

 

[wiwa64]

RMENU has different operating modes. One mode re-directs DOS stdout into a file and transfers this file to the client. This mode will only work if the "child" program writes properly via DOS to stdout.

Other modes read the screen and report its content to the client. Theese modes don't care how the screen output was produced.

But why don't you just try it, or even better, read the manual?

 

[Mike Chambers]

ah, very cool. thanks for the program. i've been using the Waterloo TELNETD.EXE utility for this, but it is downright horrible. for one thing, it reboots when a client disconnects no matter what. also, it's painfully slow. don't even think about using it on an 8088-class machine. it is practically unusable on those. even a 286 is painful to use it on.

i'll give this a try tonight. hopefully it works better!

 

[wiwa64]

Any experiences made, so far ?

 

[Ole Juul]

I don't have a lot of time to play with it right now, but I couldn't resist.

It is likely that I don't understand something, but there were some problems.
- I can't exit the client. Ctrl-C doesn't work. Exiting server does.
- When reading files the space gives a space and not a pg/dn unless I hit enter.
- It will not go to a DOS prompt. Instead it gives the following:

M:\ $rmenu
RMENU V1.0 listening as 192.168.1.109 on port 23

COMSPEC=C:\SYS\MS\COMMAND.COM
PATH=M:\NO;C:\SYS\0;C:\SYS\F;C:\SYS\1;C:\SYS\2;C:\SYS\MS;C:\
PROMPT=$e[31;40;1m$p $$$e[32;40;1m
TEMP=C:\TMP
WATTCP.CFG=d:\comm\wattcp
EDNOSCAN=u m n o

Bad command or file name
Terminating ...
M:\ $rmenu
RMENU V1.0 listening as 192.168.1.109 on port 23
Please enter selection, use '?' to show menu>

When I connect it gives the DOS boxes directory followed by the same as above.

I hope this is useful to you. Right now I can't see a use for the program as FTP is very functional for what I do and requires very few keystrokes. I must say one thing though. When I type "rmenu" the response is instant, which is very impressive. On the client side (linux) the connection is also instant. I like that.

 

[wiwa64]

Well, first of all, thank you for trying RMENU. However . . .

... It is likely that I don't understand something, but there were some problems. ...

. . . your assumption is indeed correct

But let's look further into the details:

- I can't exit the client. Ctrl-C doesn't work. Exiting server does.

That's a not a problem of RMENU, it's a client issue. If i got you right, you used the telnet client of linux. To properly close the connection, you would have to enter telnets "command mode". This is achieved by hitting the so-called "telnet-escape" character, which usually is "^[" (unless re-defined). Then enter the command "quit", which closes the connection and exits telnet. Alternatively, if you were running telnet under some windowing environment like e.g. KDE, you could simply close that window.

Closing down the server (RMENU) causes the TCP/IP connection to be disrupted. Of course the client detects that situation and in turn terminates itself as well. Even though this is possible, it is not the intended way to terminate a session.

- When reading files the space gives a space and not a pg/dn unless I hit enter.

That problem should not only have occured while reading files, rather any command character would only have become effective after hitting <RETURN>. This is again a client issue. To co-operate properly, the telnet client should be used in "single character mode". Under the linux telnet client, again enter the "command mode" by hitting "^[" (or whatever the telnet-escape character might be). Then enter "mode character"
(BTW: This advice you would have found in the manual )

- It will not go to a DOS prompt. Instead it gives the following:

M:\ $rmenu
RMENU V1.0 listening as 192.168.1.109 on port 23

COMSPEC=C:\SYS\MS\COMMAND.COM
. . .
Bad command or file name
. . .

The example configuration file (RMENU.MEN) that comes with the distribution package assumes that your command.com can be found in the root directory of drive C:. As can be seen from the above listing, this is not the case on your mashine. Adapt RMENU.MEN to reflect the actual location of command.com and it should work.

... Right now I can't see a use for the program as FTP is very functional for what I do and requires very few keystrokes.

Well RMENU is inteded to remotely control (administer) a computer running under (MS-)DOS, while FTP tranfers files, which is a totally different kind of job.

 

[mbbrutman]

Any experiences made, so far ?

Don't be discouraged. I've spent a lot of time on my FTP client, IRC client, DHCP client, and Netcat in the last year and I can probably count the number of users on the fingers of my left hand. Nah, that would be too many. ;-0

I've not checked out your RMenu program because I've been traveling for work again, and I don't have an environment setup I can use on the road. I'm thinking about it though .. DOSBox with the NE2000 support would be the foundation of it. I also need to check out NTool 1.5 - that is first on my list.

 

[Ole Juul]

Thanks for your detailed reply.

wiwa64: (BTW: This advice you would have found in the manual )

Hehe, yes I was in a hurry. It is clear that the problems that I had were not with RMENU. I'll have to learn Telnet's operation better as well. Thanks for the pointers. Regarding command.com, I figured that the problem was with my config (that's why I posted the whole thing) - and it works now.

Well RMENU is inteded to remotely control (administer) a computer running under (MS-)DOS, while FTP tranfers files, which is a totally different kind of job.

Actually, I'm not that ignorant . I should have said that my needs for dos box connection were limited to FTP at the moment.

Now that I have changed the RMENU.MEN to access command.com, I am more excited about the possibilies of RMENU. There are many times I could have used (and prayed for!) this functionality in the past. This looks like a significant contribution to DOS software, and I'll certainly be utilizing it in the future. Thanks.

Quote:
... It is likely that I don't understand something, ...

. . . your assumption is indeed correct

LOL

 

[wiwa64]

New version of RMENU

New version of RMENU

The time while you were diligently testing RMENU version 1.0
i used to improve the program. So i can now proudly present version 1.7 with several enhancements:

• The output of RMENU can now be re-directed into a file, for instance for logging purposes
• A new mode: "SHELL" to emulate a DOS prompt which performs faster, at least in some cases.
• Directory patterns can now be further qualified with an attribute class
• Many subtile improvements, e.g. in the mapping of DOS screen output to the TELNET character set
• Improved handling of critical errors
• And more . . . (see enclosed documentation file)

I am pretty shure, that those of you, who found version 1.0 a usefull program, will like version 1.7 even more
(Unfortunately, due to the size limit for uploaded files, it was not possible to enclose the source code in the package)


Please feel free to download the new version and try it. As kind of "appetizer" here two screenshots showing the integrated
development environment (IDE) of BORLAND C, remotely controled by RMENU, processing part of the source code.


Image 1: The semi-graphical telnet client of WINDOS98

Image 2: The same with PuTTY:

.

 

[wiwa64]

Any more experiences made so far?

To me it apears as if many people seem to be too impatient to read the whole thread or how does it come, that the outdated version "Rmemue-10.zip", located at the begining of this thread, had already 35 views, while the improved version "Rmenu17x.zip", located further down, was only downloaded 6 times?

 

[TandyMan100]

Heeeyyy... This looks pretty cool!! I'm definitelly DLing to my spare DOS box!

 

[MikeS]

Now that I have changed the RMENU.MEN to access command.com, I am more excited about the possibilies of RMENU. There are many times I could have used (and prayed for!) this functionality in the past. This looks like a significant contribution to DOS software, and I'll certainly be utilizing it in the future. Thanks.
LOL

Not to take anything away from this fine effort, but there have been quite a few remote access packages for DOS (and Windows) available for many years that could have answered your prayers. I still use PCanywhere daily to administer, run, and remotely back up several DOS systems in the towers of power downtown from the comfort and relaxed dress code (!) of my office in the west end; almost like being there except for the travel time (and the dress code ;-) ).

Being able to transparently redirect printing to the remote computer (or both) is extremely useful; will RMENU have that (and easy file transfers both ways of course)?

RMENU does indeed look interesting though, especially since it doesn't need a client; will have to check it out. Thanks.

mike

 

[Ole Juul]

MikeS: Not to take anything away from this fine effort, but there have been quite a few remote access packages for DOS (and Windows) available for many years that could have answered your prayers. I still use PCanywhere daily to administer, run, and remotely back up several DOS systems . . .

Well, PCanywhere was a bit out of my league, and probably still is - assuming they still charge for it. I got creative with interlnk instead, even though like most of course, it doesn't allow execution on the remote. Now, I'm stuck on the "from anywhere to anywhere" concept so something that isn't universally available (like telnet) doesn't suit me. DOS really needs a small and free telnet (or SSH) server. Rmenu is interesting.

 

[norbert79]

Hello everyone!

My name is Norbert, and I have just been advised to take a look at this page. I have just recently resurrected my old 486, added FreeDOS 1.1, have TCP/IP, SSH2DOS, Arachne and was looking for a BBS, but it seems none is capable of hosting through telnet. While this is probably a part of the old box I will never be able to solve, I just went very happy about this project. Is this still an alive thing? I am looking forward to trying this tonight, so I would like to thank wiwa64 for making this project.

Btw my hardware: MSI motherboard (afaik), AMD 5x86 133 Mhz CPU, 40 MB of RAM, AWE 64 (512 kb of MIDI RAM), 5 GB of HDD (partitioned using Damn Small Linux and booted using Linux Smart Boot manager floppy since the ~4GB BIOS limitation) Sis 6326 videocard with 4 MB of video Ram, attached is an LCD display and a PS/2 keyboard with cord extension to regular AT keyboard. I still have an older mouse, never was able to make any recent PS/2 mouse working.

So thank you again! I will try to post my experiences when I can share some.

Regards:
norbert79

 

[Ole Juul]

Welcome norbert.

The telnet BBS problem seems to a persistent issue. Mike B (who wrote mTCP) is apparently working on one so one of these days. It still seems that the best way to run a telnet BBS is using Linus - but then we're not talking vintage any more.

Anyway, hang around. This is a great forum.

 

[Caluser2000]

Anyone tried http://www.elebbs.com/index.php?category=6

 

[mbbrutman]

Welcome norbert.

The telnet BBS problem seems to a persistent issue. Mike B (who wrote mTCP) is apparently working on one so one of these days. It still seems that the best way to run a telnet BBS is using Linus - but then we're not talking vintage any more.

Anyway, hang around. This is a great forum.

I'm still working on the BBS. I've been adding Xmodem and Ymodem to the Telnet client and testing those. Assuming that those work well, they will be added to the BBS code so I will have some upload and download capability.

When it gets done it will definitely run under FreeDOS - just like the rest of the mTCP apps do. And on a low-spec machine too.

(I was going to integrate the FTP server into the BBS, but I don't think I have the stomach to do that. The FTP server was a giant project.)



Mike