There are a lot of issues with this article - Windows S is no more a 'new' OS than an environment running AppLocker is a new OS. The $49 'upgrade' from WinS to a 'full' Windows 10 is simply removing the restriction, it's the same OS through and through
UWP doesn't explicitly require XAML as part of the stack directx and win2d provide more direct access to graphics hardware
Edge is not a Native UWP application - whatever that means - it's possible to take existing applications and package them to run as a UWP applications, even ones that use COM and Win32. The rendering engine that Edge uses is actually part of the UWP stack - any HTML+JS UWP app uses EdgeHTML as the layout engine. The JavaScript engine, chakra, is a cross platform open source c/c++ library
What MS is doing with WinS is attempting to promote a walled garden and changing windows into a closed platform.
WinS is the first consumer facing foray to this approach. Somehow announcing this in the same breath as education makes it ok.
It might be a noble effort to try to sandbox windows apps, however there are some major detractors: 1) The MS store is a mess, it combines the worst parts of the android App Store and the walled approach of the iOS App Store. But nobody seems to be committed into cleaning it up. 2) not having a compelling mobile story makes existing devs look elsewhere - even Microsoft itself. 3) eliminating compatibility for a broad swath of applications is orthogonal to the approach that Windows has had for decades.
Windows S is the freemium strategy applied to Operating Systems
>Edge is not a Native UWP application - whatever that means
My assumption is that it is compiled with .NET Native[0]. That would explain why it is only available on Windows 10, as only Windows 10 supports .NET Native.
Edge is built into Windows at a lower level than UWP. It is UWP-like in the sense that it has the modern app UX on all Microsoft products, it uses the new APPX package format, it favors the new WinRT API, it uses the new AppContainer sandbox, etc. But Edge can also do things that UWP apps can't do, such as being bloody uninstallable, running executable files, and creating special AppContainers[1].
I should also mention that UWP and Win32 aren't mutually exclusive; UWP is an overarching framework that supports WinRT and a subset of Win32 (now called the Windows API).[2] Edge uses some of the Win32 API as well.
The article paints UWP as a modern programming environment, superior to Win32, that only 'lazy developers' would reject, when in reality it is a confusing mess of desktop and outdated mobile paradigms from 10 years ago when mobile devices had dramatically less RAM and were much less powerful then 'real computers'.
UWP is in many ways worse than Win32, it requires much more boilerplate code to get stuff done, and requires a proprietary dialect of C++ which is not quite compatible with standard C++ (good luck trying to compile most existing C/C++ code on UWP, it's even worse than the Objective-C situation on OSX/iOS).
The baffling fact that UWP manages to be even more complex and less pleasant to write code for then Win32 (which was also a pretty bad API to begin with), coupled with the suicidal closing-down of an once open platform is what really concerns me about the future of Windows. That's not how you win back the hearts and minds of developers.
The main thing limiting C++ code in UWP is sandbox, not the compiler.
C++/CX is a glue language between proper C++ and the rest of the OS - you can freely mix it with proper C++ (11, 14, etc) within the same binary. I successfully compiled many open source cross-platform libraries for UWP without any serious issues.
As for complexity and generally APIs, UWP is way better than old Windows APIs. It is fairly consistent, predictable, and modern.
I'm guessing you are really used to the old ways, but I don't really understand how can one prefer WndProc / manual message handling or message maps to clean approach of XAML; or think it was better.
UWP is worse than Win32API, right. It's still half finished (many things aren't possible) and it sits on top of Win32 subsystem.
Another API and framework the good 16 year old DotNet never replaced Win32 either. All process that ship with and runs by default in Windows XP/Vista/7 or Office 2003/2007/2010 are Win32 and non is DotNet based. (you can verify with ProcessExplorer)
5 days ago MS declared DotNet a legacy thing. ASP.net 2 will only be compatible with Dotnet.core 2 (which is incompatible to DotNet and Dotnet.core 1). You can read about the outcry there https://news.ycombinator.com/item?id=14297974
The only thing that keeps people in general as well as enterprise companies on Windows is Win32 compatibility and Office. MS is now just milking their products with little QA and hostile to end users privacy "the user and his data is the product".
MS really missed the chance in 1999 to refresh Win32API with an improved Win64API. Like they did before - remember Win16API. Win16API got refactored and improved overall while keeping almost code compatibility - only a few tweaks and a re-compile were necessary back in 1994/95, and Win32s layer got backported to Win3.11. But MS went full in with their failed DotNet vision in 1999 and abdomened Win32API ever since. And never upgraded the Win32API, in fact the 64bit Windows still have the same Win32API and MS completely missed the opportunity window that was open for them. So much stupid management decision, it hurts.
C++/CX is a dialect of C++ that has refcounted pointers (like COM). It is much better than the (also proprietary) extensions for COM to C++ MSVC had decades ago, and it is also much better IMO that managed C++ and C++/CLI. Of course, in a way it is still a hack. But I read that MS is also working on a way of doing managed components in modern C++ (i.e. 11/14/17). MS is doing a lot of great work in the area of modern C++ lately (surprisingly to me).
And UWP is yet another incompatible version of XAML/WPF/Silverlight/.... I don't like the castrated nature of it, it is incredible simple things are hard or impossible (like cross process drag and drop, which is not supported even in MS Office store apps. Or any kind of IPC, or networking with localhost). But things are getting better, as MS removes the worst pain points and developers learn to circumvent the missing parts.
One thing that seems great in UWP is it's async-first approach. I learned to appreciate that paradigm with Python/Twisted and JS.
So it's not all bad. If Microsoft had UWP 10 or 15 years ago (in their "Avalon" phase) it would have been great. Now, it's just "meh".
In an alternative reality were DotNet never happened and MS evolved Win32API with COM (so basically continue the strategy of 1989-1998 until the great break with DotNet happened), yes then a new "Win64API" with modern C++ would have been great. But the Web happened, DotNet original vision failed, their pivoted vision was declared as legacy 5 days ago too, and UWP failed with no one buying their Win10phone (0.02% global market share).
> it requires much more boilerplate code to get stuff done
Depends on the language. In C# it’s straightforward. In C++ yes it could be cumbersome. But that’s a language limitation, C++ lacks async-await so some boilerplate code is required to consume asynchronous APIs.
> good luck trying to compile most existing C/C++ code on UWP
Did that more than once. The largest problem is slightly different CRT, i.e. not all CRT functions are available.
For the language however, C++/CX is merely a syntactic sugar on top of regular C++ compiler that compile your stuff into native code. You can enable/disable “Consume Windows Runtime Extensions (/ZW)” for individual C++ source files inside a single project. The linker will happily link everything together.
Also, if you don’t like C++/CX you don’t even required to use it. You can compile your C/C++ code into a UWP DLL that’s not windows runtime components, but expose C-style API instead. You’ll be able to use that in UWP apps just fine.
Precisely. And the fact Bing is the only search engine allowed (on spurious safety grounds) and Chrome is barred tells you everything. This is destined to fail right? The main advantage of, say, a Chromebook is that it boots instantly and handles multiple users with no IT oversight
I've never been able to figure out what direction UWP apps were supposed to go. At one point it was C++, then it was .NET, then it was some dialect of JavaScript. The political tides ebb and flow, but Win32 abides.
The legacy Windows API itself is a confusing mess with outdated paradigms from when desktop PCs had dramatically less RAM and were much less powerful. Those that don't remember history are doomed to repeat it.
TL;DR: Microsoft has introduced a new version of Windows 10 called "Windows 10 S"[1]. The big differences are that you can only install apps from the Windows Store and you can't join an on-premise domain. This walled garden approach is designed to "enhance securrty" and kill off Win32 with the convenient side-effect of allowing Microsoft to block apps from competing vendors, so you'll use Edge and not Chrome.
I can't for the life of me see why I would ever want such a monstrosity on my desktop...perhaps certain help-desk and locked down corporate configurations could benefit slightly from a walled-off version of Windows, but much of this is already available using Group Policies and such, so I just don't get it.
Please don't tell me they are trying to androidize the desktop, because that could possible be the most hairbrained idea MS has ever had, esp. this late in the game.
I really hope this will change. I am testing elm now and I think this kind of approach is the future. But it saddens me that we had "proper functional languages" for nearly 60 years and it took all this time to realize their benefit.
The web is a Frankenstein of HTML/CSS/JavaScript that is yet to match the productivity we already had in the 90's with Delphi, VB and 4GL tools.
Even now, there isn't any Web tool that allows for designing Web UIs like Microsoft Blend (XAML) or Qt Creator (QML).
The Web could have been like that if XHTML and its related standards were adopted, then we could have had something like XUL or XAML.
Instead we have the broken promise of Web Components that still aren't properly supported across all major browsers, or the "UI framework of the day" without any kind of tooling support besides code.
Same here. After the mess with WPF, WinRT, Silverlight, HTML5/JS and now UWP I am done with windows desktop. We just ported one big WPF app to web and will continue to do so.
That line really bothers me. I'm writing a new application in WPF (thus using Win32) and am avoiding UWP because of the fact that I want (actually need to) support older platforms. As I'm writing this software to make money and it is B2B, I can't afford to ignore Windows 7 as many businesses are still running it and many more still target it.
I'm currently learning UWP as well but why would I bet my product on a technology that limits me to a single operating system version?
I am, I'm currently learning Elixir/Phoenix and Elm and am doing WebApi work at work. Most of the problems that I want to solve on a hobby/solo project, though, lend itself more to desktop software.
Cool. I have done WPF for a while and it just feels very stale. Nothing new coming, MS changing direction very 2 years. I would put everything possible on the web now. It's a much more interesting environment. And if you really need desktop for some reason, I would probably go Qt/C++ now. Or straight Win32.
My product depends on WIX, which in turn depends on .NET, so there was no reason not to go with .NET (I started with WinForms but then converted to WPF). Web can be interesting but I just have a harder time coming up with ideas for products than I do with desktop.
Missed that one, as was under the impression that UWP and Win32 was strictly separated.
I do notice that this results in the Win32 program for all intents and purposes becoming a UWP app. Complete with the issues of installs only happening via the store...
The argument doesn't seem that cogent. The strategy described is what they already tried to do with the Surface RT, a failure which the article briefly mentions and moves on.
Nonetheless, there's a truth here about UWP. Applications today are all HTML websites. They should be containerized native applications, navigated spontaneously like the web, but running native code protected by the privilege declarations system familiar to phone apps. In fact, the "web of apps" is long overdue, but it's been held back by two major players: Apple, whose Appstore discouraged inter-connected-ness by encouraging a micropayment model, while also promoting platform exclusivity; and Google, who pumps billions of dollars into browsers and other web tech propping up the antiquated HTML-based web.
A new system is overdue. UWP is not that system though, it's a straight-up copycat of Apple's app store ecosystem, nothing more.
Perhaps I misunderstood your point, but taking it literally: this claim is just plainly untrue, and reflects a very narrow-minded view of software in general.
Windows S is still Windows, but with more restriction. I don't see how giving up control over the apps is more secure. It just means you have to trust Microsoft instead of some other org making the app. With the Windows 10 privacy issues, the last thing I want to do is give up control.
They are dead. It would be basically store-within-store, except that it cannot grant permissions to run, because only the primary one can do that. Primary store will do that only for their cut, making the secondary useless.
This is exactly what Valve saw when they started their Linux push.
They haven't really been betting on Linux at all for about two years. All major development efforts, at least consumer facing ones, have pretty much stopped. SteamOS now is as bad as it was when the Steam Machines released, which are still awful. Feral and Aspyr are pretty much the only two games in town nowadays producing consistent and good Linux ports of AAA titles. And they are just that, though - ports. Neither company has the developer manpower or budget for their ports to make good native OpenGL games. Likewise, the other major source of Linux titles is Unity, whom also haven't invested much in making a well optimized OpenGL rendering engine compared to their DX one.
The end result is that games run poorly on Linux and give a terrible experience to anyone trying it, because nobody wants to invest in native titles that are as optimized as the Windows ones... besides Valve. Pretty much every Valve game runs as good or better on Linux than on Windows, but they were the exception able to throw what is in all likelihood more money than they have made from Linux users in their first year on the platform to port these titles correctly.
Top it off with how bad the uptake on Vulkan has been relative to DX12, and the future is not bright for Linux gaming. It is way better than it ever was, and for anyone except a hardcore gamer the library is definitely vast enough to not feel any desire to use Windows over Linux for the sole reason of gaming, but its in such a shoddy state it won't win over hearts or minds any time soon.
I imagine we'll just continue to ignore that UWP and the Windows Store exist. Wake me up when full versions of Office and Visual Studio are built as UWP apps.
Difference is Chromebooks are fairly open hardware wise. Almost every model uses a Coreboot you can use alternative payloads on, so you can naively boot Linux, or run it under Crouton is a nearly no overhead environment. Some Chromebooks are bad eggs that never provide unlocks to their firmware, but most do.
Apple and Microsoft would never be that respectful of its users. The whole point of how draconian iOS and Windows RT 2.0 (aka 10 S) are is to strip user freedom to make more money.
Me too. Wake me up when Office and Visual Studio are built as DotNet UWP apps. Their codebase is still C with classes and C++ mixed, dating back to 1989/90.
Is there a list of apps that are missing from the Windows Store that cause friction for Windows S? I see it often called a chicken and egg problem. But I never see anyone suggest a list of what they think the eggs are.
(I don't think the problem is missing apps. My guess is that most UWP apps in the Windows Store use a tablet-ey, metro, modern ui, and nobody seems to like it much.)
I have a two-in-one laptop/tablet (from Lenovo's Yoga series), and while I have really tried to use the Store apps so that they are comfortable in the tablet mode, I've yet to find a PDF reader that doesn't crash randomly (including Adobe Reader's Microsoft Store port) and have basically no decent epub reader (I can't find a single app in the store that will open two epub files without any weird formatting issues, let alone support things like highlighting and such). There are no clients to any Google products. Your cloud option is basically OneDrive and that's it. Heck, I've even struggled to find a text editor, so in the end, I've just used OneNote to write down some texts. Kindle reader? Nope. Decent browser? Nope.
In fact, when I think about it, the only useful Store app I was able to find was the Slack client, which seems to me like UWP-bundled Electron app that simply works! Of course, not even that one comes with no issues, because font rendering in it is absolutely horrendous on a HiDPI screen.
I could go on and on about this. At the end, I'm mostly using desktop apps in the tablet mode (things like Calibre, Chrome browser etc.) and that seems to work fine. But the Store apps (with that one sole exception where I'm actually using a Store app in the desktop mode as well) are just useless.
and Microsoft knows that it is necessary for the company's software business and for the PC industry to evolve and stay healthy.
This the boring buisness-thinking take that misses the forest for the quarterly earnings report. Operating systems are largely... done-ish. We've entered a period of refinement and iteration that can't keep pace with the expectation to have something new to sell. I dissagree with the author that pushing forward full-steam is going to keep the industry "healthy."
Windows XP SP 2 is the last OS that I wanted to upgrade to. The rest has just been a drag along as enhancements are held back to be bundled with the breaking changes that do justify a revision bump, and a fresh coat of paint is used to sell the whole thing. OS X is similar, but less egregious.
We're in a period of kicking the can down the road. The UI keeps lurching randomly in fashionable directions but makes interaction inconsistent, obtuse or lackluster. Feature sets get locked down to enable new paywalls. Gamification is everywhere turning tools into ARPU-optimizing skinner boxes.
The End of low-hanging fruit is here. How we deal with it will determine if computing retains it's magical unbounded possibility space or not.
As a lazy windows dev, I have seen more things go to web applications than desktop apps. One of my current work projects would be great as a desktop app. The client/ server divide in this website has added no small amount of hours keeping track of object state between the client and server. A desktop app would have made things much simpler in that regard. I am a big fan of desktop apps and have made a career developing them in .Net, but adding more hoops to jump through is not the answer in this regard.
Microsoft doesn't plan on replacing Windows with this, right? They are just going to use this on lower-cost machines by obsoleting win32 apps? If not, this seems like a really bad move.
Not really true. They built a new OS-level api called winrt. It includes a subset of win32. However, other parts of it are completely new and do not "call into win32" the way, say, .NET on Windows generally does.
Electron apps can be packaged up as UWP and submitted to the Windows Store (with the restriction that you can't currently target Xbox, HoloLens, or Windows Mobile via Electron)[0]
To the contrary, I think they're encouraging Electron apps. Electron apps can be packaged directly to Windows Store. Another case in point: Visual Studio Code.
UWP doesn't explicitly require XAML as part of the stack directx and win2d provide more direct access to graphics hardware
Edge is not a Native UWP application - whatever that means - it's possible to take existing applications and package them to run as a UWP applications, even ones that use COM and Win32. The rendering engine that Edge uses is actually part of the UWP stack - any HTML+JS UWP app uses EdgeHTML as the layout engine. The JavaScript engine, chakra, is a cross platform open source c/c++ library
What MS is doing with WinS is attempting to promote a walled garden and changing windows into a closed platform.
WinS is the first consumer facing foray to this approach. Somehow announcing this in the same breath as education makes it ok.
It might be a noble effort to try to sandbox windows apps, however there are some major detractors: 1) The MS store is a mess, it combines the worst parts of the android App Store and the walled approach of the iOS App Store. But nobody seems to be committed into cleaning it up. 2) not having a compelling mobile story makes existing devs look elsewhere - even Microsoft itself. 3) eliminating compatibility for a broad swath of applications is orthogonal to the approach that Windows has had for decades.
Windows S is the freemium strategy applied to Operating Systems