Obviously the guys at microsoft with a lot more experience in software development will create a superior product. This shouldn't be a surprise as OS X is merely a mod of components derived from linux.
If he wanted to have a nuanced conversation about OS architecture, he could talk about something specific rather than huge generalizations with terms which make it clear he doesn't know enough of the details to be qualified to make such broad statements.
Similarly, talking about one benchmark on one device for a feature which many people don't even use is not a good foundation for comparing the merits of entire operating systems. That's like saying you should buy a particular car because it has awesome door handles, as if there are no other possible factors which you need to consider.
In comparison, Windows 10 has its roots in the Windows NT lineage (starting with NT 3.1, and including Windows XP), which is separate from the DOS-derived Windows line that ended with Windows ME.
(That said, I agree that he was just trolling.)
Mach is not a Unix kernel and the Mach interfaces percolate up to the higher levels for many tasks which aren't covered by the POSIX layers.
The bigger difference, though, is higher up. While you certainly can compile POSIX code on OS X, most of the applications which people run use Cocoa and that owes far more to the NextStep side of its lineage than the Unix bits.
The better comparison might have been Win32 rather than DOS, where most of the interfaces were designed by the Win95 developers even though they were also implemented on top of the NT kernel. I've often wondered how much better things would have been in the late 90s/early 200s if David Cutler's team had been able to get the Win95 team to follow their generally much better instincts rather than the other way around. If nothing else, they wouldn't have needed to spend a decade duct-taping security onto a single-user design.
Microsoft has always been dominated by backwards compatibility constraints so there probably wasn't much scope for a massive redesign of the API, as it was in their best commercial interests for 16 and 32 bit Windows APIs to match as closely as possible, to ease porting of third party software.
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532...
That's a bit silly but it also meant things like dutifully porting the real-mode Windows messaging system's feature which allowed any app to execute code in any other app:
http://en.wikipedia.org/wiki/Shatter_attack
Like, say, sending a message to the anti-virus software running as SYSTEM to get root…
The most entertaining bug I found was one of the times they failed at portability: one of the Win32 APIs to enumerate the contents of a directory worked 100% of the time on the Windows NT systems our development team used but returned no results on Windows 95 unless you had enabled network sharing (you didn't even need to share something; just starting the service was enough). This manifested in a very confused user wondering why our open dialog showed C:\ as empty when Explorer showed their files were still there.
OSX is a strange OS to use. It looks and feels good at first glance but when you have used it for a year, one really longs to return to a pure Windows environment. OSX has weird bugs like the beachball cursor which is something that simply shouldn't happen in a modern OS. The last Windows to have a global lock like that was 9x.
Mach is not an “old era Unix kernel” and OS X is not exactly a vanilla Mach:
http://osxbook.com/book/bonus/ancient/whatismacosx/arch_xnu....
It has a BSD subsystem but plenty of other different things, like a completely custom device driver model (IOKit).
Secondly, you just called everything above the level of the kernel a mod, when that's where most of the code and almost all of the significant differences live. Is Android also “just a mod” on top of Linux?
> OSX has weird bugs like the beachball cursor which is something that simply shouldn't happen in a modern OS. The last Windows to have a global lock like that was 9x.
Windows 10 and most X window managers have the same thing for the same reason: you see the busy cursor when an application stops responding to events within some defined timeout. It's not due to the Win95/Mac OS Classic-like “global lock” you're thinking about but rather access to an unresponsive shared resource. I most commonly see it due to either doing blocking network I/O in the main thread (e.g. Outlook) or making the mistake of assuming that the filesystem won't block which affects just about every app with a network home directory or flaky drive, but it's also common with things like web browsers using a large cache directory where the startup blocks for awhile while the file system churns through millions of files.
The beachball is a very infrequent occurrence on OS X, and if it does happen, it usually doesn't freeze the whole shell. If you're seeing it a lot, this is often an indicator of faulty hardware. That being said...
> This literally never happens on Windows.
Not true, the exact same thing can and does happen on Windows, with similar rarity.
> Also all IO on Windows is asynchronous. It doesn't support synchronous IO.
I'm not super-familiar with Windows IO, but at the very least it has blocking, synchronous C stdlib file I/O, and blocking, synchronous WinSock network I/O. Also, anything asynchronous can be trivially be made synchronous, whether it is a good idea or not.
On Windows it is extremely rare - maybe once a year, but you'd have to be a power user for sure. On Mac, it is usually a weekly occurrence. Hell, I had it happen last night in fact just by trying to mount a DMG file (a freshly downloaded TeamViewer DMG if you must know). It decided to go to the beach instead. After a full reboot it finally let me mount it. It really is a joke of an OS.
If you're not familiar with Windows IO then why try to cobble together a response? It is true that the Windows kernel does not support anything but asynchronous IO. It simply does not support it. Yes, user-mode land implements synchronous wrappers as a convenience for lazy developers or to aid in porting software from other lesser platforms.
As TazeTSchnitzel said, this happens on both and is quite rare. If you're not just trolling and actually see this on a regular basis, it's either a hardware problem, misconfiguration, or something like using an unreliable LDAP server (this was the last time I saw it, back somewhere around 10.5 and, surprise surprise, Windows clients also wedge solid with a slow/flaky domain controller – I see this every time I use a Windows 7 domain client on a VPN).
> Also all IO on Windows is asynchronous. It doesn't support synchronous IO.
Please contact the folks at Microsoft so they can correct the first hit on Google:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Remember how we were talking about backwards compatibility? All of those traditional ReadFile/WriteFile/etc. calls aren't going away anytime soon. Even the teams at Microsoft who work on things like Outlook, Word, IE, etc. use synchronous I/O a lot since it's so much easier and there's no major downside on a local file system, particularly now that even a cheap computer can dispatch thousands of IOPs.
Finally, “merely a mod of components from Linux”? I don’t think anyone cared about the distinction between BSD and Linux or GNU user space tools. Things like a kernel with a multiuser system and different permissions are the types of improvements that were once difficult to handle on most consumer machines, yet they were also incorporated into Windows with NT. UNIX is part of the Mac OS being a modern operating system. Even if you lose the weasel word “merely”, OS X is not only a window manager or desktop environment, at a low level there are significant architectural distinctions between OS X and FreeBSD, and differences between OS X and FreeBSD compared to Linux that were developed at Apple.
The point is not that they cannot be compared, but that they have actual merits to compare rather than weaselly arguments as though we were in a 1990s chat room or forum.