TINY

Overview

TINY is a set of programs that lets you control a DOS computer from any Java-capable machine over a TCP/IP connection.  It is comparable to programs like VNC, CarbonCopy, and GotoMyPC except that the host machine is a DOS computer rather than a Windows one.

Screenshots

		Check out this amazing screenshot where I am using my 3.2Ghz Windows Server 2003 SP1 box to simultaneously control two DOS 6.22 boxes over the internet. The first DOS box is a Dell 90Mhz Pentium where I am using FoxPro's handy built-in calculator feature to figure out what 22 divided by 7 is. The second controlled DOS box is a Northgate Turbo 386 where I am using WordPerfect Office's excellent stand-alone calculator product to perform the same calculation - albeit with different results. Note that I am about to send a Shift-F1 keystroke to the FoxPro computer.
		I can honestly say without any exaggeration that this screenshot shows what is, by far, the most amazing thing ever done with a computer in history. If you look carefully, you will see that this is a Windows XP SP2 machine on which I am using Sun's Java Runtime Environment 5.0 to run the TINY client bytecode and connect over the network through a Linksys WRTP54 router back to a virtual machine running on the same XP computer using Microsoft Virtual PC 2007 to boot up MS-DOS 6.22 to load the TINY host and execute an old EGA version of Tetris that was compiled with TASM 2.0. Through this arrangement I am able to achieve performance comparable to a 16Mhz IBM PC-AT using my 2.8Ghz Intel Core2. Wow. If you are not impressed, then you probably do not fully understand what is going on here.

TINY Features

• UDP based - Get rid of those proprietary protocols on your network once and for all!
• Eliminates need to load NetBIOS - More lower 640K memory available!
• The blinking cursor lets you know it is working. And the cursor even matches updates to match the hardware cursor on the host machine. Now that's amazing!
• Works with all on-board and add-in video cards- no extra VGA card needed!
• Permits multiple people to control the same machine simultaneously. Who needs AIM? Just have you and your friend TINY onto the same DOS box and chat away (be sure to preface each line with "echo" and don't start typing until the other person hits enter)!
• Does not crash your client if the host reboots!
• Handy pop-up menu lets you send ANY key combination. No more sprained thumb ligaments from trying to type LEFT SHIFT P with one hand!
• Client selectable screen refresh rate- generate as little or as much network traffic as you want. Great for playing text mode graphics games over the network!
• Works over the "Internet"- Execute a SET ORDER TO command on a FoxPro 3.0 machine in NYC from a café in Reykjavik!
• Multiplatform Java client lets you control DOS machines from Windows, Linux, Mac OSX, even your cell phone!
• Instant connection startup- no more eye rubbing while waiting for your first connect of the day!
• Source code and protocol documentation available- have confidence that TINY will continue to be viable for decades to come (or at least until all your CMOS batteries go dead)!
• Uses either the Novell Client32 DOS TCP/IP stack or the FTP Software OnNet PCTCP TCP/IP stack- the two most popular DOS TCP/IP stacks in history!
• Toggleable status window helps you diagnose network issues.
• Fancy "About" box incase you forget where you downloaded it.
• Thanks development sponsored by SICK|MAIHAK , TINY now supports many VGA graphics modes including 640x480x16!
• Also thanks to your friends at SICK, TINY now better supports foreign keyboard codepages.
• Reliable keystroke processing means never having to type the same key twice when you only mean it once.
• Lots of command-line options to customize the TINY launch state to exactly the way you like it every time!
• The blinking LED in the icon tells you that it's working- even when the window is minimized!
• Ability to load custom keyboard translation tables. Now you can make TINY work with any foreign keyboard, or just make it so that pressing the enter key types a smiley face on the remote system!
• Use any UDP port you like - run dozens of copies of TINY on your NATed internet connection!
• Thanks to development sponsored by Electronic Flow Control A/S, now supports Hercules graphics too!
• TINY now supports screen scaling so you can fill your new 30" monitor edge to edge with DOSness!
• Choose from streamlined or full featured version depending on how much you need and how much memory you can spare.
• Load custom fonts on the TINY client to suit your screen size, language perference, or mood.

Rave reviews for TINY from around the world

"Thanks to TINY, I never have to go to work anymore. Now I can control all my DOS machines while sitting home and watching Tivo!"

-Mario Russo, President Sport Page Inc., New York, USA

"I would like to congratulate you on making a program that is very useful for us here on the farm. I was told by several companies that this could not be accomplished. You have proved them wrong. Not only can I remote control the dos machine, now I can remote control the entire computer via VNC including the dos machine from any machine on our network."

-Bobby Bloyed, Leyland Farms, California, USA

"I've tried Your new version of TINY and found it failure-free and mature. Our application has succeeded. I am very content with Your results. Congratulations!"

-Marcin Krajka, R&D Division, SICK MAIHAK GmbH, Meersburg, Germany

"Thank very mach. I came on yours the Internet page very much frequently and waited for new release of program Tiny remote control for Dos. Has loaded the program at once as soon as you have laid out it. Thank you for your work,  cyrilic fonts is displayed correctly, the client in 5 times became easier, in general emotion while only positive."

-Bveb, Minsk, Belarus

"TINY makes me wish I hadn't of ported all those DOS applications over to Linux!"

-Brian Nigito, Big Time Programmer, Financial Services Industry, New York, USA

"This is the finest piece of freeware I have ever seen. Its easy to use, reliable, robust and the support is quite amazing! I installed it in minutes and my system has never..... NEVER objected to it being there.  Top marks to Josh for providing this."

- Simon Edwards, Integrated Communication Systems Ltd., Cambridge, UK"

"What is TINY?"

-Cliff Spielman, Consultant, LA, USA

Background

I had a strange problem - I had a room filled with several hundred MS-DOS machines that I needed to control. I wanted to control them from my desk, and on my desktop I was running windows.

There are plenty of programs for remotely-controlling Windows machines. There is even a program that can control DOS machines from DOS machines. There were not any good programs that could control a DOS machine from a Windows machine.

So I wrote TINY. It was inspired by TNE.EXE and VNC.

TNE.EXE (full name, "The Network Eye") was developed by Artisoft, Inc. and first released in late 1988. Artisoft's LAN operating system, named LANtastic, also used NetBIOS. The host was very small (only about 4kb) and very reliable. I wanted the TINY host to be very small and reliable also.

VNC is a multi-platform remote control system. The protocol is simple and you can get hosts and viewers for most platforms and can control on platform from another. I wanted to be able to control a DOS machine from a wide variety of modern machines using a simple protocol.

The TINY host is written in C and runs as a small TSR in DOS. It uses the Novell or PCTCP networking API to listen for incoming UDP requests. It extracts keystroke requests from incoming requests and sends back snapshots of the local screen via UDP packets.

The TINY viewer is much more interesting. It is written in Java and should run on any Java platform. Replicating the appearance of a DOS screen in Java was a challenge. To make sure I got all the DOS colors exactly right, I had to dump the color table out of an old VGA card. To make sure I got the font exactly right, I dumped the font table out of an old VGA card. The result as that a TINY viewer looks *exactly* like the DOS screen it is viewing. Anyone who spent any time using DOS will immediately recognize that a TINY screen looks distinctly different than a Windows Command Prompt window.

Download

Quick Start

1. Setup a DOS machine running MS-DOS 6.22 and either with Novell or PCTCP network stack. This will be the host.
2. Setup a machine that can run graphical Java programs (Windows, Linux, QNX, Solaris, etc.). This will be the client. (You can download the latest Java Runtime here.)
3. Make sure the two machines can PING each other. If they can't PING, then they can't TINY.
4. Copy the appropriate TINY host executable onto the DOS machine from TinyHost.ZIP and run it by typing...
   
   For Novell stack:
   TINYH_N password password
   For PCTCP stack:
   TINYH_F password password
   
   
5. Copy the TinyClient.jar file onto the graphical machine and run the client by typing...
   
   Replace the 'x.x.x.x' with the IP address of the host machine:
   java -jar TinyClient.jar x.x.x.x password
   
   
6. You should see the host screen come up on the client. The cursor blinks each time an update is received. Click anywhere in the window for a menu. Try running the Tiny client with no parameters for options.
7. Send me an email telling me what you are using TINY for so I can add you to my list and keep you updated with future TINY news!

Quicker Start Demo (for a Windows machine on a network with a DHCP server only)

1. Download and install Virtual PC from Microsoft here.
2. Download and unzip the TINY virtual machine image files from here and save it on your computer.
3. Double click on the TINY virtual machine image file you just unzipped. The should launch a virtual DOS machine with TINY loaded.
4. Download and install Java from Sun here.
5. Download the TinyClient.jar file from here and save to your hard disk.
6. Start a command prompt and go into the directory where you saved the TinyCleint.jar file.
7. Enter the following command..
   
   java -jar TinyClient.jar 192.168.15.2 password
   
   ...except where it says "192.168.15.2", you are going to use the IP address of the virtual machine you started in step #3. You can find that address on your screen- look at the number circled in red in the example below...
   
   
   
   
8. Play with TINY! While this demo is not terribly useful, but once you have a running example, it should be easier to see how everything works.

FAQ

Q: Why on earth would I ever want to use TINY when I can just run my DOS programs directly on my Windows machine using Virtual PC or VMWARE?

I love Virtual PC and think it a great tool, but here are a few examples (taken from actual TINY users) when you might still need TINY...

• The DOS machine needs to be physically located in a remote location (like inside a nuclear power plant smokestack or on top of denim cutting machine) because it is directly connected to some sensors and controllers.

• You only have a license to run your DOS software on a single physical machine, but you want multiple people in multiple locations to be able to use the software.

• Your DOS software is incompatible with Virtual PC.

• You don't want to use a Windows machine because your DOS machine hasn't once crashed in over ten years and you like it that way.

• You can't afford to buy a new Windows machine(s), especially when you already have a perfectly good Turbo XT machine(s).

Q: I am able to connect to the remote TINY host and even type on keyboard, but I just see a blank screen on the client, what should I do?

While the TINY host does the best job it can of auto-detecting the current screen mode and active page, in DOS this is not always reliable (especially with non-VGA video cards).  You can try manually selecting video modes from the pop-up menu on the TINY client until you find the mode/page your host is in. Once you find the correct screen mode for a given video card/application, you can look up the mode number in the TINY status window and specify this number on the client command line using the "/M" parameter. This way the TINY client will launch already in the correct mode next time.

Q: TINY works fine when I connect from a machine on my local network, but it doesn't work when I try over the internet.

It sounds like the UDP packets that TINY uses are getting blocked somewhere between the host and client when you try to communicate over this internet.

This could be due to a firewall or NAT router on either side of the connection. Make sure that you do not have UDP port 25443 (the default port Tiny used) blocked anywhere.

Also, if you have a NAT router, you might have to add a Port Forwarding entry for UDP port 25443 that points to the TINY host machine's IP address on the local network.

Q: Can I have multiple TINY clients viewing the same host simultaneously?

Absolutely, as long as you have enough bandwidth to carry all the packets. Try using higher "/D" settings on the client if bandwidth becomes an issue.

Having multiple clients can open up interesting opportunities. You could make a very simple billboard system by setting up a single DOS host and giving one person the control password and all the other people the view password. The person with the control password would be able to type messages on the screen, while the other people could only view the messages as they were entered.

You could even use TINY's ability to manually select between the various host video pages to set up a pseudo-multi user system. Imagine you had a PC that was controlling a set of conveyor belts via its serial ports. You could write a simple application that showed the speed and load for each belt on a different DOS text page. By having different people select different DOS pages to view on their clients (either manually via menus or with the /M command line parameter), you could have four different people watching the different screens at the same time on the same DOS host. By carefully picking non-overlapping control keys (belt one uses "Q" to speed up, "A" to slow down; belt two uses "W" and "S", and so on), these people could even simultaneously and independently adjust their respective belt speeds. Pretty cool, huh?

Q: When I restart the host, the client continues running without updating the screen. It would be nice to say something like "Lost connection to Tiny Host" and blank the client screen.

I think this is a matter of taste. I actually prefer the current behavior. After I reboot, I like to leave the client running so that I can see it start to update again the moment the host machine comes back up. Also, for the client to detect that the host was about to restart, the host would have to send some sort of special "I'm about to reboot" packet to the client. This makes things very complicated. What if that packet got lost? So you would need the client to send a acknowledgement "I heard that you are about to reboot, go ahead" packet back to the host. What should the host do if it never gets the acknowledgement? Then it could never reboot! Since you (or at least I) usually have a good reason to do a reboot, I usually want it to be as quick and direct as possible with no chance that it could not happen.
 

Q: I found that I can start the client and point it anywhere and the client will start but with a blank screen.  It would be nice to return something like "No Tiny Host found at this address".

TINY uses UDP, which is a connectionless protocol. This makes it efficient and simple, but also means that there really is no connection between the client and server, just a bunch of unreliable packets. There is no difference between pointing it to nowhere and pointing it to a valid host and just having the packets get dropped. Interestingly, this is also a problem with TCP/IP, it is just hidden so most people don't think about it.

There are three ways to know if you are actively getting updates or not...

• The cursor blinks every time a new update packet is received from the host.
• The program window icon blinks every second when updates are coming in.
• You can watch the status window and if you don't see packets coming in then you know that the
  screen is not updating.
   

Once you get used to it, you will intuitively know that your connection is dropped or at least lagging by watching the cursor.

Keep in mind that there *ultimately* is no difference between a non-connection and just a sequence of packets getting lost. Networks are not magic. With most connection-oriented protocols (i.e. TCP/IP), the protocol specifies a fixed amount of time to wait for packets before arbitrarily giving up and declaring a connection to be "lost". 

With UDP (and thus TINY), it is up to you to decide if the screen is not updating enough for the connection to be considered down, and that really depends on your application.  If not enough packets are getting through, then there really is nothing you can do but wait anyway, restarting the client will not change anything since the problem is some where between you and the host and as soon as the problem is solved and the packets can get through, the client will start updating again.

Q: How can I run TINY from a Windows shortcut without starting a Command Prompt window?

One option is to right-click "properties" on the shortcut option and select "run minimized". This will start the DOS window minimized, although it will still be there.

Set the shortcut target to point to "javaw.exe" rather than "java.exe" if you don't want to see the dos box at all. JAVAW doesn't start a command window, so you won't see any error messages that might come up. TINY doesn't really print any error messages after it starts, but Java itself might rarely (I.e. OutOfMemory exception, NetworkHardware exception, you get the idea).

Q: How much bandwidth does TINY use?

Here is how TINY works: Client sends request packet to host, then host responds with a screen snapshot packet. By default this happens 10 times a second (100ms delay between requests). Each request is tiny, less than 100 bytes. Each response is a full screen worth of data- 80x24x2 = about 4K bytes. So, by default TINY uses about 0kb/s up and 40kb/s down bandwidth for viewing DOS text screens.

Depending on your application, you can probably reduce the update rate to once or twice a second (500ms or 1000ms delay) and greatly reduce the bandwidth.

Note that graphics screens have a lot more data, so either they update less often or use more bandwidth depending on how you set the update rate.
 

Q: Is TINY secure?

No! TINY is extremely *not* secure. Anyone with a network sniffer attached to your wire will easily be able to see every key you press, everything on your screen, even your TINY password. Note that this is also true of VNC and many, many other protocols you probably use every day. In the end, good security is very hard to do correctly, so I'd rather make TINY "explicitly insecure" than "probably secure" like most programs. If you want a secure, encrypted version of TINY, let me know and I'll try to help out, but I bet I can find lots of other ways people will be able to get the same data from you regardless of how secure TINY is.

Q: Graphics screens are so darn big, how did you squeeze them though such a tiny (pardon the pun) wire?

TINY uses a clever technique of "slicing" the graphics screen into lots of little pieces (40 of them for 640x480x16 mode) and sending each slice in a UDP packet. This is why you see that psychedelic painting pattern when watching the TINY client paint a graphics screen. This is nice because it limits network bandwidth, reduces the maximum UDP packet size to something that DOS stacks can handle, and does not require a memory-wasting buffer on the memory limited DOS machine. The downside is that you never see a single snapshot of the remote graphics screen for that screen is constantly being updated.

In VGA 800x600x256 mode, TINY also uses a technique called "nibble compression" where it takes 256 colors on the host screen and compresses them down to only 16 colors. This uses half as much bandwidth, but means you don't see as many colors. You can manually select the full color mode on the "Screen Mode" menu.

Q: Can you make TINY support the Microsoft DOS Network Client 3.0 TCP/IP stack?

Thanks to Mark Phinney at cflsb.com, I now have the Microsoft TCPIP SDK files so in theory it should be possible to make TINY work with this stack.

Unfortunately, it looks like the Microsoft stack limits the packet size to 1400 bytes so it would take some effort to make it work efficiently. If you REALLY need to get TINY working on this stack, let me know and maybe we can make it a project.

Luckily the Novell stack is free and good, so most people are happy with it.

UPDATE: Chris McFarling has been able to get the MS Client running concurently with the Novell Client32! This means that you can have a DOS machine that runs TINY and can log into a Windows server. The only real downsides here are (1) it uses more memory, and (2) it is more complicated, but you really can't beat this solution if this is what you need. You can download his VIrtual PC floppy image file here, and then boot it up on your machine and take a look to see how he did it and adapt it to your configuration. You'll need to use Virtual PC 2007 since the new Virtual XP version does not have an easy way to mount floppy images. Also note that you need to have NetBUI enabled on the server machine.

Q: Can you make TINY support the WATTCP TCP/IP stack?

While certainly possible, it would take some effort to make it work efficiently. If you REALLY need to get TINY working on this stack, let me know and maybe we can make it a project.

Luckily the Novell stack is free and good, so most people are happy with it.

Q: Can you make TINY run with no extra TCPIP stack?

I'd actually love to start a project to have TINY talk directly to the network card, probably using a Crynwr packet driver. This would reduce the amount of memory needed on a TINY host and with one less piece of software things would generally be simpler to set up. Let me know if you have a good reason to need this.

Q: How do I use custom keyboard translation tables?

Use a text editor like NOTEPAD to take a look at the sample translation files to get a feel for the very simple format. To load one or more translation files, use the /X command line parameter when loading the client. For example, to load the TINY client with both the sample translation files, you'd type something like...

java -jar TinyClient.jar /Xmathkeys.txt /Xgermankeys.txt x.x.x.x password 

...assuming that you already saved those two files into the current directory.

Q: When I connect to the TINY host, I get a "Host mode unsupported" message.

There are a huge number of graphics modes available on the various brands and models of graphics cards and there is no standardized way to access these modes in DOS, so TINY only includes support for some of the most popular modes.

First, make sure you are using the "extended" version of the TINY host that includes graphics support. If you try to view a graphics screen with the standard version of the host, you'll always get the "mode unsupported" message.

If you using the "extended" host versions and are still seeing this message, then your application is using a mode that TINY does not know about.

Try to configure your application to use one of the modes that TINY does support. You can see a list of these modes by running the TINY client with the /M command line parameter for a list of supported modes.

If you really need to use a specific application with TINY and that application can only use a graphics mode that TINY does not support and you'd be willing to pay for the work to add support for that mode to TINY, get in touch with me at the email address below.

Q: How can I override the default UDP socket that TINY uses?

You can use optional command line parameters to specify what UDP port the host should listen on and what port the TINY client should call out to. By default, both use port 6363 hex.

For example, the command line…  

TINYH_N /P6364 josh josh

You can then start the client like this…

Java –jar TinyClient.jar /P6364 192.168.1.2 josh

…and it all should work (assuming the IP address of the TINY host is 192.168.1.2 and the two machines can PING each other).

Note that it is even possible to load multiple copies of the host listening on different ports on the same machine, although this uses up lots of memory.

Q: How can I improve TINY performance?

The TINY client is not a particularly efficient Java application. My goals were to make it small (tiny?) and simple rather than fast. Since it runs on the non-DOS side of the connection, I assume this machine will be pretty modern and fast. The TINY host program, on the other hand, is as efficient as possible since I don't want to waste a single precious CPU cycle on your tired old 2.8Mhz PC-AT.  

Make sure you are using the very latest version of the Java runtime - the most recent once is better than the previous one. I'm not sure why, but it is cleverly hidden on the Sun website here...

http://java.sun.com/javase/downloads/index.jsp

...you should pick the "Java Runtime Environment (JRE)".

You can also specify how often you would like the TINY client to request a screen refresh from the host on the command line with "/Dx" where "x" is the number of milliseconds to delay between requests.

For example, launching the TINY client with this command line...

java -jar TinyClient.jar /D500 x.x.x.x password

...will send a screen refresh request twice per second (500 milliseconds = 1/2 seconds).

Using longer delays (and thus lower refresh rates) will reduce the CPU load on both the host and the client and will also reduce the bandwidth requirements. The downside to lower refresh rates is that you will see the screen update less frequently. This can be annoying if you are using an interactive application, especially when you are trying to type quickly.

On the flip side, specifying too fast a refresh rate (too low of a delay) can cause annoying problems as well. If you set a rate that generates more data than your network connection can handle, packets will start to get dropped. Once this happens, performance degrades very rapidly and unpredictably. This once happened to me and it took a while to figure out what was wrong. I had specified a refresh rate that seemed to work fine and gave me snappy response when I was typing on the remote machine, but every once in a while everything would grind to a halt and my keystrokes would start taking several seconds to show up. It turned out that someone else was occasionally TINYing onto a different machine over the same DSL link and between the two of us we were saturating the connection. We both slightly reduced our refresh rates and everything worked great.

The default refresh rate is 100ms, which translates to 10 refreshes per second. This is fine for a local Ethernet network connection, but will probably not work well over the internet. For a 768KB up DSL line, I typically use a 500ms delay. This leaves enough bandwidth available that two people can TINY across the connection at the same time without saturating our internet connection.

Ultimately the correct setting for a given installation will depend on the application and the connection, so you'll probably need to try several different values to find what works best for you. Start with a high delay and work your way up to until you find a delay that is not annoying to use and doesn't saturate the connection. Turn on the TINY status screen on the client and watch the dropped packet counters. A few occasional dropped packets are normal, but if you start seeing the counters incrementing regularly, you'll probably need to throttle back and use a higher delay. Keep in mind that other things going on over your network connection or the one at the remote machine can use bandwidth too, so you are more like to get see dropped packets if someone in your house starts downloading a Justin Timberlake video on YouTube.

Q: What are all the TINY command-line parameters?

Client Syntax:

TinyClient [optional params] host_address password

Parameters :

 /? displays this help info

/Dn sets the delay between screen requests in milliseconds (default=100)

/Kn sets the delay between key requests in milliseconds (default=500)

/R disable popup menus on left click (default=left or right click)

/X key_file loads a keyboard translation table file (you can load multiple key files)

/C show key scan codes to console for diagnosic purposes

/Px sets target UDP port in hex (default=6363)

/S show status window on startup (default is don't show)

/Ln sets the startup screen scaling size (default=1, 0=full screen)

/Mn sets the start-up screen mode (default=automatic)

/M lists available screen modes

/F specifies an optional screen font file to load

host_address is the IP address or name of the host machine (required)

password is the password for the host machine (required)

Host Syntax:

TINYH [/D] [/Px] view_password control_password

Where :

/D enables debug mode

/Px sets UDP port to listen on in hex (default=6363)

/I enables sending a keyboard interrupt after each keystroke which is needed by a very few (one so far) applications

view_password is the password that will let clients see what is on the host's screen, but not send keystrokes or reboot the machine

control_password will allow the client full control over the host machine

Q: How does debug mode on the host work?

If you load the TINY host with the /D parameter, it will start in debug mode. In this mode, the TINY host will write two letters to the upper-left corner of the text screen whenever a packet is received. This can be useful in debugging problems where you are not getting any response on the client.

The letter in the first position simply cycles each time any request packet is received by the host. If you see this blinking/spinning when you run the client, at least you know that there is good connectivity between the host and the client and they are both set to use the same port.

The second letter lets you know how the received packet was processed. Here are the possible codes...

Q: How can I get TINY client to prompt for the password each time I connect?

In Windows, you can use a batch file to ask for a password and then launch TINY with the password as a parameter. Try something like...

TinyPass.bat:

Q: How do custom fonts work?

To load a custom font on the Tiny client, you'd use the /F command line parameter like this...

java -jar TinyClient.jar /Fsmall.tf 192.168.15.1 foobar

...where small.tf is one of the sample Tiny fonts you can download here.

There are four sample fonts in that collection that I've made just to give you an idea of what is possible...

Note that if you use a font on the client that is a different height in pixels than the font on the host, your cursor might look different on the client than on the host. For example, if the host machine is using the standard VGA font that is 16 pixels high, but you are loading the "small.tf" font on the host which is only 8 pixels high, you might not see the cursor bar on the host since it is located at pixel location number 14 which is lower than the bottom of the character on the host.

Q: Sometimes when I manually pick a screen mode, I see "Received Corrupted Frame" on the Java console and the client screen stops updating.

Despite the ".tf" extension (for Tiny Font), the font files are just plain ASCII text files, so you can edit them with notepad or any other handy editor to make your own fonts. If you make a particularly useful one, please email it to me so I can share it with everyone else.

I also have a tool that I wrote to dump the font table on a VGA card into a TF file, but it would take me longer to explain how to do this than it is worth. If you really need to dump a special font, let me know and I'll walk you though it. I also have a tool that can convert some TrueType fonts into TF files.

Q: Sometimes when I manually pick a screen mode, I see "Received Corrupted Frame" on the Java console and the client screen stops updating.

If you request an invalid mode (say, Hercules Page #1 on a machine that doesn't have a Hercules card installed), the host machine may try to send packets based on memory that doesn't even exist on the host machine. The contents of the packets are typically all 1 bits, so the TINY client can't find the appropriate data fields in the packet. This does not cause any harm or problems for either the host or client machines, and you can fix it by just selecting a mode that is supported on the host machine.

Q: I just upgraded to the new version of TINY and now I can not see the screen on my host.

The latest version of TINY introduced a new protocol that is much more efficient. If you can seamlessly connect to a host running the new version with an old client, but to connect to a host running the old version using the new client you must select "Auto-Legacy" under screen modes. You can easily do this from the TINY client command line or using the pop-up menus. Or better, upgrade your host to the new version too!

Q: Do you know where I can find the Novell FTP Client?

 Thanks to a very helpfull DOS website, here is a package that contains a bunch of handy utilities that work with the Novell stack including FTP client and server, TFTP client and server, TELNET, RCP, and even a TSR that lets (supposedly) you connect to you DOS machine from TELNET or X-Windows (but I've never gotten it to work).

You can find some (partially inaccurate) documentation here.

Here is an example of an FTP script file called script.ftp that logs into an ftp server at ip address 11.22.33.44 using user username root  and password fubar and downloads all the files in the default directory:

open 11.22.33.44
user root fubar
mget *.*
quit

Here is an example of a batch file to execute the above script...

ftp -X <script.ftp

You might also want to check out JoshFTP here. It is like the Novell FTP client, except that it doesn't crash all the time. :)

Q: Do you know where I can download the latest version of the Novell DOS client?

Yes. You can download it directly from Novell here. You can also download a really nice Novell DOS boot disk here.

The TINYDISK.ZIP file above also includes all the Novell files you'll need besides the driver for your network card.

Q: How can I send files to/from the TINY host over the network?

I think the best way is to use an FTP client on the DOS machine. This requires an FTP server somewhere, but there are lots of free and simple FTP servers that you can install on your non-DOS machine.

If you are using the Novell stack on the DOS machine and have a Win2000 or Win2003 machine on your network, you could load Microsoft's free File and Print Services for Netware service on the Windows server and then map a drive on the DOS machine using the Novell MAP command.

If you have a spare Linux or BSD box on your network, you could install mars_nwe so you can use that machine as a file server for your DOS box.

Another option is to make the DOS machine an FTP server by running the Novell FTP daemon on the DOS machine and connecting to that with a normal FTP client from your Windows/Linux box.  Make sure to add your username:password in the \net\hstacc\ftpdusr.log file on the DOS machine. After transferring files end your FTP program and TINY will then regain full control of the DOS machine. (thanks Joe Murphy!)

You may also be able to transfer files to a Windows SMB server using the MS Client running concurrently with the Novell Client32.

Q: Is there any documentation about the /Ln parameter (i.e. what the values of n can be and what they mean)?

The specifies the screen scaling factor that the TINY client should use at startup. Higher values make for a larger (and blockier) client window.

"/L1" specifies that one pixel on the host should correspond to one pixel on the client (the default), "/L2" specifies that the client window should be twice as big as the HOST screen in pixels (each host pixel corresponds to a 2x2 block on the client), etc.

Q: Is there any documentation about the /Mn parameter (i.e. what the values of n can be and what they mean)?

This specifies which screen mode TINY should use on start-up. You typically would want to let TINY auto-detect this, but you might want to specify it explicitly in cases where TINY can't accurately auto-detect which mode to use.

One example is if you have a two monitor set up on the host, TINY can't know which monitor you want to see so ), or if the host is in a Hercules Graphics mode (there is no reliable way to detect Hercules modes).

If you run the TINY client and do not specify a value for the /M parameter, it will list all available modes.

Q: Can the size of the client window be changed dynamically by the user when connected.

If you click inside the TINY client window when connected, you can use the "Scale Screen" submenu to change the size of the window.

Q: When I run TINY on my DOS machine using the PCTCP stack, it crashes/stops responding.

Make sure your config.sys has a STACKS=16,512 line in it.

Q: I can get the Novell TCPIP stack to work on a virtual DOS machine, but how the heck do I get it to work on my actual DOS machine?

You'll need to load a suitable Novell Client32 driver for your card. These drivers always end with a ".LAN" extension. You can find drivers for most common network cards on the Novell website. You can also usually get the driver file from the card's manufacturer. If you can't find the right driver anywhere, consider just buying a new (well supported) card since they are so cheap now.

Look in the STARTNET.BAT for the line that says something like...

LOAD E100B.LAN

This is the line that loads the network card driver for an Intel Pro Ethernet 100B network card. Copy your driver into this directory and then change that line to reflect your card and everything should work. Note that some cards need extra parameters at the end of the line. These are different for every card, so you'll have to figure it out yourself. Try looking at the card's documentation, or just experimenting. Sometimes the driver will give a useful error message when you use the wrong parameters and that message can help you guess what the right ones might be.

Q: My card doesn't have a 32-bit Novell driver (ends in .LAN), just a 16-bit ODI Novell driver (ends in .COM). Am I screwed?

You can also use 16-bit Novell ODI drivers, you just need to load some "shim" drivers that make it possible for the 32-bit stack to talk to them. The only downsides are slightly lower performance and slight higher  conventional memory use compared to a real 32-bit driver. And it can be a pain to get it to actually work sometimes. It is usually easier to get a new card that does have Novell 32 bit drivers.

Here is some documentation on loading 16 bit drivers from Novell.

Q: What does the "Send keyboard scancode" function do?  

Some rare DOS programs (most notably EDIT.COM) use tricks to access the keyboard in non-standard ways. Because of this, these programs can not see keys that are stuffed into the keyboard buffer by programs like TINY.

Thanks to a an amazingly useful text on PC keyboards, I've added the ability for TINY to put keyboard scancodes directly  into the keyboard controller chip. This technique is good enough to fool every program I've ever tried into thinking the keys were really pressed on the local keyboard.

So why not use this technique by default? Well, scancodes are messy. There are lots of different types of keyboards with different keys in different places making different scan codes. Normally the PC BIOS takes care of all this so you just push the "A" key and see an "A" pop up on the screen, but when faking keys into the controller you need to do a lot of this work yourself.

The basic idea is that every actual key on a keyboard is a little switch. When you push the key, the keyboard sends a scancode to the keyboard controller in the computer. When you let go of a key, the keyboard sends a different  code. You can use the "Send keyboard scancode" to directly put these codes into the control as if they came from the keyboard itself and trick the computer into thinking you pushed (or let go of) any key on the keyboard in an order (Think Alt, scroll lock, even the power button).

To send a key, you need to know the "make" code (the code sent with the key is pressed) and the "break" code (the code sent when the key is released.

 Here is a table of all the make and break codes for a standard keyboard taken from the above website... 

For example, if you wanted to type the letter "J" on the host, you'd first look up the codes from the above table and then type "24 A4" into the "Send scancode" window on TINY. The "24" pushes the "J" key on the keyboard and the "A4" lets go.

So, let's say you started dos EDIT by mistake and now you can not exit because it is not recognizing your keypresses. You could use the codes "38 21 A1 B8 2D AD". This would push "Alt", then push and release "F", then let go of the "Alt", then push and release "X", thus quitting the program.

If you want to know the scancode for some fancy keyboard or a foreign keyboard, refer to this guide to every keyboard scancode imaginable.   

Q: What is the difference between the normal and "extended" versions of TINY?

The only difference is that the "extended" version of TINY supports graphics modes on the host. This takes significantly more memory, so if you only need text modes you should probably use the standard version.

If you load the standard version of TINY and then switch into a graphics mode, you'll see a "mode not supported" message in the client.

The standard version of TINY uses about 30K, whereas the "extended" version needs  about 38K. 

The TINY program will print which version it is on startup.

Note that I have not included a graphics version that runs on the FTP stack inside the distribution. Let me know if you need this and I'll compile it for you.

Q: Why are the colors all messed up when I run 800x600x256 graphics mode programs?

By default, TINY will automatically send 800x600x256 graphics screens in compressed nibble format. This mode uses only half as much bandwidth as sending the full color data, but the costs is that you only get half as much color information. DOS graphics applications tend to only use the first 16 colors anyway, so typically this is ok.

If you are using an 800x600 application that really uses all the colors and you want to see them all, you can manually select this mode on the client by clicking on "Host Screen Mode" and selecting the non-compacted 800x600 mode. Note that this will be MUCH slower than compacted mode. Also note that when you quit out of the graphics application, you'll have to go back into the "Host Screen Mode" menu and re-select "Auto" to see the text screen again.

Q: What is are the "sliced text" modes for?

These modes divide up text screens into multipule packets so that no packet is bigger than 1400 bytes. So, for example, if you pick "Sliced Text 80x25" mode, it will take 5 packets (each with about 800 data bytes) to see a full screen update. In the normal text modes, TINY sends a full snapshot of the whole screen in one giant UDP packet.

Some reasons why you might want to send lots of little packets rather than one big one...

• There is a bug in your network card driver that doesn't let it send giant UDP packets (I'm talking to you, Realtek)

• Each little packet causes a shorter pause for the running forground program than one big one would

• There is some firewall or router between your TINY client and host that can't deal with giant packets

• You want to have smoother traffic patterns on your network

Becuase the packets are smaller, you can probably send them more quickly without causing more network problems. If you were using a delay of 250ms with large packets (/D250), you can probably drop that to 100ms if you are using a sliced text mode and get better update performance.

TINY will never automatically select a "sliced text" mode. If you want to use one, you will have to manually select it from the "host mode" menu or use the /M option on the command line.

Q: What exactly does the /I option on the TINY host do?

The /I option will cause the TINY host to generate an INT 09 (the keyboard hardware interrupt) after each key is pushed into the keyboard buffer.

There is an application from TeamPhone that seems to need this interrupt to tell it to wake up and read any pending keys.

If you have an application that doesn't seem to want to read the keys from TINY, you can try this option, but in general you shouldn't need it.

Q: Can I run TINY over a PPP connection?

Maybe, but it will be slow. Maybe try using one of the sliced text modes. If you do not have an internet connection to the host, maybe consider trying my WHOST program instead. WHOST runs great over slow serial links like dial-up modems.

Q: Why am I getting weird Java errors like java.lang.AssertionError?

This means something went very wrong with the program trying to check that everything is ok. Almost all the time it means you are trying to run Java on Linux which doesn't work so well right now. I could also mean a corrupted Java install or JAR files. If you are on Linux, easiest solution is to set up a VirtualBox Windows machine and install Java there and it will work great. Sorry.

Q: What is the license for TINY?

TINY is free for non-commercial use. If you really love TINY, you can express your gratitude though a tax-deductible donation to The Aasha Foundation.

If you would like to include TINY in a product you sell, please email me at the address below and we can work something very reasonable out.

Q: How can I launch the TINY clinet on windows without the horrid console window showing up?

Make a shortcut that starts with the word "start" (litterally). More info here...
http://stackoverflow.com/questions/5710839/start-a-java-program-without-the-console

Support

If you've read all the FAQ questions above and are still having a problem with TINY, you can email me at...

Updates

01/13/2017 - Corrected historical record on TNE.EXE after hearing from Matt - an Artisoft alum. Thanks Matt!

01/09/2017 - Added destiation port to the title bar for people who love to run dozens of TINY connections to the same host machine!

05/11/2016 - Added Russian keyboard  file. (Thanks Михаил Ворошилов!)

7/10/2015- Updated link to the PC Keyboard document to point to a local copy since the source website seems to have gone dark.

7/12/2013 - Corrected Minsk to be in Belarus, rather than Russia. (Thanks Bveb!)

5/2/2012 - Add FAQ about Java Assertion errors.

12/19/2011 - Added KEYRUS.TF as a different Russian font.

1/11/2011 - Now with Farsi font support for our friends in Iran. Regardless of how our leaders may quarrel, our common love of MS-DOS 6.22 will always bond us together!

6/4/10 - New version of the host and client supports  new "sliced text" modes. See FAQ for more info.

4/29/10 - Added note about needing NetBUI when using MSClient stack to access a windows server.

4/27/10- Added Chris McFarling's cool new MSClient/Novell Client combo disk image to the section on using TINY with MS Client.

3/3/10 - Added the Arabic font and included more into in the FAQ about loading and creating fonts. Also added the descritption of the font parameter to the parameter list (just to this page, the program already knew it). Also added FAQ links to the new JoshFTP program and to Novell's FTPD server.

4/25/09 - Fixed the link on the page to actually point to the new TinyClient version rather than the old one. Sorry. :)

4/23/09-Finnally added custom font support to the TINY client! You can now load big fonts, little fonts, foreign fonts, whatever you like. You can even make your own Tiny fonts with any text editor. See above for more info.

10/1/08-Updated TinyDisk.zip so that it should now fint on a 1.44MB floppy with DOS. Also updated it to the latest version of the TINY host.

8/7/08 - Added TINYHG_F.EXE to the TinyHost.zip distributable for people who need graphics on the FTP stack. Also updated the TinyClient to take out some diagnostic code that would print cursor info to the console.

8/4/08 - Updated the TINY client to check the Disable Cursor Bit contained in the Cursor Start Register. Previously you might have seen phantom cursors or even TinyClient exceptions when running host applications used this bit. In this case, the application was BLOGMON from ER-Soft.

7/24/08 - Updated the TINY host to include the "/I" command line option that will trigger interrupts after each keypress for compatibility with TeamPhone software. Also added Simon's generous testimonial.

7/13/08 - Recompiled the TinyClient to be compatible with older versions of the Java runtime. Still, it is best to use the most up to date version of java available for your system.

7/1/08 - Posted new versions of both the client and the host that now support full VGA 800x600 graphics mode. Also broke the host into two versions so that people who do not need graphics support do not need to waste memory.

6/30/08 - Added link to LanWorkplace Extras zip file. Added link for documentation on loading 16 bit Novell drivers.

4/30/08 - New version supports directly sending keyboard scancodes to the host keyboard controller. Great for controlling programs that use non-standard ways to read keystrokes. Updated the FAQ to describe how this works.

3/26/08 - Updated the FAQ section on keyboard stuffing to suggest people can always buy a hardware keyboard wedge to solve their stuffing problems.

3/11/08 - Updated the FAQ with new "Quicker Start" section and some new answers on getting the Novell TCPIP stack working & the TINY license.

3/10/08 - New Version

• Thanks to work sponsored by Holland Co, TINY now supports VESA 800x600x256 SuperVGA graphics mode.

1/15/08 - New version

• New debug mode on host makes it easier to figure out what is wrong if the client is not connecting.
• The "unsupported mode" screen will now show you what VESA mode is currently active (if VESA is installed on the host).

5/15/07 - Added links to the FTP client and info on File and Print Services for Netware.

2/15/07- TINY Client adds "Full Screen" mode to the list of screen scaling options.

2/2/07 - New version, new features!

• You can now manually select the screen mode to access on the host machine. This is handy in lots of cases like (1) there is more than one video card on the host, (2) there are multiple active pages on the host, (3) the host video adapter does not provide any way of automatically discovering its current mode, like...
• TINY now supports Hercules graphics cards on the host. You can even pick either graphics page on cards with extra video memory. Note that you have to manually switch into Herc graphics mode (see above).
• Support for picking Interlaced or Progressive scanning in graphics modes. One or the other might be better for a given application.
• Host size reduced by 4k bytes. Hey, every k counts.
• The size of the client window can now be scaled to look larger via menu choice or startup option.
• New strategy for handling handling keystroke requests from view-only clients. Now the host sends a NACK back to the client so the client does not continue to resend the keystroke request.
• Changed the way passwords are processed to eliminate a possible password attack mechanism. I noticed this issue while making other changes - it has never been attempted in the wild.

12/16/06 - Added FAQ entries for command-line params, specifying a password on the command line, performance. Added link to download JRE.

11/11/05 - Added support for FTP's PCTCP stack in addition to Novell. This involved separating out the network code from the remote control code, making all the source much cleaner. If you need to write a DOS UDP program, consider using my NET.H to get automatic dual-stack support.

10/26/06 - TINY host version 0.6 release with support for specifying the UDP port to listen on using a command line option. Also added the ability to automatically view non-primary VGA text pages to support strange copy-protected software like TELAIO.

5/18/06 - TINY client version 2.1 released with support for custom keyboard translation tables. This makes is easy to use TINY with any foreign keyboard, which seems to be how lots of people like to use TINY.

4/10/06 - TINY host and client version 2.0 released with lots of new features including graphics mode support!

11/16/05 - Fixed typo "BAKCSPACE" to "BACKSPACE". Phew!

11/15/05 - Added a new status bar to show how many packets have been sent and received to the client.

###