Windows Code Samples
microsoft.github.io
microsoft.github.io
Fittingly, issue #1 in the WSL bug tracker is requesting it to be open-sourced: https://github.com/Microsoft/BashOnWindows/issues/1
I think this is a masterstroke by Microsoft, since it will give Windows the best of both worlds. Something that only OS X had so far.
Of course, it's not for everyone. People might be morally opposed to proprietary software or want UNIX all the way down.
I like a Linux/GNU terminal, but I prefer windows GUI to X, I find all laptops I have owned work better under windows than linux, I prefer outlook to mutt/thunderbird, and many of my games only run on windows. (Obviously, other people's opinion can be different!)
[1] I can't bring myself to use the term 'Linux' here, because, ironically, Linux is the primary missing part in this Ubuntu distribution. It should really be called WSG or WSU.
If you install an X server, such as VcXsrv and set the DISPLAY variable (typically export DISPLAY=:0 will suffice), you can just run X11 apps. For instance, here's a screenshot of a Prolog/Tk application running on WSL:
https://danieldk.eu/Posts/2017-01-10-Alpino-Windows/alpino-w...
I have installed Windows on a workstation just to try WSL out and it's quite impressive. Many regular applications just work. I could build Ubuntu packages and upload them to my PPA (I just had to use fakeroot-tcp to replace fakeroot).
Of course, there are also things that don't work for obvious reasons. E.g. because they require facilities deep in the kernel (performance counters/perf) or because they require kernel modules and hardware access (running CUDA programs).
https://wpdev.uservoice.com/forums/266908-command-prompt-con...
Er, about that: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...
DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.
Edit: downvoting accurate information that was previously posted on HN? Really?
https://gist.github.com/jibsen/7ebeddde3bc2bfd421b96ae53a824...
The Flat UI of Windows is a mistake. Because of Flat UI, there is no differentiation between Web apps and native Windows apps, which makes it possible--and even desirable--to make desktop apps using Web technologies.
I think for UI and some web stuff Electron might really be superior. Especially if your team is already fluent with the web stack. But it has it's limits and if you reach them or have very specific requirements you might be better of with WPF or UWP apps and the initially higher effort of developing in C#/XAML might pay off.
Saying this I believe the existence of Electron is a great possibility for UI devs.
- Electron Apps haven't and won't ever 100% fit into the OS environment/theme, neither Windows, macOS, or any Linux desktop
- Electron takes a long time to start up
- Electron eats a big amount of memory
- Electron uses a lot more battrey
- Many APIs of the underlying OS are not avaiable to Electron, especially those not found on competing platforms
So, allow me to say this: If web technologies are more attractive to you (which is completely fine), stick to the web. But don't create Desktop programs that waste ressources and time just for the sake of having "a true cross platform app".
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 differences in resource usage between Win32 and .NET apps are noticeable.
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.
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 that code. I recall exclaiming WTF the first time I saw that.)
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.
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.
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.
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.
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.
Keep in mind there’re another useful features, allowing users to run an unsigned application from any source, with administrator privileges.
There are permissions for which apps can use my Mic, Camera, Contacts, Call history, etc... Microsoft could easily add one that lets me run UWP apps with a higher privilege that allows IPC with Win32 apps.
As it is right now, you can't even build a UWP app that can talk to a server app running on the same exact machine. Instead, you have to build all of your UWP apps so that they depend on some Internet server.
Look at the mobile apps.
Many apps require geolocation permission, not because they need it, but because they include some ads, and ad provider who made their ad serving control needs GPS coordinates to serve better ads.
The majority of users don’t care.
They just click “I agree” on those permission popups, so unlimited number of third-parties able to literally track their each step.
So, you're covered. What's your problem now?
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.
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.
Also, the battery thing is nonsense. An idle web app will use up just as much battery as an idle native app. It's the implementation and code architecture decisions that matter more for battery then the underlying APIs.
Lastly, making apps cross-cross-platform is worthwhile unless the point of the app is platform-specific (e.g. an app that tunes something in the OS). You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity.
How about when they're not idle? There's probably an order of magnitude if not more instructions being executed in Electron, which eventually reaches the same OS APIs a native app would call directly. JITs still have overhead.
You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity.
All you've done is moved the complexity to where you as a developer may not see it, but your users sure do.
Idle apps can still vary in how much battery life they consume. I've seen some background apps that don't appear to be using any CPU (i.e. "0%" utilization) but actually have high-frequency timers which will wake the CPU every time they fire. Waking the CPU is bad news because it kicks it out of the low-power C-states and thus eats more battery.
If you're on Windows try running 'powercfg /sleepstudy' and you might find some interesting power-hungry behavior from even "idle" apps:
https://blogs.windows.com/windowsexperience/2014/06/26/sleep...
On Linux, you can use 'powertop' for the same purpose, though I've found powertop is more useful since it shows more raw data and makes fewer assumptions.
[1]: https://developer.microsoft.com/en-us/windows/develop/winjs [2]: https://www.microsoft.com/developerblog/real-life-code/2016/... [3]: https://developer.microsoft.com/en-us/windows/bridges/hosted...
https://technet.microsoft.com/en-us/library/ee692768.aspx
Just tested their "get OS version" example on my Windows 10, works fine.
And now their store is full of crap and no one uses it.
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 app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs?
Because you don't want all your users running a harder to update embedded version of Chrome with multiple separate instances.
Because you realise that since the dawn of cross-platform UIs, non-native apps have always stuck out like a sore thumb once you got past the visuals.
As a developer I definitely see why being able to leverage web technology everywhere is attractive, and even as an businessperson I'd see it, but let's not kid ourselves. It's being intentionally selfish.
In theory you can balance that out by using your savings from going with something like Electron to improve other areas of the app, but something tells me in most cases that isn't the driving factor (after all, something like Qt can offer cross platform without the overhead of Electron, it's just Js+HTML5 is more convenient than C++ if you're only trying for easily marketable/hireable skills)
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 start your users will typically accept that. And as a developer you get to use awesome Web technologies, such as D3.js, that simply don't have an equivalent in native app development. In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.
It does, but the problem is Electron is the new hotness, so every chat client that could have been a 10MB native app is now coming out as a 100MB Electron app. Instead of looking at the problem being solved and choosing Electron, people work backwards and choose Electron because that's what looks good on a resume/is easy to hire for/is popular/etc., then try and fit their problems into it.
"simply don't have an equivalent in native app development"
Really? I mean I know D3.js is just an example, but between LiveCharts, OxPlot, MS Charts, and a decades worth of charting libs there's nothing like it? The thing is native has decades of legacy, which isn't always a bad thing as much as people tend to assume it is.
Electron apps are not doing things that are extraordinarily new, I'd be shocked to find that there are popular libraries for frontend web dev that don't have alternatives on native (not to mention native has WebViews that get updated outside of your own release cadence, and offer performance that's at least good enough to embed in places where you really can't find anything as good as the Js equivalent).
>In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.
I find that statement wonderfully ironic, I think with things like Electron, the Web just started getting to where native tech is. Web technologies "advance faster" in the sense that technology "churns faster". Look at what web apps were doing in 2006 and what web apps were doing in 2016 from a user's perspective. While from a web devs perspective React and co might have brought us forward (or sideways) lightyears, from a user perspective not that much changed. If WPF could do what that user needed in 2006, it can do what they need today, that's why there's so few "advancements".
Now we're getting stuff like WASM so we can essentially utilize native stacks on web tech, I don't know how easily I can call that "advanced tech" over native.
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.
(c++ .net is not real c++ anyway)
But I think even folks with much more modest needs suffer with UWP. For instance, try to load an image from your hard drive (using UWP C++), resize it with Lanczos and get access to its pixels. The API is a fucking nightmare, there's no way to resize an image that I could find (unless you want to show it in the UI, in which case all is taken care of for you, but you can't get pixels from there). On macOS/iOS, it's just a few lines of rather plain looking code.
Here's another constraint you may have failed to consider: my code doesn't just run on Windows. I compile the same C++ code across all supported platforms with fairly minimal #ifdefs to adjust to platforms and SIMD ISA. Windows is the only platform that fights me every step of the way. Linux is great. macOS is great. iOS and Android are great. Goddamned bare metal is great (cross-compiling on Linux). UWP is awful and hostile.
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.
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.
This is all fine, but your first post make it sounds like UWP in general is crap, which I don't agree with.
https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/x...
Instead of C++/Cx, you can use the new C++/WinRT, which uses standard C++ syntax and adds "await" to make async programming much easier.
tl;dr: not gonna happen
One can buy an oem or restricted region license for windows for 20$ but legally it's about the same as pirating it.
Edit: Every OEM would have their own spin, for differentiation. Lenovo too...
Nearly everything about Android the operating system. Android the app platform is deeply tied to Google Play Services, which is not open source and is once more deeply tied to Google's online services.
And they've re-routed apps' access to basic phone data like GPS, camera and microphone through Google Play Services, so that if you want to use any app that uses those services you also have to let Google log those data.
It's almost as bad as tivoization from the FOSS perspective, while also invading your privacy. Yay.
The question is how much third-party code there is in the NT kernel. There may even be remainders of the cooperation with IBM tainting the source code (Windows NT did have an OS/2 personality at some point).
I expect most of that stuff lives in the userland interfaces to the kernel, but at least Microsoft seems to consider those to still be kernel code.
I'd be amazed if they ever make it available under anything like a GPL or BSD style license.
People like to shit on Windows with claims that Linux does it better. Actually seeing the source and reading about the internals (anyone can do that last bit) let's you see in just how many places Linux was and still is playing catch up. Linux may have a better implementation for some use cases, but to claim architectural superiority is just crazy in my eyes.
Anyway, the license for the WRK is actually quite open. Seeing it doesn't prevent you from contributing to open source projects, you can share it with anyone in a university setting, can keep it on your personal devices, and can share snippets of source code in blog posts, papers and the like. If you are eligible, willing to comply with the license, and can find someone who still has it (the hardest of the requirements) it's fair game. In my efforts I asked Microsoft for permission as well, but I didn't get the sense that was necessary (but shouldn't hurt).
You can still build the WRK on modern Windows, or on the included Virtual PC Windows Server 2003 images. The output dll can be installed in place into compatible versions of Windows. The distribution includes a full OS course, the original internal design workbook (straight from Dave Cutler's hand, in the original .DOC!) and labs detailing how to modify/extend the most interesting part of the kernel.
Source: I'm working on a tool/resource to make OS dev more accessible to students at my university (as well as to myself) and made vigorous efforts to procure the Windows Kernel for comparative purposes.
Trusted partners that develop for windows and oems can also gain access.
This idea is probably more feasible than first glance would suggest, but still, I wouldn't hold your breath.
Cute...