They failed to see people rapidly losing interest in Windows (Charles Petzold's Windows 8 book sold so badly, he gave up on Windows for Xamarin. The forced async paradigm also added massive complexity for cross-platform development. So Win32 applications would work just fine on Windows 8, but if you wanted they fancy new features, you were either SOL or had a long development cycle ahead of you. You couldn't even create COM ports (necessary for GPS dongles) in a Windows 8 (not mobile, just regular desktop) WinRT/UAP app.
Bluetooth LE or VPN APIs for example never came out until too late. In addition there was a much smaller API surface. This was particularly brutal for open source libraries (like OpenCV/OpenSSL etc.) which were sorely necessary if you wanted to target all 3 mobile platforms.
This means that extensive porting efforts were required for code that used to work fine on Win32. This was incompatible with existing ways of writing Windows code, so you couldn't bring (almost) any legacy code over. Silverlight was a pretty mature technology and there was developer interest (at least in the Microsoft ecosystem).Ģ. Let me lay this out as a long time Windows developer and someone who loved Windows Phone 7/8 compared to iOS and Android.ġ. most of the NSDocument stuff such as autosaving and previous versions.)Ĭompare this to the hodgepodge of different interfaces even in Windows' builtin apps alone, and championing a different API almost every other year.įair enough.
Even as a developer you just need to build against the latest AppKit and you get not only all the current features, but usually future features for free too (e.g. However, almost every macOS app has the same standard menus, same standard shortcuts, and most of them support the same OS extensibility features. Built ins like Calendar had skeumorphic UIs. > The flag-carrying apps (Adobe, Final Cut, Garageband) had custom UIs. I was a purely PC/MS user up until about 10 years ago, but I haven't suffered as many befuddled facepalm moments from Apple's UI decisions as from the Escheresque nightmare that Microsoft is even now.
This is not a binary question of either a desert or either a rainforest, but Apple's side of the fence is definitely a lot greener than Microsoft's in terms of UI/UX consistency. > Maybe my memory is bad but I don't think OS X ever really had it.
I wonder if was just bowing to the irrational hostility some people have to any use of goto, even though this is a highly structured pattern that should be uniform across your codebase, the opposite of unstructured, ad-hoc uses of goto that are the actual problem. I worked on Windows at Microsoft and with very few exceptions, the only time I saw the pyramid-of-doom was in the public documentation. You can get real cute and even have the macro assign hr for you, so you can drop the “hr =“ from your code. One common pattern is actually to just put the entire line of code inside the macro, so your code would look like CHK(hr = AWin32Function(param1, param2)). This is how error handling for non-trivial functions is done in any serious C code, regardless of the platform. CHK being defined as something like “if(FAILED(hr)) goto Error ”. You can encapsulate that whole logic in a macro so you just call something like CHK(hr) anytime you have an error code to check. After calling any function that can return an error code, you check the error code and “goto Error” if necessary. The correct way is to have an “Error:” label at the end of the function before all the cleanup code. It’s funny that they use that awful pyramid-of-doom error handling style in a lot of the public documentation.