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."
Thread beginning with comment 561312
To read all comments associated with this story, please click here.
Comment by Nelson
by Nelson on Mon 13th May 2013 02:51 UTC
Nelson
Member since:
2005-11-29

The death of Silverlight is an understandable one. Times changed. Just like WCF, which was a typed approach to web services, Silverlight is just mismatched for the current times. As originally envsioned, Silverlight was much more than a LOB app platform. It was an entire RIA stack and video delivery framework. HTML5 and especially the video tag took over for a lot of the reason that Silverlight existed. The things that remained that Silverlight was *really* good at was a small niche which didnt have enough clout to matter.

An interesting twist being Silverlight being repurposed for Windows Phone. It is still pretty actively used there but its obvious that Windows development is trending towards the Windows Runtime. The latest Silverlight incarnation in WP8 exposes a small subset of WinRT APIs on the phone.

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.

For the purposes of Windows 8, this is enough. On the enterprise side, they have a very sizable and growing presence in Windows Azure along with SharePoint and other Office related properties. That's significant and is attracting a new breed of developer to the Microsoft stacks.

What also cannot be downplayed is the fresh talent that the Windows Store platform is attracting. There are over 65,000 Windows Store applications. The barrier to entry to making money on Windows has never been lower. It is easier for small time developers to make money on Windows.

So, really the issue is that Microsoft is taking a phased approach to transitioning developers to the Windows Runtime. This time around, it was a consumer focused release with consumer focused APIs getting the lionshare of attention. WinRT is already in Windows 8.1 showing signs of improvement in functionality.

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

WPF turned into Silverlight which turned into the Windows Store platform. Its all the same underlying technologies, albeit smarter implementations with varying feature sets. Silverlight was always an offshoot of WPF for a different use case. The WinRT APIs are more comparable to WPF in use case, but pared down for the Windows Store sandbox.

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.

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.

It blurs the line between managed and native code. Microsoft can write WinRT components in C++ and consume them naturally from JS and C#. They can write the less performance sensitive ones in C# and consume them from JS and C++. Its really flexible.

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.

From another angle, Microsoft is improving managed code performance with Cloud Compilation on Windows Phone 8 which makes start up times for apps nearly instant.

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.

Reply Score: 2

Moonies
by tomz on Mon 13th May 2013 02:59 in reply to "Comment by Nelson"
tomz Member since:
2010-05-06

AKA the unification church.

Silverlight was a web platform something like Flash.

One of the things I notice on my Android tablet is that websites work. Often slowly or not well, but I can get to what I need instead of the blue lego icon on an iOS device. Which means Flash. Flash is awful, but is what is there, not unlike Win 3.1, Win 9x (and "Me").

Microsoft can't be Apple, but they can declare they are now the same with the app store, etc.

(remember Steve Jobs comment) Mack and Cummins ando others make trucks or truck parts. Not cars. They would likely be terrible if they abandoned the truck business to build cars. But that is MSFT. Better a bad car company than a successful and profitable truck company?

Reply Parent Score: 2

RE: Moonies
by Nelson on Mon 13th May 2013 03:24 in reply to "Moonies"
Nelson Member since:
2005-11-29

Silverlight wanted to be a web platfom. It never got to be one before HTML5 got good enough and it instead turned into a very specialized Line of Business application platform.

Silverlight was extremely good because it supported cross platform execution Out of Browser and platform agnostic integration with the host. It was an extremely attractive proposition for existing .NET shops who were invested in Microsoft technologies.

Reply Parent Score: 1

RE: Comment by Nelson
by siride on Mon 13th May 2013 03:36 in reply to "Comment by Nelson"
siride Member since:
2006-01-02

Small correction: WinForms is not a wrapper around MFC. It's a managed replacement for the same idea, but doesn't involve any MFC components. It does, of course, wrap the Windows API fairly closely. If you dig into the WinForms decompiled code, you run into API calls without having to go very far.

Reply Parent Score: 5

RE: Comment by Nelson
by moondevil on Mon 13th May 2013 06:20 in reply to "Comment by Nelson"
moondevil Member since:
2005-07-08

It blurs the line between managed and native code. Microsoft can write WinRT components in C++ and consume them naturally from JS and C#. They can write the less performance sensitive ones in C# and consume them from JS and C++. Its really flexible.


Personally I would like if they just use an optimizing compiler for .NET and throw away the VM stuff, or improve the code quality of NGEN.

Singularity had Bartok as native compiler for C# code, and Windows Phone 8 applications are compiled to native code with their optimized cloud compiler.

Now I just want to have the same for my C# code on the desktop/server.

Reply Parent Score: 3

RE: Comment by Nelson
by dpJudas on Mon 13th May 2013 07:31 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

RE[2]: Comment by Nelson
by Nelson on Mon 13th May 2013 11:27 in reply to "RE: Comment by Nelson"
Nelson Member since:
2005-11-29

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.


XNA developers were never numerous, the majority of XNA apps are written as Windows Phone 7 apps, which can still be written today if you wish.

You can also use MonoGame which is a free and open source implementation of XNA across Windows 8, Windows Phone, iOS, and Android.


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


Its a better solution than XNA, which is why I never got the issue. XNA was never good and most people who used it disliked it. I've never liked it and thought it was an overengineered mess. Suddenly its dear to some people when Microsoft *finally* axes it.


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.


No. There is no bridging with C++/CLI, in fact, if you all a C++ WinRT component from a C++ app the CLR isn't even loaded.

WinRT components use COM to define the ABI, so under the hood they're native code. The only time the CLR is loaded is if the WinRT component itself is written in C#.

The C++/CLI syntax you see is just Microsoft re-using it for C++/CX, their extensions to C++ for authoring WinRT components.

You can write WinRT code with ISO C++ if you don't mind using the WRL template library.


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.


WPF is not used with the new WinRT XAML APIs. They're not the same thing. The XAML stack in WinRT is native.



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?


Generally, yes. People knew it was a stop gap. Any .NET developer knew it didn't feel like writing .NET code. WPF brought us a proper framework with the full benefits of .NET.

I was already writing Avalon code when people were just starting to use WinForms, if people adopted it beyond more than a temporary wrapper then that's on them.



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?


My God, this isn't true. How do people like you get away with such misinformation and bullshit?

Write a C++ app, call into the WinRT APIs, look at the loaded modules with WinDbg or something and notice that mscorlib is NEVER loaded into the app. WinRT APIs are for the most part pure native code called from .NET code, or JS, or C++.


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.


No it isn't. Spend one day writing one line of WinRT code and you'd know that you're wrong.


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.


How people can be so absolutely ignorant of the facts astounds me.

WinRT is essentially a COM-based API, although relying on an enhanced COM. Due to its COM-like basis, WinRT allows interfacing from multiple languages, just as COM does, but it's essentially an unmanaged, native API. The API definitions are, however, stored in ".winmd" files, which are encoded in ECMA 335 metadata format, the same format that .NET uses with a few modifications.
http://en.wikipedia.org/wiki/Windows_Runtime

The language extensions borrow syntax from C++/CLI but target the Windows Runtime and native code instead of the Common Language Runtime and managed code.
http://en.wikipedia.org/wiki/C%2B%2B/CX

while the XAML framework is part of the Windows Runtime, written in native code
http://en.wikipedia.org/wiki/Windows_Runtime_XAML_Framework

Since you've been shown to be so afraid of the facts, watch this video on the internals of the Windows Runtime where they hold your hand and walk you through explaining that its native code.
http://channel9.msdn.com/Events/Build/BUILD2011/PLAT-875T

Reply Parent Score: 3

RE: Comment by Nelson
by segedunum on Mon 13th May 2013 13:07 in reply to "Comment by Nelson"
segedunum Member since:
2005-07-06

You could have distilled that down into one word: Astroturfing.

Reply Parent Score: 5

RE[2]: Comment by Nelson
by Nelson on Mon 13th May 2013 13:20 in reply to "RE: Comment by Nelson"
Nelson Member since:
2005-11-29

Yeah, because pointing out facts is astroturfing. Unlike the morons in this thread, or even the person who wrote the article, I've actually the technologies being discussed.

I've shipped deliverables using most of the technologies mentioned here and have followed their evolution. Is it astroturfing to point out that WPF, Silverlight, and WinRT share a similar lineage?

Or to correct falsehoods than WinRT is managed or is interoped using C++/CLI? Is that astroturfing?

Is it astoturfing to correctly point out the target demographic for Silverlight? All of this is independently verifiable. Silverlight was a RIA platform, it launched a long side RIA Services for .NET and had a scope that was different than what it ended up being.

Is it astroturfing to point out that XNA is terrible and has always been? Most people who actually used XNA, you know, the ones who would even give a damn, never liked it anyway and are glad to be on better middleware.

Unity, Unreal, or whatever are infinitely more supported and accepted by game developers and content creation tools. Its a more natural fit into the workflow. XNA was always deadweight and only on Windows Phone because Microsoft wasn't ready to put native code on WP7 and they needed a managed graphics API.

Had Microsoft had more time, I have no doubt that XNA would've never launched on the platform in favor of DirectX interop with WinRT which is more natural.

Reply Parent Score: 2