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."
This is why mainframe software lives on and on. It won't go out of fashion because it never was in fashion (except in the mid 60's) and there is so much mainframe code floating around that something or someone will always support it.
Table-ized A.I.
Even if it is an old system, everyone knows you can easily fix things in UNIX by just clicking around the 3D interface for the right file which, when opened, will magically restore everything.
The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
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.
My favorite I've encountered about ATC systems is how the documentation lies. For example, how checksums are to be computed computed for a particular broad class of messages. The ARINC specs go into detail, with diagrams and everything about the computation process. But when you look at existing samples of code, they don't do this - they do this weird thing with a lookup table and uncalled-for bitshifts and the like. After spending a day or so studying the code, I finally figured out what they were trying to do - they were trying to "optimize" the algorithm in the specs. But in the process they made it deviate from what is actually supposed to be computed in about four different ways (plus, their "optimizations" don't actually save compute time, the simple math operations are faster than the lookup in the "precompute" table that they made).
So what do we do when we need to compute and check checksums? We use the wrong code, of course! It's what's "out in the wild", so who cares what the specs say we're supposed to use, it's what we have to use if we want checksums to ever to come up valid. Hopefully they'll eventually update the specs to reflect the reality.
Hello from Sputnik 2. I am receiving you.
That's not a long time at all. How old is our perfectly functional ordinary telephone? If computers are going to remain so maintenance intensive, the damn things will never really be any good. We have to be able to plug it in and ignore it for those 20 years, until the smoke leaks out
“He’s not deformed, he’s just drunk!”
1980? Wow. You got the new stuff.
Demand support nearly forever. When steam was replaced here in the mid 50s to late 60s, the average age of the replaced engines were around 50 years. The replacement engines are still in operation. The main reason is safety. When designing a new locomotive, the manufactor spend a fortune verifying the performance, which is then added to the price (naturally). On delivery of the first of its kind, it goes through a whole lot of testing and documentation to ensure that it's not too heavy for the track, works with the signal system and all that stuff. It takes time and cost millions. It's a lot cheaper once the type is certified, but they are still tested with non-free tests. This makes buying a used already certified engine quite attractive and as a result, spare parts are produced for many decades after production stopped. It's a demand from the railroads and supplying those parts makes manufactors trustworthy enough to be candidates for new engines expected to be used for at least 30 years, likely more than that.
Computers are way too short lived. Powerplants/grid, railroad signals, air traffic control and so on are hard to replace systems and once they have something working, they want to stick to their systems as long as possible. They make horrible contracts since they are unable to get the spare parts they need. The US army invented VHDL to give a description of the work of a chip and you would not be able to sell to the army without VHDL code. The idea is that if the army needs a replacement chip 20 years later and the original company went out of business, they can send the VHDL code to another company and say "make this chip using housing XYZ". That will ensure they don't have to scrap helicopters or whatever because a single chip went out of production. Civilians should be equally demanding for critical systems.