Hacker News new | past | comments | ask | show | jobs | submit login

In my experience MSIX is the typical MS Windows project where it sounds really cool and looks well documented and supported until you actually try to use it. If you're on the beaten path, like a mobile app port for the windows store, it's probably fine. But if you're trying to do anything out of the ordinary you have to start doing Microsoft archaeology to figure out why something doesn't work.

For example certain build configurations would cause the runtime runtime to be somehow slightly different from the build runtime and it would trigger control flow integrity to immediately kill the app on startup which was very difficult to debug.

Also from documentation it looks like it's possible to install a background service and communicate with it over a named pipe from another application in the same package but in practice I don't think it's actually possible, even in a full trust app.

I think the goals of MSIX and the App SDK are good and I applaud them trying to make it flexible to support every kind of app, it just hasn't had the time or resources put in to be really worthwhile over just using NSIS at present.




Problems with CFI aren't related to the packaging mechanism though. Mismatches between DLLs have been an issue with Windows for a long time and the solution is usually to bundle the versions you need. Not sure about the background service thing, we haven't tried that.

I'd say that Windows in general is disappointingly buggy but it's been that way for a very long time, I remember having to work around bad Windows bugs in the 95 and XP days too. It just comes with the territory. We use MSIX as raw material and either work around bugs or reimplement features as necessary. The results seem to work fairly well. MSIX also has the advantage of being maintained and general purpose, which sounds basic, but a fair number of the competitors aren't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: