inno-setup

Actualización de Ansi a la versión Unicode de Inno Setup(cualquier desventaja)



inno-setup (2)

Después de la respuesta clara aquí de que no hay una razón real para quedarse con la versión Ansi Inno Setup, ayer cambiamos la configuración beta de nuestro producto a la versión Unicode y no vimos ningún problema en nuestras propias pruebas.

Pero uno de nuestros probadores beta informó hoy que esta versión se bloquea al crear una excepción de firewall con el siguiente código:

try FirewallObject := CreateOleObject(''HNetCfg.FwAuthorizedApplication''); FirewallObject.ProcessImageFileName := ''C:/Program Files (x86)/FS-FlightControl/FS-FlightControl.exe''; FirewallObject.Name := ''FS-FlightControl''; FirewallObject.Scope := NET_FW_SCOPE_ALL; FirewallObject.IpVersion := NET_FW_IP_VERSION_ANY; FirewallObject.Enabled := True; FirewallManager := CreateOleObject(''HNetCfg.FwMgr''); FirewallProfile := FirewallManager.LocalPolicy.CurrentProfile; FirewallProfile.AuthorizedApplications.Add(FirewallObject); except Log(''Error setting firewall exception: '' + GetExceptionMessage); end;

Si se ejecuta este código, la configuración se bloquea con

Exception code: 0xc0000005 Error offset: 0x0005584c

en el registro de eventos de Windows. Le pedí al beta tester que ejecutara la configuración con el parámetro "/ LOG" y no se muestra ningún error. Solo la configuración completa se bloquea.

Para estar seguros de que fue el cambio de Ansi a Unicode lo que causó este problema, enviamos al probador beta otra compilación idéntica, solo compilada con la versión de Ansi y no se bloquea allí.

Por lo tanto, parece haber más efectos secundarios (negativos) de la versión Unicode.

No pudimos reproducir este problema nosotros mismos, solo uno de nuestros probadores beta que utiliza esta configuración: https://www.fs-flightcontrol.com/download/FS-FlightControl-Beta-InnoUnicode.exe Simplemente mantenga la excepción del firewall marcada y debería bloquearse en algún lugar cerca del final del proceso de configuración.

Según el archivo de registro de instalación que envió el probador, tiene la versión de Windows 10.0.14393. Como escribí no se pueden encontrar rastros de este problema en el registro, simplemente se bloquea.

¿Hay alguna desventaja de la versión Inno Setup Unicode en comparación con la versión Ansi?

¿O cuál es la razón por la que ambas versiones se ofrecen en paralelo y no solo queda la Unicode?

¿Hay algún problema potencial cuando uso la versión Unicode para mi proyecto existente Inno Setup desarrollado con la versión Ansi?


No hay desventajas reales. En su mayoría hay ventajas. Obviamente, el hecho de que la versión Unicode no se limita al antiguo juego de caracteres Ansi. Ver abajo para más detalles.

Si está comenzando un nuevo proyecto de Inno Setup, use siempre la versión Unicode. No hay razón para usar la versión Ansi para nuevos proyectos. En realidad, ya no hay una versión de Ansi para la última Inno Setup 6.

La razón por la que la versión Ansi de Inno Setup todavía estuvo disponible durante mucho tiempo fue que el código Pascal Script de las versiones Ansi y Unicode no son 100% compatibles. En su mayoría lo son, pero hay diferencias.

Entonces, si su script de instalación existente no tiene ningún código Pascal Script (no hay una sección [Code] en su .iss ), puede (y debería) cambiar a la versión Unicode de inmediato.

Si tiene un código Pascal Script, debe tener más cuidado. Ver abajo para más detalles.

¿Por qué quieres usar la versión Unicode?

Por ejemplo, de los problemas con la versión de Ansi, si ejecuta un instalador solo japonés creado con la versión de Ansi de Inno Setup en el sistema en inglés, obtendrá:

Consulte también que el instalador de Inno Setup tiene una codificación de texto incorrecta .

Por la misma razón, la versión Ansi no podrá crear archivos con nombres que contengan caracteres que no estén presentes en el conjunto de caracteres Ansi heredado de la máquina de destino.

La versión Unicode no tiene estos problemas, como se documenta en el jrsoftware.org/ishelp/index.php?topic=unicode :

Las características clave de Unicode Inno Setup son su capacidad de mostrar cualquier idioma en cualquier sistema, independientemente de la página de códigos del sistema, y ​​su capacidad de trabajar con nombres de archivo Unicode. Uno podría considerar la configuración Inno Unicode como la nueva configuración Inno estándar y la configuración Inno no Unicode como una antigua configuración Inno especial para aquellos que desean el tamaño más pequeño posible.

También para Inno Setup 6, no hay ninguna versión de Ansi en absoluto, por lo que si desea utilizar la última versión de Inno Setup con todas sus nuevas características , debe cambiar a la versión Unicode.

Además, hay algunas pequeñas mejoras en la versión Unicode Pascal Script. Están documentados en el jrsoftware.org/ishelp/index.php?topic=unicode . Además de eso, hay algunas mejoras indocumentadas:

  • Inc / Dec funciones / declaraciones. Vea la función Inc Inno Setup .
  • Mejor soporte de Variant . Por ejemplo, vea Configuración de Inno: iterar a través de una matriz de tipo Variant (de OleObject) o ¿Hay alguna manera de leer la información del sistema en Configuración de Inno ?
  • Mejor soporte de alto DPI (y pantalla no estándar en general). Por ejemplo, ¿ve el icono de la barra de tareas de Inno Setup borroso o el instalador de Inno Setup ha bloqueado la ventana en XP?
  • Rangos en la declaración de case : error del compilador "dos puntos ('':'') esperado" en el rango de caracteres en la declaración de caso en la secuencia de comandos Inno Setup Pascal .
  • in operador con un conjunto constante: Parece que en la versión Ansi, siempre se obtiene el error "No coinciden los tipos" , a menos que primero almacene el set en un set of variables.
    Tenga en cuenta que, si bien la versión Unicode admite el operador in con un conjunto constante, no admite rangos en la expresión del conjunto, por lo que X in [1, 2, 3] es posible, pero X in [1..3] es no es posible, obtendrá "Se espera el corchete de cierre ('']'')".
  • TLabel tiene fondo transparente en la versión Unicode. Ver Inno Setup - Transparencia debajo del texto en el nombre de la página y las etiquetas de descripción
  • No es posible llamar a los controladores de eventos estándar de algunas páginas de asistente personalizadas en la versión Ansi, mientras que funciona bien en la versión Unicode. ¿Qué puede ser útil para cosas como el evento Inno Setup que se genera cuando se examina la carpeta en TInputDirWizardPage?

Posibles problemas en el código Pascal Script

Hay pocas áreas donde pueden surgir problemas en el código Pascal Script:

  • Cualquier llamada a funciones de DLL que toman parámetros de string : string y tipos de PChar . AnsiString debería estar bien, ya que es lo mismo en la versión Unicode.

    En la versión Unicode, PChar pasó a llamarse PAnsiChar .

    Si invoca cualquier función de la API de Windows que utiliza cadenas, debe cambiar a su versión Wide. Por ejemplo, use GetFileAttributesW , en lugar de GetFileAttributesA . No hay tipo PWideChar . Entonces, si su declaración usó el tipo PChar en la versión Ansi, y cambia a la versión Wide de la función, debe usar el tipo de string lugar. Inno Setup lo organizará automáticamente en LPCTSTR (o similar), también conocido como PWideChar .

    La declaración a continuación es correcta en la versión Ansi, pero incorrecta en la versión Unicode, ya que GetFileAttributesA toma PAnsiChar , pero los PWideChar string a PWideChar en la versión Unicode.

    function GetFileAttributes(lpFileName: string): DWORD; external ''[email protected] stdcall'';

    Para obtener un ejemplo completo y una solución, vea Inno Setup FileExists no puede encontrar el archivo existente .

    En casos raros, que está llamando a una función que tiene un parámetro PWideChar fuera ( var S: PWideChar ), es muy difícil usarlo, sin el tipo PWideChar real, ya que en este caso no puede usar la clasificación de string . Pero es factible, vea Constante para AppData / LocalLow?

    De manera similar a la API de Windows, algunas bibliotecas de terceros también proporcionan una versión Unicode separada con cadenas Unicode en su API. Por ejemplo, ISSkin tiene ISSkinU.dll . Consulte Cómo hacer que ISSkin funcione con la última versión de Inno Setup 5.5.9 Unicode .

  • Cualquier código que use el tipo de string como matriz de bytes (como en la versión Unicode, la string es una matriz de caracteres anchos (2 bytes)). Eso es principalmente preocupante, solo si su código usa métodos de clase TStream como:

    function Read(Buffer: String; Count: Longint): Longint; function Write(Buffer: String; Count: Longint): Longint; procedure ReadBuffer(Buffer: String; Count: Longint); procedure WriteBuffer(Buffer: String; Count: Longint);

    Estos métodos realmente deberían haberse vuelto a declarar con AnsiString . Me parece un error.

    Para que estos métodos se BufferToAnsi usar en la versión Unicode, use la función BufferToAnsi de @TLama que se usa en muchas respuestas existentes, como:

    • Inno Setup LoadStringFromFile falla cuando el archivo está abierto en otro proceso
    • Leer bytes del archivo en la posición deseada con Inno Setup
    • Para otro enfoque, vea ver Escribir archivo binario en Inno Setup
  • La versión Unicode no permite el set of char variables set of char (ya que el set no está permitido para los tipos de varios bytes). Aunque, curiosamente, admite un set of char constantes de caracteres en expresiones. Consulte el error "No coinciden los tipos" en "conjunto de caracteres" en Pascal Script de la versión Inno Setup Unicode .

  • FloatToStr utiliza un separador decimal específico de la configuración regional en la versión Ansi, mientras que siempre un punto en la versión Unicode.

  • La versión Unicode es más estricta sobre el uso de punto y coma. La versión Ansi tolera algunos puntos y comas faltantes, por lo que puede compilar incluso código que no sea 100% sintácticamente correcto a este respecto.

Si su código no utiliza ninguno de los anteriores, y tiene los puntos y comas correctos, no debería tener ningún problema con la versión Unicode.