Linked by Kyuss on Mon 13th May 2013 01:31 UTC
Microsoft "Most people understand that Windows is used by a variety of people who have a variety of needs, ranging from corporate server to workstation to POS terminals to home PC and beyond. Most people accept that whenever Microsoft updates Windows, it has to balance the competing requirements to find some kind of workable compromise. There is however another set of competing requirements that many do not really register, even those that call themselves power users or are IT admins. It is a conflict between developers/programmers and Microsoft itself."
Permalink for comment 561367
To read all comments associated with this story, please click here.
RE: Comment by Nelson
by dpJudas on Mon 13th May 2013 07:31 UTC in reply to "Comment by Nelson"
dpJudas
Member since:
2009-12-10

Generally though, from the perspective of developers that Microsoft targets, they've done well. They target existing mobile app developers (Windows Phone, iOS, Android) and they target existing Game vendors with DirectX and various middleware technology.

You are ignoring the fact that anyone coding for XNA now has to find a new "middleware" technology. Generally I agree with you though, the damage seems so far to be fairly limited as most of them flocked to Unity as a result.

However Unity works everywhere, which from Microsoft's traditional point of view is suboptimal as they prefer programs to only run on their systems. ;)

That's not even mentioning the fact that today native developers can use a subset of the Windows Runtime APIs from their Desktop applications.

I am not sure what you mean by this. From a native developers point of view Windows 8 appears as this oddly incomplete mixture of COM APIs (Direct3D, DXGI, etc), and then having to bridge into .Net with C++/CLI to truly cooperate with the Modern UI.

As an example of this, if you want to target Modern with Direct3D or Direct2D, you have to first create a .Net WPF window (using C# or C++/CLI), and then obtain a native IUnknown for the WPF CoreWindow object. Only after this can you call IDXGIFactory2.CreateSwapChainForCoreWindow which is required to setup a native rendering context.

In other words: there are no native interfaces working with Modern.

Btw: Windows Forms was always a managed wrapper around MFC, a wrapper around Win32. Most of us understood that it was a stop gap measure, plus WPF was already showing up in PDC builds as Avalon. We knew more was coming. The only people who got fucked over on WinForms were the LOB people who generally don't have much forward facing agendas once they're developed to spec.

Strictly speaking WinForms is a wrapper around GDI+, with its API closer resembling Delphi (where Anders Hejlsberg came from) than MFC.

I am not sure I understand your point though. You are saying that people that had to write a C# UI, before WPF was ready, had it coming and gets what they deserved when Microsoft stopped updating this API?

The Windows Runtime is Microsoft's attempt to fix the problems of the past. WinRT enables a language neutral rich API set to be exposed to many languages. You can invoke an asynchronous API in WinRT, await its value, and chain a response with Javascript Promises. You can do the same in C++ with the PPL or in C# with async/await and the work stealing task scheduler.

From a native developers point of view WinRT is just a fancy word for deprecating all Win32 functions related to GDI. There is no C++ support for the newly introduced Modern APIs as those all require C++/CLI. You are coding about as much in C++ when using C++/CLI as when you're coding C++ when writing an Objective C class with Objective C++. It is a nice bridging feature, but surely you wouldn't claim that P/Invoke makes C# a first class citizen for Win32?

It will make the exact problems this article brings up a thing of the past. The WinRT XAML stack is the UI framework for native AND managed code in Windows going forward. That's the richness of WPF with the performance characteristics of native code.

Microsoft marketing couldn't have written it better. Sadly that doesn't make it true. The "WinRT XAML stack" is a .Net assembly and has nothing to do with native.

Microsoft is unifying its platforms across various form factors and execution models. Looking forward, things are incredibly exciting.
This is Microsoft's .NET, Longhorn, and Avalon vision imagined.

Now on this we can at least agree. This is their second attempt at deprecating native development and force all future development to be CLR only.

That vision train-wrecked Vista. History will tell if it will do so for Windows 8 too.

Reply Parent Score: 7