3 ms·
Win32 should be in a nursing home right now awaiting death. They should have just made a clean break from it. I can't understand why anyone would want to deal
by peterkelly 13y ago
Win32 should be in a nursing home right now awaiting death.
They should have just made a clean break from it. I can't understand why anyone would want to deal with that abomination in this day and age.
And given that it's ARM, you wouldn't be able to run any of your existing apps anyway, without the vendors recompiling (and quite possibly having to update their code in the process).
- com2kid 13y ago> Win32 should be in a nursing home right now awaiting death. It is well tested, has high performance due to its heritage, and is really damn flexible. You rarely find yourself going "well that isn't possible" with Win32 given how many iterations the API has been through. Unfortunately making a general purpose API of any sort tends to get ugly as more and more stuff is added to it, and then add in legacy requirements, and yes things are pretty icky at times. But any other API that is capable of as much as Win32 is would end up looking almost as bad, minus a lot of the legacy cruft, except of course in the time it takes to develop such an all encompassing API, you'd end up with legacy cruft all of your own!
- revscat 13y agoThe same could be said of Cocoa.
- dottrap 13y agoCocoa (like everything) has some rough patches, but overall is clean, elegant, and has a pretty consistent feel and vision. Proof is that ARC exists. This is the only reason compiler tools like ARC are possible. If Cocoa were too inconsistent, ARC could not be exist. Given that Cocoa's origins are from the 80's (NeXT) and Foundation is still with us today on iOS (and UIKit is very similar/familiar to AppKit), this is an extraordinary accomplishment and it has succeeded better and longer than any of its contemporaries.
- lloeki 13y ago> Cocoa (like everything) has some rough patches, but overall is clean, elegant, and has a pretty consistent feel and vision. Exactly. Also, Apple has the courage to regularly deprecate and subsequently remove things from Cocoa/Core/Darwin, keeping it clean, focused and elegant. Which bring us to the GGP comment: > But any other API that is capable of as much as Win32 is would end up looking almost as bad, minus a lot of the legacy cruft, except of course in the time it takes to develop such an all encompassing API, you'd end up with legacy cruft all of your own!* To which I disagree wholeheartedly (not just because of Cocoa, but every single sane API out there regularly deprecates then drops stuff). Win32 accreted features around a core of cruft like a black hole. The only solution for Microsoft is to relegate the 8/16/32bit heritage lying at its core and drop it dead as it's collapsing under its own weight. Which is what they did with the Win8 internal design, where Win32 is relegated to a gangrenous limb awaiting to be severed.
- rsynnott 13y agoAh, but what is Cocoa? :) In practice, Cocoa has had at least two major refreshes; a major overhaul of AppKit in the NeXT->MacOS transition, and the replacement of AppKit with UIKit for iOS (and I'd be sort of surprised if AppKit isn't eventually deprecated and replaced with a UIKit derivative on the desktop; UIKit smooths a lot of the rough edges). Bits get added to Win32, but it hasn't really had much substantive change to existing stuff in a very long time.
- jdjb 13y agoWin32 is the only thing going for Microsoft on the windows side. They're far too late to the touchscreen party to dictate the tempo of UI design and thus they appear as a "me too" solution. The only thing they could possibly offer that Google/Apple can't would be to run windows-specific applications on your latest version of Windows. Throw that away and there's no reason why a Surface Pro 360 beats a Galaxy Tab 4 or iPad 4/5.
- peterkelly 13y ago> Win32 is the only thing going for Microsoft on the windows side And this is their key problem. They're stuck in the past, relying on previous successes and unable to come up with anything new that's sufficiently compelling for people to adopt. Contrast to Apple, who made the switch to a modern, object-oriented API 13 years ago which has steadily improved, and their willingness to cut old technology (after a transition period - see Carbon and PowerPC). iOS had zero compatibility with anything that came before, with the exception of the underlying frameworks. Microsoft needs to be able to demonstrate this level of innovation in order to survive in the long term.
- dragontamer 13y agoI don't trust Apple. I can run Win95 programs on Windows8 still, and that is a good thing. If I'm building programs that last decades, I don't want to build them upon Apple's quickly changing landscape. I mean, afterall, as much as Win32 is legacy code... Posix / SysV compatibility in Linux is an even bigger one. That doesn't make Linux a bad system, on the contrary, it makes me confident in building long-term solutions on top of those systems. Microsoft has their new APIs: C# and .NET, which are all good and all for new programs. But their constant support of Win32 API is frankly one of their best assets. APIs with 30+ years of backwards compatibility are _good_ for the programmer.
- rsynnott 13y ago> If I'm building programs that last decades, I don't want to build them upon Apple's quickly changing landscape. There's definitely a niche for "write once, run forever" (for a more extreme example, see the IBM 360/70/80/90/z/Architecture; a modern z/arch mainframe can run binaries made for a 360 half a century ago, unmodified), but it generally isn't that exciting to consumers, and even the enterprise market seems to be getting a little more cautious of it for internal stuff.
- davidgerard 13y agoWin32 will be around as long as COBOL or Java. It's one of those boring "forever" technologies that the world actually runs on.
- pgeorgi 13y agoWin32 is the only official way to "side-load" applications to a Windows box (ie. not through their store). That's reason enough for me to reject Windows systems that don't have an open Win32 environment. Every recent architecture change was used to lock down Windows: Windows on x86-64 enforces driver signing harder than Windows on x86. Windows 8 enforces Microsoft signed Modern UI apps. Windows on ARM enforces full lock down (drivers, Win32 apps, Modern UI apps, bootloader). It also prevents those signed Modern UI apps to run their own JIT. While one could argue that this is for security (inability to mark data as executable code after the fact, and so on), it's not even possible to use the CLR JIT on your own dynamically generated byte code, which might be a crude workaround for other VMs (JS, Java, ...): add a CLR target. If the CLR JIT is considered unsafe, Microsoft should disable it altogether (but that would slow down the platform even more), but if it's safe they should make it available to developers. This isn't about security, it's about their competition. Open Win32 is what keeps Microsoft somewhat honest (since they can't simply lock it down that way, as long as they keep caring about compatibility). The only redeeming part of the Windows on ARM story is that it doesn't matter commercially. May it stay that way.