In different areas, though. Windows also supports some very old hardware and the FOSS community is also out of luck when phone chip makers stop releasing blobs/kernels.
Part of the problem here is that SoC drivers are hacked on top of the kernel (and are not merged in-tree). So SoC vendors have this pile of legacy and hacked-on code they need to cherry-pick every time the Kernel changes an interface they used (which is a lot) [0]. Of course, that costs and fortune and hampers the sales of newer chipsets so it’s not in the SoC vendor’s interest to do so.
I was hopeful with Windows Phone running a build of NT that the platform would still have the same strict ABI compatibility for drivers as the desktop version has. So you get kernel updates and the existing drivers just work.
Now, with Windows getting some emulation support for Linux (one of their Subsystems for Linux effectively translates system calls and execution happens in the NT kernel) I wonder if they could ship a phone running NT with an Android userland.
But we're talking about source compatibility, not binary compatibility. So getting around the quirks of the old devices is an already solved problem, even if it needs to be #ifdef'd out for the newer devices. The problem isn't technical, it's a philosophy that treats every device as an opaque special case, rather than factoring out the common parts and abstracting out the differences. Of course the incidental complexity continues to pile up.
I've got 18 years of experience running Linux, compiling my own kernel and packages on a Slackware base up until 2002 or so. In that time I also did embedded design and development for about five years, using cp/zip/email as the ultimate revision control. I know the two philosophies pretty damn well, and I'm unequivocally stating that Android and CM are being run as embedded development projects, where code flexibility and maintainability take a back seat to just making working blobs for specific device configurations. This is ridiculous for what purports to be an open source OS running on a computer roughly equivalent to a desktop PC circa 2000.
But alas, I'm being downvoted into oblivion by non-technical fanboys who probably think that flashing a phone is a highly technical activity, rather than just annoyance due to manufacturer obfuscation (this isn't you - which is why I'm replying to your comment. it's general frustration with the non-thinking HN masses these days). The incidental complexity from the non-scalable development philosophy has built up so much that most people are incapable of even seeing my simple point.
So then, I'm out. I'll keep dreaming of being in a place where I'd have the time to dedicate to making an actual open source user-centric mobile OS to run on mass market hardware. Android will make a great Windows XP.
My point was that the intersection between the low level programming where you do care about which architecture you are running on and phones is very very slim.
Not saying that shouldn't be the case, but that is unfortunately where we are.
I disagree. I would even say that it is as least as easy to support most Android-based devices than it is to support most Hardware running Windows.
In both platforms you run into very little issues for most apps, and you need to add support for lot's of different configurations if you write on the system level (Game developers can tell you a tale or two about this).
POSIX only covers the API's not the ABI's the software will run on. Also, that still leaves them running on a vendor specific CPU architecture.
Your naive if you believe Microsoft and Google don't hold all the cards with thier platforms. More and more of Android is being swallowed up by Google Play Services. Windows does have a central software repository called "Windows Store". Let's not forget about how users have to put up with thier shenanigans because they are the gatekeepers to apps.
By the same token... if you want to run Android applications the situation is much worse on x86 processors, because while Android is supposed to be agnostic the reality is that there hasn't been any requirement for developers to target x86 market wise for a long time, and anything that goes remotely near direct graphics rendering or video DRM tends to break quite badly.
Isn't this pretty much a no-go for any large public software project, given that microcode updates often depend on the OEMs, which are notoriously bad about supporting devices older than about a year?
yeah, no. Tooling support, driver support and general Optimization matters. So does platform maturity.
You don't want your phone to run x86 (and it won't for a while) and though possible its a pain to deal with an arm server at the moment because some random library you use just won't be compatible. And If single threaded performance matters, ARM is behind by a decade.
Because it is extremely disruptive to the entire platform? Windows has been keeping decades old APIs on life support for the sake of business customers. This would quite literally be the opposite move.
These two ecosystems have not converged in the past 20+ years, why would they now?
Also, somehow most Android vendors still provide bootloader unlock keys.
Probably not as Chinese devs will be unable to cheaply write crummy drivers in it. Plus it is a huge cost.
Better replace the kernel with L4 and a good set of services. Except those platforms have way fewer developers also because they are not as easy to develop for.
I think that the point of this comment is that that's mostly incorrect. There are support libraries which basically mean that any device can run at any API level. This is fact, it has been for a while. Suck it up.
One exception: the vast majority of Android games use a portion of native code; which won't run on Intel chipsets without at least a recompile.
All WinPhone apps run on the .NET VM; however it's up to Microsoft what chips get used in Windows Phone devices. So far; the only SoC in Windows Phones has been the Snapdragon. It may be a while before we see other ARM chips used; much less x86. (This is excluding a theory that Win8 may possibly extend to phones as well)
FWIW, you are my single most respected commenter on HN, and I often find that you've commented with what I would have wanted to say myself were I only a bit quicker.
But while this is very interesting and I am learning a lot from it, I do think you're stretching a point to breaking here.
> Here we go,
:-)
> Android uses the Linux kernel, tranparently!
>
> Officially only native shared libraries are allowed by non-rooted devices.
OK. I didn't know that.
> Windows Phone 7 only allowed .NET applications for common developers, C++ applications required a special license from Microsoft.
Interesting.
> Windows Phone 8.x used MDIL (Machine Dependent IL), with a on-device linker at installation time.
OK. Both only ran on Arm32, though, didn't they? So, not native, true, but also not cross-platform binaries?
> Windows Phone 10 used MSIL as main package, and Windows Store does the job of AOT compiling that MSIL with a so called cloud compiler.
Again, fascinating stuff. Still Arm-only, though, right?
> Doesn't matter, unless one is using Metal C, all applications use TIMI.
I submit that it does.
I was saying that 2 OSes I knew of allow the same binaries to run on multiple different CPU architectures: Inferno and Taos/Intent/Elate. There are no native binaries and if you compile source to a binary, the result is inherently natively cross-plaform.
These examples are all fascinating but they are examples of a different phenomenon: where the OS does not allow or does not have native object code for the metal underneath, the only permitted binaries are in some abstract form or for some abstract architecture...
But if the OSes only ran on one arch, then the cross-platform part of the equation is missing.
> What matters is the orignal version.
Did MCP run on >1 native CPU arch?
> There were commercial systems using native compilation like Corvus Systems workstations.
Did the resultant binaries run on different platforms, though?
> Modula-2 was designed for Lillith and M-Code originally.
Originally, maybe, but that is not where it enjoyed mainstream success. I first encountered it as Topspeed Modula-2, the fastest compiler of any kind for the original IBM PC and compatibles.
> Lillith uses bytecode with interpreter on microcored CPUs.
Bitsliced, weren't they?
Anyway, I did not know that. I'd argue that in all other implementations it was just a natively-compiled language like Pascal before it.
> Oberon System 3, nicely documented on its manual.
I will read up on that. I see someone's added it to the Wikipedia page since I did quite a bit of work on that.
> Xerox PARC systems use bytecode formats, before booting the OS, a microcoded interpreter for the respective bytecode format is loaded into the CPU.
reply