Mudlet: Usuários do Windows com não ASCII no caminho de arquivo não podem carregar LuaGlobal

O Windows é conhecido por ser estranho com nomes de caminho - e as funções de arquivo em Lua precisam ser alimentadas com os nomes de caminho cortados corretamente. No código C ++, se não usarmos literais de string brutos C ++ 11 (e podemos ser forçados a não lidar com um bug do Qt com QObject::tr( ... ) ) um único / em um nome de caminho codificado para sistemas nix deve ser duplamente escapado * para \\\\ se for enviado para uma função lua - a compilação C ++ tira cada \\ até \ e a mesma coisa acontece no intérprete lua.

Acontece que o caminho na mensagem [ ERROR ] parece que o caminho para preceder ao LuaGlobal.lua nome do arquivo foi deixado como um ./ padrão de modo que era esperado que estivesse no mesmo diretório do executável Mudlet - entretanto, para * Doze, isso pelo menos deveria ter sido alterado para .\\ ou melhor, .\\\\ no código-fonte C ++!

Isso também significa que acho que o método estático QDir::nativeSeparators( ... ) NÃO faz a coisa certa se estivermos escrevendo um nome de caminho / arquivo como uma string bruta no código C ++ que está sendo para ser alimentado no interpretador Lua como uma string.

Não tenho certeza se entendi seus comentários ou se eles foram realmente direcionados a mim .. :)

Você vê alguma chance de eu corrigir esse problema, exceto configurar um novo usuário do zero?

É mais uma observação geral para qualquer um que dê uma olhada nele. Deve ser possível consertá-lo observando o (s) caminho (s) usado (s) para carregar o arquivo LuaGlobel.lua, especificamente na plataforma Windows. Suspeito que deixamos que o SO use algum valor padrão - que pode ser "o mesmo diretório do executável", mas que não é adequado devido ao caminho não POSIX.

Olhando para o que eu acho que é a causa deste 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;
    }
}

Isso imediatamente parece um pouco duvidoso porque A a D são todos errados para o Windows, por exemplo, A deve ser "..\\\\src\\\\mudlet-lua\\\\lua\\\\LuaGlobal.lua" mas os outros precisam de substituições em tempo de execução de / para \\\\ em ambas as strings literais E as variáveis ​​incluídas. O erro original na parte superior do tópico é porque LUA_DEFAULT_PATH está vazio no momento em que é usado no Windows!

Lembre-se de que a depuração desta mensagem na tela [ ERROR ] reproduzirá um caminho que passou por ambos, eu acho que \\ a \ un-escapings, então deve parecer um verdadeiro Caminho do Windows na tela - que seria \LuaGobal.lua no caso fornecido - que provavelmente também está errado e deveria ser .\LuaGobal.lua talvez - então LUA_DEFAULT_PATH deveria ser .\\\\ vez disso?

No entanto, Lua no Windows trata / como um separador de diretório.

Essa não tem sido minha experiência um tanto limitada - IIRC há uma definição de configuração em algum lugar no material lua que contém uma matriz de 4 caracteres que contém as configurações compiladas para, entre outras coisas, o caractere curinga em nomes de pacotes e o separador de diretório. Lembro-me disso porque quando eu corrigi o tratamento (interno para) LuaGlobal.lua de caminhos de arquivo do Windows vs. * nix no passado, eu usei uma verificação, acho que em um índice de matriz C em config char array para '\\' ou '/' - embora eu ache que uma solução melhor foi encontrada posteriormente.

Ah, ha - sim - veja a variável package.config - é isso, do FAQ de Lua não oficial :

1.40 Problemas de compatibilidade entre Windows e Unix?

Aqui, 'Unix' significa qualquer sistema operacional semelhante ao POSIX, como Linux, Mac OS X, Solaris, etc.

package.config é uma string onde o primeiro 'caractere' é o separador do diretório; então package.config:sub(1,1) é uma barra ou uma barra invertida. Como regra geral, tente usar isso ao construir caminhos.

Uma grande diferença entre as compilações do Windows e do Unix é que o package.path padrão é baseado na localização do executável do Windows, enquanto no Unix é baseado em /usr/local/share/lua/5.1 . Portanto, é mais fácil fazer uma instalação de usuário local de Lua no Windows, mas Lua respeita as variáveis ​​de ambiente LUA_PATH e LUA_CPATH .

Lua depende mais diretamente das bibliotecas de tempo de execução C do sistema do que a maioria das linguagens de script, portanto, você deve apreciar as diferenças de plataforma. Use o especificador "rb" com io.open se precisar de compatibilidade com E / S binária do Windows. Tenha cuidado com os.tmpname porque ele não retorna um caminho completo no Windows (prefixo com o valor da variável de ambiente TMP junto com uma barra invertida primeiro.) os.clock é implementado muito de forma diferente no Windows.

Da mesma forma, os.time pode realmente travar Lua se passados ​​por especificadores de formato não compatíveis. (Isso não é mais um problema com Lua 5.2, que faz verificações de integridade primeiro.)

Para o subsistema Windows GUI, os.execute pode ser irritante e io.popen simplesmente não funciona - bibliotecas de extensão de plataforma cruzada estão disponíveis neste caso.

'como regra geral' - isso não se opõe ao fato de que / como separador de diretório funciona bem no Windows em Lua.

É exatamente isso - para alguns, inclusive eu, que não funciona - pode muito bem ser que eu não tenha uma instalação lua preparada seguindo a receita normal citada (ou que eu tenha um Cygwin instalado também).

Eu me pergunto - você está confundindo, por acaso, o manuseio do subsistema lua (ou melhor, a parte do pacote dele) de separadores de diretório - que podem ser configurados de qualquer maneira (ou possivelmente para algo totalmente diferente, digamos, ' para RISCOS aparentemente!), Os shells cmd ou powerline do Windows que aceitarão ambos ou o núcleo Qt C ++ que também lidará com ambos?

Isso me confunde profundamente sobre o que deveria funcionar para uma instalação lua compilada em uma plataforma Windows - ah, será que msys é POSIX, mas mingw é Windowish?

Não, não estou, e é também por isso que usar / em LuaGlobal.lua funciona para muitas pessoas no Windows em seu estado atual ...

Os separadores de caminho não são o problema aqui.

Então, presumivelmente, o interpretador lua no mingw do Qt está configurado corretamente para Windows, e está usando o mesmo liblua que o aplicativo Mudlet é vinculado {pode não ser, suponho, para todos}. Por exemplo, luarocks fornece um interpretador lua 5.1 que pode ser usado se nenhum outro for encontrado, mas pelo mesmo token ~ it ~ suas bibliotecas podem ser usadas em seu lugar.

💡 Ah, eu me pergunto, @Kebap o que você obtém se tenta obter os valores de package.config nessa configuração que está apresentando o erro? Para mim na linha de comando, por exemplo, no meu sistema atualmente em execução:

[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> ~]$

Observe o primeiro valor / que é o separador de diretório atual que será usado ao carregar pacotes - como o arquivo LuaGlobal.lua ! Claro, sem os scripts lua externos sendo executados / disponíveis, não consigo me lembrar se é possível executar coisas a partir da "linha de comando" no Mudlet. Vou tentar ligar meu laptop 'Doze mais tarde e ver o que achei ...

Claro, posso tentar:

Parece que há uma barra invertida onde você tinha uma barra

Não tenho certeza se devo tentar isso em Mudlet, pois você parece ter usado uma maneira e lugar diferentes ..?

Eu poderia criar um ou dois novos usuários, com e sem caracteres especiais, apenas para ter certeza de que o nome do usuário é realmente o problema aqui. Você acha que é útil?

Sim por favor tente

Na quarta-feira, 25 de abril de 2018, 18:48 Kebap, [email protected] escreveu:

Eu poderia criar um ou dois novos usuários, com e sem caracteres especiais,
apenas para ter certeza de que o nome de usuário é realmente o problema aqui. Você acha que
É útil?

-
Você está recebendo isso porque comentou.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Mudlet/Mudlet/issues/1616#issuecomment-384355980 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAGxjN9JHbiPCOgUf3u1u8jVg0KjDiSbks5tsKj3gaJpZM4TZAbQ
.

Pelo que eu posso ver, o código está tentando todos os locais sugeridos para os arquivos LuaGlobal.lua e finalmente atinge aquele onde tenta:

LUA_DEFAULT_PATH "/LuaGlobal.lua"

no entanto, a partir da mensagem de erro resultante, parece que LUA_DEFAULT_PATH é uma string vazia, então o caminho usado é:

/LuaGlobal.lua

assumindo (e ainda não estou convencido, mas espero que seja apenas meu problema) que '/' É um separador de diretório viável onde está sendo usado, significa procurar o arquivo na raiz do sistema de arquivos - em POSIX que é literalmente a raiz e no Windows é a raiz da unidade atualmente ativa, provavelmente C:\ (ou C:/ : wink :) - se realmente quisermos que seja o diretório de trabalho atual , LUA_DEFAULT_PATH deve ser um único caractere . e não completamente vazio - sendo esse o caso, a mensagem de erro retornaria:

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

ou se retornar o caminho completo, possivelmente algo como:

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

pode ser? 😮

Vejo que a mensagem de erro do intérprete lua é capturada em um std::string e enviada para cTelnet::postMessage( ... ) por meio de uma conversão de std::string::c_str() para um const char * mas como o postMessage está esperando um QString isso deve envolver o construtor QString :: QString (const char que usa o conversor QString::fromUtf8() caracteres não ASCII * devem passar sem danos ... 😌

\

lua print(package.config)

na linha de comando do perfil Mudlet, mesmo com o erro que você está obtendo.

Isso é um pouco especulativo, mas como uma correção de tempo de execução, eu me pergunto se é possível fazer algo como:

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

para mudar o separador para / - embora você possa querer mudar a configuração do "separador de comando" nas preferências para que não divida o anterior em ; - e então veja se você pode "executar" o arquivo LuaGlobal.lua manualmente? Oh, isso não fornecerá mensagens de erro do tipo [ ERROR ] se não funcionar. \

Erro confirmado com Mudlet 3.8.1 no Win 8.1 com nome de usuário com caractere especial: ä.
Nenhum erro com o nome de usuário sem caracteres especiais.

lua print(package.config) sem resultado visível
lua print('test') também sem resultado visível
lua alias está disponível, mas print não parece estar
lua echo('test') funciona conforme o esperado

Executou lua package.config = "/;?!_"
O registro de erros diz: ERROR:[string "Alias: run lua code"]:4: [string "package.config = "/"]:1: unfinished string near '<eof>'

Separador de comando alterado de; para outra coisa

Executou lua package.config = "/;?!_"
OK eu acho? Resultado invisível

Executou lua run("./LuaGlobal.lua")
O registro de erros diz: ERROR:[string "return run("./LuaGlobal.lua")"]:1: attempt to call global 'run' (a nil value)

Teste com include - mesmo erro.

lua require("./LuaGlobal.lua") - erro interessante:
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'

Apenas para ter certeza lua require("/LuaGlobal.lua")
O log de erros diz:
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'

É estranho que print não esteja funcionando - eu pensei que fosse uma lua embutida - mas:

lua echo(package.config)

deve funcionar bem.

Olhando para a saída do primeiro tipo de exemplo de trabalho, a saída de erro está tentando carregar o arquivo LuaGlobal.lua - vamos ver quais nomes de arquivo e caminhos estão sendo tentados:

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

Eu não tinha certeza de onde o arquivo deveria estar atualmente, então baixei e instalei o binário 3.8.1 e descobri que o caminho usado é:

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

também com essa versão do Windows Installer, tenho o seguinte para o package.config:

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

então os caminhos para ele devem usar \ para que o manipulador de pacotes funcione IMO. Ainda não está claro por que pessoas diferentes estão recebendo coisas diferentes.

Editado: para citar a lista de caminhos com `em vez de '

Por que alguns caminhos são mojibake e outros exibem corretamente o nome de usuário deve ser porque eles vêm de fontes diferentes e alguns deles ainda não são adequadamente capazes de I18n - seria útil se pudéssemos rastreá-los e corrigi-los pelo Mudlet 4.0 - mas eles podem não ser aqueles sobre os quais temos controle. Observe que não pode ser o código de exibição ou as fontes porque as mensagens de erro individuais passam pelo mesmo processo em que foram criadas.

Apenas para ter certeza de que estava usando a instância esperada (como desenvolvedor, tenho mais de uma cópia naquele PC), renomei o arquivo e obtive o mesmo resultado:

Além disso, criei um novo usuário COM caracteres não ASCII (e provavelmente nem mesmo Latin1 / ISO 885901) e posso confirmar que as coisas estão bagunçadas da mesma maneira para esse usuário - Mudlet não pode ver o arquivo em:

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

mas pode por

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

:soluço:

Estas perguntas e respostas no Stack Exchange não parecem promissoras.

No entanto, o conversor de nome de arquivo do Windows (apenas compila em mingw NÃO MSVC) licenciado pelo MIT luawinfile do Windows (converte nomes de arquivo UTF-8 para / do UTF-16 que deve ser usado com a API de manipulação de arquivos do Windows) parece um pouco melhor - fornece substituições para o módulo LFS que pode receber arquivos UTF-8 e nomes de caminho.

Bom achado. Só para jogar por aí, temos https://github.com/starwing/luautf8 já em Mudlet, há algo nisso que poderia nos ajudar?

SlySven, sua lista de 15 nomes de diretório parece errada. Por exemplo, 13 deve ser .\.dll e não ..dll

Ah, esse é o sistema de marcação interferindo - em alguns contextos aqui uma barra invertida escapa do seguinte caractere que é necessário, por exemplo, se você quiser mostrar um símbolo menor que em um texto comum como este "\ <", você não verá o barra invertida ali ... e eu usei aspas simples comuns em vez das aspas de código - editado para corrigir as aspas.

O luautf8 tem tudo a ver com o manuseio de strings UTF-8 - não acho que ajude aqui, pois luainfile trata especificamente da interface com o manuseio de arquivos do Windows (que só funciona com strings UTF-16) C ou biblioteca C ++ mais provável - parece que precisa ser encerrada ou substituir lfs apenas no

Hmm, mas não usamos lfs para carregar LuaGlobal.lua , então como luainfile resolverá o problema?

Não é apenas um substituto para lfs . Ele também tem um substituto para dofile e loadfile . Provavelmente precisaremos substituir nossa chamada para luaL_dofile por uma chamada lua para dofile .

Edite para adicionar: Os links da biblioteca luainfile (por padrão) contra lua 5.3 ... Não tenho certeza se essa é uma dependência rígida ou não.

Parece que podemos simplesmente escrever nossa própria função luaL_dofile , então ela funciona com a codificação especial do Windows?

Como podemos levar isso adiante?

Eu levantei um problema no repositório luawinfile perguntando sobre a compatibilidade 5.1, mas eu dei uma olhada e ele realmente usa alguns recursos da linguagem 5.3 que não são fornecidos pela lua 5.1 - há um módulo de compatibilidade 5.3 oficial separado que tenta fornecer alguns dos recursos que faltam para 5.2 e 5.1, mas não é sem algumas outras complicações, portanto, não é uma solução gota.

Parece relacionado com # 229

Como podemos levar isso adiante?

Precisamos fazer backport do https://github.com/cloudwu/luawinfile licenciado pelo MIT (um único arquivo C com cerca de 884 linhas {808 soc} de código) de 5.3 para 5.1 para acomodar alguns recursos que não estão presentes no anterior versão de lua que Mudlet usa. Isso exigirá alguém com um domínio melhor de codificação lua-C do que eu sinto atualmente, eu acho. No entanto, parece ser algo que pode ser feito e testado independentemente, sem se preocupar muito com o resto da base de código - embora só possa realmente ser testado em uma plataforma de desenvolvimento Windows.

O outro problema é que as pessoas não podem salvar seus perfis em janelas com nomes de usuário que não sejam em inglês - nenhum histórico é escrito. Não pense que temos um ingresso para isso.

@SlySven
Você talvez tenha aprendido algumas coisas durante suas recentes correções para trazer cartas internacionais para Mudlet, para trazer esse problema para a frente?

Não realmente, eu acho que a portabilidade de luawinfile para Lua 5.1 oferece nossa melhor esperança, mas eu simplesmente não tenho uma compreensão boa o suficiente (ainda?) De C/C++ + lua API para colocar qualquer confiança em minha capacidade de fazer isso. Alguém mais? Acho que precisamos examinar o código da biblioteca oficial Lua io e ver como luawinfile substitui algumas (todas, não sei?) Das funções por substituições específicas do Windows.

Como as pessoas devem ter notado, minha plataforma de desenvolvimento principal do Windows não é a mais compatível (um laptop Windows 7 com um processador de 64 bits, mas executando a versão de 32 bits) - meu PC principal também tem um Windows 7 de 64 bits, mas que triplo máquina de inicialização não foi executado que o OS por meses, por isso tenho várias horas de olhar para um "Atualizando o Windows ... não desligue" tela para olhar para frente e eu não que estou motivado, ATM!

Embora, agora que o instalador on-line do Qt finalmente parece ter mudado para oferecer apenas uma instalação do Mingw64 Windows de 64 bits - em comparação com a instalação anterior do Mingw de 32 bits, eu poderia considerar fazer isso se tiver algumas horas para jogar fora. ..

Parece bom...

Isso é graças a https://gist.github.com/Egor-Skriptunoff/2458547aa3b9210a8b5f686ac08ecbf0 que foi criado no início do ano.

Estará disponível no Mudlet 3.22