Resultado de la imagen para msix

Microsoft hizo un anuncio masivo en el discurso del día del desarrollador de Windows con respecto al futuro del empaquetado e instalación de aplicaciones para Windows 10. Microsoft tiene una historia profunda con los instaladores de aplicaciones de Windows, y el anuncio reveló que finalmente han encontrado una manera de empaquetar los desarrolladores de software. Aplicaciones heredadas y modernas de Windows para la plataforma Windows 10 con un solo instalador.

La nueva especificación del paquete, denominada MSIX, proporciona un formato de empaquetado unificado para las aplicaciones Win32, Desktop Bridges y Universal Windows Platform (UWP). MSIX se creó desde cero para ofrecer una contenedorización completa para las aplicaciones de Windows 10. El formato utiliza el marco de la aplicación AppX y proporciona una ruta para implementar todas las aplicaciones de Windows 10 en la tienda de Windows.

Los contenedores son una capa intermedia que se ajusta entre un sistema operativo virtualizado y una aplicación donde el contenedor garantiza un aislamiento estricto entre la aplicación y el sistema operativo. Es importante no confundir la virtualización de aplicaciones con los contenedores de aplicaciones, donde el primero es principalmente una tecnología de redirección, mientras que el segundo mantiene la aplicación aislada del sistema operativo y otras aplicaciones.

Si bien el anuncio fue música para mis oídos, simpatizo con muchos de mis clientes que luchan por comprender las ventajas de MSIX para el desarrollo de aplicaciones modernas y por qué este es un nuevo capítulo en la historia de la administración moderna. En esta publicación, lo guiaré a través del historial de implementación de aplicaciones de Windows y explicaré por qué el formato MSIX tiene la posibilidad de unificar realmente cómo se empaquetan y se implementan las aplicaciones de Windows.

En el principio era desordenado

Resultado de la imagen para bebe pintandoUn desarrollador de software escribiría una aplicación para ejecutarse en Windows y luego compilaría esa aplicación, pero el instalador del software en sí era un paso separado que implicaba un esfuerzo de desarrollo separado. Esencialmente, era el extremo oeste de la instalación de software, y la mayoría de los proveedores de software tenían una visión limitada cuando se trataba de los requisitos de la aplicación. Todo lo que les importaba era algo que pudiera instalar su aplicación, y las mejores prácticas eran en su mayoría un arte negro que muchos ignoraban por ignorancia.

Las primeras generaciones de instaladores de aplicaciones tenían una lógica limitada y no estaban muy bien escritas, lo que resultó en aplicaciones mal instaladas. Los instaladores sobrescribirían ciegamente los archivos de sistema compartidos (por ejemplo, DLL) sin verificar las versiones de los archivos. El resultado neto fue que los instaladores de aplicaciones sobrescribían continuamente los archivos compartidos del sistema con versiones anteriores (es decir, la versión del archivo con el que estaban empaquetados) y causaban errores de ejecución con otras aplicaciones. Este problema se conoció como “DLL Hell” y se convirtió en parte integral de la instalación de aplicaciones en Windows en los primeros días.

La necesidad de instaladores más sofisticados impulsó el surgimiento del reenvasado de aplicaciones donde pudimos tomar instaladores suministrados por el proveedor y hacerlos implementables a través de nuevas tecnologías de administración como Systems Management Server (SMS).

El punto que se debe tener en cuenta es que hasta la llegada de los instaladores de scripts desplegables, se requería físicamente que un técnico o usuario instalara una aplicación en la máquina del usuario. Con los instaladores de secuencias de comandos, finalmente pudimos realizar una instalación silenciosa de la aplicación a través de SMS sin interacción humana.

Las herramientas de reenvasado se crearon para monitorear y registrar los cambios realizados en el sistema por los instaladores de software y generar un instalador automatizado para la implementación masiva. Quienes trabajaban en herramientas de reempaquetado esperaban que al monitorear los cambios en el sistema, pudieran eliminar el ciclo de DLL Hell introducido por el proceso de instalación. Tan inteligente como suena, la tecnología tenía deficiencias.

Por el lado positivo, las herramientas de reenvasado fueron buenas para capturar el estado de la configuración del sistema cuando se instalaron las aplicaciones. Desafortunadamente, dependiendo del enfoque de reenvasado que emplee un desarrollador (máquina limpia vs. imagen corporativa de Windows), la utilidad de captura solo hizo una mejor estimación basada en los cambios del sistema de los que estaba al tanto.

Aquellos de nosotros que fuimos adoptadores tempranos empezamos a empaquetar contra la compilación corporativa del sistema operativo. Muy rápidamente, comenzamos a notar que los cambios no triviales en la compilación corporativa (es decir, la eliminación de una aplicación) hacían que muchos de los instaladores de aplicaciones reenvasados ​​no pudieran compensar los archivos faltantes y las entradas de registro que existían.

La situación continuó empeorando porque las herramientas de reenvasado no pudieron capturar parte de la lógica de los instaladores de los proveedores. Por ejemplo, el mecanismo de captura no pudo registrar llamadas a API o acciones más avanzadas que copiar archivos o establecer valores de registro en el sistema.

El mayor desafío para quienes crean instaladores de software reempaquetados fue cómo identificar los cambios relevantes del sistema. La mayoría de las veces, tenían una experiencia limitada en el mundo real y tenían dificultades para discernir si lo que se capturaba era una parte necesaria de la instalación del software o si se trataba de un ruido de fondo del sistema operativo o de la actividad de otra aplicación.

Como sabemos ahora, cada parche, cada nueva versión de Windows y muchas aplicaciones de terceros cambiaron la máquina del usuario, a veces de manera sutil y a veces drástica. Con el tiempo, la complejidad de la instalación de aplicaciones en este entorno eclipsó las capacidades de los instaladores e inevitablemente condujo a la inestabilidad del sistema operativo, que se volvió tan ubicuo que se ganó el nombre de Winrot.

La evolución de los instaladores silenciosos condujo a avances que redujeron el tiempo de inactividad del usuario y la cantidad de esfuerzo necesario para implementar el software en entornos grandes, sin embargo, el riesgo de hacer daño permaneció. En consecuencia, los administradores de sistemas necesitaban un montón de experiencia y habilidad para asegurarse de que no crearan un desastre del entorno.

La introducción del instalador de Windows.

El siguiente gran impulso para mejorar las capacidades y el rendimiento del instalador provino del gran kahuna, Microsoft, que creó y lanzó el formato Windows Installer (MSI). El formato del paquete MSI no debe confundirse con una interrupción señalizada por mensaje. Una vez más, las convenciones de nomenclatura de Microsoft parecen involucrar una bola mágica 8.

En cualquier caso, el objetivo del formato MSI era desarrollar un marco estandarizado alrededor de la lógica del instalador de software que fuera más capaz de negociar los cambios que el instalador necesitaba hacer al sistema operativo. El formato fue utilizado por los desarrolladores de software y los reempaquetadores de aplicaciones; sin embargo, en lugar de una instalación basada en scripts, el autor (según su función) tenía que entender la base de datos relacional sobre la que se construyó MSI.

Una de las nuevas características introducidas por el formato MSI fue la capacidad de modificar un instalador sin tener que volver a empaquetarlo al implementar un archivo de transformación con él. Normalmente, los archivos de transformación se utilizaron para aplicar las configuraciones locales (por ejemplo, para deshabilitar la función de actualización automática de un producto de software).

Microsoft creía que el formato MSI sería más fácil de usar porque pensaron que una gama más amplia de partes interesadas podría analizar el paquete de instalación del software y comprender qué requería el instalador al inspeccionar la base de datos subyacente.

Si bien una base de datos relacional es ciertamente más estructurada que un archivo de script, en la práctica es más trabajo obtener la información que necesita porque necesita usar herramientas personalizadas para obtener la información que necesita, y es más difícil interpretar el resultado de La instalación, ya que la mayoría de los cambios debe ser negociada por el servicio Windows Installer que forma parte del sistema operativo.

No es sorprendente que se necesitaran herramientas más especializadas para desarrollar estos instaladores de MSI, por lo que Windows Installer implementó  acciones personalizadas .

Las acciones personalizadas permitieron a los desarrolladores de software y a los administradores de aplicaciones omitir la mayoría de las limitaciones impuestas por Windows Installer para que pudieran ejecutar scripts y EXE. Idealmente, las acciones personalizadas no eran necesarias, pero no todo lo que necesita una aplicación se puede instalar de forma nativa con el servicio Windows Installer. La desventaja de la flexibilidad para eludir las limitaciones del instalador permitía a las personas perezosas o sin educación romper con todo tipo de mejores prácticas cuando se trataba de la instalación de software.

El equipo detrás del formato MSI pensó que eliminaría gradualmente DLL Hell y Winrot y, por extensión, mejoraría significativamente la estabilidad tanto del sistema operativo como de las aplicaciones instaladas en la máquina del usuario.

What Microsoft didn’t take into account was the scope of developing an ecosystem of packaging tools around the MSI technology nor did they want to make tools for this new standard. They intended to rely on software vendors to build package creation tools for developers and repackaging tools for IT staff.

For a time, Windows Installer was the go-to solution for installing applications on Windows machines. As the industry evolved, the need to deal with the remnants of DLL Hell and WinROT lead to the rise of application virtualization.

Application Repackaging Goes Virtual!

In the context of application virtualization, applications are considered “virtual” when they aren’t installed through traditional methods, and they don’t have direct access to the file system or system registry. Instead, virtualized applications either access a synthetic file system and registry, or the virtualization layer redirects application data to alternate locations in the file system and registry.

Application virtualization usually has COM isolation and a virtual file system to prevent problems such as DLL Hell, but it works so well that you can often run several versions of the same application side by side with no issues.

For remote desktop session hosts, this was a huge deal because more complex environments could simplify by allowing more applications to co-exist on the same server. The virtual applications removed the groups or silos of servers that were built for specific application sets and also reduced the uncertainty of adding a new application to the environment.

Since remote desktop session hosts are shared machines, there was a focus on making sure that they were stable (i.e., as few errors as possible), but also had no performance quirks that the end user would notice.

Microsoft recognized the value that enterprises were getting out of application virtualization and decided to acquire SoftGrid in 2006 because it was the best application virtualization technology on the market. The technology had a large user base with quite a bit of documented knowledge to make applications work with the technology. Once Microsoft began to introduce some of their security standards to the product and updated many of the features, it was rebranded to Microsoft Application Virtualization or App-V.

It was obvious back then that application virtualization was a complex and difficult technology to work with for Microsoft’s engineers, and although it was painful to watch, Microsoft needed to part ways with some of the design choices that SoftGrid brought with it.

Despite starting with a solid foundation, App-V 5 was almost a complete rewrite of the product, which not surprisingly, introduced bugs and a steep learning curve that needed to be ironed out.

App-V 5 relies on native capabilities of the operating system to redirect file and registry data to other parts of the registry and file system, which eliminated the need for synthetic subsystems.

In the end, App-V 5 turned out to be a solid technology, and the application repackagers were able to handle the majority of use cases. Having said that, I’m still working with clients that encounter 5%-20% of their application inventory failing to run properly in virtualized environments, which means the search for the perfect installer is still far from over.

On the flip side, the methods, technologies, and best practices that software developers used to write their software needed to evolve to keep pace with the new hardware, operating systems (and versions), and devices that their customers were beginning to use at work and remotely.

 If You Control the Code You Control the World

Microsoft understood that the shortcomings of the Win32 application architecture meant that it could not evolve to meet the demands of modern computing or Microsoft’s vision for the future.

This need for modernization was especially true for applications using cloud architectures where the user’s computer may never reside on the corporate network. Office 365 took advantage of App-V by integrating it into its version of Office to run, which gave Microsoft a lot of experience in creating and maintaining a complex virtual application. Due to the volume of its customer base, Microsoft was beginning to revolutionize the way businesses approached application packaging and deployment. Add in the burgeoning ecosystem of devices that users instinctively began using in all sorts of locations, and software developers were suddenly faced with new requirements to adapt to their applications.

A new way of building and installing easy-to-use applications that could automatically adjust to a wide variety of device form factors was needed. Microsoft shortened the gap with the Universal Windows Platform (UWP) and a “store” concept for Windows application consumption that mimicked the way applications were installed on mobile devices.

They also needed applications that were more autonomous because Windows was already heading down the road of behaving more like Android or iOS, where applications are installed and removed easily and cleanly without affecting the health of the operating system.

The UWP application format is very strict, and there are no significant equivalents of the Win32 API. This fact poses a serious and costly problem for Win32 developers because they have to rewrite significant parts of their code base to take advantage of UWP and install their application through the Windows store.

In some cases, the features had to be removed because there was no way to implement the solution with the limited set of APIs in the new UWP framework.

Those lucky few who were able to turn to UWP noticed two key benefits:

    1. UWP applications do not need to be packaged, which effectively eliminates the workload necessary to prepare them for automated installation on the user’s machine.
    1. Self-initiated installation and customization of an application through Windows Store almost eliminates the need for an IT technician to intervene on behalf of the user, as the user already has experience with an application store when using their smartphone.
    1. The Windows store also offers significant cost savings to its customers, as Microsoft hosts the application deployment infrastructure needed to store applications in the cloud.
    1. This means that companies no longer need to maintain a separate software deployment infrastructure with on-premise servers.
  1. Windows devices can download the application directly from the Windows Cloud Store.
  2. The experience can be managed through Windows Store for Business, which allows organizations to monitor available applications and track their usage.

Some software vendors are legitimately annoyed with the Windows Store model because Microsoft’s 30/70 split in each sale is considerable for expensive applications – a considerable non-technical barrier to adoption.

If you prefer to deploy your applications manually or with standard electronic software distribution tools, that remains an option, as this technology is not exclusive to the Windows store.

While Windows Store for Consumers offers an appropriate experience, Windows Store for Business only includes a basic set of features to manage Windows Store applications, which is important because it still lacks business features such as role-based access.

Of course, if your organization cannot use the cloud for application delivery, there are ways to deliver UWP applications using more traditional software distribution technologies.

Given the high cost of entry, the industry was reluctant to migrate applications to UWP. As a result, Microsoft needed to lower the entry barrier for Win32 applications and began working on Desktop Bridges (codename Project Centennial) to support both Win32 and UWP applications.

Desktop Bridges loosened the knot in the UWP API (a step in the right direction), but required access to the source code for the application to work.

This meant that Desktop Bridges was only useful for application developers, as applications were rarely successful when repackaged using this technology. There were UWP repackaging tools, but they were aimed at developers who could modify the application to overcome problems.

As a result, the adoption of modern application formats came close to solving the problems inherited from Win32 applications. However, application compatibility and the fact that applications were not isolated enough were areas where UWP fell short.

In our opinion, Microsoft needed a way to introduce more legacy applications into the store to make the migration to modern application formats a success story and, more importantly, technologies such as S Mode for Windows 10, where only modern applications can run, created a more technical need to complete the modern view of the Windows desktop.

3d rendering of the letter X in brushed metal on a white isolated background.

Put An X On It

That brings us to Microsoft’s announcement of MSIX and the hope for a unified packaging format that enables everyone to run applications on Windows 10. You may be thinking that Microsoft just refactored their MSI package format and added an ‘X’ on it to sound hip and cool like Apple, but MSIX has nothing to do with the MSI format. Nor does it have anything to do with MSI-X, which is the PCI V3.0 compliant Message-signaled interrupt. Confused?

MSIX is genuinely different from previous attempts at software installation technologies because it is a container-by-design technology targeted for use with end-user applications. The second reason is that the technology is useful for both developers and repackagers alike. The industry is working towards less repackaging, however, migrating existing applications into a container technology is an enormous and important goal to achieve Microsoft’s 365 vision.

Windows 10 makes use of containers from applications to the operating system. Containers are a great way to quickly deliver isolated application environments to different systems. Microsoft also uses containers for a wide range of services, primarily within the new security architecture built on top of Hyper-V.

With traditional Windows applications, the application state isn’t easy to manage. Containers, on the other hand, are analogous to application virtualization where application state is maintained inside the container regardless of what machine you deliver the application to. In theory, containers are that isolated, but I expect there will be compromises to make traditional Windows application formats work with MSIX.

Based on what I’ve read, you can use MSIX to deliver Win32 applications via the Windows Store. I hope that is true because it will help improve the modern management story for Windows 10. The most notable detractor is the relationship between Windows 10 and Intune because Intune’s mobile device management capabilities do not have a great deal of support for legacy software installers. Ideally, the Windows Store will be used to deliver applications, but only modern application formats are allowed in the store.

Aside from traditional Win32 application consumers, I am curious to see if MSIX opens the door to get more applications onto other Windows devices such as Xbox and the augmented reality realm, which further helps the whole Windows Store story.

Where MSIX May Take Us

Creo que el enfoque tradicional para las aplicaciones ha sido un viaje “suficientemente bueno”, pero a medida que nos enfocamos en el escritorio moderno, debe haber una ruptura clara con el pasado y los instaladores de software tradicionales deben irse en favor de formatos modernos como MSIX para simplifique la implementación de software, aumente la seguridad y aísle las aplicaciones del sistema operativo.

{:}{:es}Resultado de la imagen para msix

Microsoft hizo un anuncio masivo en el discurso del día del desarrollador de Windows con respecto al futuro del empaquetado e instalación de aplicaciones para Windows 10. Microsoft tiene una historia profunda con los instaladores de aplicaciones de Windows, y el anuncio reveló que finalmente han encontrado una manera de empaquetar los desarrolladores de software. Aplicaciones heredadas y modernas de Windows para la plataforma Windows 10 con un solo instalador.

La nueva especificación del paquete, denominada MSIX, proporciona un formato de empaquetado unificado para las aplicaciones Win32, Desktop Bridges y Universal Windows Platform (UWP). MSIX se creó desde cero para ofrecer una contenedorización completa para las aplicaciones de Windows 10. El formato utiliza el marco de la aplicación AppX y proporciona una ruta para implementar todas las aplicaciones de Windows 10 en la tienda de Windows.

Los contenedores son una capa intermedia que se ajusta entre un sistema operativo virtualizado y una aplicación donde el contenedor garantiza un aislamiento estricto entre la aplicación y el sistema operativo. Es importante no confundir la virtualización de aplicaciones con los contenedores de aplicaciones, donde el primero es principalmente una tecnología de redirección, mientras que el segundo mantiene la aplicación aislada del sistema operativo y otras aplicaciones.

Si bien el anuncio fue música para mis oídos, simpatizo con muchos de mis clientes que luchan por comprender las ventajas de MSIX para el desarrollo de aplicaciones modernas y por qué este es un nuevo capítulo en la historia de la administración moderna. En esta publicación, lo guiaré a través del historial de implementación de aplicaciones de Windows y explicaré por qué el formato MSIX tiene la posibilidad de unificar realmente cómo se empaquetan y se implementan las aplicaciones de Windows.

En el principio era desordenado

Resultado de la imagen para bebe pintandoUn desarrollador de software escribiría una aplicación para ejecutarse en Windows y luego compilaría esa aplicación, pero el instalador del software en sí era un paso separado que implicaba un esfuerzo de desarrollo separado. Esencialmente, era el extremo oeste de la instalación de software, y la mayoría de los proveedores de software tenían una visión limitada cuando se trataba de los requisitos de la aplicación. Todo lo que les importaba era algo que pudiera instalar su aplicación, y las mejores prácticas eran en su mayoría un arte negro que muchos ignoraban por ignorancia.

Las primeras generaciones de instaladores de aplicaciones tenían una lógica limitada y no estaban muy bien escritas, lo que resultó en aplicaciones mal instaladas. Los instaladores sobrescribirían ciegamente los archivos de sistema compartidos (por ejemplo, DLL) sin verificar las versiones de los archivos. El resultado neto fue que los instaladores de aplicaciones sobrescribían continuamente los archivos compartidos del sistema con versiones anteriores (es decir, la versión del archivo con el que estaban empaquetados) y causaban errores de ejecución con otras aplicaciones. Este problema se conoció como «DLL Hell» y se convirtió en parte integral de la instalación de aplicaciones en Windows en los primeros días.

La necesidad de instaladores más sofisticados impulsó el surgimiento del reenvasado de aplicaciones donde pudimos tomar instaladores suministrados por el proveedor y hacerlos implementables a través de nuevas tecnologías de administración como Systems Management Server (SMS).

El punto que se debe tener en cuenta es que hasta la llegada de los instaladores de scripts desplegables, se requería físicamente que un técnico o usuario instalara una aplicación en la máquina del usuario. Con los instaladores de secuencias de comandos, finalmente pudimos realizar una instalación silenciosa de la aplicación a través de SMS sin interacción humana.

Las herramientas de reenvasado se crearon para monitorear y registrar los cambios realizados en el sistema por los instaladores de software y generar un instalador automatizado para la implementación masiva. Quienes trabajaban en herramientas de reempaquetado esperaban que al monitorear los cambios en el sistema, pudieran eliminar el ciclo de DLL Hell introducido por el proceso de instalación. Tan inteligente como suena, la tecnología tenía deficiencias.

Por el lado positivo, las herramientas de reenvasado fueron buenas para capturar el estado de la configuración del sistema cuando se instalaron las aplicaciones. Desafortunadamente, dependiendo del enfoque de reenvasado que emplee un desarrollador (máquina limpia vs. imagen corporativa de Windows), la utilidad de captura solo hizo una mejor estimación basada en los cambios del sistema de los que estaba al tanto.

Aquellos de nosotros que fuimos adoptadores tempranos empezamos a empaquetar contra la compilación corporativa del sistema operativo. Muy rápidamente, comenzamos a notar que los cambios no triviales en la compilación corporativa (es decir, la eliminación de una aplicación) hacían que muchos de los instaladores de aplicaciones reenvasados ​​no pudieran compensar los archivos faltantes y las entradas de registro que existían.

La situación continuó empeorando porque las herramientas de reenvasado no pudieron capturar parte de la lógica de los instaladores de los proveedores. Por ejemplo, el mecanismo de captura no pudo registrar llamadas a API o acciones más avanzadas que copiar archivos o establecer valores de registro en el sistema.

El mayor desafío para quienes crean instaladores de software reempaquetados fue cómo identificar los cambios relevantes del sistema. La mayoría de las veces, tenían una experiencia limitada en el mundo real y tenían dificultades para discernir si lo que se capturaba era una parte necesaria de la instalación del software o si se trataba de un ruido de fondo del sistema operativo o de la actividad de otra aplicación.

Como sabemos ahora, cada parche, cada nueva versión de Windows y muchas aplicaciones de terceros cambiaron la máquina del usuario, a veces de manera sutil y a veces drástica. Con el tiempo, la complejidad de la instalación de aplicaciones en este entorno eclipsó las capacidades de los instaladores e inevitablemente condujo a la inestabilidad del sistema operativo, que se volvió tan ubicuo que se ganó el nombre de Winrot.

La evolución de los instaladores silenciosos condujo a avances que redujeron el tiempo de inactividad del usuario y la cantidad de esfuerzo necesario para implementar el software en entornos grandes, sin embargo, el riesgo de hacer daño permaneció. En consecuencia, los administradores de sistemas necesitaban un montón de experiencia y habilidad para asegurarse de que no crearan un desastre del entorno.

La introducción del instalador de Windows.

El siguiente gran impulso para mejorar las capacidades y el rendimiento del instalador provino del gran kahuna, Microsoft, que creó y lanzó el formato Windows Installer (MSI). El formato del paquete MSI no debe confundirse con una interrupción señalizada por mensaje. Una vez más, las convenciones de nomenclatura de Microsoft parecen involucrar una bola mágica 8.

En cualquier caso, el objetivo del formato MSI era desarrollar un marco estandarizado alrededor de la lógica del instalador de software que fuera más capaz de negociar los cambios que el instalador necesitaba hacer al sistema operativo. El formato fue utilizado por los desarrolladores de software y los reempaquetadores de aplicaciones; sin embargo, en lugar de una instalación basada en scripts, el autor (según su función) tenía que entender la base de datos relacional sobre la que se construyó MSI.

Una de las nuevas características introducidas por el formato MSI fue la capacidad de modificar un instalador sin tener que volver a empaquetarlo al implementar un archivo de transformación con él. Normalmente, los archivos de transformación se utilizaron para aplicar las configuraciones locales (por ejemplo, para deshabilitar la función de actualización automática de un producto de software).

Microsoft creía que el formato MSI sería más fácil de usar porque pensaron que una gama más amplia de partes interesadas podría analizar el paquete de instalación del software y comprender qué requería el instalador al inspeccionar la base de datos subyacente.

Si bien una base de datos relacional es ciertamente más estructurada que un archivo de script, en la práctica es más trabajo obtener la información que necesita porque necesita usar herramientas personalizadas para obtener la información que necesita, y es más difícil interpretar el resultado de La instalación, ya que la mayoría de los cambios debe ser negociada por el servicio Windows Installer que forma parte del sistema operativo.

No es sorprendente que se necesitaran herramientas más especializadas para desarrollar estos instaladores de MSI, por lo que Windows Installer implementó  acciones personalizadas .

Las acciones personalizadas permitieron a los desarrolladores de software y a los administradores de aplicaciones omitir la mayoría de las limitaciones impuestas por Windows Installer para que pudieran ejecutar scripts y EXE. Idealmente, las acciones personalizadas no eran necesarias, pero no todo lo que necesita una aplicación se puede instalar de forma nativa con el servicio Windows Installer. La desventaja de la flexibilidad para eludir las limitaciones del instalador permitía a las personas perezosas o sin educación romper con todo tipo de mejores prácticas cuando se trataba de la instalación de software.

El equipo detrás del formato MSI pensó que eliminaría gradualmente DLL Hell y Winrot y, por extensión, mejoraría significativamente la estabilidad tanto del sistema operativo como de las aplicaciones instaladas en la máquina del usuario.

Lo que Microsoft no tuvo en cuenta fue el alcance del desarrollo de un ecosistema de herramientas de empaquetado en torno a la tecnología MSI, ni tampoco querían crear herramientas para este nuevo estándar. Tenían la intención de confiar en los proveedores de software para crear herramientas de creación de paquetes para desarrolladores y herramientas de reenvasado para el personal de TI.

Durante un tiempo, Windows Installer fue la solución de referencia para instalar aplicaciones en máquinas Windows. A medida que la industria evolucionó, la necesidad de lidiar con los remanentes de DLL Hell y WinROT condujo al aumento de la virtualización de aplicaciones.

La aplicación de reenvasado se vuelve virtual!

En el contexto de la virtualización de aplicaciones, las aplicaciones se consideran “virtuales” cuando no se instalan a través de métodos tradicionales, y no tienen acceso directo al sistema de archivos o al registro del sistema. En su lugar, las aplicaciones virtualizadas acceden a un sistema de archivos y registro sintéticos, o la capa de virtualización redirige los datos de la aplicación a ubicaciones alternativas en el sistema de archivos y el registro.

La virtualización de aplicaciones generalmente tiene  aislamiento COM  y un sistema de archivos virtual para prevenir problemas como DLL Hell, pero funciona tan bien que a menudo puede ejecutar varias versiones de la misma aplicación en paralelo sin problemas.

Para los hosts de sesión de escritorio remoto, esto fue un gran problema porque los entornos más complejos podrían simplificarse al permitir que coexistan más aplicaciones en el mismo servidor. Las aplicaciones virtuales eliminaron los grupos o silos de servidores que se crearon para conjuntos de aplicaciones específicos y también redujeron la incertidumbre de agregar una nueva aplicación al entorno.

Dado que los hosts de las sesiones de escritorio remotas son máquinas compartidas, hubo un enfoque en asegurarse de que fueran estables (es decir, con la menor cantidad de errores posible), pero que tampoco tuvieran peculiaridades de rendimiento que el usuario final notaría.

Microsoft reconoció el valor que las empresas estaban obteniendo de la virtualización de aplicaciones y decidió adquirir SoftGrid en 2006 porque era la mejor tecnología de virtualización de aplicaciones en el mercado. La tecnología tenía una gran base de usuarios con bastante conocimiento documentado para hacer que las aplicaciones funcionen con la tecnología. Una vez que Microsoft comenzó a introducir algunos de sus estándares de seguridad en el producto y actualizó muchas de las funciones, se le cambió el nombre a Microsoft Application Virtualization o App-V.

Era obvio en ese momento que la virtualización de aplicaciones era una tecnología compleja y difícil con la cual trabajar para los ingenieros de Microsoft, y aunque era una tarea dolorosa, Microsoft necesitaba deshacerse de algunas de las opciones de diseño que SoftGrid trajo consigo.

A pesar de comenzar con una base sólida, App-V 5 fue casi una reescritura completa del producto, lo que no es sorprendente, introdujo errores y una curva de aprendizaje empinada que necesitaba ser resuelta.

App-V 5 se basa en las capacidades nativas del sistema operativo para redirigir los archivos y los datos del registro a otras partes del registro y el sistema de archivos, lo que eliminó la necesidad de subsistemas sintéticos.

Al final, la App-V 5 resultó ser una tecnología sólida y los reenvasadores de aplicaciones pudieron manejar la mayoría de los casos de uso. Dicho esto, sigo trabajando con clientes que no pueden ejecutar correctamente el 5% -20% de su inventario de aplicaciones en entornos virtualizados, lo que significa que la búsqueda del instalador perfecto aún está lejos de terminar.

Por otro lado, los métodos, tecnologías y mejores prácticas que los desarrolladores de software usaron para escribir su software tenían que evolucionar para seguir el ritmo del nuevo hardware, sistemas operativos (y versiones) y dispositivos que sus clientes comenzaban a usar en el trabajo. y de forma remota.

 Si controlas el código controlas el mundo

Microsoft entendió que las deficiencias de la arquitectura de la aplicación Win32 significaban que no podía evolucionar para satisfacer las demandas de la computación moderna o la visión de Microsoft para el futuro.

Esta necesidad de modernización fue especialmente cierta para las aplicaciones que utilizan arquitecturas en la nube donde la computadora del usuario nunca puede residir en la red corporativa. Office 365 aprovechó App-V al integrarlo en su versión de Office para ejecutar, lo que le dio a Microsoft mucha experiencia en la creación y el mantenimiento de una aplicación virtual compleja. Debido al volumen de su base de clientes, Microsoft estaba empezando a revolucionar la forma en que las empresas abordaban el empaquetado y la implementación de aplicaciones. Agregue el creciente ecosistema de dispositivos que los usuarios comenzaron a usar instintivamente en todo tipo de ubicaciones, y los desarrolladores de software se enfrentaron repentinamente con nuevos requisitos para adaptarse a sus aplicaciones.

Se necesitaba una nueva forma de crear e instalar aplicaciones fáciles de usar que pudieran ajustarse automáticamente a una amplia variedad de factores de forma de dispositivos. Microsoft acortó la brecha con la plataforma universal de Windows (UWP) y un concepto de “tienda” para el consumo de aplicaciones de Windows que imitaba la forma en que se instalaron las aplicaciones en dispositivos móviles.

También necesitaban aplicaciones que fueran más autónomas porque Windows ya estaba avanzando en el camino de comportarse más como Android o iOS, donde las aplicaciones se instalan y eliminan de manera fácil y limpia sin afectar la salud del sistema operativo.

El formato de la aplicación UWP es muy estricto, y no hay equivalentes significativos de la API de Win32. Este hecho plantea un problema serio y costoso para los desarrolladores de Win32 porque tienen que volver a escribir partes significativas de su base de código para aprovechar el UWP e instalar su aplicación a través de la tienda de Windows.

En algunos casos, las funciones debían eliminarse porque no había manera de implementar la solución con el conjunto limitado de API en el nuevo marco UWP.

Los pocos afortunados que pudieron recurrir a UWP notaron dos beneficios clave:

    1. Las aplicaciones UWP no necesitan estar empaquetadas, lo que elimina de manera efectiva la carga de trabajo necesaria para prepararlas para la instalación automatizada en la máquina del usuario.
    1. La instalación y personalización auto iniciada de una aplicación a través de la Tienda Windows casi elimina la necesidad de que un técnico de TI intervenga en nombre del usuario, ya que el usuario ya tiene experiencia con una tienda de aplicaciones cuando usa su teléfono inteligente.
    1. La tienda de Windows también ofrece ahorros significativos en costos a sus clientes, ya que Microsoft aloja la infraestructura de implementación de aplicaciones necesaria para almacenar aplicaciones en la nube.
    1. Esto significa que las empresas ya no necesitan mantener una infraestructura de implementación de software separada con servidores locales.
  1. Los dispositivos de Windows pueden descargar la aplicación directamente desde Windows Cloud Store.
  2. La experiencia se puede administrar a través de Windows Store for Business, que permite a las organizaciones monitorear las aplicaciones disponibles y hacer un seguimiento de su uso.

Algunos proveedores de software están legítimamente enojados con el modelo de la Tienda Windows porque la división 30/70 de Microsoft en cada venta es considerable para aplicaciones costosas, una barrera considerable no técnica para la adopción.

Si prefiere implementar sus aplicaciones manualmente o con herramientas estándar de distribución de software electrónico, esa opción sigue siendo válida, ya que esta tecnología no es exclusiva de la tienda de Windows.

Si bien Windows Store para consumidores ofrece una experiencia adecuada, Windows Store para empresas solo incluye un conjunto básico de funciones para administrar las aplicaciones de la Tienda Windows, lo cual es importante porque aún carece de características empresariales, como el acceso basado en roles.

Por supuesto, si su organización no puede usar la nube para la entrega de aplicaciones, hay formas de entregar aplicaciones UWP utilizando tecnologías de distribución de software más tradicionales.

Dado el alto costo de entrada, la industria se mostró renuente a migrar aplicaciones a UWP. Como resultado, Microsoft necesitó reducir la barrera de entrada para las aplicaciones Win32 y comenzó a trabajar en Desktop Bridges (nombre en clave Project Centennial) para admitir las aplicaciones Win32 y UWP.

Desktop Bridges aflojó el nudo en la API de UWP (un paso en la dirección correcta), pero requería acceso al código fuente para que la aplicación funcione.

Esto significaba que Desktop Bridges solo era útil para los desarrolladores de aplicaciones, ya que las aplicaciones rara vez eran exitosas cuando se reenvasaban con esta tecnología. Había herramientas de reempaquetado de UWP, pero estaban dirigidas a desarrolladores que podían modificar la aplicación para superar los problemas.

Como resultado, la adopción de formatos de aplicación modernos estuvo cerca de resolver los problemas heredados de las aplicaciones Win32. Sin embargo, la compatibilidad de las aplicaciones y el hecho de que las aplicaciones no estaban lo suficientemente aisladas eran áreas en las que UWP se quedó corto.

En nuestra opinión, Microsoft necesitaba una forma de introducir más aplicaciones heredadas en la tienda para hacer de la migración a formatos de aplicaciones modernos una historia de éxito y, lo que es más importante, tecnologías como S Mode para Windows 10, donde solo se pueden ejecutar aplicaciones modernas, creó un Necesidad más técnica para completar la vista moderna del escritorio de Windows.

Representación 3d de la letra X en metal cepillado en un fondo aislado blanco.

Poner una x en ella

That brings us to Microsoft’s announcement of MSIX and the hope for a unified packaging format that enables everyone to run applications on Windows 10. You may be thinking that Microsoft just refactored their MSI package format and added an ‘X’ on it to sound hip and cool like Apple, but MSIX has nothing to do with the MSI format. Nor does it have anything to do with MSI-X, which is the PCI V3.0 compliant Message-signaled interrupt. Confused?

MSIX es realmente diferente de los intentos anteriores en tecnologías de instalación de software porque es una tecnología de contenedor por diseño diseñada para el uso con aplicaciones de usuario final. La segunda razón es que la tecnología es útil tanto para los desarrolladores como para los reenvasadores. La industria está trabajando para conseguir menos reempaquetado, sin embargo, migrar las aplicaciones existentes a una tecnología de contenedor es un objetivo enorme e importante para lograr la visión 365 de Microsoft.

Windows 10 hace uso de contenedores desde aplicaciones al sistema operativo. Los contenedores son una excelente manera de entregar rápidamente entornos de aplicación aislados a diferentes sistemas. Microsoft también utiliza contenedores para una amplia gama de servicios, principalmente dentro de la nueva arquitectura de seguridad construida sobre Hyper-V.

Con las aplicaciones tradicionales de Windows, el estado de la aplicación no es fácil de administrar. Los contenedores, por otro lado, son análogos a la virtualización de aplicaciones donde el estado de la aplicación se mantiene dentro del contenedor, independientemente de la máquina a la que entregue la aplicación. En teoría, los contenedores están tan aislados, pero espero que haya compromisos para hacer que los formatos tradicionales de aplicaciones de Windows funcionen con MSIX.

Según lo que he leído, puede usar MSIX para entregar aplicaciones Win32 a través de la Tienda Windows. Espero que eso sea cierto porque ayudará a mejorar la historia moderna de administración para Windows 10. El detractor más notable es la relación entre Windows 10 e Intune porque las capacidades de administración de dispositivos móviles de Intune no tienen una gran cantidad de soporte para los instaladores de software heredados. Idealmente, la Tienda Windows se usará para entregar aplicaciones, pero solo se permiten formatos de aplicación modernos en la tienda.

Aparte de los consumidores de aplicaciones Win32 tradicionales, tengo curiosidad por ver si MSIX abre la puerta para obtener más aplicaciones en otros dispositivos de Windows, como Xbox y el reino de realidad aumentada, que ayuda aún más a toda la historia de la Tienda Windows.

Donde MSIX nos puede llevar

Creo que el enfoque tradicional para las aplicaciones ha sido un viaje «suficientemente bueno», pero a medida que nos enfocamos en el escritorio moderno, debe haber una ruptura clara con el pasado y los instaladores de software tradicionales deben irse en favor de formatos modernos como MSIX para simplifique la implementación de software, aumente la seguridad y aísle las aplicaciones del sistema operativo.{:}