Windows 10 Hosted App Model
blogs.windows.com
blogs.windows.com
> 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?
This is exactly what I was thinking about.
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
Even their flagship app, teams, is running its own copy at the moment.
If it wasn’t obvious: I anal.
https://commons.wikimedia.org/wiki/File:%22Org_charts%22_com...
:)
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.
I remember some people on HN already predicting exactly this back when the announcement to base Edge on Chrome was made.
If I check the dozens of Chrome processes on my machine, the largest part of their working sets is private, which is evidence against significant memory sharing.
It seems reasonable to only run the security sensitive parts in a dedicated process per origin and run other tasks in a central process for all web pages.
From what I understand, Chrome's processes communicate a lot via message-passing. You probably don't need large amounts of shared memory for that.
The largest part being private doesn't mean saving 10-20mb per process is insignificant. With a few electron apps open I'm easily losing a few hundred megs to electron overhead and many machines don't have that much RAM, especially laptops.
Each electron app also needs its own copy of centralized services like the i/o process, where a single chrome instance can share that across all tabs. An OS-level PWA implementation could share it across all PWAs and electron apps too.
MS had a similar technology over a decade before Electron existed:
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.
Monolithic static apps and stuff like Snap are relatively modern.
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.
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?
The upcoming Windows 10X, uses sandboxing for everything, including Win32.
https://www.youtube.com/playlist?list=PLWZJrkeLOrbZ3CMHpbglE...
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.
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.
What you get with JRE and Python in the Win9x days is that the executable is "java.exe" or "python.exe" which isn't helpful when the actual application is what is being run by these programs. Granting a permission to python.exe is not what you intend when you're wanting a notification from helloworld.py.
The whole effort reminds me of W3C doubling down on XHTML despite everyone else ignoring it (and it isn't like XHTML wasn't nice on paper, but real world has other concerns beyond doing some things the theoretically "right way").
That's what this is! "Hey, I'm helloworld.py and I'm a Python application". Just an API call isn't going to work because every application is potentially hostile.
Windows 10X is sandboxing Win32 application through a virtualization layer.
Think of it more as a Windows version of apt-get.
The host needs to be registered as a Windows app, so it either needs to be distributed/installed as MSIX (either from your own website as explained in https://docs.microsoft.com/en-us/windows/msix/app-installer/... or from the Microsoft store) or if you can't/don't want to do that for whatever reason, there's another recently added feature called "sparse package registration" that basically lets you distribute/install in some other format and then at runtime, register a mini-MSIX that just points the OS at your already installed files: https://blogs.windows.com/windowsdeveloper/2019/10/29/identi... (this is a WinRT API so someone needs to have implemented bindings in your language for those, which exists for Rust - https://github.com/contextfree/winrt-rust - but idk about Free Pascal or D)
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).
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.
Why not just XAML/C#/Desktop App?
Also WinUI, is the only Windows UI toolkit that is actually being developed, instead of getting only bug fixes like the other ones.
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/platf...
https://github.com/xamarin/Xamarin.Forms/wiki/Platform-Suppo...
Just like with Qt, Flutter, wxWidgets, Gtk+, Swing and JavaFX, Forms is only ugly when one cannot bother having designers on the team.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
This is like the evolution after migrating to Chrome.
Also Google does the same with PWAs on Android and ChromeOS.
If they are signed and distributed via the store, you can access OS APIs from the browser directly.
https://developers.google.com/web/android/trusted-web-activi...
If they successfully sandboxed to that level, that is basically mobile device level of app severity. Fantastic!
(though i guess you were sarcastic :-P)
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.
And neither did the people who designed that phone.
That being said, your general point that there's so many ways to develop an app for Windows, and that not all of them support the same features, is definitely true. I think the general advice these days is that if you _can_ build your app as a UWP, do that. Otherwise, use the Win32 APIs as sparingly as possible, defaulting to the UWP APIs. Legacy apps are a bit trickier, and that's where Microsoft is investing in things like the Desktop Bridge (run Win32 apps in a UWP container) and XAML Islands (host UWP controls in a Win32 app).
[1] https://docs.microsoft.com/en-us/windows/uwp/audio-video-cam...
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.
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.
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.
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.
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.
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.
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
.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.
I'm scratching my head trying to come up with a use case that doesn't feel so contrived, can anyone think of one?
The horror of HTA aren't forgotten, I'm hoping they handle this better.
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.
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.