On 7 Feb 2022 at 21:58, Michael Brutman wrote: > > This has all been terribly interesting, but I can't help but think: > * This product should have been ported to a more capable operating > system years ago. > * The inner workings of how the product was made to run under DOS seems > to have rotted away. > Sounds like it has been ported. I understand that the point is to avoid forklift upgrades of old PC hardware in existing deployments = avoid fixing things that work, requiring manpower that possibly isn't really there.
One last (I hope) note on this = excuse another life story: Unrelated to Mr. Haywood, I have this other veteran/retired customer, supporting a [misc heavy industry] company of some sort, running a handful of DOS-based control PC's with obscure I/O hardware (fast-paced low-latency 16bit DC-referenced analog input), and an amazing but abandoned/unmaintained/closed-source modular multi-tasking real-time control system (1 ms scheduler clock) written in Borland Pascal :-O The management at the [misc heavy industry] company must've seen the writing on the wall for well over a decade. Reportedly, the tight timing and some other special sauce (fuzzy controllers, discontinuous/hysteretic controllers, non-linear noise filtering) is so exquisite in the old system that it's darn hard to find anything more modern off the shelf that would serve as a replacement. I mean - even just a RAD environment for PC-based industrial process control, or some brand of PLC's. So apparently the management just leave the old system to its moral decay, and the old bard (my integrator customer) keeps the system floating by the skin of its teeth. The other management-level option would be to hire some (non-existent?) talent to rewrite the thing from scratch in some more modern environment that would - meet the RT timing and control requirements - have the required algorithms / modules, or be extensible enough to allow the integrator to write the missing software blocks - be architecturally future-proof: the OS and the control software and the hardware IO, all layered / modular / replaceable, and long-term available. - the [misc heavy industry] company should demand source code. I know about various RTOS brands, and Linux with RT extensions, or even just vanilla Linux on appropriate hardware, with appropriate config (and application SW architecture). Apart from the programming effort required, relatively the most difficult part is getting industrial-grade analog input with open-source drivers (or register-level documentation) - yes there are analog input PCI(-e) cards, but the industry has moved away from open HW docs to closed-source drivers for the current issue of operating systems. The PCI(-e) bus interface on modern industrial IO cards is a custom FPGA-based job. I also know about PC-based and other HW available from National Instruments - some of it embedded and dedicated to RT control. NI are a powerful and lasting brand, but to me the jury is out, to what extent such a solution would be future-proof across proprietary platform EOL's and whatnot. I expect my veteran integrator customer guy to go away one day, and the frantic management of the [misc heavy industry] company to come hammering on me to revive their system - of which I barely know the PC hardware, have disgust for their dependence on every last byte of UMB+HMA, have seen a glimpse of the ancient Pascal-based software, but have no knowledge of the control-level configuration etc, and no spare parts anymore (compatible CPU boards, analog input boards, signal conditioning barriers etc). It's gonna be interesting when the * finally hits the fan. > * This really isn't relevant to FreeDOS. > you're right... apologies. Mr. Haywood I suggest that we move our debate into private e-mail. Mine should be visible in my messages. Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
