I have a fork of NestedVM that I've been using with success but I don't have any simple examples for you:
Here is an example of compiling the Apache Thrift compiler to run on the JVM:
And I have a version of the toolchain precompiled as a docker image:
This is what the archive.org Software Library does.
MSDOS Games: https://archive.org/details/softwarelibrary_msdos_games
Atari 2600: https://archive.org/details/atari_2600_library
There is no comparison since the idea was not to port the programs to JS or in the browser but rather being able to compile them (with a common setup) and create an API on top of them :)
There are quite a few options to run MS-DOS applications on modern hardware.
> First, these software have been written for MS-DOS and therefore require a rather old computer to use them. This leads to two more issues: not everyone can easily use them, and it is nearly impossible to interface them with other software.
> We have been asked to build a Proof Of Concept (POC) to transform these programs into web services in a week
This person is a museum curator, so there's a good reason (society benefit) for their desire to transform something from the old computing world into something people can appreciate and understand in today's context.
Re-compilation, cleverly disguised as 'auto-configuration' in this case, is pretty much a total fakery.
(No double entendre intended here with "gets", by the way.)
Vim (/vɪm/; a contraction of Vi IMproved) is a clone of Bill Joy's vi text editor program for Unix. It was written by Bram Moolenaar based on source for a port of the Stevie editor to the Amiga and first released publicly in 1991.
The original code for vi was written by Bill Joy in 1976, as the visual mode for a line editor called ex that Joy had written with Chuck Haley. Bill Joy's ex 1.1 was released as part of the first BSD Unix release in March, 1978. It was not until version 2.0 of ex, released as part of Second Berkeley Software Distribution in May, 1979 that the editor was installed under the name "vi" (which took users straight into ex's visual mode), and the name by which it is known today.
In 1989 Lynne Jolitz and William Jolitz began porting BSD Unix to run on 386 class processors, but to create a free distribution they needed to avoid any AT&T-contaminated code, including Joy's vi. To fill the void left by removing vi, their 1992 386BSD distribution adopted Elvis as its vi replacement. 386BSD's descendants, FreeBSD and NetBSD followed suit. But at UC Berkeley, Keith Bostic wanted a "bug for bug compatible" replacement for Joy's vi for BSD 4.4 Lite. Using Kirkendall's Elvis (version 1.8) as a starting point, Bostic created nvi, releasing it in Spring of 1994. When FreeBSD and NetBSD resynchronized the 4.4-Lite2 codebase, they too switched over to Bostic's nvi, which they continue to use today.
I used the original Elvis in the early 1990's a bit and am aware that nvi is based on it. I don't know off the top of my head how old Elvis is. I don't know whether Joy's vi code is still in use anywhere, either; obviously it isn't in any of the BSD's that use nvi.
Probably the vi in AT&T derivatives (Solaris, etc) has Bill Joy code in it. Does Solaris receive daily use involving invocations of vi? That is the question ... haha!
So be careful. Take measures so people do not exploit those vulnerabilities, such as executing arbitrary code in your machines.
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."
"The first principle was security: The principle that every syntactically incorrect program should be
rejected by the compiler and that every syntactically correct program should give a result or an
error message that was predictable and comprehensible in terms of the source language program
itself. Thus no core dumps should ever be necessary. It was logically impossible for any source
language program to cause the computer to run wild, either at compile time or at run time. A
consequence of this principle is that every occurrence of every subscript of every subscripted
variable was on every occasion checked at run time against both the upper and the lower declared
bounds of the array. Many years later we asked our customers whether they wished us to provide
an option to switch off these checks in the interests of efficiency on production runs.
Unanimously, they urged us not to - they already knew how frequently subscript errors occur on
production runs where failure to detect them could be disastrous. I note with fear and horror that
even in 1980, language designers and users have not learned this lesson. In any respectable branch
of engineering, failure to observe such elementary precautions would have long been against the
-- The Emperor’s Old Clothes By C.A.R. Hoare Communications of the ACM, 1981
As for exploits in the wild, before the UNIX worm there were the game cheats on home micros.
However regular C programmers in the 70s and 80s were not defending themselves against arbitrary code execution from buffer overflows.
In addition, you can take C programming books from the time and see how functions like memcpy and strcpy were being used in unsafe ways.
That is my point. If you are going to reuse old programs, be aware that in earlier decades there wasn't as much awareness about security as there is today.