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.
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.
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.
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.
Shoulda used TRS80 and arcnet.
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!”
They're so cute when they're young. But so clumsy. Someday this little Windows 3.1 machine will grow up to be bigger stronger, just not any faster.
> [ Or emulate ] ....In a Browser.
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!!
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.
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.'"