TINY: VNC for DOS(josh.com)
josh.com
TINY: VNC for DOS
http://josh.com/tiny/
65 comments
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.
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.
Glad it worked out with Dosbox. Sometimes thats a no-go though because the software expect direct access to something or other.
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.
At first I assumed this was some kind of toy project, but as I read more I realized this was intended to be serious industrial software.
Are pure-DOS machines still deployed in industrial uses? How common are they?
Are pure-DOS machines still deployed in industrial uses? How common are they?
Not industrial, but I still see quite a few supermarkets in Denmark using DOS based POS systems at the checkout counters.
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.
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...
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?
> Could you relate how you go about fixing a DOS machine?
CTRL + ALT + DELETE and a dog-earred copy of "DOS for Dummies"?
CTRL + ALT + DELETE and a dog-earred copy of "DOS for Dummies"?
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:
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
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).
Oops, that's me misremembering. I haven't had to use DOS regularly for some time now.
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.
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.
> "screw it I'll make a new one from scratch"
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.
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.
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.
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.
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.
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.
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.
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.)
(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.)
Curiosity: Do any of these legacy setups use FreeDOS? Curious to know how much compatibility FreeDOS has to DOS itself.
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.
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.
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.
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.
So... yeah.
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.
So... yeah.
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.
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.
Whenever I boot up my CNC controller computer, I get greeted with AWARD BIOS (c) 1996.
It's a Pentium-S DOS box.
It's a Pentium-S DOS box.
Common. There are even OS/2 industrial machines that still get sporadic software updates by the the company I work for.
I too thought this would be a toy.
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.
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.
If it ain't broken, don't fix it?
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.
If it ain't broken, don't fix it?
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.
"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.
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...)
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.
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.
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.
Either way, very cool project.
[0]: http://josh.com/tiny/download/TinyImage.zip
Since it's freeware/"source-available", I wonder if they would consider making it publicly available or passing it on to a new maintainer.
Either way, very cool project.
[0]: http://josh.com/tiny/download/TinyImage.zip
> 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.
Why is this so impressive?
Why is this so impressive?
I suspect sarcasm.
> performance comparable to a 16Mhz IBM PC-AT using my 2.8Ghz Intel Core2
> performance comparable to a 16Mhz IBM PC-AT using my 2.8Ghz Intel Core2
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
"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 have no words to describe how great this is. I would even, but I find myself mysteriously unable to.
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.
(Probably) won't run on DOS, but libcaca is a thing that VLC, mpv, etc support that does exactly that.
Edit: https://www.youtube.com/watch?v=-h8g5NGUbDM
Edit: https://www.youtube.com/watch?v=-h8g5NGUbDM
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).
>"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).
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.
Poor security is worse than no security. At least the latter doesn't give you any false assurances.
>Poor security is worse than no security. //
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.
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.
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?
The VirtualPC emulation is for testing. He's running this on bare metal machines in production.
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.
If the source for this had been on Github that BAKCSPACE issue would have already been fixed ;)
There's a spelling error in the software on the first screenshot.
BAKCSPACE -> BACKSPACE
BAKCSPACE -> BACKSPACE
Anyone know if this works with FreeDOS?
Yes, it should work fine, it uses it's own (actually Novell) TCP/IP external kernel (or stack) :
http://freedos.sourceforge.net/wiki/index.php/Networking_Fre...
You can use this:
http://www.veder.com/nwdsk/
for tests.
It includes Tiny.
http://freedos.sourceforge.net/wiki/index.php/Networking_Fre...
You can use this:
http://www.veder.com/nwdsk/
for tests.
It includes Tiny.
Sweet.
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.
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.
TSR, omg, that brings back memory.
Before I clicked the link I imagined that this was some sort of VNC client which worked inside a terminal window. Does such a thing exist?
(I mean something like this - https://github.com/mustafaakin/terminal-webcam/blob/master/R... - except with a VNC image)
(I mean something like this - https://github.com/mustafaakin/terminal-webcam/blob/master/R... - except with a VNC image)
[deleted]
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.