
Windows 10 Hosted App Model - ComputerGuru
https://blogs.windows.com/windowsdeveloper/2020/03/19/hosted-app-model/
======
qzw
The most interesting part to me:

> We are working with the new Microsoft Edge browser to take advantage of the
> Hosted App Model for Progressive Web Apps (PWAs) – converting the web app
> manifest into an app manifest, package the additional web content into an
> MSIX package and register it. In this model, a PWA is its own independent
> app registered to the system even though it is being hosted by Edge.

Can a shared, system-wide Electron runtime be far behind?

~~~
Systemic33
I can recommend trying this out with the Spotify web app.

It is genuinely difficult to spot that it’s actually “just” a website.

When you lock windows while it’s playing it shows up with media details like
album art, play/pause etc.

It is additionally “registered” in the start menu, and correct icons and
windows taskbar behaviour is used, making it virtually indistinguishable from
a native app.

~~~
NikolaeVarius
Its a terrible app though

~~~
hizanberg
Compared to what? What’s the best Desktop media player?

~~~
7leafer
foobar2000 + media player classic HC

~~~
FpUser
exactly what I use as well

------
ChuckMcM
Looks like python becomes a first class citizen to Windows.

Sadly I was just complaining about how "apps" these days weren't apps
(especially on Linux) they were directed-acyclic-graphs of dependencies with
an execution conductor at the top. This can work fine except when two of these
things want a different version of a dependency n layers deep. This is
especially a problem when those dependencies are managed/maintained by
volunteer labor that may or may not see the wisdom of compatibility rules
across minor revisions.

I know that the alternative is having the OS controlling entity be a
gatekeeper over "blessed" and "not blessed" dependency layers, which bites
because they can never keep up. Still the pain of having things break so badly
that an entirely new meta-layer called "containers" was invented in part to
partition these 'App-DAGs' in a space where they don't conflict with others.
That doesn't feel like progress to me somehow.

~~~
nine_k
A Linux app as a DAG of dependecies, sometimes hard to reconcile? Welcome to
25+ years ago, when dynamic linking and .lib.so stuff became the norm on
Linux. That is, basically as long as Linux existed.

Monolithic static apps and stuff like Snap are relatively modern.

~~~
ChuckMcM
Yeah, I know, and I've certainly got blood on my hands here as I helped to
implement dynamic linking in SunOS 4.0.

That said, there is a qualitative difference between an app as DAG where said
DAG is restricted to only those nodes that are present on a given "release"
which describes the entire graph, and an App which is a DAG on a set of
subgraphs, each with their own notion of 'currency' and overlapping nodes with
other subgraphs.

------
badsectoracula
So, i'm not sure why this is needed... is it a workaround for some limitation
with MSIX? Is it only for windows store/UWP/whatever-it-is-called-nowadays
apps? Or it is usable by a regular Win32 desktop .exe (so, can i for example
use it via Lazarus/Free Pascal by loading some API from a DLL?) and if so in
what scenario?

From the description it sounds like this is for something like, e.g., some
Java application appearing as something else than javaw.exe in task manager.

Let's say i'm making some sort of scripting language (which sounds like what
is being described there) that is distributed from my web site as an installer
made with -e.g.- InnoSetup or NSIS that registers .mylang to be launched with
mylangparser.exe (or whatever)... how am i supposed to use this (especially if
the parser isn't written in C or C++ but in Free Pascal or D or Rust or any
other language that isn't C or C++ but still has the ability to call C calls
via DLLs) and for what reason? Or am i not supposed to use this?

~~~
pjmlp
In the future all Windows applications will be sandboxed, MSIX was the first
step merging UWP and Win32 worlds after the failed experiments with Project
Centipede, Android and Cocoa integration into Windows 8.x.

The upcoming Windows 10X, uses sandboxing for everything, including Win32.

[https://www.youtube.com/playlist?list=PLWZJrkeLOrbZ3CMHpbglE...](https://www.youtube.com/playlist?list=PLWZJrkeLOrbZ3CMHpbglE4NyJSEo-
_qhr)

This is intended for languages that require some kind of interpreter to run,
and to have OS integration out of the box as if they were "native" apps on
Windows.

~~~
badsectoracula
That doesn't really answer any question i made though. Is it something
specifically about Windows 10X and MSIX limitations? How would i use it? Etc
(i do not want to repeat my questions, i'd just copy/pasting them :-P).

~~~
contextfree
It's a fix for a limitation of the Windows app model, i.e. to the OS's
knowledge of which executables, processes, files, etc. logically belong to
which apps. MSIX is how you register an app with the OS so in that sense it's
about "MSIX limitations" but apps/runtimes not installed with MSIX still have
the same problem.

The OS knowing what's logically the same app vs. separate apps is a
prerequisite for 10X and sandboxed apps, but there are other features usable
by non-sandboxed apps that depend on it too.

------
GordonS
Hmm, others are pointing towards PWAs, but to me this looks more like a way to
"install" scripts (python, ruby, PHP, powershell etc).

I _guess_ this is trying to open the Windows Store to more devs, giving them
an option other than UWP - which is certainly a laudable notion. But I really
wish the article was clearer about what the end goal is.

This actually _sounds_ pretty cool... but I'm not sure _who_ it's aimed at;
scripts are typically for command line tools, not GUIs. And for those _au
fait_ with the command line, I'm not sure what the benefit is, beyond signing
the package (which, technically, could already be done if you packaged your
script in an MSI/MSIX installer).

~~~
pjmlp
Windows store is already more than UWP, nowadays Win32 is also part of the
store and after Windows 10X the models will be even more so.

------
judah
My big takeaway from this is that Progressive Web Apps (PWAs) will become more
like first-class apps on Windows.

Installing a PWA on Windows will make it show up as its own process in Task
Manager, listed in start menu and taskbar, listed as its own entry in
Add/Remove programs, etc.

This is made possible in part by this Hosted App Model.

~~~
ComputerGuru
Absolutely. With frontend logic powered by C#/.NET courtesy of Blazor.

~~~
mycall
Are you suggesting XAML/C# to WebAssembly/PWA to Desktop app?

Why not just XAML/C#/Desktop App?

~~~
tasogare
PWA are multiplatforms while C# still hasn't a first party multiplatform GUI
toolkit. Which is shame, because the dev experience in XAML+C# is really good,
and Silverlight out of Browser was exactly that.

~~~
moonchild
Avalonia?
([https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia))

~~~
tasogare
Avalonia is not first party (Microsoft). It’s also still in development and
not production ready.

------
GoToRO
Very nice but they should unify things a little on Windows. There are so many
types of apps and it's not clear when you should use which. For example,
Windows Store apps can not snapshot the screen...

~~~
georgyo
This sounds like a feature, at least as a user. Sandboxing that is fantastic.
I wonder if they also block the app from reaching into the copy/paste buffer.

If they successfully sandboxed to that level, that is basically mobile device
level of app severity. Fantastic!

~~~
badsectoracula
Unless you are a user who wants to snapshot the screen or copy/paste between
different applications :-P.

(though i guess you were sarcastic :-P)

~~~
BlueDingo
The app being able to snap the screen is different than the user.

~~~
badsectoracula
Sure, you can always pull out your camera and take a photo of your monitor,
but usually what you want is to use a program to grab a screenshot - so that
program is what needs to be able to take the screenshot in behalf of the user.

~~~
j0057
You don't need an app for taking a screenshot. Windows used to include the
Snipping Tool I think since Windows 8, and nowadays in Windows 10 it's just
functionality baked into the OS: press Shift+Win+S to access it.

~~~
badsectoracula
You do not _need_ an app for taking a screenshot, but apps can and often do
provide additional functionality than the OS - the OS cannot provide by itself
every single functionality you may need, its developers may not even think
about all cases or consider them important to implement them.

For example while the snipping tool (and printscreen and alt+printscreen, etc)
exist, there are tools like Greenshot and Snagit that provide functionality
like instant saves to files, better on-screen snipping, an embedded editor for
annotations, etc that can be very useful when you want to create many
screenshots fast.

Another thing is that some tools may not exactly do what the OS would do
(screenshots in this case) but use the mechanism for something similar but
different. For example ScreenToGif uses pretty much the same mechanisms for
taking screenshots to create short GIF animations from screen captures and
then provides a simple timeline editor to for editing the frames, adding
annotations, shapes, etc.

The OS simply has nothing like these and it is impossible for it to provide
every single functionality that could ever exist.

Note that this applies to other stuff too, not just screenshots.

------
grawprog
Maybe I'm getting this wrong, or over simplifying things here but my
understanding is this means windows now has an overly complicated '#!'?

~~~
sveiss
It's closer to a macOS bundle than a single script with '#!'. It's at a higher
level of abstraction than linking a single script file to an executable.

It would let you build, say, a Ruby interpreter which declares itself as a
host, and then package a Ruby application that makes use of the interpreter,
including its libraries, native code extensions, and all the related assets.

The Ruby application would behave like a native application, with its own
identity in the Start Menu/Task Manager and its own sandbox/entitlements. The
Ruby interpreter and the packaged applications would appear separately in the
uninstaller list in Settings, and presumably could be distributed via the
Microsoft Store walled garden.

The whole 'Windows app model' concept is about bringing something close to the
"one icon = one app" experience from mobile to Windows, instead of depending
on heuristics or uninstallers to figure out which set of files/processes are
part of a single "app" from the user's point of view. This is an extension to
that model.

~~~
zozbot234
> The Ruby application would behave like a native application, with its own
> identity in the Start Menu/Task Manager

You've always been able to achieve this by changing settings/properties on a
.LNK file - or a .PIF file for MS-DOS based applications, as far back as
Windows 3.x. (With the 'canonical' .LNK file for an app being precisely the
one that's linked in the user- or system-wide Start menu). This stuff has
worked just fine for the last 25+ years. Sandboxing is of course new, but MS-
DOS applications linked in .PIF files used the same strategy to define
sandbox-like properties, and .LNK properties could be extended for the same
purpose.

~~~
sveiss
A LNK/PIF doesn't give a coherent view of the whole "app" from the user's
point of view, though.

If you delete the LNK, you don't uninstall the app -- you just can't access it
easily any more. If you create a second shortcut to the app, then uninstall
the app, the second shortcut lingers but doesn't work.

If you install an app, it might put two or three shortcuts onto the start menu
-- lets say it's a video game, and it installs a shortcut for the game itself,
and another for a settings tool. (If it's an old game, it'll probably install
a shortcut for the uninstaller, too). Which of those shortcuts should the
start menu highlight as the newly installed app, to help the user discover it?

You can make the argument that an abstraction based on files, paths,
individual executables and command line arguments (which is what LNK/PIFs
support) is superior, and I think a lot of people on HN would agree -- but
it's not the abstraction that new computer users being trained on mobile
devices are internalizing.

~~~
ChrisSD
It should also be emphasized how game changing proper packing is in itself.
Historically Windows scripts, installers, applications, etc could liberally
spray the filesystem and registry with their content. Cleaning this up was
rarely easy as it relies on each script (or uninstaller, etc) to do the job
right.

Proper packing gives more control to the user in this regard. Changes to the
filesystem or registry will (by default) be contained. It's worthwhile to make
this type of packaging easier and better integrated.

~~~
zozbot234
> Historically Windows scripts, installers, applications, etc could liberally
> spray the filesystem and registry with their content.

They _could_ do this, but suggested standards have always existed, e.g.
system-wide files in a sub-directory of $PROGRAM_FILES, user-specific data in
$APPLICATION_DATA and the like. Then, in principle, a general uninstalling
procedure can figure out what it needs to delete. It's not clear what all the
extra complexity in these newer standards is adding.

~~~
ClumsyPilot
It was left up to application developer to implement, and each software house
could fuck it up.

Just think about computer games, I have one that saves savegame files in app
data, one that saves it to my documents, and an older one that saves them into
program files.

Now the 'container' is managed by the os, and the OS can actually tell me how
much space an app is taking, and update/delete it with all the residual files

------
jacobush
Neat! Now we can have the seamless .NET experience for other languages too!

.NET core, 4.x what is desktop only etc etc. It will be of course extra simple
when combined with pyenv, virtualenv and node.

Seriously though, I can see one possible benefit - whatever Microsoft pushes
as a version of the runtime, may be what developers expect and use.

Or maybe not, since you can depend on a "host" app you yourself publish
(right?) which is your preferred Python version or whatever.

------
SiDevesh
This sounds like (for now) the first step towards something like shared
runtime for electron apps, would greatly solve the perf issues associated with
electron. I built [https://github.com/SiDevesh/Quark-
Carlo](https://github.com/SiDevesh/Quark-Carlo) a while ago to convert web
apps to native apps using the installed chrome browser as a runtime, using the
carlo project by google, google killed it pretty soon though. This way apps
would only have to package their own node runtime (since a lot of electron
apps use native modules or modified version of nodejs) and use chromium from
the system. The above project by me does the same thing and the size and
memory requirement is greatly reduced, (apps come at average of 40mb as
compared to 120mb for electron apps).

------
eyegor
So as best I understand it, this has 1 niche advantage over typical
exe/msi/uwp. It makes it more straightforward to create a generic application,
which could then easily be "branded" by customers and then resold as their own
app. So in essence you become an oem app developer, and then affiliates make
apps based on your product. So instead of distributing a raw api, you can
distribute an app in a box. And then it also allows the affiliate app to
identify as your own for api calls, but I'm not sure when that is actually
useful.

I'm scratching my head trying to come up with a use case that doesn't feel so
contrived, can anyone think of one?

------
erik_seaberg
Huh, today I learned you can convert a UUID to decimal and prepend {joint-iso-
itu-t(2) uuid(25)} to get a really big OID.

~~~
dfox
Which is probably the dumbest approach to generating OIDs as getting your own
subtree is simple (and in many cases you already have your own subtree without
even realizing it).

------
wilt
Seems like another attempt at beating a dead horse to me. Ms need to give up
on the whole app store thing and start creating a decent desktop experience
again. If they decoupled the app virtualisation from the app store and made it
less locked down it would actually be useful.

~~~
contextfree
This isn't dependent on Store at all. App virtualization has been decoupled
from the store for some time now.

------
Meph504
This feels to me, like the next best vector to compromise users.

The horror of HTA aren't forgotten, I'm hoping they handle this better.

------
neves
Argh! I am reluctant to install any software in my Windows machine, be it a
Pdf reader or a camera driver, because all of them install "services" to auto
update their software. I have an old notebook that could be perfectly usable
but crawls to a halt due to all installed software. Now everything will have
their associate always running service.

~~~
freehunter
IMO that's mostly the fault of Windows not having a real package manager for
so long. There's no way for software to know that it needs an update unless it
runs a background service to constantly check. So either your users constantly
run outdated software (which is one of the reasons companies love offering
their product as SaaS) or the users have to check manually (which users won't
do). Some software checks when you run, but a lot of times I just need to open
Excel and get to work, so I'm going to click "Skip this version" and keep
going.

Honestly I don't see really any good way to handle it without _some_
background service. It's just nicer when the OS has a way to handle it built
in.

~~~
ksk
> There's no way for software to know that it needs an update unless it runs a
> background service to constantly check.

That is required only if you need to update the app when you are not using it.
Apps can check for updates when you run them and then let you decide when to
install the update/or skip it/etc.

Package manager would be good, but not possible on Windows given the amount of
commercial software. Companies are not going to seed control to the Microsoft
when they can potentially up-sell you via their b/g update services or do
other kinds of advertising. I doubt MS would want to play rough with their
partners either.

~~~
neves
Surely they can, but tell it to Adobe, Apple, Oracle (Java), Google (Chrome),
Razer,

~~~
ksk
Unfortunately, they already know this.

------
vxNsr
Is this formalizing a way for any app to implement a scripting engine?

------
animalnewbie
Please do something like this for Edge Linux too! (once it arrives)

------
bitwize
So, it's #! for Windows, except complicated because Windows.

~~~
stinos
Read sveiss' comments above for a good explanation of what it is/does.

