From the footer on that page: "Windows maintained by Microsoft".
Cute...
Windows Code Samples
91–100 of 107 posts
Re: Windows Code Samples
#92Earlier quoted context omitted.
.Net offers reasonable SIMD access through the System.Numerics package. Roslyn offers writing plain IL Assembly, which is heavily used throughout SharpDX, and ultimately, P/Invoke is fast and allows you to call any C++ library you might want if you really want to get down to the metal. Seems a better alternative to me that having to deal with the hilariously bad C++ UWP API
Really, you call this "reasonable SIMD" access: https://msdn.microsoft.com/en-us/library/system.numerics(v=v... ? For comparison get a load of Apple Accelerate: https://developer.apple.com/reference/accelerate . Now that's "reasonable" SIMD access, and extremely heavily optimized on both macOS and iOS for both speed and power efficiency. Similar capabilities are just one command line incantation away in Linux. And if…
For 90% of the usage of SIMD instructions where people just want to parallelize iterating on lists, yes, that's reasonable enough.
Apple Accelerate isn't a SIMD API, it's a higher level API that happens to use SIMD for its utilities. Apple makes great APIs, yes, I can't deny that.
You seem to have forgotten P/Invoke where your performance critical C++ code can actually be called from C#. You get your assembly and everything whenever you want, for a low initial cost of calling your FFI. And you also get a pretty damn good UWP experience, as well as WPF, WinForms and a long list of UI toolkits.
Let's be real for a second though, the Android NDK is an absolute joke , and calling the C++ experience on Android "great" might be pushing it a bit far.
Re: Windows Code Samples
#93Earlier quoted context omitted.
Really, you call this "reasonable SIMD" access: https://msdn.microsoft.com/en-us/library/system.numerics(v=v... ? For comparison get a load of Apple Accelerate: https://developer.apple.com/reference/accelerate . Now that's "reasonable" SIMD access, and extremely heavily optimized on both macOS and iOS for both speed and power efficiency. Similar capabilities are just one command line incantation away in Linux. And if…
For 90% of the usage of SIMD instructions where people just want to parallelize iterating on lists, yes, that's reasonable enough. Apple Accelerate isn't a SIMD API, it's a higher level API that happens to use SIMD for its utilities. Apple makes great APIs, yes, I can't deny that. You seem to have forgotten P/Invoke where your performance critical C++ code can actually be called from C#. You get your assembly and eve…
The beauty of NDK is not that it offers a ton of APIs (it does not), it's that it's not overcomplicated and lets you reasonably easily incorporate a lot of the same libs you're already using on Linux anyway, and build them pretty much exactly the same as any other Linux lib, with minimal, if any modifications using tried and true Linux toolchains. It took me much less time and effort to get my stuff going under NDK.
PInvoke would do me no good whatsoever, since my UI needs are fairly limited, and my entire pipeline is basically capture, resize, run inference, and display. Running it through extra layers would only slow it down -- something I try very hard not to allow.
Fundamentally, though, my issue is this: Microsoft pretends to support C++ under UWP, yet when you actually take a look at what's being offered, you see that it's a bare minimum and it's hardly used by anyone. A step off the beaten path and you're on your own since it seems no one is actually using this stuff. Or at least no one publishes anything on the internet. APIs are idiosyncratic, documentation is sparse, tools are crashy (XAML editor), and there's nothing on Stack Overflow. Epic fail.
Re: Windows Code Samples
#94Earlier 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.
> 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-W…
Yeah, I know there was classic Win32 environment on Windows 8 RT, just it wasn’t public.
However we’re talking about UWP apps here, Windows 8 is unrelated. And there’s no Win32 environment on Windows Mobile 10, or Windows 10 IoT Core.
Re: Windows Code Samples
#95Earlier quoted context omitted.
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 do…
There is going to be a Win32 subsystem on phones. That's the next thing Microsoft is trying. They already showed Windows 10 running on arm with Win32 apps running on it. The things I mentioned or not permissions. They are limitations. No UWP app is permitted to do them so they might as will not exist. However those things do exist and there must be a reason why. Maybe people have needed to use them before? I think so…
> going to be a Win32 subsystem on phones
Maybe, but currently there’s none.
> Maybe people have needed to use them before?
It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard.
Apparently, Microsoft prioritized user’s safety and battery life over needs of those few software vendors who heed the functionality for legitimate reasons.
Re: Windows Code Samples
#96Earlier quoted context omitted.
There is going to be a Win32 subsystem on phones. That's the next thing Microsoft is trying. They already showed Windows 10 running on arm with Win32 apps running on it. The things I mentioned or not permissions. They are limitations. No UWP app is permitted to do them so they might as will not exist. However those things do exist and there must be a reason why. Maybe people have needed to use them before? I think so…
> going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard. Apparently, Microsoft…
"Regress" would be more appropriate, it's taking away useful features. Gimping what an application is capable of should not be the solution to security.
Re: Windows Code Samples
#97Earlier quoted context omitted.
> going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard. Apparently, Microsoft…
"Regress" would be more appropriate, it's taking away useful features. Gimping what an application is capable of should not be the solution to security.
How are you going to secure user against key loggers when there’s a “useful feature” allowing any app to listen keyboard events of the whole windows station?
Keep in mind there’re another useful features, allowing users to run an unsigned application from any source, with administrator privileges.
Re: Windows Code Samples
#98Most 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...)
WDK != WDF source code. This release is ~200k LoC. WDK is just tools and code templates.
Re: Windows Code Samples
#99Earlier quoted context omitted.
For 90% of the usage of SIMD instructions where people just want to parallelize iterating on lists, yes, that's reasonable enough. Apple Accelerate isn't a SIMD API, it's a higher level API that happens to use SIMD for its utilities. Apple makes great APIs, yes, I can't deny that. You seem to have forgotten P/Invoke where your performance critical C++ code can actually be called from C#. You get your assembly and eve…
The beauty of NDK is not that it offers a ton of APIs (it does not), it's that it's not overcomplicated and lets you reasonably easily incorporate a lot of the same libs you're already using on Linux anyway, and build them pretty much exactly the same as any other Linux lib, with minimal, if any modifications using tried and true Linux toolchains. It took me much less time and effort to get my stuff going under NDK.…
From what I read you have some very specific needs and for various reasons also have decided to use tools/languages every one here advices against.
This is all fine, but your first post make it sounds like UWP in general is crap, which I don't agree with.