
Windows Code Samples - aburan28
https://microsoft.github.io/windows/
======
kirillkh
Too bad the WSL (Windows Subsystem for Linux) is not open source. It is
already an impressive piece of software, but many features are still lacking
(e.g., neither Valgrind nor gperftools work right now), and it could benefit
greatly from community involvement.

Fittingly, issue #1 in the WSL bug tracker is requesting it to be open-
sourced:
[https://github.com/Microsoft/BashOnWindows/issues/1](https://github.com/Microsoft/BashOnWindows/issues/1)

~~~
20161112
For development, is WSL good enough to replace dual-boot?

~~~
kirillkh
Depends on your use case/tools/habits. WSL gives you the advantage of being
able to access the same files with native Windows tools and from the GNU[1]
command line. If you plan on using the X GUI tools, it will be much less
useful to you.

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

~~~
danieldk
_If you plan on using the Linux GUI tools, it will be much less useful to
you._

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...](https://danieldk.eu/Posts/2017-01-10-Alpino-
Windows/alpino-windows.png)

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

~~~
20161112
So if I want to use my GPU for machine learning applications, I would have to
run my programs under Windows rather than from inside the WSL?

~~~
danieldk
Indeed. There is a 'uservoice' about this issue:

[https://wpdev.uservoice.com/forums/266908-command-prompt-
con...](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-
on-ubuntu-on-windo/suggestions/16108045-opencl-cuda-gpu-support)

------
interlocutor
Here's the problem: As a developer Electron (see
[http://electron.atom.io/](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](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 skills will be portable too.

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.

~~~
Longhanks
\- Electron is big dependency, adding hundreds of MB to our app

\- 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".

~~~
riskable
I was with you until you mentioned how long to takes to start an electron
app... It's nearly instantaneous for me. Actually, nearly _all_ apps open
instantaneously for me but maybe it's because I'm running a Linux Desktop with
an SSD?

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.

~~~
userbinator
_An idle web app will use up just as much battery as an idle native app._

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.

------
general_ai
Having actually used UWP SDK for C++ fairly recently, I was left with the
impression that it's a complete non-starter for most folks. It assumes too
much skill on the part of the developer (i.e. "everything is asynchronous"),
it uses a significantly extended superset of C++, and it inexplicably comes
with _no_ libraries for such basic things as image processing, signal
processing, linear algebra, etc -- stuff that Apple knocks out of the park.
It's just basically WPF and very little else. Enough perhaps to write business
apps, but way inadequate for anything outside this narrow niche. And because
everything is async, and UI uses opaque data binding, the debugging experience
tends to be a bit of a nightmare. I'm not sure what Microsoft was thinking,
but Apple's approach to async (concurrent and serial queues in GCD) is an
order of magnitude easier to understand, use, and debug, and OS X and iOS SDKs
come with a ton more high quality features.

~~~
bostand
I have no idea what your problems are, but I code UWP in C# which is the
preferred language and its all fine and dandy here.

(c++ .net is not real c++ anyway)

~~~
general_ai
C# maybe. But C# is not suitable for what I do (fast deep learning on video,
images, and audio). Any kind of managed language is hostile to those kinds of
things and just plain not designed for them. I want to drop down to SIMD
intrinsics and assembly when I need perf, and C# won't let me do so.

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.

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

~~~
general_ai
Really, you call this "reasonable SIMD" access:
[https://msdn.microsoft.com/en-
us/library/system.numerics(v=v...](https://msdn.microsoft.com/en-
us/library/system.numerics\(v=vs.111\).aspx)? For comparison get a load of
Apple Accelerate:
[https://developer.apple.com/reference/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 that's not enough, you
get real, actual assembly, not some "IL assembly" where you have no control
over what it will emit when converted to machine 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.

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

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

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

~~~
general_ai
If it's not crap, how come there are so few decent apps in the Windows App
Store?

------
erikbye
Most interesting thing MS has released the code for recently is perhaps the
KMDF and UMDF.

[https://github.com/Microsoft/Windows-Driver-
Frameworks](https://github.com/Microsoft/Windows-Driver-Frameworks)

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

~~~
erikbye
WDK != WDF source code. This release is ~200k LoC. WDK is just tools and code
templates.

------
bobsgame
I really hope they open source the NT kernel, or at least part of it. This
makes me really excited about the future of Windows!

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

~~~
patrickaljord
They still make money on every single pc/laptop that ships with windows which
is still their biggest money maker with office. If they truely open source
windows (BSD or else) it will be free to ship for OEM and Microsoft will lose
one of their biggest source of income.

tl;dr: not gonna happen

~~~
keevie
Open source doesn't mean free....

~~~
kowdermeister
Be realistic, the next day 10 forks would appear distributing it for free.

~~~
dogma1138
Windows is always pirated distributed for free doesn't mean they don't violate
copyright laws and other restrictions.

One can buy an oem or restricted region license for windows for 20$ but
legally it's about the same as pirating it.

------
richev
From the footer on that page: "Windows maintained by Microsoft".

Cute...

------
p2t2p
I think we can call it 'click bait'

~~~
tetrep
Yeah I think "Windows Application Samples" or "Windows API Samples" would be
more accurate.

------
AJRF
For one brief second, I really thought...

