whartung wrote:
They've ported the kernel. I never said anything about the kernel.
I'm talking about the eco-system, the development environment, and the underlying philosophies of the OS and, by projection, the community.
I'm just going to agree to disagree with you, but I will conclude with this: the underlying philosophies of the OS are very much an export of the NT ecosystem, regardless of hardware port in question. You actually have no choice
but to expose the development philosophy; it's the
kernel, and that pervades
everything. One need look no further than the relative philosophies of Linux and BSD maintainers to see this in action in a visceral way.
NT has no fat binary structure; you're right. That's because it doesn't need one. But then again, neither does Linux, which is undeniably the most ported operating system on the planet to date, running on everything from "wristwatches to supercomputers".
Quote:
Developers seamlessly ported to the ARM environments of the portable devices, and the build chain supports this as well.
Going to just nod my head in silent "OK" on this. I know a few iPhone developers personally, and they have a very different opinion that you do about the ecosystem, how easy things are, etc.
Quote:
...as most developers would need to simply click a check box and rebuild their code with little actual interruption to their normal workflow.
IDEs are wonderful things, aren't they? Of course, I can do the same with most open-source products sans an IDE or philosophically compatible runtime environment with a simple:
Code:
$ MARCH=doohickey make blah
The platform retargetability is an intrinsic feature of GNU (and, for compatibility, LLVM) toolchain in particular. Remember, X-Code is not anything special; it sits almost entirely on top of GNU and/or LLVM tools.
Quote:
They wouldn't have to flag their software in any special way,
This is definitely not true; the last time I used X-Code, there were multiple checkboxes I had to configure correctly to get a fat binary that actually worked. That X-Code
automates this process
most times is quite nice; but that configuration has to be there all-the-same. Thankfully, this is a thing of the past for me, and I suspect for a lot of other people, because the idea simply hasn't taken off at all. And not for lack of trying. Besides NeXTStep, the Oberon community had a similar, and vastly superior, technology called "Slim Binaries" (get it?), which was in many respects the intellectual forefather of both WebAssembly and LLVM. In the POSIX arena, a technology called ANDF was the hero of the day. Etc. Etc.
Quote:
Developers get all of that "for free".
You get what you pay for. Nothing is truly free. Nothing.
Quote:
Objective-C is written at a higher level than normal C or C++.
Please illustrate with an example. On the surface, this argument is incredulous, seeing as how Objective-C works at a fundamentally lower level of abstraction than C++ (no templates, weak type-checking fixed only a decade later, and only by making
massive changes to the ObjC compiler semantics ultimately leading to them abandoning Obj-C in favor of Swift).
Quote:
Part of that mandated that coders adopt different idioms during development that fosters portability.
This makes no sense, and seems irrelevant. So far as my experience is concerned, things considered good practice in MacOS X are pretty much the same things in Windows and Linux too, MacOS X
User Interface Guidelines notwithstanding. Always check your result codes for errors, always close or free resources that you've opened or acquired. Release your acquisitions in the opposite order they're acquired, etc. The community ultimately decides the UI guidelines in use, not the kernel or APIs per se. This can be seen by studying the KDE vs Gnome communities, and even in the Gnome world, Ubuntu-vs-non-Ubuntu sub-communities.
Maybe you're talking about something else, more in the middle of the software stack? Or, maybe it's just an artifact of the app approval process for iPhone and MacApp stores. But, I'd argue this is a
social incentive, not a technical incentive.