Linked by Thom Holwerda on Mon 16th Oct 2017 10:47 UTC

All of the new design changes to Windows 10 are demonstrated in a new video from Microsoft. It’s a good showcase of how subtle the changes are, but it doesn’t tease much for the future. Microsoft’s Fluent Design System is designed to be the true successor to Microsoft's Metro design, and will appear across apps and services on Windows, iOS, and Android. Microsoft is focusing on light, depth, motion, material, and scale for its Fluent Design, with animations that make the design feel like it's moving during interactions in Windows.

Like Metro applications before them, these Fluent applications look really nice, but it's all for naught. Microsoft showed off its redesigned Outlook application for Windows (and macOS), and guess what? It's a Win32 application.

If not even Microsoft itself is interested in making Metro/Fluent applications, why should anyone else?

Microsoft's approach to Metro/Fluent has been baffling from day one, and it doesn't seem like anything's changing any time soon. They made really great Metro Office applications, but then proceed to hide them from the Windows Store behind the "mobile" tag, and artificially cripple them by not allowing you to open more than one document per Office application.

Even when Microsoft does make great Metro/Fluent applications, they artificially cripple them.

I have no idea what Microsoft is doing, and I don't blame developers for giving them the finger. They are telling an unreliable, unfocused, unclear, and chaotic developer story, and any developer worth her salt wouldn't touch the Windows Store/Metro/Fluent with a ten-foot pole.

Permalink for comment 649906
To read all comments associated with this story, please click here.
Member since:

Some developers already "ported" their code to Windows Store (, IrfanView).
They are actual reiteration of the same win32 app but deployed under Windows Store logo.

Paint.Net is not a Win32 app. It's written using the DotNet framework. I just decompiled it under Telerik Decompile to take a look at the internals. I didn't look to far, so I don't actually now which toolkit it uses for the UI (but it has models, so possibly WPF.) The think here is, the .Net framework is missing a common UI toolkit implementation. I guess if it had one, this would have a good chance of running on Mono, possibly .Net core and maybe other OS supported by them.

A lot of this "Win32" hysteria is a bit more complicated. I'm not talking about Office or any specififc app. I mean, going forward - in general - things are going to get a bit fuzzy, even after UWP becomes the default target.

This is the thing - you can compile a 32-bit target in ,Net easily. In fact there are 3 targets under Windows:

1) x86
2) x64
3) AnyCPU

If you compile for AnyCPU, (god help you) it will be up tot he runtime to decide how to run it. But if you compile for x86, it *will* run as a 32bit process. But that has little to do with Win32.

The framework you use has P/Invokes in to the OS. A P/Invoke is like JNI on Java or an extern function in C that links to an external dynamic/shared library. The OS level P/Invoke decides how to work. So in the Windows versions of .Net there will be some P/Invokes in to Win32. There will also be code calling directly in to Win32 because that was how the framework was written. I think we need to separate these calls from the notion that something targets a specific API.

With the UWP frameworks, all of the linking is done behind the interface, and is opaque tot he user of the API. But a UWP app can still be calling in to a Win32 API. Nothing stops the library from being written that way on Windows.

Edited 2017-10-16 14:21 UTC

Reply Parent Score: 6