Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Calling Windows 10 APIs from a WinForms or WPF application

blogs.windows.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Calling Windows 10 APIs from a WinForms or WPF application

#41

Post by contextfree »

pjmlp wrote: post #40
contextfree wrote: post #38

Earlier quoted context omitted.

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

Re: Calling Windows 10 APIs from a WinForms or WPF application

#42

Post by throwawayish »

nikanj wrote: post #24
ocdtrekkie wrote: post #21

Earlier quoted context omitted.

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.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#43

Post by JumpCrisscross »

derefr wrote: post #32
ocdtrekkie wrote: post #31

Earlier quoted context omitted.

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?

Re: Calling Windows 10 APIs from a WinForms or WPF application

#44

Post by becarefulyo »

Longhanks wrote: post #35
becarefulyo wrote: post #7

Earlier quoted context omitted.

The article has Win32 examples too.

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

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

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

Re: Calling Windows 10 APIs from a WinForms or WPF application

#45

Post by derefr »

JumpCrisscross wrote: post #43
derefr wrote: post #32

Earlier quoted context omitted.

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

Re: Calling Windows 10 APIs from a WinForms or WPF application

#46

Post by pjmlp »

contextfree wrote: post #41
pjmlp wrote: post #40

Earlier quoted context omitted.

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 com…

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.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#47

Post by recursive »

miguelrochefort wrote: post #14
jmkni wrote: post #9

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.

Why not port WPF to the web?

Is that a reference to silverlight?

Re: Calling Windows 10 APIs from a WinForms or WPF application

#48

Post by recursive »

pjmlp wrote: post #37
miguelrochefort wrote: post #14

Earlier quoted context omitted.

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!

Re: Calling Windows 10 APIs from a WinForms or WPF application

#49

Post by mhomde »

jug wrote: post #19
digi_owl wrote: post #12

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 alwa…

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 t…

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

Re: Calling Windows 10 APIs from a WinForms or WPF application

#50

Post by lightlyused »

jmkni wrote: post #9

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'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.
Post reply on HN