Hacker News Reader

Comment by 013a | Hacker News Reader

Just 4 months ago they announced they were suspending development of OneNote Win32 in favor of just the UWP version [1]

Moreover, they have (had?) an entire multi-year roadmap planned around UWP, including the eventual release of a version of windows which was supposed to substantially reduce day-to-day reliance on Win32 for lower powered devices, codenamed Project Polaris [2], in an attempt to compete with Chromebook-like devices.

This is a massive destruction of confidence in the UWP platform. If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?

[1] https://www.theverge.com/2018/4/18/17252312/microsoft-office...

[2] https://www.windowscentral.com/understanding-windows-core-os...

View on HN

"If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?"

That's why I avoid any kind of Windows desktop development. They release a new framework every 2-3 years and developers are expected to adopt it. But then they drop support for that framework quickly and release a new incompatible one.

In the Windows environment choice is bad. You only have bad choices and the frameworks that are being used for flagship apps like Office are not available to devs.

I really envy iOS devs where the path to an app is straightforward and your biggest problem is to use ObjectivC or Swift.

Except that's not what Microsoft does at all. The .NET Framework is forward compatible and very rarely breaks compatibility. You can select multiple compilation targets for .NET and have a single piece of code that compiles to multiple frameoworks concurrently.

I currently am maintaining a handful of Projects that build Nuget packages compatible with .NET Core, .NET Standard and .NET Framework.

If you do have compatibility issues you can easily set preprocessor directives and implement platform specific work arounds just like in C or C++.

We aren't talking about .NET in general bit about desktop UI frameworks. If you started with ASP.NET MVC years ago you still are on the main platform that's in full development. With desktop development you have several frameworks that are either in support mode or not fully featured.

GDI, Win32, and XAML are the only ones that come to mind for me, am I missing some? 3 frameworks in 3 decades seems reasonable considering they all still work. The same can't be said for MacOS

If you're referring to Silverlight, that was never a serious desktop UI framework. It was initially targeted as a Flash /Java killer but pivoted to cross platform desktop apps when it became clear that it would never be adopted on Mobile and that Apple/Google were actively trying to kill Flash on the desktop.

That being said, we got XAML from Silverlight and it's not terribly difficult to covert ti a XAML or even UWP app from a Silverlight codebase.

You are missing Winforms and several XAML frameworks (WPF, Silverlight, WinRT and UWP). Even if you use one of the XAML frameworks porting any app of decent size is really hard to almost impossible.

I think trouble started with .NET. Since then there was a change in direction almost every 2-3 years.

Edit: Forgot WinJS...

Because before the reorganization, .NET used to be part of DevTools, while C++ and related tooling was part of WinDev.

So since .NET was introduced there has been an ongoing power struggle between the two camps regarding how the future of Windows development should look like.

The whole Longhorn/Vista debacle was more a side effect of those political issues than actual technical problems. Likewise with lack of management support for bringing Singularity and Midori outcomes into mainstream Windows, or trying to replace .NET with WinRT.

The reorganization was supposed to help sort out such silos, apparently it wasn't successful at that.

I guess the MS org chart is still accurate:

http://www.globalnerdy.com/2011/07/03/org-charts-of-the-big-...

Everything lives on top of win32. Even UWP is a wrapper around win32, if you look at the modules list you'll see gdi.dll in the list.

In a sense the rest of these frameworks are all just libraries. You can choose the one that makes your life easier but win32 will do the heavy lifting. Because of this its relatively easy for them to add support for new features to the various frameworks. They just wire up the win32 calls as necessary.

I don't think that's correct. In Winforms and MFC every control is a Win32 window. As far as i know WPF has only one root window and then does all the drawing by itself on a canvas.

How it uses windows is orthogonal to whether it’s based upon win32 APIs. The framework may add some of its own controls, but copy+paste and even touch hit testing are win32. This is very unlike say KDE vs Gnome.

I used to work on the office UWP apps, and I’ve seen the underlying code.

What do you mean same can’t be said for macOS? Carbon and Cocoa. Cocoa has been around since 2001 (17 years), and is still going. Since 2007 UIKit has been around (11 years) and doesn’t seem as if it’s going anywhere either. I personally think Apple has the nicest UI frameworks to develop for, and the longevity is quite good. The frameworks (particularly UIKit) regularly get meaningful updates to make it modern, and now there’s an entire new modern language that’s 100% compatible while moving things forward.

Disclosure: I happen to work for Apple, but this was my previous opinion having spent many years using all the major frameworks/platforms out there.

> What do you mean same can’t be said for macOS?

I wasn't so much taking a shot at Apple as I was trying to point out the stability of Windows. The reality though is that APIs on either system outlive the usefulness of most applications.

In a purely technical sense though you can't run a 2001 era Cocoa App on a 2018 Mac without recompilation. You can't run a System 7 era App on a 2018 App without at least minor API tweaks (Cocoa isn't 100% compatible with System 9's API). You can run a 1990s era Win32 App on a 2018 Windows 10 PC without recompilation.

ASP.Net MVC 5 (ASP.NET Core) was a complete rewrite of MVC/Web API. The MVC work that was done previously would have to be completely rewritten.

Why are you targeting net standard and core in your nuget packages? Targeting standard should be all you need to cover both.

> They release a new framework every 2-3 years and developers are expected to adopt it. But then they drop support for that framework quickly and release a new incompatible one.

Doesn't matter, as a developer you're free to pick whichever you like. You can run VB6 apps on Windows 10. A software I've made on my first job with MFC for NT4.0 still runs on Win10. WPF is awesome, I still pick it now in 2018 when I need compatibility with older Windows.

WPF hasn’t been seriously upgraded for a long time now. I love WPF, but it is beginning to feel like WinForms.

Didn't realize, I really like WPF too, hope that executives aren't trying to push too many efforts towards whatever they think the trends might be, I tried Xamarin for mobile but ended up switching to Android Studio and just targeting there.

"Preparrrre for Q#........" (jk on that....for now)

I think it matters a lot. If I develop an application that's supposed to be in development for many years I want to use a framework that has a forward path to the latest OS features.

> a framework that has a forward path to the latest OS features.

Microsoft usually adds support of OS features into old frameworks. For example, they have added touch support into their 25+ years old MFC.

Technically speaking, WPF gets updated regularly with each release of .NET framework. For example, in 4.6.2 they have implemented per-monitor DPI scaling support.

As a developer, I like stable APIs, and frameworks which don’t break my code with version upgrades.

If I'm starting development on a Windows 10 app tomorrow, with no legacy codebase, and I'm going to target only Windows 10, which framework would you suggest? I want it to be the best of both worlds: when running on a Surface or other detachable with the keyboard detached, it should have no compromise compared to an iPad Pro app in its UX, with fluid gestures, working well with high PPI screens, and so on. At the same time, when running on a system with keyboard and mouse, it should have no compromise relative to a classic desktop app with all the power users expect, like full multitasking.

Which framework provides the best of both worlds?

Not UWP, since it doesn't offer full multitasking and is limited in various other ways like sandboxing that I can't opt out of.

Is there ANY framework that provides the best of both worlds?

You can but it would be better for developers if you could rely on a framework being developed rather than frozen in time. I'm pretty sure there are no classes supporting touch in MFC.

> I'm pretty sure there are no classes supporting touch in MFC.

https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-clas...

Thanks, I was clearly wrong on that point.

True, but it's not like frameworks stop working. I still write an occasional app in WinForms and it works great.

I personally know of some companies that are still running VB6 programs on Windows 10. We're talking about 1998 tech here. Even the development tools are still working 20 years later on the newest version of Windows.

I agree with you. I would never take a job doing Windows desktop development and I am a big fan of .Net and Microsoft’s development tools.

But web development is far worse.

Developing UWP apps is challenging though, it's not a straightforward experience and as a result many people hate it.

I don't know if you've ever had to debug a UWP app but compared to almost anything else it's painful. Exceptions don't propagate properly, and finding errors takes a ton of time. Development is likewise painful with elements of random things being required and the packaging and publishing process a nightmare compared to competitors.

UWP was made for phone and Microsoft then ported it to Core OS, but as a format it is not developer friendly. If you look at new Microsoft under Satya - and their goal of being developer friendly, this move makes sense. I wouldn't be surprised to see UWP and the current store deprecated entirely (as they are honestly failures).

The UWP version of Office has never really made sense. Office is a massive project and a moving target from a features perspective. It seems like a monumental task to reimplement it from scratch.

It makes more sense to gradually rewrite portions of it but that doesn't work well with the annual release model. It does however work with the O365 continuous release model they adapted from Windows 10.

Just as they're gradually porting Control Panel and other legacy Win32 apps to the Settings App. I could see them gradually convert Office to modern cross platform frameworks.

They have been "gradually porting" the control panel since Windows 7... with like three different UI frameworks in its Windows 10 version it's one of the best examples of Microsoft's schizophrenic approach to code updates

"gradually porting Control Panel and other legacy Win32 apps to the Settings App"

They have been porting the control panel since Windows 8 and it's still far from done.

How hard can it be to rewrite control panel in UWP?.

With all the bits that have lived in there since Win95, I suspect it is something of a Lovecraftian horror.

Parts of it are public API with the API specifying the look and even the size of the panels. It’s impossible to rewrite without breaking compatibility.

Compatibility with what? Do people do UI automation with the control panel?

Drivers can add panels to it, for instance to allow the user to change mouse settings.

>If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?

Endemic at Microsoft. I believe the main reason the Xbox One Kinect - an impressive piece of hardware - failed, is that Microsoft themselves couldn't manage to make one big flagship game for it at launch. If Microsoft themselves are avoiding it, why on earth would third parties invest?

While it seems ironic and uncoordinated at first glance, perhaps UWP is right for OneNote since it has far fewer features than Word or Excel, and less legacy, being a newer app?

This whole headline feels like deja vu... how many times has Microsoft promoted and then abandoned Windows Mobile?

What I find most remarkable is that they are still using Win32!

Why rewrite a massive code base that works in WPF? That would have been a mistake.

Win32 probably is just WinAPI, not necessarily 32-bit application.

Correct. I have never heard the term Win64.

Reply on news.ycombinator.com