4 ms·

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

vbezhenar 7y ago
'#!' 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 7y ago
  Security: those apps are sandboxed and also cleaner to de/install. Otherwise it’s mostly MS trying hard to make its store relevant.
sveiss 7y ago
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 7y ago
  > 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 7y ago
    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 7y ago
      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.

vbezhenar 7y ago

'#!' 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 7y ago
Security: those apps are sandboxed and also cleaner to de/install. Otherwise it’s mostly MS trying hard to make its store relevant.

sveiss 7y ago

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 7y ago
> 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 7y ago
  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 7y ago
    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.