Slashdot Mirror
Windows 3.1 Glitch Causes Problems At French Airport -- Wait, 3.1? (vice.com)
OakDragon writes: Microsoft has tamped down the earth on XP's grave, steered Internet Explorer toward the nursing home, and is trying to convince everyone Windows 10 is a bright up-and-comer. But in the Paris airport of Orly, a system called DECOR — which helps air traffic controllers relay weather information to pilots — is running on Windows 3.1. That program suffered a glitch recently that grounded planes for some time. The airport actually runs on a variety of old systems, including Windows XP and UNIX. Maintenance is a problem. There are only three people in Paris that work on DECOR issues, and one of them is retiring soon. Hardware is also an issue. "Sometimes we have to go rummaging on eBay to replace certain parts," said Fiacre. "In any case, these machines were not designed to keep working for more than 20 years."
Wouldn't virtualization be a viable option here?
- Henrik
- when the Shadows descend -
Possibly for the physical machines needing parts from eBay issue. I think their real problem is still needing to run on Windows 3.1, and once you address that (hopefully moving to something much more modern) you can solve the legacy machine part as well.
When I worked at the college bookstore warehouse in the early 1990's, we had an ancient IBM XT computer with dual 5.25" drives, an amber monitor and a dot matrix printer for printing shipping labels. It did that one job exceptionally well. I wouldn't be surprised if it still working there today.
You're both wrong. The reason why these machines weren't virtualized a while ago is that you have to make a lot of serial/parallel/ps2 conversions for ports that are truly physical. These are the types of programs that send specific voltage down the wires and expect exactly something specific in return. Lots of times you try to get those returns right and you simply can't anticipate the various bugs that amazingly show up just a few months after you convert. The real problem? Some are nearly unsolveable. You can't even figure out what the manufacturer/programmer was trying to achieve with their hardware interface so it's best to simply leave eveything as is. Half these people don't even work in computers anymore, let alone the vendor they were at in the 80's.
This coming from a guy who espouses VMs every day on a variety of systems.
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
I have some old VB apps from the 3.1 era.
Although it may be technically possible to get them running, it's certainly not as easy as just copying the files across and running the program.
The fact that it is to do with weather suggests it interfaces with hardware of some kind or some external services. That's where you'll REALLY hit problems that just running as admin or renaming files or providing substitutes isn't going to fix.
Good luck getting a driver from the 3.1 era working on anything at all nowadays, even emulated. You would literally just be better off throwing it out, starting again and suffering the inconvenience.
And, more importantly, it's also why you can't always replace those mainframe systems: because it works, and has worked for decades.
I've been on projects to replace aging mainframe stuff, some of which went back to the mid 60s or so.
You could start off trying to design a replacement, gather requirements, and design something which works on your assumptions and in the limited use cases you've seen.
And the more you delve into it, and discover all of the exceptions, corner cases, "didn't we tell you that?", sheer size of the data, all of the hairy bits, the 50 other systems which tie into that system and would also need to be replaced or updated ... you can quickly reach the point where you really can't design a system which does the same things, you can't replace all of the integration points, you can't even really map out all the logic and business rules embedded in that system.
At the end of the day I've seen at least two such projects utterly fail.
Say what you will about legacy mainframe stuff. But they work, are so closely tied into the entire business and other systems that you can't simply swap them out as easily as people think you can, and as often as not are vastly more complex than you can possibly know until it's too late.
They're old, clunky, convoluted, and utterly mission critical. And when every other computer system in the company ties into them to extract data, you quickly realize you can't possibly update all of them.
That, and you might also find that you simply can't match the performance and throughput of those damned things.
A mainframe is a big lumbering beast. But it's a big lumbering beast which has kept the company moving for decades, hasn't had much in the way of downtime, has been expanded and added onto over the years, and in many cases will cost so much damned money to replace that nobody can afford to do it.
The guys coming in thinking they can whip up something in .NET, running SQL server, and on one machine? They often have no idea of just how big of a task they're trying to take on.
Personally, I would run screaming in the opposite direction from any project trying to replace a mainframe that's been in service for a long period. Because the scope of those things, and extent to which they interact with everything else in the company can be mind-boggling.
Lost at C:>. Found at C.
Considering I still use a TRS-80 Model 100 on a regular basis (great keyboard!), Systems using Windows 3.1 do not surprise me.
Then again, I work for a bank, login to a mainframe and review COBOL code that dates back into 1980... So, yeah. I'm not surprised.
If telephones are outlawed, then only outlaws will have telephones.
Very true I'm sure. But I also believe in "where there's a will, there's a way"
I've been in these kinds of discussions. The Cost to figure out or build such a gap-device is too-large, or equal to "just rewrite it in modern tech." So everyone waits for another 10 years while the rewrite doesn't happen. Rather than picking it apart and refactoring a bit here and there - wait for the big bang!!
+100
You're both wrong. The reason why these machines weren't virtualized a while ago is that you have to make a lot of serial/parallel/ps2 conversions for ports that are truly physical. These are the types of programs that send specific voltage down the wires and expect exactly something specific in return.
Ironically, you just named three ports where that's either not the case, or trivial to achieve. All PC keyboard ports are digital 5V, there are only two kinds of signaling, and nobody was using the old kind by the time Windows 3.1 came out. All PC parallel ports are digital 5V. And by definition, RS-232 is 12V, although many if not most ports will accept a 5V signal. (If you hook up any outgoing lines, though, you may well murder any 5V serial devices you hook up, if they don't have a real MAX232 in them.)
The real problem is that a lot of these PCs have ISA-bus interface cards in them, and their drivers are often crap that is pissy about timings. Even a really high-speed PC is enough to make them not work. In order to reasonably replace these devices, you have to analyze the circuit and/or connection to figure out what the original control board was doing, throw it away, and replace it with something else. These days you might reasonably replace it with any little microcontroller board, like an Arduino. They are faster than early PCs were! But first you have to figure out how. Those boards also often included a specialty power supply to drive whatever-it-was, so you've got to replace that as well.
Most of the time it's going to make more sense to throw it all away and start with a new thing. But it's not impossible, just expensive.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"