
Calling Windows 10 APIs from a WinForms or WPF application - mcrump
https://blogs.windows.com/buildingapps/2017/01/25/calling-windows-10-apis-desktop-application/
======
diimdeep
Look at this screenshot of context menus in Windows 10
[https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large](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.

~~~
CoolGuySteve
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.

~~~
tbrock
The Excel team even has their own compiler!

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

~~~
frik
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.

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

~~~
cm2187
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.

------
jmkni
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.

~~~
miguelrochefort
Why not port WPF to the web?

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

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

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

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

~~~
pjmlp
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.

~~~
recursive
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.

------
digi_owl
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.

~~~
jug
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.

~~~
contextfree
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.

~~~
pjmlp
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.

~~~
contextfree
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

~~~
pjmlp
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.

------
diego_moita
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...](https://software.intel.com/en-us/articles/using-winrt-apis-from-
desktop-applications)

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

~~~
becarefulyo
The article has Win32 examples too.

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

cppwinrt is ISO C++.

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

[https://msdn.microsoft.com/en-
us/library/hh438466.aspx](https://msdn.microsoft.com/en-
us/library/hh438466.aspx)

------
dorianm
Some Apple docs for comparison:
[https://developer.apple.com/library/content/samplecode/Metal...](https://developer.apple.com/library/content/samplecode/MetalGameOfLife/Introduction/Intro.html#//apple_ref/doc/uid/TP40017382-Intro-
DontLinkElementID_2)

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

------
tracker1
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.

~~~
becarefulyo
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...](https://blogs.windows.com/buildingapps/2015/09/15/dynamically-
detecting-features-with-api-contracts-10-by-10/)

    
    
        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
        }

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

~~~
becarefulyo
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.

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

