[HN Gopher] Windows 10 Hosted App Model
___________________________________________________________________
Windows 10 Hosted App Model
Author : ComputerGuru
Score : 64 points
Date : 2020-04-03 20:46 UTC (2 hours ago)
(HTM) web link (blogs.windows.com)
(TXT) w3m dump (blogs.windows.com)
| neves wrote:
| 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 wrote:
| 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.
| grawprog wrote:
| Maybe I'm getting this wrong, or over simplifying things here but
| my understanding is this means windows now has an overly
| complicated '#!'?
| sveiss wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| vbezhenar wrote:
| '#!' is implemented by associating file extension with some
| specific application. For example you can associate '.py' files
| with 'python.exe' and when you double-click on 'app.py', it'll
| be launched using python. So it definitely not this thing.
|
| I, personally, didn't understand what this article is about and
| why would I use this mechanism when simpler one exists and
| works for decades.
| tasogare wrote:
| Security: those apps are sandboxed and also cleaner to
| de/install. Otherwise it's mostly MS trying hard to make its
| store relevant.
| GoToRO wrote:
| 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 wrote:
| 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!
| CamperBob2 wrote:
| Yes, let's continue the trend of dragging the desktop PC down
| to the level of functionality available on a cell phone.
| We'll be so "secure" that we can't get anything done.
| badsectoracula wrote:
| 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 wrote:
| The app being able to snap the screen is different than the
| user.
| Ididntdothis wrote:
| The problem is that it's increasingly difficult to figure out
| how to start. Let's say you have a Store app after a while
| you realize that screenshots would be a good feature. You
| should be able to add this without having to rewrite the
| whole thing. That's why a lot of people stick to WPF because
| it's predictable and you don't have the risk that some Store
| rule will trip you up later.
| qzw wrote:
| 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?
| saagarjha wrote:
| How is this different from the browser?
| eightysixfour wrote:
| > Can a shared, system-wide Electron runtime be far behind?
|
| This is exactly what I was thinking about.
| catblast wrote:
| Maybe whoosh...but.. Congratulations you've invented a web
| browser.
| drannex wrote:
| This was a _major_ feature in IE9-11, that you could run
| basically a UI-less modifiable web application without
| noticing* that it 's running on an embedded browser.
|
| Electron is a similar ideal, but not on the OS level. They
| are just recreating the best aspects of IE for Chromium,
| and we will be better for it.
|
| * noticeable for that era
| basch wrote:
| Thats probably why they switched Edge to chromium. Instead of
| each electron app running its own copy of node and chrome,
| those components can be build into the os, which is much better
| for battery life.
|
| Even their flagship app, teams, is running its own copy at the
| moment.
| Systemic33 wrote:
| 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 wrote:
| Its a terrible app though
| Kye wrote:
| I can tell because it's as slow to load and as unresponsive
| as a typical web app.
| PhilippGille wrote:
| > Can a shared, system-wide Electron runtime be far behind?
|
| I remember some people on HN already predicting exactly this
| back when the announcement to base Edge on Chrome was made.
| dakna wrote:
| Given the efforts behind
| https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor I
| would say it is the WebAssembly based .NET runtime that counts
| in the long run.
| judah wrote:
| 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 wrote:
| Absolutely. With frontend logic powered by C#/.NET courtesy of
| Blazor.
| GordonS wrote:
| 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).
| ChuckMcM wrote:
| 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.
| eyegor wrote:
| 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?
| vxNsr wrote:
| Is this formalizing a way for any app to implement a scripting
| engine?
| erik_seaberg wrote:
| 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.
| badsectoracula wrote:
| 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?
| jacobush wrote:
| 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.
___________________________________________________________________
(page generated 2020-04-03 23:00 UTC)