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 561520
To read all comments associated with this story, please click here.
RE[4]: Comment by Nelson
by Nelson on Tue 14th May 2013 16:13 UTC 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