
How Windows Everywhere finally happened - nikbackm
http://arstechnica.com/information-technology/2016/05/onecore-to-rule-them-all-how-windows-everywhere-finally-happened/
======
dingo_bat
I don't like the Universal apps or whatever they're calling them this month.
They are limited, slow, crashy and buggy. They regularly just disappear after
a sleep and wake. I have been left questioning my sanity wondering if I closed
Messenger.

Also, they are clunky and slow. For example, switch to a desktop with a
universal app open and for the duration of the desktop slide animation, the
app window will be completely blank. And then suddenly all the content will
flash into sight after the slide ends.

The start menu itself is slow and will miss your first few keystrokes if you
try to start a search too quickly. The notification bar is sometimes laggy to
open, and so are the universal style notifications.

Sharing across universal apps sometimes works, other times it just opens the
target app and sits there. I dunno if this is an app problem or universal
platform problem.

I wonder if improving Windows Forms would have been a better strategy. Instead
now Forms is seen by many as a dead platform, and UWP is so limited/slow that
nobody is developing for it. When soundcloud is smoother/less buggy running on
Chrome than as a standalone UWP app, what is even the point of having a
software ecosystem, apart from a web browser?

~~~
mafuyu
As a side note, I fixed the Start menu searching issue by disabling the slide
animation for the menu: [http://lifehacker.com/disable-this-animation-to-make-
windows...](http://lifehacker.com/disable-this-animation-to-make-
windows-10s-start-menu-o-1734223008)

~~~
userbinator
That dialog appears to have remained with little change since XP. I always use
"adjust for best performance" (which clears all the boxes), then select only
"show windows contents while dragging". Everything instantly becomes so much
faster.

------
Maarten88
Operation successful, patient dead...

It's kind of tragic that much of this effort may never pay off: in the process
of merging platforms and restructuring API's (that started with Vista and is
still going) Microsoft lost the connection to many of its developers, who went
to build Web, iOS and Android apps. WPF, Silverlight, WinRT, XAML, UWP: there
were too many changes, rewrites and deprecations. Windows Phone, brilliant as
it is, did never reach mass adoption and all the effort that went into
unifying it with Windows has probably been wasted.

I think developers prefer a crappy but stable technologies with a proven
market over uncertain and fast-moving technologies. It takes many years for a
new platform to mature and settle down.

Microsoft really needs to stop introducing "upgrades" that require application
rewrites in Windows for the next 3-5 years, and focus on getting the Windows
Store going.

~~~
userbinator
As a long-time Win32 programmer (over a decade), I can safely say that the
vast majority of existing applications still remain (for the time being)
forward-compatible.

Here's some examples:

[https://www.youtube.com/watch?v=JOj-
bAZBhnE](https://www.youtube.com/watch?v=JOj-bAZBhnE)

[https://www.youtube.com/watch?v=mRfn4M5DXTE](https://www.youtube.com/watch?v=mRfn4M5DXTE)

[https://www.youtube.com/watch?v=wqFWuNmWbHk](https://www.youtube.com/watch?v=wqFWuNmWbHk)

The reasons people hold off on "upgrading" Windows versions is not mainly
because of compatibility, but other factors like unwanted UI changes and
removed features, and particularly with Windows 10, the increased data-
collection intrusiveness and "we own your machine" attitude:

[http://www.howtogeek.com/243581/windows-10-may-delete-
your-p...](http://www.howtogeek.com/243581/windows-10-may-delete-your-
programs-without-asking/)

~~~
piyush_soni
That's great! I didn't know about it. Would anyone happen to know how does it
compare with the applications on Linux? Are they similarly forward compatible?

~~~
copperx
Oh, in no way, shape, or form, unless the application was statically linked,
which is uncommon.

~~~
creshal
Closed source programs usually are, exactly for that reason. (Or at least ship
all libraries they link to, up to and including the libc.)

Go also makes it relatively easy to statically compile everything, one of the
reasons why it's gaining popularity.

Apart from those two it's highly uncommon: You're supposed to ship sources and
compile them on the target system.

To get a sort of forward compatibility you'd need to find compatible sources
for all involved userland, or ship them with your sources. The latter is
sometimes used in larger projects, to work around distributions having wildly
incompatible versions of whatever library you need (Samba, Firefox,
LibreOffice e.g.).

------
sandworm101
Windows FOR everywhere. No matter that Microsoft says, windows is still a
choice. We have all seen shops where windows is just taken for granted, but
every senior guy I know has some horror story about MS that makes them dream
of a world without.

A typical story:[http://www.zdnet.com/article/microsoft-no-longer-allows-
admi...](http://www.zdnet.com/article/microsoft-no-longer-allows-
administrators-to-block-windows-store-access-in-windows-10-pro/)

------
ebbv
> Microsoft promised developers that Windows would run anywhere. This summer,
> it finally will.

Bullshit. _Versions_ of Windows that are all labeled Windows 10 are running in
a lot of devices, and you can write applications that in theory can run on all
of them (though practically writing one application that runs well on all of
them may be somewhat harder if you want your application to be useful in any
way.)

But that is NOT the same as "Windwos runs everywhere." in a number of ways.

The first and most obvious way is that you can't just take your existing
Windows application and put it everywhere, which is what that phrase seems to
imply. Nor can you buy one of these devices and immediately have access to all
the library of millions of Windows applications that exist. No, if you're a
developer you have to write a new universal app and embrace the Windows 10 App
Store whether you want to or not.

And if you're buying a device, you better check twice that the software you
want is available for the platform you're buying lest you find out too late
your device has special requirements.

Secondly, we've had _a version_ of Windows running on lots of devices for a
long time. The only thing that's different now is the branding. They're
finally all branded "Windows 10" even though in many cases (like Phone and
X-Box One) the user and developer experiences are totally different. Is that
helpful? I don't really think so.

This article might as well have been written by Microsoft's PR department.
Totally not grounded in reality at all.

~~~
blackoil
Your comment has some merit, if we ignore the fact that now same kernel is
running across devices, with same subsystems and same applications, with
possibility to write one application that works on all. While it is difficult
to write UI to scale across screen size and input types, it is possible to
build responsive UIs and people are doing so.

~~~
bigger_cheese
>"with possibility to write one application that works on all"

I'm not sure this is such a good thing. Maybe I'm in the minority but my phone
and my desktop OS have vastly different use cases and I'd expect apps running
on each of them to be different.

I'm not interested in a converging UI. I want a user experience tailored to
the platform I'm running the app on.

I'd rather a solid desktop experience then having to put up with trade off's
the developers decided to make because they wanted a "one size fits all
experience".

I've seen it in the Linux world where toolkits/desktop environments tried to
chase the idea of converging UI's and we ended up with the worst of both
worlds - miserable to use apps on a phone/tablet and miserable Desktop Apps.

~~~
dragontamer
> I'm not sure this is such a good thing. Maybe I'm in the minority but my
> phone and my desktop OS have vastly different use cases and I'd expect apps
> running on each of them to be different.

But why should they be programmed different?

You can create XAML forms that are optimized for each platform. But why would
you want to rewrite your code to adapt to the different GUIs?

Won't it just be easier, as a developer, to create a singular platform with
two XAML (one for small screens, one for large screens) that share the same
codebase?

~~~
bad_user
Your assumptions hold for OS X and iOS even though they are not the same OS
and never claimed to be.

> _Won 't it just be easier, as a developer, to create a singular platform
> with two XAML (one for small screens, one for large screens) that share the
> same codebase?_

In theory yes, in practice changing the UI isn't the only problem. The problem
is that a phone is much more limited, both in hardware and in what it is
allowed to do.

Just as a simple example, on the desktop you can have storage that's shared
between apps (at least for now), hence if you want your app's settings to be
synchronized with Dropbox, you only need to detect Dropbox's folder and save
your stuff in it, whereas on a mobile, you need to integrate with Dropbox's
API. Plus on the desktop you usually have a lot of storage space, like my 5
year old desktop has 1 TB of storage, whereas my phones only have 32 GB and 64
GB respectively and these are high-end phones. So clearly storage is a
bottleneck on mobile phone, but not on desktops. Another simple example:
battery life. Mobile developers have to worry about battery life, the big and
forever bottleneck of mobile devices, whereas desktop developers have never
been concerned about it. For example I avoided to install Skype on my Android
for two years because it was sucking my battery dry in only 2-3 hours. And now
mobile Skype is so aggressive in cutting down on background chat that I cannot
rely on it to deliver chat messages on time. And you want to hear the worst
part? Moore's law doesn't apply well to batteries, so unless major
breakthroughs happen, this will only get worse ;-)

And if universal apps on the desktop are as limited as their phone
counterparts, that would turn out quite ironic for Microsoft to have turned
your powerful desktop into a dumb phone just to have the same experience
everywhere. Of course, them and others will try and turn this around as being
for the senile grandmas everywhere that are unable to use their laptops, but
many of us will have known the truth about that one.

~~~
pavlov
For a lot of people, "desktop" really means laptop these days.

Laptops are much closer to mobile than the traditional desktop PC you
describe. Limited storage and battery life are important considerations on a
MacBook just as on an iPad.

Also the Mac desktop software environment is more like iOS these days, if you
want to go through the Apple-sanctioned route of using the Mac App Store. For
example direct folder access is not possible, so the Mac desktop app in your
example would have to use the Dropbox API too.

~~~
bad_user
> _Limited storage and battery life are important considerations on a MacBook
> just as on an iPad._

No, I don't believe that's true.

Laptops are bigger, so they can afford bigger batteries. My Macbook Pro's
battery holds without problems for 4 to 6 hours of intense work, which is not
something I can say about my phone and I'm talking about working on and
compiling Scala code and few things are more intensive than that.

Also, most of the time, laptops are used while sitting on desks for actual
work. Oh, I know, you might pull your laptop at your coffeeshop to write an
email or write comments on HN, or you might need it for work during a flight,
which is cool, but overall laptops do get used pretty near an electrical
outlet.

But the biggest difference is one of expectations. Phones are still
communication devices which we rely on. If my laptop's battery goes out during
a flight, I don't care because I do not need my laptop to make phone calls or
to orient myself using maps or to call a cab or to open my travel documents or
whatever. Whereas I do really need my phone. So the Scala compiler running on
my laptop doesn't need to be battery efficient. But my phone needs to last for
12 hours while traveling, otherwise I'm fucked.

> _Mac desktop software environment is more like iOS these days, if you want
> to go through the Apple-sanctioned route of using the Mac App Store ... the
> Mac desktop app in your example would have to use the Dropbox API too_

Oh, I don't know about that and the reason is the Mac App Store is a wasteland
and I can't think of a single app I installed from it. Also, the Mac App Store
isn't the " _Apple sanctioned_ " way and they know it's a wasteland too, it's
not like they are blind.

No, the Apple sanctioned way is to sign your app. Signing apps needs an Apple
developer account, which is fairly costly for open-source devs, but at least I
can see the benefit to it. And as long as your app is signed, OS X gives you
no problem in letting it be installed.

------
Animats
All platforms now have enough hardware to run a bloated OS. Even the dinky
machines. Thus, we now have Windows and Linux everywhere, endlessly being
patched because some feature completely irrelevant to the application has a
problem.

------
wornohaulus
What are the substantial benefits of getting onboard the UWP rain ? Will the
platform code work faster.. will the deployment be faster ? what about the
knowledge devs have gathered for decades. will the new way of doing things
produce a more efficient and better running application ?

~~~
pjmlp
For long time Windows developers like myself, the underlying model of WinRT is
what the original .NET was supposed to be.

It was called Ext-OS and based on an improved COM API, called COM+ Runtime.

[https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-
net...](https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-
research-project-history-the-msr-white-paper-from-mid-1999/)

So with C++/CX and .NET Native built on top of WinRT, Microsoft has gone full
circle back to the original idea.

Personally I enjoy developing UWP (started right away with the old Windows 8
model), because it offers me a modern OO API to Windows, similar to the OS
APIs from Xerox PARC and ETHZ OSes.

Also, sadly Microsoft torpedoed the whole WP eco-system, but the tooling is so
much pleasant to use than Android's.

I also welcome the container model to put some control into the mess that is
installing Windows applications.

~~~
voltagex_
Do you use XAML? What do you think of it? I've never really been able to get
my head around it - although my professional projects are mostly ASP.NET MVC
and WebAPI so I've had no real pressing need to learn it.

Am I the only one who still likes Windows Forms?

~~~
pjmlp
It has the developer sanity that web development lacks with its Frankenstein
mixture of HTML, CSS, JavaScript to make <div/> behave like native widgets.

Have you ever tried to use any web design tool capable of matching Blend for
UI design?

XAML is what web could have become if XHTML and its sublanguages had been
adopted properly.

------
mmastrac
> Microsoft has still arguably achieved something that its competitors have
> not. Rumors that Google will somehow merge ChromeOS and Android have been
> circulating for some time, but it hasn't happened just yet

Uhhh.. ChromeOS and Android are both Linux. This is just as merged as running
a stripped down Windows kernel.

~~~
thebigshane
I think you might be underestimating just how aligned Windows 10 is across
these devices, certainly more than Android vs ChromeOS is. (Then again, from
what I hear, ChromeOS is starting to creep more toward Android... So maybe
that is changing). This is more than a shared stripped-down kernel.

~~~
creshal
Google is experimenting with an Android Runtime for Chrome:

[https://developer.chrome.com/apps/getstarted_arc](https://developer.chrome.com/apps/getstarted_arc)

Assuming this does take off, ChromeOS (and any desktop OS running Chrome) will
have direct app sharing.

------
novaRom
It's a little ironic that in the summer they have achieved Windows everywhere,
that it would coincide with my first summer of Windows nowhere.

~~~
zabador
I bet it has been a great summer so far too

~~~
xufi
All they needed for Windows back then reminds me of
[https://www.youtube.com/watch?v=Vhh_GeBPOhs](https://www.youtube.com/watch?v=Vhh_GeBPOhs)
I miss that guy

------
simonh
> Apple and Google will probably do something similar with their various
> operating systems, but Microsoft has managed it first.

I thought all of Apple's OS variants these days were based on the Darwin
kernel and variously intersecting sets of the same unix components and APIs.
Every now and then I see someone complaining that a new Apple device contains
'an entirely new OS' like Apple TV OS, but isn't that just a variant of iOS?
It seems to me it's precisely because Apple have been determinedly pursuing
this common core stragety ever since the first iPhone OS that they've been so
successful, compared to Microsoft's strategy at the time of having completely
different code bases across product categories.

~~~
andy9775
I'm only speculating, but I believe that Darwin is much more bare or stripped
down compared to universal Windows. I believe that the author was refering to
being able to run iOS apps on OSX and vice versa.

This IMO is not very smart. Each platform, mobile or desktop, has a different
purpose and requires different things. So to make a universal OSX or iOS it
means that either you make a significant amount of compromises which don't
benefit either platform and each suffers. Or you build everything into the
core and it ends up being a complete and buggy mess with a bloated install
size.

------
EdSharkey
The article doesn't discuss it, but I thought the Kin was the forerunner to a
lot UX of the Windows Phone 7. Was the Kin also a forerunner to the Windows RT
platform change, or was it just a re-skinned Windows CE?

~~~
Const-me
Zune HD was released before Kin, and I think that was the first WP7-like
touch-oriented UX.

Kin and WP7 all run CE. The platform for WP7 was Silverlight 3, designed long
before the RT.

------
smt88
There was an excellent segment on This American Life about a man who cured his
own severe allergies by giving himself hookworms:
[http://www.thisamericanlife.org/radio-
archives/episode/404/e...](http://www.thisamericanlife.org/radio-
archives/episode/404/enemy-camp-2010?act=3)

------
mwcampbell
I wonder why the Windows Phone team decided to remove USER and GDI. After all,
they ran fine on PCs in the 90s, so surely performance wouldn't be a problem
on smartphones.

~~~
DrPizza
Modern graphics hardware isn't optimized for drawing bitmapped lines. It's
optimized for drawing textured triangles. This means that it's not actually a
good fit for GDI any more. Given that Windows Phone was, as far as apps were
concerned, a clean slate, there was little reason to retain USER and GDI.

win32k.sys is also rife with security flaws, so scrapping it has arguably
reliability benefits too.

------
sidawson
First immediate thought: Can you get virus/malware scanners for XBox?

Otherwise, it seems an immediate easy target for a new botnet.

~~~
thebigshane
Windows has had a sufficient built-in virus/malware scanner for a while now.
But, I agree, it's now as easy of a target as other Windows 10 machines out
there.

~~~
cwyers
No, because desktop and server Windows 10 machines have to be compatible with
arbitrary older binaries that were written against the Win32 API. The Xbox One
version of Windows 10 can leave out the backwards compatible and more easily
targeted parts of Windows, and only support UWP apps, which are sandboxed and
thus are less exposed to various types of exploits.

------
bitmapbrother
I must have missed something because last time I checked it was still on the
desktop, a failed phone platform and a game console with an installed base of
less than 30 million. Meanwhile Android is everywhere from phones, tablets,
desktops, cars, TV's and numerous IoT devices.

~~~
sz4kerto
The article is about the state of the technical implementation, not the actual
market penetration.

------
TelAviv_1
We've been using the Windows 10 for RaspberryPi and love it. Don't think of
Win32 as your API--think of .NET and it all makes sense.

