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 561390
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by Nelson
by Nelson on Mon 13th May 2013 11:27 UTC 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[3]: Comment by Nelson
by dpJudas on Tue 14th May 2013 12:23 in reply to "RE[2]: Comment by Nelson"
dpJudas Member since:
2009-12-10

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.

In my opinion the point of the original ReactOS article was partly that Microsoft once again burned the developers that were using their technologies. I am well aware that there are countless alternatives to XNA, but that still means that if you relied on XNA all that knowledge is now totally useless, and any code you wrote up against it now has to be rewritten or at least ported.

And strangely enough this time Microsoft is even forcing people to port to technologies that doesn't tie them into their platform. That is what I meant by calling it suboptimal from Microsoft's point of view.

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 have no love for XNA, nor WinForms, since I'm generally a native developer by trade. I used neither much beyond trying them out shortly. But this isn't the 1990's anymore where Microsoft could get away with burning developers left and right. Not everyone is in awe about everything Microsoft as you are, and they might simply chose to drop the platform.

Yes, this isn't likely to happen for Desktop, but for Mobile this is can become a real threat to Microsoft.

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.

OK, thank you. This is the missing piece that I've been overseeing whenever I got MSDN links about Modern. I thought I was seeing garbage collected C++/CLI (which generally interacts really poorly with other C++ code), while I was actually seeing reference counted C++/CX.

No need for all the insults. For someone that doesn't follow all the Microsoft blogs daily it is a perfectly reasonable error to make. The two systems are almost identical visually after all.

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.

There were many reasonable reasons to not target WPF. For starters, Microsoft tried to not support Windows XP in the beginning, until they realized the market would not adopt their new tech if they insisted on this. So many people were left with the unpleasant choice of either using MFC (eek!), use WinForms, or only support Vista which had no users yet.

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++.

I probably should have been more clear in my original posting, but my main issue with CLR has never really been the "native vs managed" angle. As a C++ developer the problem with C++/CLI has been that it integrated terribly with ordinary C++ code to the degree that you now were simply coding in a form of "poorly skinned C#".

C++ and C# each have their strengths and weaknesses and if you're going to be forced to adopt the C# weaknesses (such as IDisposable and finalizers), then you might as well take the advantages too and switch language. Which has always been my personal grudge against the CLR, that any other language targeting it had to adjust to becoming a worse C# (the language the CLR was effectively designed for).

C++/CX does seem to go about this differently from what I can tell so far (due to the switch from GC to refcount). I'll have to toy around with it a bit to see how it integrates. ;)

WRL on the other hand.. what a disaster! I doubt anyone will use that.

Reply Parent Score: 1

RE[4]: Comment by Nelson
by Nelson on Tue 14th May 2013 16:13 in reply to "RE[3]: Comment by Nelson"
Nelson Member since:
2005-11-29


In my opinion the point of the original ReactOS article was partly that Microsoft once again burned the developers that were using their technologies. I am well aware that there are countless alternatives to XNA, but that still means that if you relied on XNA all that knowledge is now totally useless, and any code you wrote up against it now has to be rewritten or at least ported.


MonoGame maintains a great amount of compatibility. The only parts it doesn't support are the XBox Live leaderboard API which only ever worked on the 36 and less useful APIs like the Microphone API.


And strangely enough this time Microsoft is even forcing people to port to technologies that doesn't tie them into their platform. That is what I meant by calling it suboptimal from Microsoft's point of view.


I think there is an overriding priority to ease development. It reflects the fact that more Unity and Unreal devs exist than XNA devs. Microsoft doesn't have a sizeable amount of XNA developers even complaining about this.


I have no love for XNA, nor WinForms, since I'm generally a native developer by trade. I used neither much beyond trying them out shortly. But this isn't the 1990's anymore where Microsoft could get away with burning developers left and right. Not everyone is in awe about everything Microsoft as you are, and they might simply chose to drop the platform.


Its worth quantifying developers. Users of XNA were XBLIG users (not that many) and WP7 developers. WP7 developers can still use XNA on WP7 using the compatibility layer on WP8 or they can port to MonoGame, or port to other middleware.

XNA can even used reflection to access the WinRT API from WP7 projects and support new APIs on a WP7 app running on a WP8 device. There are a lot of options for people genuinely affected like this.

But then again this is the whole point: The only people complaining about XNA are people who don't use XNA. Its people looking for clickbait that see a headline and automatically think that developers breathed more than a collective sigh of release.

Yes, some WP7 devs complained. Most by now have been convinced by the quality of MonoGame that things are not really that bad, and in fact, are better.

MonoGame is innovating on XNA, bringing it to more platforms. It runs on iOS, Android, Windows, Windows Store, Windows Phone 8, etc.

Prior to MonoGame Microsoft hadn't updated XNA in a meaningful way in years. XNA was already a dead technology, not due to Microsoft axing it, but due to poor popularity.


OK, thank you. This is the missing piece that I've been overseeing whenever I got MSDN links about Modern. I thought I was seeing garbage collected C++/CLI (which generally interacts really poorly with other C++ code), while I was actually seeing reference counted C++/CX.


C++/CLI has great interaction with existing C++, Microsoft just had the luxury of going many steps further and introducing the deep level changes needed to avoid a shim like C++/CLI.

I did find it a fun exercise to write a mixed mode WPF and C++/CLI program back in the day. The interop story actually isn't that bad, but was bad was the mental model needed to even think in mixed mode.


No need for all the insults. For someone that doesn't follow all the Microsoft blogs daily it is a perfectly reasonable error to make. The two systems are almost identical visually after all.


It just shows the distorted lens through which people view Microsoft and WinRT, and it really is unfair. The Windows Runtime adresses *exactly* the problems that this article truly gets at, which is a disparity between native and managed code APIs.

With the WinRT, .NET is a first class citizen as a consumer of the Windows API. So is JavaScript, and so is C++.

.NET finally got a good API interop story with native code
Native Code finally got a native modern UI stack
JS got an optimizing AOT compiler, API interop, and some other misc things iirc.


There were many reasonable reasons to not target WPF. For starters, Microsoft tried to not support Windows XP in the beginning, until they realized the market would not adopt their new tech if they insisted on this.


I was hearing about Avalon going to XP since early 2004 probably if memory serves me correctly. It was a big effing deal at the time, so devs had plenty of time to see the tea leaves.

To me, the WinForms people are the same people that jumped on the Managed DX bandwagon.

The truth is that straight up wrappers like that rarely get long life times and you have to go in there knowing that. I knew from the start that WinForms wasn't how true .NET UI code should be written. It felt too much like native code with managed code veneers.


So many people were left with the unpleasant choice of either using MFC (eek!), use WinForms, or only support Vista which had no users yet.


The problem is that its' been over a decade since Vista RTM'ed, even more since Avalon CTP builds went out.

How do people not have their ducks in a row yet? The real people who have a duty complaining are those in the most position to affect change People locked into WinForms using LOB contracts would've been in there were WinForms mainstreamed or depreciated. Thats how that game works, unfortunately.

I was getting WinForm jobs in 2010 the same way I get WPF jobs today.


I probably should have been more clear in my original posting, but my main issue with CLR has never really been the "native vs managed" angle. As a C++ developer the problem with C++/CLI has been that it integrated terribly with ordinary C++ code to the degree that you now were simply coding in a form of "poorly skinned C#".


My C++/CLI code never touched my pure ISO C++ just like my C++/CX code doesn't touch my ISO C++. You could on a per-file basis change types to use the CLR or to use pure C++ when using C++/CLI.

The real annoying language extension was Managed C++, that was truly terrible.


C++ and C# each have their strengths and weaknesses and if you're going to be forced to adopt the C# weaknesses (such as IDisposable and finalizers), then you might as well take the advantages too and switch language. Which has always been my personal grudge against the CLR, that any other language targeting it had to adjust to becoming a worse C# (the language the CLR was effectively designed for).


IDisposable still exists for WinRT components because reference counting still isn't determinalistic, and some things are too expensive to wait for.

Some types implement IDisposable (now moved into VCLibs and under ABI::Windows::Foundation::IClosable COM interface) which helps you get a determinalistic clean up of resources.


C++/CX does seem to go about this differently from what I can tell so far (due to the switch from GC to refcount). I'll have to toy around with it a bit to see how it integrates. ;)

WRL on the other hand.. what a disaster! I doubt anyone will use that.


WRL isn't that bad, just that documentation is lacking. You initially hate WRL, but once you try to write straight up C based WinRT code you quickly come to love it.

Reply Parent Score: 3