Microsoft has a long history of innovations which never really went anywhere, but with the new Hosted App Model on Windows 10 the company may just have hit it out of the ballpark.
Microsoft introduced the Hosted App Model in Windows 10 2004 ie. the Windows 10 May 2020 Update, and the technology already appears set to solve a wide variety of problems for both Microsoft and end-users.
In the Hosted App Model, an app can declare itself as a host for other applications, while allowing those applications to retain their identity as independent apps.
It does seem like a neat technology.
This is one of those things that you read and then wonder why it wasn’t always like this!
So I wonder where the historical precedent is, I bet this has all been done before somewhere somehow!
This is basically a more limited equivalent of Unix shebangs for an app-oriented environment. Unix has supported shebangs since the early 80s, and they allow running arbitrary scripts with arbitrary binaries as interpreters, rather than requiring both script and interpreter to be “apps”.
Nice comparison!
It is indeed more limited to developers, but at the same time much more meaningful for the user. So don’t think of this as something that you would do on your own system on adhoc basis but think of something that a developer/packager could arrange for all users
A conventional package manager could handle the packaging part quite easily. There’s no real need to integrate shebang-like functionality with an app-oriented model, because if the underlying OS has shebang support or something comparable there’s no difference between launching a binary and launching a script.
Actually, there’s really no need to have an app-oriented framework at all because it’s needlessly limiting. The components included in app-oriented frameworks (package management, security, application launching, etc.) should stay separate (with loose integrations where it makes sense) and not be part of a framework that requires all of them to be used together.
The difference, if I am understanding this correctly, with Unix you have the permissions from the binary while with this you can have different firewall rules for different scripts.
I normally assume permissions are based on the account that runs a binary, but especially related to firewall rules you make a great point.
I don’t know how many people/businesses are going to create different rules for different scripts but it seems like a great extra option to have
That’s only a limitation of traditional Unix permissions. In an OS that replaces the setuid/setgid bits with per-program permissions, there’s no reason why scripts should be handled any differently from binaries when it comes to permissions.
I vaguely recall OLE in Windows 3.11…
Repost from a few months ago…
https://www.osnews.com/story/131622/windows-10s-new-hosted-app-model/
So… they reinvented file associations, basically?
Yes.
Old file extensions: All .cmd files are executed by cmd.exe and you set permissions on what cmd.exe is allowed to do and see cmd.exe in the taskbar. Basically the host becomes what is important and the actual content is just an argument.
Future way: old_timesheet.lnk opens with Internet Explorer and youtube.lnk opens with Chrome. adminscripts\*.ps1 show in elevated powershell_ISE.exe while regularscripts\*.ps1 run immediately with powershell.exe. The taskbar will show “doing usefull task” instead of “running powershell”