frameworks - termino - ¿Por qué no podemos crear programas multiplataforma en estos días?
multiplataforma sinonimos (9)
¿Por qué es tan difícil pasar la aplicación Windows .NET a una aplicación Mac?
.NET se entiende como un marco para que los programadores creen programas para Windows . la implementación completa de .NET (como lo hizo MS) solo está disponible para Windows. Parece que no hay mucha esperanza, que esto cambie.
Para un mejor soporte de plataforma cruzada, es posible que desee echar un vistazo a otros idiomas, como Java 1 :
Las aplicaciones Java normalmente se compilan en bytecode que se puede ejecutar en cualquier máquina virtual Java (JVM)
... que es muy similar a lo que hace python 2 :
CPython compila el programa Python en bytecode intermedio, que luego ejecuta la máquina virtual.
y aunque .NET hace lo mismo 3 :
También es parte de .NET Framework, este entorno de tiempo de ejecución se conoce como Common Language Runtime (CLR). El CLR proporciona la apariencia de una máquina virtual de aplicación
el problema es que la "máquina virtual", tal como está definida y construida por MS, simplemente está disponible solo en Windows:
.NET en su forma completa solo está disponible en plataformas Windows
Me pregunto, si todos los compiladores en cualquier idioma transforman el código en el único idioma "hablado" en las agallas de la computadora (Código máquina - ceros y unos), ¿por qué es tan difícil pasar la aplicación .NET Windows a una aplicación Mac?
¿No debería venir alguien con una idea brillante (no tengo ideas brillantes desde que me casé hace 3 años) y tener un ... No sé ... un marco de código máquina así que, en lugar de convertir el compilador a código máquina, se convertiría a ese marco, que se instalará en cualquier plataforma (SuSE, fsb, Ubuntu, AIX, SCO, OS X, Windows 9x, Vista, 7, etc., etc.).
Me pregunto por qué no podemos hacer las cosas así de fácil, en estos días ...
¿Alguna idea?
Bueno, puedes hacerlo con Silverlight. En cuanto a si Silverlight sale del navegador y entra en las aplicaciones nativas, esa es una decisión política de Microsoft, en lugar de un problema técnico. Los chicos de Mono también han trabajado en conseguir .NET para crear binarios de iPhone, por lo que sin duda va a tener más plataforma cruzada en el futuro.
Adobe Air, Java y otras cosas similares también hacen aplicaciones de cliente multiplataforma: diablos, incluso puedes hacer cross-platform en C ++ si realmente quieres :-)
Como ya se ha mencionado, es posible (especialmente los lenguajes basados en JVM y Python), y muchas personas crean aplicaciones multiplataforma. Lo que me sorprende es la cantidad de personas que se quedan con los marcos dependientes de la plataforma. Aparentemente se han comercializado mejor.
Estas cosas tienen más que ver con cuestiones políticas que con cuestiones técnicas. En la práctica, los problemas técnicos más exigentes con el desarrollo multiplataforma surgen de la comunicación de hardware de bajo nivel (controladores a dispositivos específicos, etc.), pero las aplicaciones típicas no necesitan comunicarse directamente con el hardware de todos modos.
De hecho, ya está hecho. Hasta cierto punto al menos.
Uno de los esfuerzos se llama Java, que es un lenguaje multiplataforma. El compilador de Java compila el código fuente de algo llamado "bytecode", que no es más que un "lenguaje ensamblador" independiente de la máquina. Ese "ejecutable" es luego ejecutado por la Máquina Virtual Java (JVM), que es la parte que difiere de una plataforma a otra (es decir, Windows JVM es obviamente diferente de MacOS JVM).
Sin embargo, las aplicaciones multiplataforma no son tan simples. Es relativamente simple escribir una VM básica que ejecute algún tipo de bytecode abstracto para cada plataforma posible. Pero el lenguaje en sí no es prácticamente nada si carece de una biblioteca de clases enriquecedora. Por lo tanto, la implementación de dicha biblioteca de clases es muy difícil por varias razones.
El problema siempre es que obtendrías una aplicación por debajo de lo normal.
Si una aplicación necesita funcionar en todas las plataformas, terminará con una GUI que no se adapta correctamente a ninguna plataforma, y una aplicación que omite la funcionalidad esperada en la plataforma, es decir, funcionalidad que solo existe en una plataforma: en OS X esperaría una integración con todas las características más recientes, y lo mismo para Windows y * nix
Lo más cerca que puede llegar, supongo, es tener la funcionalidad central multiplataforma, y luego construir la GUI y cualquier característica adicional específica de la plataforma en la parte superior.
Este problema es más profundo de lo que la mayoría de la gente está planteando, Java aún no es realmente independiente de la plataforma, ya que no se ejecutará en todos los sistemas operativos x86 o x64, aún necesita una máquina virtual para ejecutarse en la cima del sistema operativo. Ni siquiera está cerca de lo que propone, ya que todavía necesita un tiempo de ejecución dependiente del sistema operativo para ejecutar el bytecode ''independiente''.
El problema viene con el hecho de que la mayoría de los ejecutables están superponiendo el sistema operativo y usándolo como una especie de marco. Tan pronto como coloque algún tipo de código dependiente del sistema operativo en su aplicación, tendrá la oportunidad de hacerlo independiente. Disco IO, IO de red, IU gráfica, obtención de información del sistema, cualquiera de estas cosas afectará cómo y por qué su código no puede ser independiente.
También está el problema de qué es un ejecutable, en Windows tiene PE, mientras que en la mayoría de los sistemas operativos Linux tiene ELF . Estos tienen diferentes estructuras y diferentes estilos de carga. Cómo se cargan y ejecutan depende del sistema operativo y no del asunto del ejecutable.
Puede ver la diferencia entre los dos formatos en esta imagen (tomada desde aquí : http://software.intel.com/file/9800
Básicamente, el problema es que no existe un estándar para la forma en que los archivos ejecutables / binarios se estructuran y cargan en una computadora. Luego, encima de eso está el marco y la funcionalidad del sistema operativo. Es un problema mucho más complejo, pero que no se resolverá mientras las empresas quieran tener funcionalidades específicas del sistema operativo.
Microsoft solo implementó .NET en Windows. Por lo tanto, para que las aplicaciones .NET se ejecuten en otras plataformas, es necesaria una nueva implementación. Mono está tomando medidas para que esto sea posible. La versión actual ejecuta la mayoría de los ensamblados .NET 2.0 y es compatible con muchas de las interfaces específicas de Windows.
En cuanto al resto de su pregunta: volver a implementar todas las API que todos los demás usan es difícil, y los proyectos existentes están incompletos. Wine es compatible con la mayoría de las aplicaciones de Windows, pero solo de forma justa. GNUstep implementa la mayor parte de la especificación OpenStep y tiene cierta compatibilidad con la API Cocoa de Mac OS, pero es dolorosamente incompleta y lo será durante mucho tiempo.
Si todos usaran una API estándar, tal vez sería diferente. Pero, francamente, todas las API que existen absorben de alguna manera.
Podemos hacer eso, ver Java para un ejemplo. Si Microsoft lo hará es otra cuestión. Mantienen una ventaja competitiva para Windows al no hacerlo.
Otros ejemplos son Perl y Python para nombrar solo dos. No es suficiente con solo tener un idioma, necesita tener bibliotecas para que la vida de los programadores sea más fácil. Java, Python y Perl parecen haber logrado esto relativamente bien y estoy seguro de que Microsoft tiene la capacidad intelectual para hacer lo mismo con .NET. Pero la pregunta sigue siendo: ¿por qué lo harían?
Al alejarse de las máquinas virtuales de tipo bytecode, también tiene cosas como VMWare, Virtual PC, etc. que pueden ejecutar código en un procesador virtual de nivel de hardware. Algunos de estos necesitan el mismo procesador debajo de las cubiertas, otros (como VirtualBox y Bochs, creo) ejecutan un procesador virtual encima de un procesador diferente.
Lo que realmente no he visto es una integración perfecta entre el host y los entornos virtuales. El drag-n-drop de VMWare entre los dos está bien, pero sería mucho mejor poder alojar un entorno SPARC encima de x86 y, básicamente, hacer que las aplicaciones SPARC se vean exactamente como las x86 (similar a cómo las ventanas X de Cygwin Las aplicaciones basadas en Windows se parecen a las ventanas normales de Windows.
Las aplicaciones dependen del sistema operativo para proporcionar servicios.
Puede crear una aplicación con una dependencia mínima en el sistema operativo. Pero incluso si (con algo de Fu, Magic y handwaving serio) lo haces funcionar en "cada computadora", no es lo que queremos.
Las secuencias de comandos y los lenguajes similares a los de secuencias de comandos (como Python y Perl, como se menciona) van por ese camino: usan funciones mínimas del sistema operativo y crean todo lo que proporcionan encima. Eso es genial para aplicaciones de línea de comandos porque todo lo que necesita (más o menos) es leer y escribir archivos y la consola del usuario.
Las aplicaciones enriquecidas de hoy en día necesitan muchos más servicios, sin embargo, necesitan "ejecutar en el sistema operativo" en lugar de "en la CPU" solos: esperamos que se integren con el sistema operativo, la interfaz de usuario debe parecer nativa, usted quiere usar el portapapeles, el el cuadro de diálogo "abrir archivo" debe proporcionar todas las funciones que ofrecen los otros cuadros de diálogo de archivos abiertos.
Un entorno como Java intenta proporcionarlo de una manera portátil mediante el uso de un mayor nivel de abstracción: hay ventanas y widgets y todas las cosas bellas. Pero eso tiene algunos problemas propios:
En primer lugar, siempre debe equilibrar entre la "consistencia de la plataforma de virtualización" (es decir, la aplicación funciona igual sin importar dónde la ejecute) y la "consistencia de la plataforma del host" (es decir, la aplicación funciona como una aplicación nativa).
Podrías tratar de eliminar por completo las "cosas nativas" para evitar ese problema, pero luego apuntas a la intersección de la funcionalidad que proporcionan todas las plataformas. Usted corre en Apple? Elimine con el segundo botón del mouse. etc. También su plataforma de abstracción siempre va a la zaga de las innovaciones en las plataformas de host.
La esencia de esto es que no hay una bala de plata: siempre hay un compromiso que tienes que hacer. Hay diferentes compromisos exitosos en el mercado.