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.
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.
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:
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).
You can access your entire Windows filesystem freely from Linux, so that's not really an issue. Just keep your data in /mnt, or link it from there to other places.
I've been using it for a couple months now for web development. There are still some quirks and bugs but I haven't had to move to dual-boot. I'm on the edge of doing so (see aforementioned quirks and bugs), but I've been rather happy with it so far.
For many people I think it's still the wrong way around. It's not the first solution to running Linux applications on Windows. The first I saw involved X-Win32 and a Linux server in the basement. It's just that most of these solutions get it wrong. It's not that people want Windows, and a little Unix. People want Unix/Linux, and a little Windows.
I think there is a large group of people that needs or want to develop on Linux (POSIX API, open source tools). But have difficulty getting their hardware running on Linux, need applications that are not available on Linux (Microsoft Office, Adobe suite), or simply want to run games as well without dual booting.
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've been using this, and find it works well enough for me.
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!)
I don't have WSL available, but I would love some numbers for tasks like cloning a large repository with git and running cmake. These things tend to be slow on Windows due to fork, see for instance this comparison for Windows vs. Linux in a VM:
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 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.
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 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)
> 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 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.
>This can be an issue, but it depends on the type of app you are making.
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.
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.
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.
- 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".
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 differences in resource usage between Win32 and .NET apps are noticeable.
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.
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:
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.
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.
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.
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.
"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.
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.
Permission settings only work for the minority of people who’re into that information security thing.
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.
> 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.
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.
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.
An idle web app will use up just as much battery as an idle native app.
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:
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.
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 is definitely a part of "new MS" strategy. Look at things like Xamarin and the Objective-C compiler for visual studio (whatever they're calling it). They don't care if your app isn't Windows exclusive, they're just begging you to put it in the Windows Store.
We had to redo an inhouse Electron app in WPF because we came to the point where we had to do some stuff within windows, e.g. printing or create a heavily customized MSI file. Both is possible with Electron but with the native Windows solution it's easier to fine-tune behavior.
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.
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...
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.
There is a new XAML feature called x:Bind where the XAML compiler code-gens the data binding code instead of the framework doing it all at runtime. You can set breakpoints in the generated code.
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.
.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 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.
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.
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.
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...)
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.
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.
Android is open source, and still (nearly) everybody is locked into Google's version with licensing costs. Google open-sourced nearly everything, while managing to make their "apps" so entrenched that every customer expects them and even a lot of apps don't work without them.
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.
NO no no...
Alibaba has a clone that they claim their OS, YunOS, is not Android and even it is not written in java, but can run most of Android apps.The OS is written in some java like programming language and close sourced.
Actually it does mean free to redistribute, this is the essence of the BSD or even GPL licenses. And free to redistribute (for free) would be a huge loss for windows. Therefor, not happening.
If the license isn't extremely restrictive about what you can do with the source and your knowledge of it, it would be a huge boost for Wine and ReactOS. Since those two are the biggest threat to Windows on the Desktop, I don't think Microsoft would risk that.
If it's just the kernel and not the userland above it, I doubt it. Apple's open sourcing of XNU and Darwin was never an existential threat to Apple.
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).
Based on what researchers who had access to the Windows kernel are saying, Windows has a decent amount of edge cases and special conditions to maintain backwards compatability with old software. For example if some popular software from 2000 abused some implementation detail that has since changed, Windows will detect that specific program and simulate old behaviour for it.
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.
If you think of kernel32 & friends, that's not actually considered kernel code. That is the "kernel" of Win32, which is mostly a userspace thing. The word kernel is just used in an overloaded way.
Some institutes at some universities have access to the NT source code for academic purposes. (Google "Windows Research Kernel" -- supposedly some academic entities have more access).
This is true. The program allowing this was active a few years ago, so the Windows research kernel is stuck at NT 5.2 (just before Vista). That makes it a decade old, but it is still a great tool for understanding the unique things about the NT architecture. The downside is that Windows has improved dramatically in ten years, so the old source can be misleading if not taken with proper perspective.
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.
I wouldn't say Windows has "improved dramatically in ten years" --- perhaps "changed" would be the right word for me; given how popular XP was, I'd say WRK is still quite relevant.
That would be an interesting concept. NT is a powerful operating system, but without the Windows Subsystem, it would be useless except as a drop-in replacement on Windows installations.
This idea is probably more feasible than first glance would suggest, but still, I wouldn't hold your breath.
Fittingly, issue #1 in the WSL bug tracker is requesting it to be open-sourced: https://github.com/Microsoft/BashOnWindows/issues/1