Hacker News Reader

Comment by roc | Hacker News Reader

> "And it seems like they're not willing to get rid of any of that for the new world of web/mobile apps"

They did it pretty handily with WP7 development.

And Win8-on-ARM obviates the legacy issue anyway. There's going to be a clean-slate development approach put forth as the recommended way to develop for 8. There's no way around that.

It'll almost certainly look a lot like current Windows development (likely just a new iteration of Silverlight and .Net). And just as certainly, legacy apps will stick around in a sort of "XP Mode" for x86 Win8, but they're going to be phased out.

If MS isn't talking yet, it's probably just because they have a new slew of buzzwords and marketing to finish drafting before they introduce it.

View on HN

But, a good part of the point of .Net was that the managed code was in MSIL and being compiled to X86 down the line rather than by the developer, so the argument that ARM support requires a move from .Net really doesn't hold water.

I'm hoping there's more to this than meets the eye, but... Here's a test case for you. VB6 apps are supposed to be going out of support relatively soon, but there's a lot of them still out in the wild. The understanding had been to redevelop them in .Net, but based on this exactly what should the authors commit their investment to? Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.

> "the argument that ARM support requires a move from .Net really doesn't hold water."

I would draw a thick, dark line between managed .Net and "legacy". When people talk about legacy Windows code, they're talking about those massive enterprise apps running front ends written in VB6/MFC-era code. Those are the ones that Microsoft has to push to the curb in Win8 [1].

That said, any number of .Net tricks to enable legacy behaviors will likely pose roadblocks for particular apps. So some .Net incompatibility will be at issue as well.

> "but based on this exactly what should the authors commit their investment to"

I'd imagine the question Microsoft is grappling with, is which versions and parts of .Net they can reasonably support. Though I'd be surprised if anything they recommended in the last five or so years that wasn't supported.

That said, anyone designing an enterprise replacement in the last five years, who did so as anything other than a web app is likely out of their gourd [2].

[1] i.e. live on in an XP-mode style ghetto only on Win8x86

[2] Sure, some of have some steep client requirements that rule out web apps. But that's a tiny minority amongst enterprise apps. The overwhelming majority are workflow/database interfaces.

Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.

Don't get carried away. MS has been very clear that you can run any Windows app here. If you're porting over old VB6 apps it seems clear that porting to VB.NET makes the most sense. .NET development isn't going away as at the very least MS's web server-side story is still all .NET.

Yeah, that's what is confusing to me about any .NET developer employment angst. ASP.NET and other business infrastructure technology seem unaffected by desktop software innovation. I have to believe that desktop software is a small piece of all .NET development and innovation in this area shouldn't threaten the platform.

I agree. Whatever this is, it won't completely invalidate all of .NET. And the world could use better options for making desktop gui's on Windows.

Reply on news.ycombinator.com