If you have these compiling with a modern toolchain, you may wish to ditch the python subprocess wrapper and compile them with something like emscripten (compile to javascript) or NestedVM (compile to JVM bytecode). Then you won't be exposing 30 year old unsafe code directly to the internet... at least it would sandboxed. If you use emscripten you could even have the programs run client side.
I have a fork of NestedVM that I've been using with success but I don't have any simple examples for you:
Thanks. I did not know about it to be honest. Very interesting!
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 :)
If you don't need multiple people to interact with shared data maintained by the same program, and instead everyone's interactions with the program can run independently, then you could still run the JavaScript version of DOSBox on the client side, and extend that version of DOSBox to offer JavaScript APIs to communicate with the virtual machine running inside. For instance, to send or receive characters, or modify files on the virtual disk.
If you give that sentence more context, it becomes clearer what the author was hoping to be able to do with the old code. It's not merely "keep this old DOS accounting app working for the local auto mechanic".
> 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.
This is not a 'curation' worthy event, in my opinion. A more accurate presentation would be to have the DOS machine 'in the flesh' (i.e. a booting example of the ol' PC). When that's not happening, the next best thing is emulation.
Re-compilation, cleverly disguised as 'auto-configuration' in this case, is pretty much a total fakery.
"
Vim (/vɪm/;[3] 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[4] 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.[2][3] 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[4] 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.[28] When FreeBSD and NetBSD resynchronized the 4.4-Lite2 codebase, they too switched over to Bostic's nvi, which they continue to use today.[28]
"
No, I meant Vim very specifically, because I know Vim to be based on sources dating to 1987 or older, and I know it to be in daily use.
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!
How many programs from that era still exist and were not updated over the years? Of those, how many are of the form of "diagnostics program for a 1960s era IBM printer attached to an OS/360 machine using some custom bit of hardware?" For the latter running the process in a browser is probably worthless.
Surprisingly pretty good. Simple API load tests show response time < 80ms. The C programs themselves are very fast (because there is not a lot of computation involved).
Older C programs were made before many well-known security attack vectors were discovered. e.g: the first exploitation of the buffer overflow came in 1988.
So be careful. Take measures so people do not exploit those vulnerabilities, such as executing arbitrary code in your machines.
Actually it was already acknowledged by the C designers in 1979 that not everyone was writing good C code, hence lint.
"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
law."
-- 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.
I have a fork of NestedVM that I've been using with success but I don't have any simple examples for you:
https://github.com/bgould/nestedvm
Here is an example of compiling the Apache Thrift compiler to run on the JVM:
https://github.com/bgould/thrift/tree/nestedvm/contrib/neste...
And I have a version of the toolchain precompiled as a docker image:
https://hub.docker.com/r/bcg1/nestedvm/ https://github.com/bgould/thrift/blob/nestedvm/contrib/neste...