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 was probably the world's first remote control program. It was written by
Lantasic in the early 1990s and ran on top of NetBios. The host was very small (only
about 4kb) and very reliable. I wanted the TINY host to be very small and reliable.
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

TinyHost.zip

Contains the executables to run on MS-DOS host.

Contains EXE files for both the Novell and PCTCP stacks.
You only need one or the other. You actually can run both
at the same time if you have both stacks installed, but that
would be a little silly. Also contains the EXE file for the
extended version of TINY that supports graphics modes.

TinyClient.jar

The viewer. Run this on any machine that supports Java

and you'll be able to instantly connect to any TINY server
on the Internet!

TinyDisk.zip

A snapshot of a full install of TINY on a DOS 6.22

machine, including the Novell TCP/IP NLM and drivers for
some popular (old) network cards. To use this snapshot,

just unzip it onto a DOS 6.22 boot disk and edit the
SETTINGS.BAT batch file to reflect your network card and
TCP/IP address. Possible network cards are listed in
\Novell\Client32\Drivers. Note that some PCI cards
require that you set the SLOT variable in SETTINGS.BAT.

TinyImage.zip

A Virtual PC configured to boot directly into TINY from a

virtual floppy so you can play with it without needing an
actual DOS machine. You'll only need Virtual PC, and
Java to use this (both free).

TinyClient.zip

All the Java source files to build the Tiny viewer. Check
out VGASoftFont.java if you want to include a real
bit-for-bit and pixel-for-pixel accurate VGA font in your
own Java programs. It also contains the RGB values for
the the VGA text mode color set.

MathKeys.txt
GermanKeys.txt

Some sample custom keyboard translation files. Uses

these as is, or edit them to make your own based on the
simple format.

TinyFonts.zip

Some sample custom fonts you can use on the TinyClient.

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 screenlook 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 connectionoriented 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
...will load the TINY host and have it listen on port 6364 (hex) with the view and control
passwords 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...
Code Meaning
R

A packet was received. This should only show up for the split second between
after the packet is received and before it is processed, so you probably won't
see it.

The packet received was ignored because it was less than 9 bytes long. This
maybe means someone is trying to spoof/hack you TINY host since the TINY
client would never send a packet like this.

An old style key request was received with the wrong control password. Check
that your password on the host and client match, and consider upgrading the
client to the latest version too.

An new style key request was received with the view password. Use the
control password on the client if you want to send keys.

An new style key request was received with a totally wrong password. Check
that your password on the host and client match.

A view request was received, but the password did not match either the view
or control passwords. Check password on the client.

A reboot request was received that did not match the control password. Check
the password on the client.

An unknown packet was received. This again probably means that someone is
trying to hack your TINY host, or another application is mistakenly sending
UDP packets to the port that the TINY host is listening on.

Success. The most recently received packet was processed successfully and
a response packet was sent, so you should be able to debug the problem on
the client.

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:

Set /P pass=Please enter your TINY connection password:

%windir%\System32\javaw.exe -jar TinyClientNew.jar /D400
192.168.1.113 %pass%
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...
small.tf

A tiny 5x7 font designed for LCD displays that I found here.

screenshot

normal.tf

The standard VGA 9x16 font. Good base for making a

custom font.

screenshot

big.tf

A huge 14x23 font I converted from the ASCII TrueType font

I found here.

screenshot

cyrillic.tf

A normal VGA font with some Cyrillic letters in the high

ASCII range.

screenshot

keyrus.tf

Another VGA font with Russian letters in high ASCII range.

screenshot

arabic.tf

A normal VGA font with Arabic letters in the high ASCII

range.

screenshot

ibm_arab.tf

An IBM supplied Arabic font.

screenshot

script.tf

A silly font to give some ideas of what is possible.

screenshot

farsi.rf

A font to make your old post-Sassanid text files come to life

screenshot

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 "AutoLegacy" 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...
Key
Esc
1!
2@
3#
4$
5%
6^
7&
8*
9(
0)
-_
=+
Bksp
Tab
Q
W
E
R
T
Y
U
I
O

Down
1
2
3
4
5
6
7
8
9
0A
0B
0C
0D
0E
0F
10
11
12
13
14
15
16
17
18

Up
81
82
83
84
85
86
87
88
89
8A
8B
8C
8D
8E
8F
90
91
92
93
94
95
96
97
98

Key
[{
]}
Enter
Ctrl
A
S
D
F
G
H
J
K
L
;:
'"
`~
L shift
\|
Z
X
C
V
B
N

19

99

PC Keyboard Scan Codes (in hex)

Down
Up
Key
Down
1A
9A
<
33
1B
9B
.>
34
1C
9C
/?
35
1D
9D
R shift
36
1E
9E
* PrtSc
37
1F
9F
alt
38
20
A0
space
39
21
A1
CAPS
3A
22
A2
F1
3B
23
A3
F2
3C
24
A4
F3
3D
25
A5
F4
3E
26
A6
F5
3F
27
A7
F6
40
28
A8
F7
41
29
A9
F8
42
2A
AA
F9
43
2B
AB
F10
44
2C
AC
NUM
45
2D
AD
SCRL
46
2E
AE
home
47
2F
AF
up
48
30
B0
pgup
49
31
B1
4A
32

B2

left

4B

Up
B3
B4
B5
B6
B7
B8
B9
BA
BB
BC
BD
BE
BF
C0
C1
C2
C3
C4
C5
C6
C7
C8
C9
CA

Key
center
right
+
end
down
pgdn
ins
del
/
enter
F11
F12
ins
del
home
end
pgup
pgdn
left
right
up
down
R alt
R ctrl

CB

Pause

Down
4C
4D
4E
4F
50
51
52
53
E0 35
E0 1C
57
58
E0 52
E0 53
E0 47
E0 4F
E0 49
E0 51
E0 4B
E0 4D
E0 48
E0 50
E0 38
E0 1D
E1 1D
45 E1
9D C5

Up
CC
CD
CE
CF
D0
D1
D2
D3
B5
9C
D7
D8
D2
D3
C7
CF
C9
D1
CB
CD
C8
D0
B8
9D
-

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.Asser onError?
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.

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

Updates
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.
###