5 ms·

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? O

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 7y ago
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=PLWZJrkeLOrbZ3CMHpbglE4NyJSEo-_qhr 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.
- badsectoracula 7y ago
  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 7y ago
    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.
int_19h 7y ago
This is to avoid having every app bundle the same runtime over and over again. Instead, the runtime is shipped as a separate package, and then apps written in languages that require that runtime depend on that package.
- badsectoracula 7y ago
  What you write sounds exactly what you'd get with JRE and Python which worked ever since the Win9x days. My questions are about the differences that make this necessary.
  - wvenable 7y ago
    Microsoft is moving to same security model as Android and iOS where individual applications request (and can be denied) permissions to do things. One example is triggering desktop notifications. If you get a notification you can see exactly which application sent it and then prevent that application from ever sending you another one. 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.
    - badsectoracula 7y ago
      That would easily be solved with an API call that says "Hey, i'm helloworld.py". It wouldn't solve the sandboxing stuff, but TBH i do not see that working for desktop applications (in that the sandboxing wont be mandatory for backwards compatibility - the main reason people keep using Windows - and most desktop applications wont bother restricting themselves). 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").
      - wvenable 7y ago
contextfree 7y ago
It's just needed if you want scripts for your runtime to be treated as separate apps by the OS. Otherwise, they'll all be treated as the same app, so any OS feature that depends on the OS understanding what's logically a separate app will be either unusable or at least sort of broken. Ranging from how they show up in task manager as you mentioned, to sandboxing and package uninstall as others mentioned, to share target, notification and background task support as the article mentions, to how they're grouped on the taskbar, etc. 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/installing-windows10-apps-web 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/identity-registration-and-activation-of-non-packaged-win32-apps/ 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 https://github.com/contextfree/winrt-rust - but idk about Free Pascal or D)

pjmlp 7y ago

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=PLWZJrkeLOrbZ3CMHpbglE4NyJSEo-_qhr 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.

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

int_19h 7y ago

This is to avoid having every app bundle the same runtime over and over again. Instead, the runtime is shipped as a separate package, and then apps written in languages that require that runtime depend on that package.

badsectoracula 7y ago
What you write sounds exactly what you'd get with JRE and Python which worked ever since the Win9x days. My questions are about the differences that make this necessary.
- wvenable 7y ago
  Microsoft is moving to same security model as Android and iOS where individual applications request (and can be denied) permissions to do things. One example is triggering desktop notifications. If you get a notification you can see exactly which application sent it and then prevent that application from ever sending you another one. 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.
  - badsectoracula 7y ago
    That would easily be solved with an API call that says "Hey, i'm helloworld.py". It wouldn't solve the sandboxing stuff, but TBH i do not see that working for desktop applications (in that the sandboxing wont be mandatory for backwards compatibility - the main reason people keep using Windows - and most desktop applications wont bother restricting themselves). 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").
    - wvenable 7y ago

contextfree 7y ago

It's just needed if you want scripts for your runtime to be treated as separate apps by the OS. Otherwise, they'll all be treated as the same app, so any OS feature that depends on the OS understanding what's logically a separate app will be either unusable or at least sort of broken. Ranging from how they show up in task manager as you mentioned, to sandboxing and package uninstall as others mentioned, to share target, notification and background task support as the article mentions, to how they're grouped on the taskbar, etc. 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/installing-windows10-apps-web 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/identity-registration-and-activation-of-non-packaged-win32-apps/ 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 https://github.com/contextfree/winrt-rust - but idk about Free Pascal or D)