IT professionals have another wave of application compatibility concerns to deal with as a result of MSIX, a new...
Microsoft app packaging format.
Microsoft introduced MSIX in March with the goal of making it the standard app packaging format for Windows by combining aspects of other formats, such as Microsoft App-V and Appx. Potential problems with MSIX don't come from new apps or mainstream apps that are constantly updated, but from legacy line-of-business apps that hide in the shadowy recesses of an organization's network. These are often apps users work with to accomplish business-critical tasks, but they don't really have anyone looking after them.
In this Q&A, Mat Clothier, CEO, CTO and founder of Cloudhouse Technologies Ltd., a software company that helps organizations repackage legacy apps, discusses the app packaging format and Cloudhouse's MSIX Enterprise Edition, which is geared toward helping organizations take their apps to MSIX.
Which apps tend to run into compatibility problems with MSIX?
Mat Clothier: Typically, the most important apps for business are the ones that do things that are no longer desirable. One part is getting the app working.
The app might work in MSIX, but does it work in a way that's secure and manageable using the new best practices? Will it stay working? How vulnerable is it to changes in Windows that could break it in the future?
Where does Cloudhouse come in?
Clothier: We correct those legacy bad behaviors. A partnership with Microsoft allows us to really take the complexity that exists within applications and move those to MSIX. We can [move] from bad behaviors to best practices to put you in the best place to work with MSIX.
We describe it as the last packaging you ever need. If your application has a fundamental incompatibility with the functions MSIX delivers, then that's where we level up your app to convert the behavior that is not supported to a behavior that is supported.
How do Cloudhouse containers work?
Clothier: When the application is inside the Compatibility Container, which looks like an App-V or MSI package, we capture what the application consists of -- the OS and all its components, other third-party libraries and runtimes, and the external environment.
For example, when you package an app in XP [to move it to another OS], when it talks to the [new OS], it still sees the XP environment. As far as it's concerned, it's still living the dream on XP.
When you take our container and deploy that to the new world, the new world sees a shiny new application. It's about bridging the gap. We have a redirection engine that maps together the behavior of the app expected from its old [OS] with whatever the new [OS] expects from a new application and blends those together.
What other options are there to move to the MSIX app packaging format?
Clothier: Microsoft's MSIX packaging tooling allows you to convert MSI and App-V to MSIX, but within the confines of what MSIX is capable of executing itself. So if you have a brand new Windows 10-compatible application and it's well written, it's probably going to work fine with Microsoft's tooling. As you move backward across the spectrum of complexity and legacy, the app is more and more likely to do things that won't work.
[Other] packaging vendors [require] you to access the source code, so you're building a product and a new type of installer. They have some capability around conversion of existing apps like MSI to MSIX on a stream, but that relies on the underlying capability of what MSIX can do itself that Microsoft provides.
How can you ensure that the apps work no matter what changes Microsoft makes to Windows?
Clothier: If the Windows kernel can run the application, then we can make sure the app stays working. If the underlying Windows kernel does something to make the application stop working, we can't make that reappear. We operate within the user mode of Windows so we can take any user mode API that an application calls for and translate that to whatever it should call for.
For example, if you need an app to run as 64-bit, but it's written as 32-bit, that's outside our fundamental capability. If [Microsoft] decides that the way you're going to talk to the networking stack is going to change, then we can fix that as the middleware between your app and the operating system to keep pace with the changes that Microsoft has within their APIs.
What other trends are you seeing with Windows?
Clothier: The new [Windows] servicing model of updating twice a year is really stressing [IT]. It will force people's offerings to move to an as a service. Microsoft has some stuff around devices as a service and some innovative business models that are going to shake up how the industry works -- trying to figure out where hardware fits in, what the refresh cycle is for hardware, how you deploy those Windows updates, how you deploy your apps, test it, get user adoption, all those other things.