Not usually. The main thing for lab equipment is that it is controlling hardware. So you are often using proprietary drivers for custom hardware. Wine can’t handle drivers and for security reasons can’t get low level hardware access.
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.
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.
Not usually. The main thing for lab equipment is that it is controlling hardware. So you are often using proprietary drivers for custom hardware. Wine can’t handle drivers and for security reasons can’t get low level hardware access.
On the other hand, something like ReactOS could, in theory, work if it was much more mature and had more developers behind it.
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.
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.