• Please review our updated Terms and Rules here

DOS VNC Server and/or Win3.x VNC Server/Client

Shadow Lord

Veteran Member
Joined
Jun 16, 2010
Messages
3,233
Location
California
My googling points to negatory but thought I ask here as well. Anyone know of a DOS VNC Server (not client) and/or Win3.x VNC Server/Client? I just want to be able to control my text based DOS programs from other computers in the house. Heck, mostly I plan to be doing plain DOS stuff (like DIR, COPY, MD, etc...) and since I have VNC on all my other systems a VNC on an older system would be great! Thanks!
 
Thanks for linkage. I had found TINY on my own but the java client kills it... RMENU sounds interesting and worth a serious look! But VNC would be best if it exists...
 
Thanks for linkage. I had found TINY on my own but the java client kills it... RMENU sounds interesting and worth a serious look! But VNC would be best if it exists...

I'm pretty sure I came across a VNC client but I can't seem to locate it on my machines ATM, but a server is another story. I couldn't get TINY to work as far as I remember. RMENU is not a telnet server, but it is very interesting and indeed unique. One of the statements I made on that thread was that I didn't know of a functional telnet server - I've been looking for years. Funny how nobody challenged me on that. Presumably nobody else on this board knew of one either. Except .......

@Chuck(G) thanks for that link! I've been asking and looking for that and for some reason nobody, besides you, has known where to get it. I just tried it and even without configuration it just works. Very nice! Again thanks. :)

That said; I find that I use my DOS box mostly as a client and it is a nice way to control more powerful boxes. To me that is one of the reasons Mike's mTCP telnet is such an important contribution.

Edit: Oops, I've just tried the telnetd program some more. It hangs sometimes, crashes others. Needs too much work to be usable yet. Too bad.
 
Last edited:
Long before KVM switches and whatnot, a friend and I developed an ISA board for the 5150. It used a Z80 and some DRAM and mapped into the MDA buffer address space. It looked at the buffer area periodically and issued ANSI/VT220 control codes over a RS232C connection to remote VT220. Similarly, it connected to the keyboard port.

The cool thing was that it could split-screen what was happening on the PC with a remote connection to another system on the same VT220.

We sold a few (< 100) to a few OEMs, but it obviously couldn't do graphics and didn't do well on anything faster than the basic 5150/5160.

I still have the card and the original source code. It was a way to remotely operate a PC without impinging on the system resources.

Our next product was a card that could be used operate three 5160s as a fault-tolerant majority-voting system. You could kill power on one machine, disconnect the hard disk, or any sort of failure. The card would reboot the system, run some diagnostics and bring the system into sync with the others. It was pretty cool and almost worked, but supporting masses of third-party peripherals eventually doomed the project. This was at a time when Tandem computers were hot and Bill Gray was the authority.
 
Last edited:
VNC client for dos http://arcady.chem.anrb.ru/vncdos/ though the OP wasn't after that. It's nice to know its there all the same. . . .

I just downloaded that. Unfortunately their instructions "To install just unpack vncdos.exe" fails because of lack of inclusion of the vncdos.exe. The source is there though.

Anyway, it got me thinking. What is the difference between a VNC and a telnet connection when you're using DOS? I do a lot of my computing over a telnet connection around here and I don't see any difference when I sit at the actual computer to which I'm connecting. Well - apart from translation problems between terminal types if they are different.
 
Last edited:
Long before KVM switches and whatnot, a friend and I developed an ISA board for the 5150. It used a Z80 and some DRAM and mapped into the MDA buffer address space. It looked at the buffer area periodically and issued ANSI/VT220 control codes over a RS232C connection to remote VT220. Similarly, it connected to the keyboard port.

The cool thing was that it could split-screen what was happening on the PC with a remote connection to another system on the same VT220.

We sold a few (< 100) to a few OEMs, but it obviously couldn't do graphics and didn't do well on anything faster than the basic 5150/5160.

I still have the card and the original source code. It was a way to remotely operate a PC without impinging on the system resources.

High-end servers often have a "Lights Out" capability (that's a brand name). This board has a separate Ethernet connection and is powered on even when the CPU is powered off. It allows you to remotely boot and change bios settings, or power cycle a frozen box even if it does not respond through the OS. This works with any OS, but is probably pretty specific to the server hardware.
 
Anyway, it got me thinking. What is the difference between a VNC and a telnet connection when you're using DOS? I do a lot of my computing over a telnet connection around here and I don't see any difference when I sit at the actual computer to which I'm connecting. Well - apart from translation problems between terminal types if they are different.

For text mode DOS probably not much. But I like having options and VNC SHOULD allow you to run a much larger set of programs then just telnet. Plus my LAN is setup for VNC (ports are open, client on every computer) where as w/ telnet I need to do some work. Again all minor stuff unless you need graphics support or want win 3.x control. For now telnet seems the way to go.
 
I just took the time to read the docs for TELNETD. It is very similar to TINY in many respects - both 'scrape' the screen and inject keystrokes into the local keyboard buffer.

TINY uses an external TCP/IP stack (a TSR from Novell), it only uses UDP, and it can handle graphics. TELNETD uses WATTCP (and is written by the author of WATTCP), only handles text, and appears to be using TCP/IP sockets. The DOC says that once you login it converts to a TSR, but I'm wondering if it does a 'shell' command so that it can remain resident while the logged in user is working. That would be much easier and work about the same.


Mike
 
I just took the time to read the docs for TELNETD. It is very similar to TINY in many respects - both 'scrape' the screen and inject keystrokes into the local keyboard buffer.

TINY uses an external TCP/IP stack (a TSR from Novell), it only uses UDP, and it can handle graphics. TELNETD uses WATTCP (and is written by the author of WATTCP), only handles text, and appears to be using TCP/IP sockets. The DOC says that once you login it converts to a TSR, but I'm wondering if it does a 'shell' command so that it can remain resident while the logged in user is working. That would be much easier and work about the same.


Mike

TINY is far superior to TELNETD, not only in performance but features (obviously) and TELNETD is incredibly annoying in that when you disconnect, the machine reboots. that made me facepalm. oh, and TINY can use either PC/TCP or Novell actually!
 
Well, I tried both the NCSA server and the WATTCP server and could get neither to work. As far as I can tell I am setup correctly. The Megacube is on the LAN an MS Client can setup a connection. I then loaded the packet driver for my NIC and that seemed to go fine as well. However, when I run the NCSA telnet server it just crashes and when I run the WATTCP it tells me packet driver not found and then crashes. Any ideas? Thanks.
 
Just to be clear, you are not trying to run the MS client at the same time as the packet driver, right? It's one or the other ...
 
Just to be clear, you are not trying to run the MS client at the same time as the packet driver, right? It's one or the other ...

That would be a negatory :stupid: Honestly, DOS networking is not my forte. I had assumed since the MS Client uses NDIS and the servers go through the packet driver the two could co-exist. :sigh: I'll try w/ out the client running and see what happens.
 
Well, look at it this way - both the NDIS driver and the packet driver are trying to talk to the same piece of hardware. If they are both doing it at the same time, bad things will happen to you.

DOS networking is not a mystery - have patience and you will get it.
 
Back
Top