I remember setting this up about a decade ago on some old electroplating control system front end. It worked very well - unlike the rest of the software on there.
Unfortunately the DOS program it was being used to remote was highly picky on the hardware being used, and would refuse to communicate with the PLC if the PC was too new. Due to the harsh environment of the plant, we'd go through two or three computers per year. So there was a lot of digging around for old hardware until we realised it would run reliably in DOSBox with a suitable CPU speed set.
After that, our use case for TINY was no more, and we just used a VNC server for Windows. Saved a great deal of site to site travel and plant downtime while it was set up though.
My first paid tech project (I was a high school student) was to get CNC control software working on newer PC hardware for a local metal fab shop. Through debugging the machine code, I determined the cause of the problem was that code that tests a hardware security dongle counts the number of (milli)seconds a tight loop takes to execute N times, so it can use that value to calibrate a communication protocol. On modern CPUs the time measured is often "0", leading to division by zero later on. If the binary is patched to fix that bug, the rest of the software runs fine on faster hardware.
I worked for a CNC router manufacturer and fought the same issues. ISA interface cards, extremely picky software that would just not run on certain chipsets/cpus and good luck finding documentation for 25 year old German software!
At the time (~2009) there was still a company that produced motherboards with an ISA slot but many controllers would throw a fit... never really found the root of it.
Incredibly common. There are industrial control systems in all sorts of factories that run hardware for which only DOS (XP is common too) drivers exist.
The companies that make most of these systems are out of business (mostly VARs that have a lifespan of 5-10 years), and nobody wants to retool a $3 million assembly line just to upgrade an OS.
Edit: I can think of a dozen times I woke up in the middle of the night to drive 20 miles to fix a DOS machine to get a plant working again. This is amazing.
By the way, it is not just unwillingness to upgrade.
Microsoft trying to push the industry in a certain direction outright banned (or made very annoying) lots of tech after Windows XP.
Example:
Post-winXP is very hard to make decent parallel port stuff.
Post-winXP you can't use dedicated hardware to calculate 3D audio (unless you do it in a funky way, like AMD failed attempt that was by adding a audio chip to the GPU and using the fact that HDMI must output audio...)
Post-winXP several graphics features that favour CRTs were removed too, using CRT in Windows7+ is a pain, many people think CRT suck compared to flat panels because they never saw a CRT being used properly.
And the list goes on...
In my particular case I know of this stuff because I once tried to start a company that make arcade (of the wood cabinet kind) games.
It is completely non-viable with Windows after WinXP...
Could you relate how you go about fixing a DOS machine? I'm imagining that technical experts get paid a lot of money and get flown across the country to get critical assembly lines working again. Am I far off?
This was many years ago, so it was mostly reboots, reconfiguring settings, and things like that.
But a good friend of mine has a very awesome job: he is employed by a very large manufacturing company that makes consumer products. They have dozens of plants all over north america, most of which run machines from companies that are out of business or the lines are no longer supported. When one of these antiquated machines break and the on-site service techs can't fix it or don't have spares they call him in. He will basically pull an old ISA card out of a machine, troubleshoot what broke, and replace board level components. He has a stash of old harddrives from eBay. Every version of old software you can imagine. In a few cases he has made new controller boards completely from scratch (including dumping firmware off of chips and flashing it on to new ones). When you are losing $200k an hour with a line down, "screw it I'll make a new one from scratch" isn't a silly response to the plant manager.
That guy must have had a steady hand and be really quick with the soldering iron. Making a new controller board while a 200k $ / hour line is down, well I always suspected my job was boring, now I know.
When the possibly of losing $200k an hour with a line down even exists, "screw it, I'll have a few spares made" seems like it would be a less silly idea the plant manager might want to consider.
You'd think so and in some cases you'd be right, but plant managers can pick the strangest things to be tight about.
I remember fighting to get some UPSes on important machines once upon a time. I don't remember going even one single summer without having a power outage. In fact, there were normally several per year.
Surely if you could lose $200k an hour, you would want to ensure you have spares for absolutely everything already on site before the problems occur. Redundancy is an amazing thing.
It depends on whether we're speaking of turnover or profit. An average profit of 200K$/h for a single production line must be very rare (but it may exist). You're almost always not really 'loosing' 200K$ (otoh you'll surely be late in delivering your customers, and that may be valuable, think 'late delivering fees').
When you're 'only' earning an average 20K$/h (10% profit is an ok number I would say, but it may be far less if it's a common finished good), then it may have sens not to pursue buying couples of every single spare part you should have. The full price for always having in stock working spare parts for 100% of a 3M$ production line could be well in the tens of hundreds per month. At the end you're cutting your profit and that's the last thing you want to report to the board, as a plant manager.
If only that were true... "Fixing a DOS machine" used to be the entry level skillset to get into IT. At this point, the issue is more faded memories than finding the people who did it.
(My first real IT job was creating the DOS configurations for IBM ThinkPads at F100 corporation. Prior to that I was a total point-n-click Apple guy who was into DTP. If I could write a bullet-proof CONFIG.SYS, a lot other people could too.
Those ThinkPads were weird too, some of them had more devices than available IRQs, including a "mwave" DSP, so you had to create boot menus. Plus, they were running token ring, and there was actually a relevant difference between ISA and PC AT.)
I can't speak for GP, but in my case, I'd run chkdisk or possibly "reimage" the thing.
And when I say "reimage" I mean that I'd run an XCOPY script I had that copied the last known-good backup from a Novell share, after which I'd boot from a DOS floppy and do a sys c:
I eventually made a batch file called 'fix' that would do the more common fixes and had them run that without bothering me.
Novel network share brings back memories :)
I had a machine hosting it, with dead BIOS battery. Every time it restarts, date/time had to be adjusted. Luckily, as I had already been fiddling with Turbo Pascal at the time, I made a tool to prompt the user to enter the date/time and have put it in autoexec.bat to run before NetWare does. Worked :)
I used to hate it though, as I was dealing with it at the time when Windows Server was already becoming standard in the enterprise environment.
It's hilarious because that's like the only DOS book that was even findable. And I actually gave that book to some of the maintenance techs who were struggling with "install instructions" they were getting from the devs.
When I say "install instructions" of course, I mean they were told to type something like:
c:
cd \foo
cd \bar
cd \baz
copy a:\wuzzle.exe
And sometimes they'd typo something and get completely confused.
Well there is a lot to be confused about, in the above example, I should imagine the intention was to NOT include a blackslash before bar and baz (otherwise the end result is changing the directory to 'baz' on the root of the C drive, meaning the cd to \foo and \bar and redundant).
I've encountered some newer systems running FreeDOS, which includes controllers, HMIs and along with some vendor-provided USB boot tools. In time these will become legacy systems.
In new deployments these non-PLC industrial systems are some combination of CE, XP, or very rarely 7. Linux is starting to gain traction with some Rockwell touch panels, but your typical vendor is loathe to try anything new.
If software innovation were left to the industrial vendors, we'd still be on parchment and punch cards.
Not sure if it's still the case, but I remember a Radio station setting up new computers, but that specifically had to have ISA/VESA slots in order to run a particular set of older hardware, and had to run Windows 98 because of the DOS drivers/software. The card itself was tens of thousands in investment (including software licensing), so they didn't want to spend that much replacing it with something newer.
It was an AMD 586@133mhz iirc, with a lot of ram for the hardware. Rather old design at the time (around 2000-2003, the past bleeds together after a while), and still surprised that someone would take that route. But I'm not surprised that an organization would do similarly today. I know of CNC machines with similarly legacy requirements (XP) that are still run today.
The company I work at does industrial process engineering, and a few of our customers have plants for which we do automation (PLC programming, visualization, ...) that are fairly ancient (1980s - mid-1990s) and. Some of these PLCs were made by a company that since has gone out of business, and the software for programming them runs on DOS.
MS-DOS, in fact. We tried setting it up on FreeDOS, but apparently only the real thing will do. One and a half years ago, I had the pleasure to install MS-DOS 6.22 on two programming computers. Finding 3.5" floppy disks was ... interesting. But it was fun to see how a freshly installed DOS will boot within seconds, even on fairly dated hardware. Fun times! ;-)
(Some of the visualization workstations at one of those plants seem to run DOS VMs on top of QNX so a single computer can run several displays, but I don't know about the details...)
> We tried setting it up on FreeDOS, but apparently only the real thing will do.
Just a small aside, you might want to try to spoof the correct version of MS-DOS with FreeDOS's VER command. Usually that's enough to get programs running that are picky about DOS versions.
Reminds me that there are at least one company out there that offer devices that emulate floppy drives for industrial uses. Meaning that you feed it a disk image, and it will pretend to be a floppy out the other end. They are even sized for fitting inside drive bays.
Yes, they exist. I worked with some about a decade ago. They ran on a single board computer with a flash memory card that emulated an IDE drive. They ran some 30+ year old industrial automation software written by someone who put everything into a single, messy, C file. It had what looked like a curses menu, but it did not use curses as a library. It also didn't use malloc. Source control consisted of sending the devs your .C file when you needed changes and getting a .C and a .EXE file in return.
I did automation by having all the computers source a batch file off a Novell Netware share and they'd reboot to have changes take effect.
Oh and how do I know it didn't use malloc()? Because we were running short on memory when using it.
Why was that? Well, they had to store about one thousand 6-digit unit IDs. So they made the unit ID an int and created a UNIT_ID[1000000] array that I don't think was ever made it to 2% used.
Saw some last -week- when I was getting a tour of a medium-sized small-parts manufacturer.
"It works, don't touch it" is the motto. Some of the more brave souls had started moving what they can to newer hardware, dosbox, or something, but the machine it was supposed to replace was literally within 5 feet of the control panel, ready to boot.
But to answer your question, last time I touched DOS system was 2005/2006. My first job out of Uni was working for a check cashing/credit card OEM that still had a dos machine with modem based check verification. There was literally a stack of like ~16 modems hooked up to a com port adapter card.
They were fed negative check file updates via serial cable. It us to come from a dos program, but we modified a SUSE Linux machine to send it the update files instead (straight text, null modem connection with a simply login protocol that was easy to reverse engineer). The modem/check verification program was running on MS-DOS 6.22.
The primary debt collection system was run off FoxPro for DOS files, migrated to ForPro for SCO that was running on the SCO Linux emulation layer on a RHEL box. O_o
We were moving to a newer Linux system, but their terminal software to view checks only worked on Windows. I had to reverse engineer our vendors protocol and reimplement their viewer in Java for our Linux stations (it had more features their theirs). They didn't complain about this (surprisingly), but they also weren't interested in buying it form us (the project manager told me they were moving from that protocol in the next release :-/)
I was looking at moving that check verifier to a dos emulator on a Linux box around when I left. Years later they weren't doing well and sold everything.
I also worked for a Uni in 2005 that actively deployed access control at dorms that was based on the dorm canteen food ordering system, running on dos.
By doing so they only have to capture the students details once, and students used the same card to access the dorm, or to order food.
The downside was the cost of the hardware, which was only avail from the vendor. I believe it still runs today.
For those commenting about open-source: check out the zip archive[0] provided by the author. This project appears to be about a decade old; those files have modified dates of 2007/2008 (& perhaps the post title should reflect this).
Since it's freeware/"source-available", I wonder if they would consider making it publicly available or passing it on to a new maintainer.
> 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.
Title, “TINY: VNC for DOS”, is not original and also incorrect. It is not using the VNC protocol. From the article: “[TINY] is comparable to programs like VNC, […]“.
This is excellent. I have absolutely no use for it, but I wish it was OSS just so I could poke around and see how the host works. Either way, badass geekery.
> 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)!
"source available" not being the same thing as "OSS", but it's something
BTW, the Josh who wrote this (Josh Levine), also wrote The Island Trading system (which ran on DOS I believe). Pretty brilliant guy; he was a subject of a very good book (IMO) called Dark Pools. Not sure if he's still doing this or not, but of your name is Josh xyz, he'll delegate xyz.josh.com to you (if not already reserved).
Looking at the Background, Josh wrote this to run Island.
Bonus- you can read the original matching wbighe code at http://www.josh.com/notes/island-ecn-10th-birthday/. It's written in FoxPro. Make sure you read the bit about hard drives.
Although not the same, it brings back memories of having webcams facing TVs/monitors, which allowed people from multiple locations to view the output of programs they had written running on actual harware (where the hardware itself allowed code to be executed over the network, but didn't offer a remote display option).
I read VNC but my mind interpreted it as "VLC". I was mighty confused there for a while, yet intrigued. I expected something like video streaming to DOS and being encoded into ASCII art on the fly.
FWIW whilst the FAQ claims VNC send passwords in plaintext. TightVnc docs claim:
>"for password encryption, VNC uses a DES-encrypted challenge-response scheme, where the password is limited by 8 characters, and the effective DES key length is 56 bits"
Which seems better than nothing at all.
I wonder if there's an SSH for DOS to tunnel the UDP packets over to avoid adding an intermediary to the system (though I guess a rasberrypi would be sufficient).
Not sure on this. Mostly the security on houses only has to put people off a little, it doesn't need to actually be effective at keeping people out, it only has to do enough to stop a random passer-by. So don't keep your wallet open on the front porch and you're probably a million-times less likely to be stolen from.
That said I think if the author meant to echo this idiom he should have just said that. The way the FAQ put it sounded like "we really should have security here and I'm embarrassed about it enough to claim that it's what everyone else does to try and diffuse any suggestion it's a deficiency" rather than "we don't have security by choice".
Perhaps I'm just being over-critical of the one thing I noticed that was not quite right.
Yeah i would thing it would be easier to set up some kind of VPN tunnel using a Pi or similar small board than try to get even more running under DOS without everything destructively interfering.
As the page says the arrangement is using VirtualPC to emulate a PC and boot DOS, I noticed that VirtualBox has an option to host an RDP/VNC server in the settings. Wouldn't that be easier to configure?
Ah, that's quite nice! Although I'm not sure what use case I'd like to use it for... Although... I do have an old i486 with SB AWE32 with some sound software that only runs good enough on metal (not on dosbox). Now I can run it headless... at least if I can get an UTP cable there.
Damn how I miss VirtualPC, the emulation was very good, so you could test low level stuff easily. It had a complete S3 Trio VGA in software, which worked very fast, not like it's "successor", HyperV, which is unusable for Linux graphic desktops.
Would it be faster then Virtualbox? I'm emulating Ubuntu on Linux with Virtualbox but perhaps switching to VmWare, Parallels or maybe VirtualPC will result in better performance.
If you don't need MS-DOS bare metal hardware, it's worth noting that a Xen hypervisor HVM setup for an MS-DOS guest can provide a "VGA" + keyboard console over VNC. It's basically QEMU.
I've got a couple old DOS / early Windows machines that I'd love to resurrect, preferably with remote access. This + FreeDOS (which is my more typical go-to nowadays) looks to be close to perfect.
Unfortunately the DOS program it was being used to remote was highly picky on the hardware being used, and would refuse to communicate with the PLC if the PC was too new. Due to the harsh environment of the plant, we'd go through two or three computers per year. So there was a lot of digging around for old hardware until we realised it would run reliably in DOSBox with a suitable CPU speed set.
After that, our use case for TINY was no more, and we just used a VNC server for Windows. Saved a great deal of site to site travel and plant downtime while it was set up though.