Mudlet: Los usuarios de Windows que no tienen ASCII en la ruta de archivo no pueden cargar LuaGlobal

Se sabe que Windows es extraño con los nombres de ruta, y las funciones de archivo en Lua deben alimentarse con los nombres de ruta cortados correctamente. En el código C ++, si no usamos C ++ 11 literales de cadena sin formato (y es posible que nos veamos obligados a no manejar un error de Qt con QObject::tr( ... ) ) un solo / en un nombre de ruta codificado de forma rígida para sistemas nix tiene que ser doblemente escapado * a \\\\ si se va a enviar a una función lua - la compilación de C ++ elimina cada \\ hasta \ y lo mismo sucede en el intérprete lua.

Da la casualidad de que la ruta en el mensaje [ ERROR ] parece que la ruta para anteponer al nombre LuaGlobal.lua archivo ./ predeterminado, por lo que se esperaba que estuviera en el mismo directorio que el ejecutable de Mudlet; sin embargo, para * Doze eso al menos debería haberse cambiado a .\\ o más bien .\\\\ en el código fuente de C ++.

Esto también significa que creo que el método estático QDir::nativeSeparators( ... ) NO hace lo correcto si estamos escribiendo una ruta / nombre de archivo como una cadena sin formato en el código C ++ que va para introducirse en el intérprete de Lua como una cadena.

No estoy seguro de entender sus comentarios o si en realidad estaban dirigidos a mí .. :)

¿Ve alguna posibilidad de que solucione este problema, salvo que configure un usuario completamente nuevo desde cero?

Es más una observación general para cualquiera que la mire. Debería ser posible solucionarlo mirando las rutas utilizadas para cargar el archivo LuaGlobel.lua, específicamente en la plataforma Windows. Tengo la sospecha de que hemos dejado que el sistema operativo use algún valor predeterminado, que puede ser "el mismo directorio que el ejecutable", pero que no es adecuado debido a la ruta que no es POSIX.

Mirando lo que creo que es la causa de este problema:

void TLuaInterpreter::loadGlobal()
{
#if defined(Q_OS_MACOS)
    // Load relatively to MacOS inside Resources when we're in a .app bundle,
    // as mudlet-lua always gets copied in by the build script into the bundle
    QString path = QCoreApplication::applicationDirPath() + "/../Resources/mudlet-lua/lua/LuaGlobal.lua";
#else
    // Additional "../src/" allows location of lua code when object code is in a
    // directory alongside src directory as occurs using Qt Creator "Shadow Builds"
    QString path = "../src/mudlet-lua/lua/LuaGlobal.lua"; // <== A
#endif

    int error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
    if (error != 0) {
        // For the installer we do not go down a level to search for this. So
        // we check again for the user case of a windows install.

        // overload previous behaviour to check by absolute path as well
        // TODO this sould be cleaned up and refactored to just use an array and a for loop
        path = QCoreApplication::applicationDirPath() + "/mudlet-lua/lua/LuaGlobal.lua"; // <== B
        if (!QFileInfo::exists(path)) {
            path = "mudlet-lua/lua/LuaGlobal.lua"; // <== C
        }
        error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
        if (error == 0) {
            mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
            return;
        }
    } else {
        mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
        return;
    }

    // Finally try loading from LUA_DEFAULT_PATH
    path = LUA_DEFAULT_PATH "/LuaGlobal.lua"; // <== D
    error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
    if (error != 0) {
        string e = "no error message available from Lua";
        if (lua_isstring(pGlobalLua, -1)) {
            e = "[ ERROR ] - LuaGlobal.lua compile error - please report!\n"
                "Error from Lua: ";
            e += lua_tostring(pGlobalLua, -1);
        }
        mpHost->postMessage(e.c_str());
    } else {
        mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
        return;
    }
}

Esto inmediatamente parece un poco dudoso porque A a D son incorrectos para Windows, por ejemplo, A debería ser "..\\\\src\\\\mudlet-lua\\\\lua\\\\LuaGlobal.lua" pero los otros necesitan reemplazos en tiempo de ejecución de / a \\\\ en tanto las cadenas literales como las variables que se incluyen. El error original en la parte superior del tema se debe a que LUA_DEFAULT_PATH está vacío en el momento en que se usa en Windows.

Recuerde que si al depurar esto, el mensaje [ ERROR ] en pantalla reproducirá una ruta que ha pasado por ambos , creo que \\ a \ no-escapes, por lo que debería verse como un Ruta de Windows en pantalla, que sería \LuaGobal.lua en el caso dado, que probablemente también sea incorrecta y debería haber sido .\LuaGobal.lua quizás, por lo que LUA_DEFAULT_PATH debería haber sido .\\\\ lugar?

Sin embargo, Lua en Windows maneja / como un separador de directorio muy bien.

Esa no ha sido mi experiencia algo limitada : IIRC hay una configuración de configuración en algún lugar de lua que contiene una matriz de 4 caracteres que contiene la configuración compilada para, entre otras cosas, el carácter comodín en los nombres de los paquetes y el separador de directorios. Recuerdo esto porque cuando me fijo hasta la (interna a) LuaGlobal.lua manejo de Ventanas vs * nix rutas de archivos en el pasado hice uso de un control sobre, creo que en un índice de matriz en la C config char matriz para '\\' o '/' , aunque creo que posteriormente se encontró una solución mejor.

Ah, ja, sí, mira la variable package.config , esa es la cuestión, de las preguntas frecuentes no oficiales de Lua :

1.40 ¿Problemas de compatibilidad entre Windows y Unix?

Aquí, 'Unix' significa cualquier sistema operativo similar a POSIX, como Linux, Mac OS X, Solaris, etc.

package.config es una cadena donde el primer 'carácter' es el separador de directorio; por lo que package.config:sub(1,1) es una barra o una barra invertida. Como regla general, intente usar esto al construir caminos.

Una gran diferencia entre las compilaciones de Windows y Unix es que el package.path predeterminado se basa en la ubicación del ejecutable de Windows, mientras que en Unix se basa en /usr/local/share/lua/5.1 . Por lo tanto, es más fácil hacer una instalación de usuario local de Lua en Windows, pero Lua respeta las variables de entorno LUA_PATH y LUA_CPATH .

Lua depende más directamente de las bibliotecas de tiempo de ejecución C del sistema que la mayoría de los lenguajes de scripting, por lo que debe apreciar las diferencias de plataforma. Utilice el especificador "rb" con io.open si necesita compatibilidad con E / S binarias de Windows. Tenga cuidado con os.tmpname porque no devuelve una ruta completa en Windows (prefijo con el valor de la variable de entorno TMP junto con una barra invertida primero). os.clock se implementa muy diferente en Windows.

Del mismo modo, os.time puede bloquear Lua si se pasan especificadores de formato no compatibles. (Esto ya no es un problema con Lua 5.2, que primero realiza las comprobaciones de cordura).

Para el subsistema GUI de Windows, os.execute puede ser irritante, y io.popen simplemente no funcionará; en este caso, hay bibliotecas de extensión multiplataforma disponibles.

'como regla general' - eso no contrarresta el hecho de que / como separador de directorio funciona bien en Windows en Lua.

Eso es todo, para algunos, incluido yo mismo, eso no funciona, es posible que no tenga una instalación de lua preparada siguiendo la receta normal citada (o que también tenga una instalación de Cygwin).

Me pregunto: ¿está confundiendo, por casualidad, el manejo del subsistema lua (o más bien la parte del paquete) de los separadores de directorio, que se puede configurar de cualquier manera (o posiblemente para algo completamente diferente, por ejemplo, ' para ¡RISCOS aparentemente!), Los shells cmd o powerline de Windows que aceptarán ambos o el núcleo Qt C ++ que también manejará ambos?

Me confunde muchísimo en cuanto a lo que se supone que funciona para una instalación lua compilada en una plataforma Windows; ah, ¿podría ser que msys sea POSIX pero mingw sea Windowish?

No, no lo soy, y también es la razón por la que usar / en LuaGlobal.lua funciona para muchas personas en Windows en su estado actual ...

Los separadores de ruta no son el problema aquí.

Entonces, presumiblemente, el intérprete lua en el mingw de Qt está configurado correctamente para Windows, y está usando la misma liblua a la que se vincula la aplicación Mudlet {puede que no sea, supongo, para todos}. Por ejemplo, luarocks proporciona un intérprete lua 5.1 que puede usar si no se encuentra otro pero, por la misma razón, ~ it ~ sus bibliotecas podrían usarse en su lugar.

💡 Ah, me pregunto, @Kebap , ¿qué obtienes si intentas obtener los valores de package.config en esa configuración que te está dando el error? Para mí en la línea de comando, por ejemplo, en mi sistema que se está ejecutando actualmente:

[stephen<strong i="11">@ripley</strong> ~]$ lua51
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(package.config)
/
;
?
!
-
> ^D
[stephen<strong i="12">@ripley</strong> ~]$

Tenga en cuenta el primer valor / que es el separador de directorio actual que se utilizará al cargar paquetes, como el archivo LuaGlobal.lua . Por supuesto, sin los scripts lua externos ejecutados / disponibles, no puedo recordar si es posible ejecutar cosas desde la "línea de comandos" en Mudlet. Intentaré encender mi computadora portátil 'Doze más tarde y veré qué obtengo con esa ...

Seguro que puedes probar:

Parece que hay una barra inclinada hacia atrás donde tenías una barra inclinada hacia adelante

Sin embargo, no estoy seguro de si debería probar esto en Mudlet, ya que parece haber usado una forma y un lugar diferentes ...

Podría crear uno o dos nuevos usuarios, con y sin caracteres especiales, solo para asegurarme de que el nombre de usuario sea realmente el problema aquí. ¿Crees que es útil?

Si, por favor intente

El miércoles 25 de abril de 2018 a las 6:48 pm Kebap, [email protected] escribió:

Podría crear uno o dos nuevos usuarios, con y sin caracteres especiales,
solo para asegurarse de que el nombre de usuario sea realmente el problema aquí. Tu crees
¿es útil?

-
Estás recibiendo esto porque hiciste un comentario.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Mudlet/Mudlet/issues/1616#issuecomment-384355980 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAGxjN9JHbiPCOgUf3u1u8jVg0KjDiSbks5tsKj3gaJpZM4TZAbQ
.

Por lo que puedo ver, el código está probando todas las ubicaciones sugeridas para los archivos LuaGlobal.lua y finalmente llega a la que intenta:

LUA_DEFAULT_PATH "/LuaGlobal.lua"

sin embargo, a partir del mensaje de error resultante, parece que LUA_DEFAULT_PATH es una cadena vacía, por lo que la ruta utilizada es:

/LuaGlobal.lua

asumiendo (y todavía no estoy convencido, pero espero que sea solo mi problema) que '/' ES un separador de directorio funcional donde se está usando, significa buscar el archivo en la raíz del sistema de archivos, en los POSIX que es literalmente, la raíz y en Windows es la raíz de la unidad actualmente activa, probablemente C:\ (o C:/ : wink :) - si realmente queremos que sea el directorio de trabajo actual, entonces LUA_DEFAULT_PATH debe ser un solo carácter . y no completamente vacío; en ese caso, el mensaje de error devolvería:

... cannot open ./LuaGlobal.lua ...

o si devuelve la ruta completa, posiblemente algo como:

... cannot open C:/Users/Eingeschränkt/AppData/Local/Mudlet/LuaGlobal.lua ...

¿quizás? 😮

Veo que el mensaje de error del intérprete lua se captura en un std::string y se envía a cTelnet::postMessage( ... ) través de una conversión std::string::c_str() a un const char * pero como el postMessage espera un QString esto debería activar el constructor QString :: QString (const char str) que usa el convertidor QString::fromUtf8() así los caracteres que no son ASCII * deben pasar sin daños ... 😌

\

lua print(package.config)

desde la línea de comandos del perfil de Mudlet incluso con el error que está recibiendo.

Esto es un poco especulativo, pero como solución en tiempo de ejecución, me pregunto si es posible hacer algo como:

lua package.config = "/;?!_"

para cambiar el separador a / - aunque es posible que desee cambiar la configuración del "separador de comandos" en las preferencias para que no divida lo anterior en ; - y luego vea si puede "ejecutar" el archivo LuaGlobal.lua manualmente? Oh, eso no proporcionará mensajes de error de tipo [ ERROR ] si no funciona. \

Error confirmado con Mudlet 3.8.1 en Win 8.1 con nombre de usuario con carácter especial: ä.
No hay error con el nombre de usuario sin caracteres especiales.

lua print(package.config) sin resultado visible
lua print('test') también sin resultado visible
lua alias está disponible, pero print no parece estar
lua echo('test') funciona como se esperaba

Corrió lua package.config = "/;?!_"
El registro de errores dice: ERROR:[string "Alias: run lua code"]:4: [string "package.config = "/"]:1: unfinished string near '<eof>'

Se cambió el separador de comandos de; a otra cosa

Corrió lua package.config = "/;?!_"
¿OK, eso creo? Resultado invisible

Corrió lua run("./LuaGlobal.lua")
El registro de errores dice: ERROR:[string "return run("./LuaGlobal.lua")"]:1: attempt to call global 'run' (a nil value)

Prueba con include - mismo error.

lua require("./LuaGlobal.lua") - error interesante:
ERROR:[string "return require("./LuaGlobal.lua")"]:1: module './LuaGlobal.lua' not found: no field package.preload['./LuaGlobal.lua'] no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua\init.lua' no file '.\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua' no file '.\\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\' no file '.\.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll'

Solo para estar seguro lua require("/LuaGlobal.lua")
El registro de errores dice:
ERROR:[string "return require("/LuaGlobal.lua")"]:1: module '/LuaGlobal.lua' not found: no field package.preload['/LuaGlobal.lua'] no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua\init.lua' no file '.\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua' no file '.\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal' no file '.\/LuaGlobal.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll'

Es extraño que print no funcione, pensé que era un lua incorporado, pero:

lua echo(package.config)

debería funcionar también.

Al observar la salida del primer tipo de ejemplo de trabajo, la salida de error está intentando cargar el archivo LuaGlobal.lua ; veamos qué nombres de archivo y rutas se están probando:

1. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua.lua
2. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua\init.lua
3. .\\/LuaGlobal\lua.lua
4. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua.lua
5. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua\init.lua
6. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.lua
7. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua\init.lua
8. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua
9. .\\/LuaGlobal\lua.dll
10. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.dll
11. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll
12. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\
13. .\.dll
14. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\.dll
15. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll

No estaba seguro de dónde debería ubicarse el archivo en estos días, así que descargué e instalé el binario 3.8.1 y descubrí que la ruta utilizada es:

C: \ Users \ Stephen \ AppDataLocal \ Mudlet \ app-3.8.1 \ mudlet-lualua

también con esa versión de Windows Installer, tengo lo siguiente para el package.config:

lua print(package.config)
\
;
?
!
-

por lo que las rutas deben usar \ para que el controlador de paquetes funcione en mi opinión. Sin embargo, todavía no está claro por qué diferentes personas obtienen cosas diferentes.

Editado: para citar la lista de rutas con `en lugar de '

La razón por la que algunas rutas son mojibake y otras muestran correctamente el nombre de usuario debe ser porque provienen de diferentes fuentes y algunas de ellas aún no son capaces de I18n adecuadamente; sería útil si pudiéramos rastrearlas y solucionarlas con Mudlet 4.0, pero puede que no sean aquellos sobre los que tengamos control. Tenga en cuenta que no puede ser el código de visualización o las fuentes porque todos los mensajes de error individuales pasan por el mismo proceso en el que fueron creados.

Solo para estar seguro de que estaba usando la instancia esperada (como desarrollador, tengo más de una copia en esa PC), cambié el nombre del archivo y obtuve el mismo resultado:

También creé un nuevo usuario CON caracteres no ASCII (y probablemente ni siquiera Latin1 / ISO 885901) y puedo confirmar que las cosas están mal de la misma manera para ese usuario: Mudlet no puede ver el archivo en:

C:\Users\şțȅƥĥēƞ\AppData\Local\Mudlet\app-3.8.1\mudlet-lua\lua\LuaGlobal.lua

pero puede por

C:\Users\stephen\AppData\Local\Mudlet\app-3.8.1\mudlet-lua\lua\LuaGlobal.lua

:sollozo:

Esta sesión de preguntas y respuestas en Stack Exchange no parece prometedora.

Sin embargo, el traductor de nombre de archivo de Windows luawinfile con licencia del MIT (solo compila en mingw NO MSVC) (convierte los nombres de archivo UTF-8 a / desde el UTF-16 que debe usarse con la API de manejo de archivos de Windows) se ve un poco mejor: proporciona reemplazos para el módulo LFS que puede tomar archivos UTF-8 y nombres de ruta.

Buen descubrimiento. Solo para tirarlo, tenemos https://github.com/starwing/luautf8 ya en Mudlet, ¿hay algo en eso que pueda ayudarnos?

SlySven, su lista de 15 nombres de directorio parece incorrecta. Por ejemplo, 13 debe leer .\.dll y no ..dll

Ah, ese es el sistema de marcado que interfiere: en algunos contextos aquí, una barra invertida escapa al siguiente carácter que es necesario, por ejemplo, si desea mostrar un símbolo menor que en texto ordinario como este "\ <", no verá el barra invertida allí ... y usé comillas simples ordinarias en lugar de las comillas de código, editadas para corregir las citas.

El luautf8 tiene que ver con el manejo de cadenas UTF-8; no creo que ayude aquí ya que luainfile trata específicamente de interactuar con el manejo de archivos de Windows (que solo funciona con cadenas UTF-16) C o, más probablemente, biblioteca C ++: parece que necesita envolver o reemplazar lfs solo en

Hmm, pero no usamos lfs para cargar LuaGlobal.lua , entonces, ¿cómo resolverá luainfile el problema?

No es solo un reemplazo de lfs . También tiene un reemplazo para dofile y loadfile . Probablemente necesitemos reemplazar nuestra llamada a luaL_dofile con una llamada lua a dofile .

Edite para agregar: Los enlaces de la biblioteca luainfile (por defecto) contra lua 5.3 ... No estoy seguro si esa es una dependencia difícil o no.

Parece que simplemente podemos escribir nuestra propia función luaL_dofile , ¿entonces eso funciona con la codificación especial de Windows?

¿Cómo podemos impulsar esto?

He planteado un problema en el repositorio de luawinfile preguntando acerca de la compatibilidad con 5.1, pero he echado un vistazo y en realidad usa algunas características de lenguaje 5.3 que no son proporcionadas por lua 5.1; hay un módulo de compatibilidad 5.3 oficial separado que intenta proporcionar algunas de las características que faltan en 5.2 y 5.1, pero no está exenta de otras complicaciones, por lo que no es una solución inmediata.

Parece relacionado con el n. ° 229

¿Cómo podemos impulsar esto?

Necesitaremos exportar el archivo con licencia del MIT https://github.com/cloudwu/luawinfile (un solo archivo C de alrededor de 884 líneas {808 soc} de código) de 5.3 a 5.1 para acomodar algunas características que no están presentes en la versión anterior. versión de lua que usa Mudlet. Esto requerirá a alguien con una mejor comprensión de la codificación lua-C de lo que me siento actualmente, creo. Sin embargo, parece ser algo que se puede hacer y probar de forma independiente sin preocuparse demasiado por el resto del código base, aunque solo se puede probar en una plataforma de desarrollo de Windows.

El otro problema es que las personas no pueden guardar sus perfiles en Windows con nombres de usuario que no estén en inglés; no se escribe ningún historial. No creas que tenemos un boleto para eso.

@SlySven
¿Quizás aprendiste algunas cosas durante tus arreglos recientes para llevar cartas internacionales a Mudlet, para sacar adelante este problema?

Realmente no, creo que la conversión de luawinfile a Lua 5.1 ofrece nuestra mejor esperanza, pero simplemente no tengo una comprensión suficientemente buena (¿todavía?) De C/C++ + lua API para confiar en mi capacidad para hacer esto. ¿Alguien más? Supongo que debemos revisar el código de la biblioteca oficial Lua io y ver cómo luawinfile reemplaza algunas (¿todas, no sé?) De las funciones con reemplazos específicos de Windows.

Como la gente habrá notado, mi principal plataforma de desarrollo de Windows no es la más conforme (una computadora portátil con Windows 7 con un procesador de 64 bits pero que ejecuta la versión de 32 bits); mi PC principal también tiene un Windows 7 de 64 bits, pero ese triple- máquina de arranque no se ha ejecutado ese sistema operativo durante meses, así que tengo varias horas de mirar fijamente una "Actualización de Windows ... no apagar" la pantalla que esperar y no me siento motivado que, ATM!

Aunque, ahora que el instalador en línea de Qt finalmente parece haber cambiado para ofrecer solo una instalación de Mingw64 de Windows de 64 bits, en comparación con la anterior de solo Mingw de 32 bits, podría considerar hacerlo si tengo algunas horas para tirar. ..

Luciendo bien...

Esto es gracias a https://gist.github.com/Egor-Skriptunoff/2458547aa3b9210a8b5f686ac08ecbf0 que se creó a principios de año.

Estará disponible en Mudlet 3.22