Ah yeah, drivers are another thing entirely. Especially for what I imagine is very proprietary undocumented hardware. The only thing that can help there is a reverse engineer / kernel module dev.
Comment on abandonware empires
beautiful_boater@hexbear.net 1 year agoNot usually. The main thing for lab equipment is that it is controlling hardware. So you are often using proprietary hardware drivers for custom hardware. Wine can’t handle hardware drivers and for security reasons can’t get low level hardware access.
TheCaconym@hexbear.net 1 year ago
beautiful_boater@hexbear.net 1 year ago
On the other hand, something like ReactOS could, in theory work, if it was much more mature and had more developers behind it.
Thorry84@feddit.nl 1 year ago
Not really I’m afraid. ReactOS is focused on implementing the old APIs which allows software that used those APIs to function.
But my experience with old proprietary software from that era is that they were trying to do something which was hard at the time. So they wrote their software with lots of clever tricks and hacks, to make the thing do the thing. This can be as simple as manually invoking interrupts and using undocumented APIs, to setting up non protected memory and communicating with the hardware directly.
I’ve seen cases where the software would only run with a specific version of Windows 95 and only with specific chipsets. Even changing the cpu from an Intel to a Cyrix for example could cause issues.
I was involved as an intern with a project to fix something like this a long time ago. We chose to simply reverse engineer the hardware interface, put in a custom controller to handle it and write modern software. It took a lot of doing and we lost some features, but the original system was beyond saving.
As time went on more and more hardware abstraction is applied, so I would hope this issue would be fixed in the future. But the whole of the 90s and early 2000s is a big issue.