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

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