Calling Windows 10 APIs from a WinForms or WPF application | Hacker News Reader

Calling Windows 10 APIs from a WinForms or WPF application

blogs.windows.com

84 pointsmcrump69 comments

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

Because Microsoft supports critical applications that businesses use for well over ten years in a lot of cases. Zero other operating systems have to provide the platform stability that Microsoft does.

So, of course, if they have to focus on supporting only one, archaic platform, they never move forward or create anything new or improved. Which doesn't make sense. So you continue to create newer, better platforms, but continue to support the old ones for years to come. Eventually, older ones fall out of use and can eventually be retired.

They only have to provide this because they lock down their products. They do it to themselves.

This is only partially true. A large issue is that most of the software that runs on top of their products is also locked down. So when people have business critical software that's no longer supported by the original developer there's no way to fix it if the operating system gutted support for something they depend on.

Tailor-made business-critical software is supported in a completely different way than your average shrink-wrap.

"Sure we can update from Win32 to $modern. We estimate it to take between thirteen to seventeen man-months. You know the usual rate for a man-month, let us know when you want to start the project."

Let's not forget that there are still huge COBOL applications out there, still updated and maintained by rather well paid engineers.

The enterprise market has repeatedly chosen locked-down-and-supported over free-but-you're-on-your-own.

This will probably never change.

What would happen if the vendors got together as an organizational body (or their employees as a union/guild) and decided to just not provide the enterprise market with even one locked-down-and-supported option?

Then the one company that either bucks the trend or decides to enter the market after them with a locked down and supported option wins the market by default.

Are you imagining a union without any sort of industry-wide enforcement of disbarment for professional malfeasance? That's a pretty nonstandard interpretation of "union."

You'd be willing to disbar engineers for not adhering to your ideology?

Presumably, if it's a union disbarring people for doing something, then it's something the majority of its members feel strongly about. Like how, say, civil engineers feel about buildings being built to code.

Given that the union I was talking about above is specifically one that would be formed by ISVs to protect its member employees from being coerced into bad working conditions by their managers or the clients their demands come on the part of, I assume that "not having to maintain software in perpetuity with increasing labor-load" is probably one such ideological point they'd be likely to stand behind, among others. (Or it might not be; either way, I still think "union that can disbar programmers" is an interesting solution to the problems that programmers do care most about, whatever they may be.)

Remember, the point isn't to punish the disbarred engineer--they likely were coerced into the practice. The point is to signal to the companies who would attempt such coercion, that it will result in their engineers being removed from them, so they shouldn't bother. (Yes, the company's name might also be blackballed in the industry, but that might not matter to the company if they're still able to make money. On the other hand, having no engineers who would ever want to work for you, for fear of what it would do to their careers, would matter.)

The open web and open frameworks supporting it have changed significantly over the past 10 years. It's "keep the old stuff running" or "rewrite" there too.

+ All your apps look the same

- Half of your apps are no longer supported

I think mostly everyone who uses their computer to make their living (ie the prime audience of MS) does not consider this a good trade-off

That argument works to an extent, but all of those screenshots are from components of the operating system itself, not third-party apps. Surely Microsoft has the resources to keep the core components of their OS up to date, and if not, they should devote fewer resources to creating new APIs and more to using them.

Deprecating all but one GUI framework doesn't mean breaking all but one. It just means picking one option and adopting it wholeheartedly. How different would all these Microsoft frameworks have been if they were only finalized after gaining the experience of porting over the entire OS? Microsoft might have ended up with a solution that could unify the landscape on its own merits.

Apple's OS X/macOS has always had an evolving look and feel with notable first-party apps that don't conform, but it's never been half as inconsistent as Windows has gotten.

And what I don't understand is that they are capable to create tools to create very productive UI, but do not seem to be using them themselves. Refreshing the appearance of a menu should take one of their intern a day at most.

The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation.

We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups.

What I find more interesting is that Google products are starting to feel similarly fragmented. Project fi, Android, Plus, and Search all look and behave differently. My damn phone gets SMS on Hangouts and the Messenger app, my voicemails come on the phone and hangouts. None of it makes sense.

We can all agree that inconsistent GUIs are bad, but it seems like a problem you have to solve from a top down organizational perspective, which might not obviously align with the business.

I'm actually not all that convinced inconsistent GUIs are bad. Especially when the main difference is the appearance. They all function identically.

The Excel team even has their own compiler!

The problem is that they keep compiling the same version of Excel, just changing a little bit the color scheme each time.

Word, Excel, PowerPoint were all coded between 1989 and 1993. And received major update with Word 6 and Office 95 and 97. Basically Office 97 was feature complete. Very little has changed since then. The ribbon bar and all the other minor increment improvements are really minor compared to the changes up to Office 97. Office uses it's own UI library. Using Word 6 in Win95 shows floating toolbars in Win3.1 UI theme. Office 95 had an italic title bar. Using Office 97 in WinXP or Win7 shows and Win95 UI theme.

Well, MS removed quite a few ridiculous features from the Office 97 days. Like auto summary or Cliparts.

But removed some quite useful features at the same time, like the ability to customize the UI by moving the most frequently used buttons to the front.

That collage of screenshots is kind of misleading. There are issues however those screenshots are scaled, the theme is different from one to the next. Here's a more fair comparison: http://i.imgur.com/nCmOrmn.png

The philosophy of WPF is that you do all of the UI yourself. It gives great flexibility to make anything look like anything else, but it provides a subpar experience if you mostly need your app to be functional, vs winforms. And as you point out it kills any form of standardisation. What's missing to WPF is good tooling. The current tooling in VS is nothing more than an XML editor, without a useful intellisense, and reverting to a blank page if you need to customize any control.

I wouldn't say it's encouraged to give every control a custom look. It can be done, and far more easily and useful than in Windows forms, but that doesn't mean you have to use it in every application. Horrible owner-drawn controls have been a thing before WPF and just because WPF has better separation between appearance and behaviour doesn't cause inconsistent looking UIs without the developer doing weird things.

The tooling you look for is probably Blend.

In Win9x and even WinXP Luna theme everything looked the same. Even as new as Win7 with its theme or the classic UI in Win7 99% looked very consistent.

But Microsoft tipping point was Win7, everything beyond 2009 was put the former UI and UX guidelines to the trash bin and it seems color blind designers and managers with no taste and understanding are working on the Windows UI. Win8 and Win10 are now and inconsistent mess of dozens of legacy UI frameworks. The little maintained Win32 API is still the most used and best in class - like 99% of applications are coded in C/C++ with Win32API. All the small scale enterprise dotNet apps with legacy WinForm or legacy WPF in legacy dotNetFramework or the new dotNetCore mess are used rarely outside of a small niche market. (all of my hundreds of applications on Win7 are Win32, I see no dotNetFramework in ProcessExplorer - would be highlighted in yellow). And the new WinRuntime aka UniversalRuntime seems to be a trainwreck as well, with limited to to the failing WinStore - clearly a success story ;) Oh and there is the failed Silverlight and the non-public UI API from Win7+ that is used in various new UI elements like Help, Addon dialog of IE10+.

It would be so nice if they once again focus on a nice looking UI theme, and focus on an consistent UI again. In Win95 to WinXP (or Win7) days everything looked to familar and nice put together. If one knew one Windows application, he knew how to use all other applications without searching around or reading a manual. Please surprise me with a nice UI, do away with thr evil phone home features and show that you value the user as your customer and not as dump sheep products. For this to ever happen, they need a major management change and turn-around.

I absolutely love WPF development.

I'm all web now, and I love it too, but sometimes I just wish I could go back to the good old WPF days!

The extensive tooling involved with frontend web development and the constant religious wars between frameworks can get exhausting.

I moved from Web back into Forms, WPF and Android.

Couldn't be happier and dread of the next time I will have to switch customers, because of the high probability to return to web.

Why not port WPF to the web?

I have a better idea, drop JavaScript from Web and leave it as pure HTML/CSS.

It's as easy as disabling it in your browser options. You can purify your own web in seconds!

It doesn't help if the web site is JavaScript only!

Pure html/css can't do everything javascript can. You can't have it both ways.

Of couse it can't, that is the whole point.

The web should be HTML/CSS for hyperlinked documents only, for everything else native apps.

Where should that be enforced? Browsers? Web servers? Firewalls? If you believe the answer is browsers, you can make that change today. Obviously, others don't agree with you. Why should their web experience be limited by your unsupported point of view? You haven't really made a great case.

Is that a reference to silverlight?

As a mostly C++/.NET dev since over a decade, I've tried to embrace the "modern web" a bit more, but as soon as I did... Web development in 2016 feels comparatively _insane_ to a dev used to structured .NET full stack development in a big IDE made for the purpose, on a platform with slow incremental improvements over the years with a vision and coherence from a single company.

It's like assembling a castle from bricks of lego where each brick changes shape every 6 months. Jesus. I feel burnt out before I barely begin! And when I've settled on something, it's about the toolchain and distribution models. "Is it Webpack or Gulp or Browserify and what is a docker image anyway or should I just use Meteor..."

There _are_ options for people like me. Angular 2, EmberJS, big hunking frameworks like those. But then the problem instead becomes that it's hard to grow your web apps organically. The startup... You have to build a huge garden of Eden surrounding it, and only then can you ship your "Hello world". So exhausting before I've barely got started. Besides, what do these big frameworks even _do_ for me behind the curtains? I don't understand the underpinnings. I just have to trust the docs and that they don't change.

So then I tell myself "oh f all that" and build a fun Web API in Python and Flask. And hack raw HTML and CSS in a text editor. The minimalist, pretty code and lack of 100 MB's of dependencies is too alluring. I feel like I'm forced to give up. How in the world will I have enough spare time and energy after full time job days to get even just average experience in the main JS frameworks of today and keep up with "what you have to know in 2017/18/19"? I also feel like the JS world suffers a lot from not settling down, from experience hugely underestimated. It takes time to mature, and create a high quality, broad ecosystem and community. I sometimes think of the waste from the community being this fragmented, keeping to reinvent the wheel.

> There _are_ options for people like me. Angular 2, EmberJS, big hunking frameworks like those.

The biggest problem isn't just that, it's that those big frameworks change fairly frequently too.

I've witnessed web projects go from backbone to angular to react in the span of a year.

I'm mainly a Qt dev, however I needed to add a Cesium component to the application I'm working on. What a mess. Everything about the javascript ecosystem seems to be in a constant state a flux. I tried to make it better with Typescript, but after trying that for ages I realized I was only complicating things for myself, many of my libraries didn't ship typescript definitions, the main one I was working with needed to be generated based on the documentation and once that was done was severely lacking in much of its functionality.

From crashing editors that wipe your files to dependencies that have breaking updates every few days. And there's a dozen options for everything, at least 5 different module loading systems, of which I had to use several in order to get something compatible with both Cesium and node since both use different module formats and I needed a loader that would support both.

Then there's the packing tools which didn't support what I wanted to do at all without a lot of manual hacks.

Eugh, I don't want to touch it again, the whole thing just made me feel incompetent and thrown around.

But I know I have to, and now I'm sitting here asking myself if React or Backbone would help clean up some messy UI code...

I haven't found a compelling reason to move away from Backbone yet. It's not perfect, but it does the essentials and it is very stable and well understood.

Might be the relatively reasonable size of the projects I have going. But it works well for a lot of stuff.

I think a lot of the problem comes from fear of projects becoming obsolete. Ultimately JS/CSS/HTML isn't going to fundamentally transform in short order.

Backbone is definitely stable and solid, and there's a bunch of good addons in the ecosystem that build on it (particularly Marionette for lifecycle handling and more advanced views, Ampersand for a better Model/State class, and Epoxy for data binding).

That said, having built a Backbone app, and then gotten into React+Redux, I'm all in on React and Redux as a better way to build apps. It's a much more consistent mental model, and makes tracing data flow much easier.

I've built three web apps using Cesium, so I'm familiar with some of its complexities. The first uses GWT/SmartGWT, the second uses Backbone, and the third uses React+Redux+Webpack. Of the three, I'm the happiest with the React+Redux one so far.

I'm actually hoping to write a blog post in the next few weeks discussing how to use Cesium with React+Webpack: basic setup, using React to render Cesium primitives, and then advanced Webpack setup for code splitting.

I'm actually building a windows client app at work using wpf. I agree, the web world is exhausting and this work has been a breath of fresh air because I can just get stuff done.

As a user i find going the other way more troubling.

Say i want to use a UWP file manager on Windows 10. Out of the box the folders i can access are limited, and adding more require that i use the age old Win32 file picker window.

Similarly both Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default one. Something that is not always desirable.

So from a user perspective, UWP feels bolted on rather than a integrated part.

I find UWP pretty terrible. :( It feels like developing for a weakest link (the traditional cross-platform problem) which is often Windows Phone or something. Which doesn't exist!! Windows Phone doesn't bloody exist! If MS had amazing mobile market penetration UWP would be amazing but what is this?! How is UWP exactly better than WPF for Windows desktop apps? It isn't. But it's where MS now wants you to be, because they have crazy deeams.

>How is UWP exactly better than WPF for Windows desktop apps?

CoreWindow lets you recolor the window decorations without having to owner-draw the entire thing. But that's all i've got.

WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first place; they wanted a developer platform they could use themselves, and those teams are unlikely to adopt C# anytime soon.

Actually WinRT/UWP are the Longhorn ideas, using the original design of .NET, originally known as COM+ Runtime.

Also a reason why .NET is AOT compiled to native code on UWP.

Right, they tried adopting C#/XAML for the shell and Office with Longhorn, and when that project failed they decided to essentially reimplement WPF and .net in native code, e.g.

WPF text stack -> DirectWrite

WPF visual layer -> Direct2D, Windows.UI.Composition

WPF UI layer -> WinRT XAML

.net type system/metadata -> WinRT metadata

CAS/partial trust/other .net security stuff -> AppContainer

ClickOnce -> AppX

If you compare what .net was supposed to be around 3.0 with what .net Core is now, they've basically stripped out all of the "OS-like" stuff - UI frameworks, app model/packaging, security - and taken the stance that those are the responsibility of the OS. UWP is just the Windows native implementation of the stuff that was stripped out of .net to be left up to each OS

I always thought that .NET should have been AOT compiled to native code since day one, not the JIT/NGEN mix, given Anders experience with Turbo Pascal and Delphi.

But as someone that follows Windows development since 3.0, and had the pleasure to being introduced to Oberon, I think one of the biggest reasons for Longhorn's failure was the wars between DevTools and WinDev.

To build on your mappings, many other components shown up as COM in Vista and since then the majority of Windows APIs are actually COM based, not Win32 C style ones.

Reading the paper about Ext-VOS, .NET's genesis, and doing the comparisasion with how WinRT looks like, was quite interesting.

right now? Two words: Composition API. It's fairly new addition but they've started integrating UWP with hardware accelerated effects (through abstraction of DirectX). Means that finally you can run animations butterly smooth with 60 fps and do more bitmap-based effects on ui elements.

The downside with UWP is that it lives in the runtime sandbox so it's limited in how it can interact with the os (for good and bad). On the plus side there's some really nice integration with OS notifications, app services, handover and stuff like that. I really hope the composition stuff comes to WPF however

Windows Phone still exists. A lot of companies are still buying a lot of Windows Phones. But you will not get them in a customer store, they're OEM phones. Also Windows IoT is and will be used a lot in POS systems, refrigerators, cars, and so on. In this case, UWP makes a lot of sense. But you will never read about it in you famous news blog or paper.

You can still get them in European stores.

Actually when my S3 dies, I will most likely keep using one of those ones instead.

> Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default

Woha. That is pretty crazy.

It's not like Google ever cared much, though. The 'metro' Chrome was exactly the same, just full screen. Still unusable with touch, because of the same tiny hit boxes for controls. They just drew their normal UI (which is completely custom anyway) with a different flavor of DrawBitmapToScreen.

Similar tricks[0] can be used on Win32 applications.

Although, I never got Intellisense working in VS if I declare #using <windows.winmd> in C++/Win32 projects.

A simpler and a lot more interesting alternative (for Win32) is the excellent cppwinrt library[1]

[0] https://software.intel.com/en-us/articles/using-winrt-apis-f...

[1] https://github.com/Microsoft/cppwinrt

The article has Win32 examples too.

Using C++/CX (as seen by ref new).

cppwinrt is ISO C++.

C++/WinRT is still WIP.

I wouldn't use it for production code until it reaches feature parity with C++/CX.

You can use Windows Runtime Library (WRL) instead of C++/Cx.

https://msdn.microsoft.com/en-us/library/hh438466.aspx

Some Apple docs for comparison: https://developer.apple.com/library/content/samplecode/Metal...

That's just sample code. Actual docs look something like https://developer.apple.com/library/content/documentation/Mi...

What inference should I draw from the comparison to Apple docs? Also aren't you comparing a blog post to docs? (Apples and Oranges)

My only concern would be supporting older versions of windows while utilizing features where available. Would have been cool to see an example of doing this in the article.

Just the same, it's cool that it can be added without having to completely migrate/rework an application.

See last few paragraphs.

The Windows 10 API provides API availability checks. So you target the latest version but then add checks to see what API's are available.

This is nice because it encapsulates both OS version API differences and device capabilities.

https://blogs.windows.com/buildingapps/2015/09/15/dynamicall...

    using Windows.Foundation.Metadata;
     
    if(ApiInformation.IsTypePresent("Windows.Media.Playlists.Playlist"))
    {
        await myAwesomePlaylist.SaveAsAsync( ... );
    }

    if(ApiInformation.IsApiContractPresent("Windows.Media.Playlists.PlaylistsContract"), 1, 0)
    {
       // Now I can use all PlayList APIs
    }

Unfortunately that's a Windows 10 API, meaning it isn't very useful for older versions of Windows!

In that case, you put your Windows 10 stuff in a different .dll that doesn't get deployed on old versions of Windows.

The article has an example.

Except the Native API and it's high performance timers!

Reply on news.ycombinator.com