I think it's more likely a question of: "Does such a move make us money in a non-negligible way?"

Porting Office to Linux would be most likely a zero-sum game - a PC which formerly ran Windows now runs Linux. The amount of Office installations remains the same.

Such a move only makes sense for a company if they're opening up new markets - and currently it's obviously not a big enough number.

Listen, I don't really care. The original argument was: "It's impossible to connect to live cams and shit!"

Somehow you made xbox controllers out of it, I don't really care and if I searched a bit more it would most likely turn out to be possible after all. Plus, Universal Apps are targetted at touchscreens on tablets and phones. If you really need to run an emulator or something, Win32 ist still available.

I'm not exactly sure how you think something like this is achieved on other mobile platforms which also will close apps not currently in the foreground at will.

https://developer.android.com/training/best-background.html

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

Maybe you should research a bit before talking out of your ass?

Well, they do restrict THOSE specific ones because, for example, you don't access gamepads through the USB / HID namespace. You use Windows.Gaming.Input

They stated the reasons in the clear: "to prevent conflict with other Windows APIs" - you can access those just fine, you just have to use their specific namespaces and not the generic ones.

So? Register a background task which does exactly that. https://msdn.microsoft.com/en-...

I have to ask: Did you actually look at what is possible?

Nope. You just need to use the Windows.Devices.HumanInterfaceDevice namespace and jump through some additional hoops.

Because that measuring device I was talking about? That's also not on their list. But I can use it regardless.

I don't think that there are a lot of Android programs out there which are permanently network connected even when their app is closed.

You also might to want to look into a thing called "background tasks". Those are executed in response to events (like incoming Voip calls) - but a background task that's permanently running and sucking data limit dry? Bad idea on a tablet / mobile.

Of course you can get that to work - you can access USB devices just fine through Universal Apps.

I'm currently doing that myself for a USB measuring device which is used for Physics lessons and can measure speeds, voltage, magnetic field strengths and so on. The vendor's program is written by engineers for engineers - and not so much suited for pupils. So I'm using the Vendor's API and implement a custom-tailored solution for every experiment the pupils have to do.

Of course it's a huge problem if Office runs on an OS other than Windows. That's why they ported Office to Android and iOS.

I'm not sure how useful an FTP server is for the intended target audience.

There's also a plastic hull to contend with. Plus, such a leak is not exactly "fails catastrophically". After all, we're not talking about strong acids or bases here - the most problematic would be the manganese due to its toxicity, it's a heavy metal after all. But as long as you don't eat that stuff, you won't have any problems.

Look at the ingredients - carbon, wet ammonium chloride and zinc chloride as electrolytes / electron conductors, zinc and mangan(IV)-oxide as the electrodes.

There are quite a lot of battery types out there which are much more nasty. This? This is something you can give your pupils to demonstrate how batteries work - it's that harmless.

That's why they have a steel casing around the Zinc, genius.

Well, it's the one which passes all the checksums and error corrections. Plus, in case it's ambiguous, you can always shut down both ports in both networks.

It's not even possible in theory. There are several reasons for that.

1. The routing of data is hardcoded into the switches and cannot be changed without physically accessing the switch. The routing table not only determines which devices may talk to which devices, but also the direction of the data flow. This means that a monitor device cannot talk to an engine because the monitor is configured only to receive data.

2. But even if they managed to get the monitor device to send data, the switch would recognize this as a device malfunction (because it's not allowed to send) and disable the port it's sending on. This is not due to security against hacking but more due to "a malfunctioning device should not be able to DOS the plane's network".

3. There are actually two networks, sending identical data for redundancy. Now guess what happens if one of the networks sends different data than the other? Right: The offending port / device gets shut down.

4. The network protocol is a modified UDP protocol (no need for TCP) which makes the network deterministic - data delivery is guaranteed within a certain timeframe. Which means, again, that you need specialized hardware to even talk to the network.

5. And even if you managed to take down both switches, there'd still be a manual override in the cockpit which allowed the pilot to steer the plane without the network.

In essence, you need pretty hefty physical access to modify the planes flight mechanics. Something you will not achieve while the plane is in the air and even very unlikely while the plane is on the ground.

Um, the development of the frontal lobe and its importance for the development of human cognitive processes has been pretty well researched.

But I'm done with your particular brand of trollish behaviour - if you have nothing to contribute but mindless insults then your opinion is most likely worthless.