Slashdot Mirror
Notch Won't Certify Minecraft For Windows 8
MojoKid writes "The backlash against Windows 8 from various developers continues, but this time a game's creator isn't just expressing discontent. Notch, the developer behind smash hit Minecraft, has declared that he won't be working with Microsoft to certify Minecraft for Windows 8. Note that this doesn't mean Minecraft won't run on Windows 8. The certification process in question is Microsoft's mandatory rules for submitting content to the Windows game store. In order to be listed there, an application must be Metro-compatible and conform to a laundry list of other conditions. The real problem with Windows 8 is that it locks ARM users into a second class experience. If you buy an x86 tablet, you can download programs from SourceForge, GitHub, or any file mirror. If you're an ARM user, you can download programs from the Microsoft store and that's it. The bifurcated permission structure is the problem, and it makes WinRT tablets categorically impossible to recommend for anyone who values the ability to install whatever software they please."
no significant loss of features aside from backward compatibility itself
That's a common misconception perpetuated by clever marketing, but it's flat out wrong.
Metro/WinRT is not Win32 modernized, instead it is Silverlight 6 Tablet Edition.
It's severely sandboxed, even more in some ways than Silverlight 5 was, which means that really important things that a lot of common applications require just Don't Work At All, and can't be made to work unless Microsoft relents and releases Windows 9 with a newer, more permissive API.
To give you an idea of just how restricted Metro/WinRT apps are, they're prevented from communicating with Desktop apps and traditional local services. That means that there's no shared memory, no named pipes, no Windows event passing, not even "localhost" sockets! Really major things can't be done, like runtime code generation (JIT), which directly impacts applications like Firefox and Chrome. Statically compiling Java code may work for some apps, but not if dynamic class loading is required.
Put yourself in the shoes of an Enterprise developer: Message Queues? Missing. LDAP? Nope. Background services? Blocked. Oracle client? Hah! Local database? Can't connect. Group Policy? Unavailable. PowerShell Integration? Desktop only.
Try this from a games developer's perspective: OpenCL? No JIT. PhysX? Can't talk to the driver. OpenGL? Over Ballmer's dead body.