It sounds like it's still possible to communicate with the company. Excellent: ask them what their opinions are with
reverse engineering the program, expressly to facilitate continuation of business operations
publicly disseminating binary copies of the program on the internet, modified or unmodified, also for the express purpose of reverse engineering to facilitate continuation of operations
if public dissemination is not agreeable, privately sharing the binary with others without requiring a signed NDA from the would-be recipient
allowing the same team performing reverse engineering to also reimplement the required functionality directly, without a clean-room needing to be in the middle (ref: https://en.wikipedia.org/wiki/Clean_room_design)
(you may be able to answer this yourself) sharing many screenshots and/or videos (from a camera, or from the obs-studio screen recording software) of what interaction with the program looks like
(if you have any .bas files) sharing anything that might appear to constitute program source code, privately or publicly
Essentially you're kind of asking to slightly rearrange your original license agreement :). I look at this a bit like a warranty: your software has completely exceeded all original definitions of maintenance, along with what might be contemporarily regarded as reasonable aftermarket maintenance. The vendor's perspective may differ here.
In the interests of cooperation you might offer to send the vendor any algorithms you recover from any reverse engineering efforts you make. (What is sent may or may not include any modernization/interfaces you add on top, since that is unique effort you are making independently.) Of course such an offer would only be of value to the vendor if they do not offer a modern supercessor to LUKWAN themselves.
In any case, once you have some clear answers, you'll have a concrete legal foundation to built on instead of the current sea of gray you're in right now.
If you can publicly dump the binary on the internet, that will simplify matters greatly; go find a few reverse engineering forums, share the program, and you'll likely receive extremely accurate quotes (and ETAs) in a matter of days. You may end up hiring a team of two or so.
If you can share the program privately without NDA, you can reach a 90%+-as-good situation, especially if you can share images/videos of the program in action. The quote process will just require interested parties to ping you first, and will go somewhat slower as the initial analysis won't be asynchronous.
I'm not sure what sort of rates you'd be looking at, as I have no experience in this field myself. Video and descriptions will likely get a good rough initial estimate.
I took a look at https://en.wikipedia.org/wiki/PowerBASIC, which is what Turbo BASIC got turned into.
Unfortunately for you, one of this particular environment's headline features (back when it was still Turbo BASIC) was that it built native binaries that did not require a bundled runtime.
This generally means you will have to go down the "hard mode" road of full assembly-language reverse engineering... but on the flip side of the coin, while there are eg a huge number of tools out there to eg reverse "compiled" Java or obfuscated JavaScript, by now (2019), any tools to reverse eg the QuickBASIC "compiled program" format (which used bytecode and a runtime interpreter) would probably have either fallen off the edge of the earth or be hiding behind a massive price tag. So that's kind of a nice thing, FWIW.
Clearly noting the program is written in Turbo BASIC when you look for RE assistance will be particularly useful. There are probably people out there very experienced with the peculiarities of the TB compiler.
I am wondering whether it is possible to reverse engineer this program and put in into a "modern" jacket, + enable easy data instruction.
Yes. I can think of two different approaches. Both are complex, and it's hard to say which will work out easier without a good stare at the exact circumstances.
What might be described as the "traditional" RE approach would be to take the program to bits through techniques such as static (IDA Pro, Ghidra, radare2) and dynamic (CodeView, Turbo Debugger, SoftICE) analysis, and attempt to tease the math out from the rest of the program, where it can be straightforwardly reimplemented elsewhere.
The main risk here is whether the process doesn't catch important algorithmic details or edge case handling. This is the only bit I'm going to make bold: you can aid this process by providing tens to many hundreds of tests. (Start thinking about this process now - say, 10 or so tests of each kind of specific case the program handles should be a good start.)
If the program is straightforward and the areas where calculation are done are easy to identify (impossible to say without poking the binary) this should mitigate the risk somewhat.
A technique that fairly closely follows the literal translation of your notion of making a "jacket" would have you wrap the program in an emulator (such as DOSBox) that has been modified to "export" the state of the screen and accept synthesized keyboard input - and then add a translation layer on top that rapidly keys data in and scrapes the screen for the results.
The main risk with this approach is the number of screens the program can show, and the complexity involved (is scrolling needed to grab all data? is the next action to perform unambiguously obvious based on what indications are presented on the screen?) in scraping the information.
[...] it would be a lot easier/faster to run the program on a list of components (extracted from our drawing software). (this is an extra)
What format is this list of components generated in?
This may be anything from trivial to mildly complex. The cost to add this capability will be significantly less than the initial RE effort.
I am very interested to hear how this project goes! If you take this question to other forums it would be very cool if you could put links out to the relevant threads. :)
