Perhaps not for medical, but you can coax windows to behave mostly "realtime" (aka 1ms polling interval) by invoking some win32 API around the multimedia timer interface. This still works as of Win11, but it has to be foreground and not running on battery and a few other reasonable constraints.
There are really 2 things you need to avoid: Context switching, and tripping over the internals of the kernel. By forcing the multimedia timer to 1khz, you can address the latter. You should still try to run your time-sensitive code on a dedicated thread and never yield to the OS, even if yielding is made less costly. Keeping the cache hot all the way thru is way more important. If the kernel doesn't have an opportunity to make a decision about your priority, you don't have to worry about a thing. Hold onto the thread of execution and never let go. Async/await is your enemy. Poll everything.
For me, the biggest win is in the development experience. Building this stuff on Windows is like cheating compared to being forced to target an obscure RTOS linux distribution up-front. Even then, if I build my RT product in something like .NET6+, it is plausible I could compile the exact same code for a more power efficient platform after completing initial development on windows. The only code that would be platform-specific are any "hacks" like one-time mm_timer calls.
The fact they run in hospitals doesn't mean it's a good thing... Hospitals were duped into using MS products. Today, this is a major plague in the health system of many countries few people realize the extent of.
In short, the problem MS created for medical / hospital equipment is that by trying to ensure they control the software, they made the hospital staff incapable of using the software to their own benefit. Hospital research today is archaic in its practices compared to virtually any other field because of how it relies on Microsoft products. Usually, it's a bunch of people manually filling Excel spreadsheets and doing a lot of other things that would've been trivial to automate by hand.
Hospital / medical equipment is not validated well by various bodies established to do that (eg. FDA or similar European bodies) because the technology is proprietary and validation, essentially, relies on companies submitting their internal research results to get the equipment approved.
PACS and similar systems are designed and implemented by companies who don't understand how hospitals work, and aren't interested in learning that -- the typical enterprise model inspired and encouraged by the use of MS products, where deals are made between high-ranking managers w/o any attention to the actual needs of the personnel who are supposed to use the software. And this is again, because MS conditioned hospitals not to use open-source software, which also resulted in no internal talent / expertise growth. So, doctors in external clinics and even inside the hospital, even though connected by their computerized system, don't know how to use it well, or, sometimes systems lack important functionality.
By bribing their way into medical system, MS committed the largest crime in its history, much larger than anything it's been taken to courts for. Countless lives have been lost or severely impacted because of MS profiteering. But nobody really talks about it because these numbers are hard to count. It would be very hard to sue them for this as this is too broad and hard to get concrete evidence of... but if you had ever interacted with the hospital computer systems from the inside, you'd see this plain as day.
this is probably machines that handle special hardware.. like MRI, ECG, or monitor for vitals like pulse, blood pressure, blood oxygenation or other stuff like that..
Those machines need to be certified as a whole package and this include the computer that will control it.. and once you certify you cannot make changes to the package without having to certify again..
So you certify the machine with that software on it.. that specific kernel version, that specific libc version and so on.. if you change anything you need to get a new certification..
and now those machines are no longer air gapped because hospitals want to be able to remote monitor the patients vitals from a central nurse station..
> and once you certify you cannot make changes to the package without having to certify again..
Oh you are so naive... You probably wish it worked like that, but in practice it doesn't.
The certification process is completely broken today. First of all, it allows proprietary software / hardware to go through this process (which is the majority of applicants by far). Typically, FDA or similar will ask for company's own research that establishes that the software works with absolutely no way of verifying that it does. They, as well, have no way of ensuring that whatever version was used to produce the research results is the one that's being installed on the hardware shipped to the hospital / patient. Companies producing software routinely patch their software if they discover problems after initial release and don't hesitate to claim that it was approved.
There are really 2 things you need to avoid: Context switching, and tripping over the internals of the kernel. By forcing the multimedia timer to 1khz, you can address the latter. You should still try to run your time-sensitive code on a dedicated thread and never yield to the OS, even if yielding is made less costly. Keeping the cache hot all the way thru is way more important. If the kernel doesn't have an opportunity to make a decision about your priority, you don't have to worry about a thing. Hold onto the thread of execution and never let go. Async/await is your enemy. Poll everything.
For me, the biggest win is in the development experience. Building this stuff on Windows is like cheating compared to being forced to target an obscure RTOS linux distribution up-front. Even then, if I build my RT product in something like .NET6+, it is plausible I could compile the exact same code for a more power efficient platform after completing initial development on windows. The only code that would be platform-specific are any "hacks" like one-time mm_timer calls.