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

Windows Code Samples

microsoft.github.io

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Windows Code Samples

#61

Post by Const-me »

userbinator wrote: post #59
Const-me wrote: post #55

Earlier quoted context omitted.

That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.

The API is COM-like I have been forced to use COM a few times, and that doesn't sound very encouraging... IMHO Win32 is simpler for a lot of things, compare for example the task of using the file selection dialog the Win32 way: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ...with the COM "replacement": https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... (There's a 10-level nested if in…

> forced to use COM a few times, and that doesn't sound very encouraging

I use COM a lot and I love it.

The problem with COM is it’s too many things at once.

It’s an excellent ABI.

At the same time it’s crappy RPC and overengineered serialization framework. In addition, registration could become a point of failure.

You can only use good parts and ignore the bad ones. See how MS did it with their Direct3D or MediaFoundation.

> 10-level nested if in that code

You can write shitty code like that with any framework and in any language. Doesn’t say anything about a framework or language.

Apparently, there’s some stupid policy that prevents them from using ATL in their code samples.

With CComPtr instead of raw interface pointers, you can just return the code when FAILED(), the destructor will release the objects as needed.

Re: Windows Code Samples

#62

Post by WayneBro »

Const-me wrote: post #55
userbinator wrote: post #43

Earlier quoted context omitted.

It makes me think Electron is the new Java. Trying to make things cross-platform inevitably introduces inefficiencies and lowest-common-denominator functionality. The UI may look native but the contrast in everything else is instantly noticeable. That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the di…

That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.

UWP is a sandbox. I wouldn't call that native. You can't even do any sort of local IPC with it if your other process is Win32.

Furthermore:

- You can't run a UWP as Administrator.

- A UWP app has less access to the system and user data.

- You can't develop a UWP app that has in-process plugins.

- You can't hook into a UWP app like you can with actual native Win32 apps, to send keys, hook keys or do screen overlays.

In summary, UWP is full of artificial limitations and that's why nobody is building on it. I'm looking forward to the day when Microsoft announces that UWP is either going away or being pulled out of it's sandbox. Then I'll consider using it.

Re: Windows Code Samples

#63

Post by interlocutor »

marpstar wrote: post #58
interlocutor wrote: post #57

Earlier quoted context omitted.

> Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an issue, but it depends on the type of app you are making. If you are making a calculator app, you don't want it to consume 100 MB of memory and take 15 seconds to start. But if you are making a Business Intelligence app then if it takes 100 MB and 15 seconds to s…

I agree that web-based libraries are being released at a more frequent rate and with greater adoption than desktop APIs, but to suggest that native app development offers no data visualization libraries seems a bit naive.

I didn't say there are no data visualization libraries for native development. What I said is there is no equivalent to D3.js. I recommend taking a look at D3. It is not a charting library. There are charting libraries built on top of D3, but D3 is not your average charting package like MS chart control.

Re: Windows Code Samples

#64

Post by Const-me »

WayneBro wrote: post #62
Const-me wrote: post #55

Earlier quoted context omitted.

That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.

UWP is a sandbox. I wouldn't call that native. You can't even do any sort of local IPC with it if your other process is Win32. Furthermore: - You can't run a UWP as Administrator. - A UWP app has less access to the system and user data. - You can't develop a UWP app that has in-process plugins. - You can't hook into a UWP app like you can with actual native Win32 apps, to send keys, hook keys or do screen overlays. I…

Just because you don’t have permissions to do something, doesn’t mean something is wrong with the API. Technically, you can restrict permissions in a similar way on any NT-based OS. Doesn’t mean the Win32 API is not native. Doesn’t mean those ACL permission checks everywhere are “artificial limitations”.

Most of those UWP’s limitations are here to protect users. Microsoft learned their lesson about the security. I don’t want your app to be able to do local IPC or hook keys on my PC.

Furthermore, you can’t have unrestricted access to the lower levels of the system, and universal apps at the same time. There’s no Win32 subsystem on the phones, or on embedded windows 10.

Re: Windows Code Samples

#65

Post by amckinlay »

mastax wrote: post #47
interlocutor wrote: post #36

Here's the problem: As a developer Electron (see http://electron.atom.io/ ) is more attractive to me than Windows APIs. Take a look at the RSS Reader ( https://github.com/Microsoft/Windows-appsample-rssreader ). I can make a desktop app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs? If I use Electron then my app will run on Mac and Linux, not just Windows, and my…

I don't think MS wants to discourage developing apps using web technologies. They support a number of ways [1,2,3] to turn HTML/JS apps into windows {,store} apps. They've been supportive of using web technologies to make apps before electron existed. The original "modern" app platform for Windows 8 had APIs for C#, C++/CX, and JS. I don't think the first JS push was an effort to improve portability, but portability…

> they're just begging you to put it in the Windows Store.

And now their store is full of crap and no one uses it.

Re: Windows Code Samples

#66

Post by dx034 »

interlocutor wrote: post #57
BoorishBears wrote: post #51

Earlier quoted context omitted.

Here's the problem: As a user, Windows APIs is more attractive to me than Electron. Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). They also have a look and feel that's just "off" most of the time (there's more to the "Flat UI" than having a flat UI). They also tend to not play as well with right click. >I can make a desktop…

> Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an issue, but it depends on the type of app you are making. If you are making a calculator app, you don't want it to consume 100 MB of memory and take 15 seconds to start. But if you are making a Business Intelligence app then if it takes 100 MB and 15 seconds to s…

I disagree with that. PgAdmin is a great example of how bad performance can be when you choose to build a non-native app. I admit it's not in Electron, but the idea behind it is similar.

Performance is especially important for BI programmes. Start up time can be a bit longer, but users will heavily use the programme, so every delay to use it will be noticed much more than for a non-BI app. Navigation without using the mouse is also more important for BI apps, and typically worse in non-native apps (not that it couldn't be different).

So while the pure start up time is itself not a huge problem, non-native apps will also take more resources and time performing tasks, which is a huge deal for BI apps.

Re: Windows Code Samples

#67

Post by xorblurb »

Const-me wrote: post #55
userbinator wrote: post #43

Earlier quoted context omitted.

It makes me think Electron is the new Java. Trying to make things cross-platform inevitably introduces inefficiencies and lowest-common-denominator functionality. The UI may look native but the contrast in everything else is instantly noticeable. That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the di…

That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.

> On some Windows platforms, win32 API is emulated and very limited.

hm, very limited, maybe. There is actually no public Win32 for the platforms you have in mind, I think, but a subset is common with UWP. However, it's not emulated... and probably nearly all of Win32 are standing right there, only you just can't use it...

For ex in Win8 RT the whole (or nearly whole) Win32 was there and could even be used by a non-Windows program: Office.

Re: Windows Code Samples

#68

Post by wilun »

erikbye wrote: post #37

Most interesting thing MS has released the code for recently is perhaps the KMDF and UMDF. https://github.com/Microsoft/Windows-Driver-Frameworks

This was previously in the WDK, I think, which was public (maybe only since a few versions, but nevertheless I believe at least even the Win7 WDK was public, so it has been a "few" years now...)

Re: Windows Code Samples

#69

Post by felixrieseberg »

interlocutor wrote: post #36

Here's the problem: As a developer Electron (see http://electron.atom.io/ ) is more attractive to me than Windows APIs. Take a look at the RSS Reader ( https://github.com/Microsoft/Windows-appsample-rssreader ). I can make a desktop app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs? If I use Electron then my app will run on Mac and Linux, not just Windows, and my…

I used to be the project lead for Electron at Microsoft (now building the Slack Desktop App) and I'm super happy to say that there's been a lot of great work around interacting with native Windows APIs from Electron: https://felixrieseberg.com/using-native-windows-features-fro...

Re: Windows Code Samples

#70

Post by xorblurb »

mrweasel wrote: post #12
ealexhudson wrote: post #5

Earlier quoted context omitted.

In all honesty, I wouldn't be that surprised if that happened at this stage - I don't know that they would have much to lose, but they'd potentially have an awful lot to gain.

I suspect that large part of Windows, perhaps not the kernel, but many of the required subsystems, are written by 3rd. parties and licensing will prohibit an open source release of Windows.

There definitively are some third party components in Windows, but I believe in the core most is either written directly by MS or at least the copyrighted (or its handling) is transferred to them. Parts of an old NT kernel has already been published for a limited audience (mostly education and research, with some additional prereq and with the need of an explicit licence), so probably it can be done again.
Post reply on HN