Mudlet: Пользователи Windows с не-ASCII в пути к файлу не могут загрузить LuaGlobal

Windows, как известно, использует странные имена путей - и файловые функции в Lua должны загружаться с правильными именами путей с косой чертой. В коде C ++, если мы не используем необработанные строковые литералы C ++ 11 (и мы можем быть вынуждены не обрабатывать ошибку Qt с помощью QObject::tr( ... ) ) одного / в жестко закодированном имени пути для систем nix должно быть дважды экранировано * до \\\\ если оно будет отправлено в функцию lua - компиляция C ++ удаляет каждый \\ до \ и то же самое происходит в интерпретаторе lua.

Как это бывает, путь в сообщении [ ERROR ] выглядит так, как будто путь, добавляемый к LuaGlobal.lua filename, был оставлен как ./ умолчанию, поэтому ожидалось, что он будет в в том же каталоге, что и исполняемый файл Mudlet - однако для * Doze его, по крайней мере, следовало изменить на .\\ или, скорее, на .\\\\ в исходном коде C ++!

Это также означает, что я думаю, что статический метод QDir::nativeSeparators( ... ) НЕ делает правильные вещи, если мы пишем путь / имя файла в виде необработанной строки в коде C ++, который выполняется. для передачи в интерпретатор Lua в виде строки.

Не уверен, что понимаю ваши комментарии и были ли они на самом деле адресованы мне .. :)

Видите ли вы какой-нибудь шанс, что я исправлю эту проблему, если не настроить совершенно нового пользователя с нуля?

Это скорее общее наблюдение для всех, кто на это смотрит. Это должно быть возможно исправить, посмотрев на пути, используемые для загрузки файла LuaGlobel.lua, особенно на платформе Windows. У меня есть подозрение, что мы оставили эту ОС использовать какое-то значение по умолчанию - которое может быть «тем же каталогом, что и исполняемый файл», но не подходит из-за пути, отличного от POSIX.

Глядя на то, что я считаю причиной этой проблемы:

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;
    }
}

Это сразу кажется немного изворотливым, потому что все от A до D неверны для Windows, например, A должно быть "..\\\\src\\\\mudlet-lua\\\\lua\\\\LuaGlobal.lua" но другие нуждаются в замене во время выполнения / на \\\\ в как буквальные строки, так и включенные переменные. Исходная ошибка в верхней части темы связана с тем, что LUA_DEFAULT_PATH пуст в то время, когда он используется в Windows!

Помните, что при отладке экранное сообщение [ ERROR ] будет воспроизводить путь, который прошел через оба, я думаю, от \\ до \ неэкранирований, поэтому он должен выглядеть как настоящий, настоящий Путь Windows на экране - в данном случае это будет \LuaGobal.lua - что, вероятно, также неверно и должно было быть, возможно, .\LuaGobal.lua - так что LUA_DEFAULT_PATH должно было быть .\\\\ вместо этого?

Lua в Windows прекрасно обрабатывает / как разделитель каталогов.

Это не было моим несколько ограниченным опытом - IIRC есть параметр конфигурации где-то в материале lua, который содержит массив из 4 символов, который содержит скомпилированные в настройках, среди прочего, подстановочный знак в именах пакетов и разделитель каталогов. Я вспоминаю это, потому что, когда я исправлял (внутреннюю) обработку LuaGlobal.lua путей к файлам Windows и * nix в прошлом, я использовал проверку, я думаю, на одном индексе массива C в config char array для '\\' или '/' - хотя я думаю, что впоследствии было найдено лучшее решение.

Ах, ха - да - посмотрите переменную package.config - вот в чем дело, из Lua Unofficial FAQ :

1.40 Проблемы совместимости между Windows и Unix?

Здесь «Unix» означает любую POSIX-подобную операционную систему, такую ​​как Linux, Mac OS X, Solaris и т. Д.

package.config - это строка, в которой первый «символ» - это разделитель каталогов; поэтому package.config:sub(1,1) - это либо косая черта, либо обратная косая черта. Как правило, старайтесь использовать это при построении дорожек.

Большая разница между сборками Windows и Unix заключается в том, что путь к пакету по умолчанию основан на расположении исполняемого файла Windows, тогда как в Unix он основан на /usr/local/share/lua/5.1 . Поэтому проще выполнить установку Lua локальным пользователем в Windows, но Lua уважает переменные среды LUA_PATH и LUA_CPATH .

Lua в большей степени зависит от системных библиотек времени выполнения C, чем большинство языков сценариев, поэтому вы должны понимать различия в платформах. Используйте спецификатор "rb" с io.open если вам нужна совместимость с двоичным вводом-выводом Windows. Будьте осторожны с os.tmpname потому что он не возвращает полный путь в Windows (префикс со значением переменной среды TMP вместе с обратной косой чертой). os.clock реализован очень иначе в винде.

Точно так же os.time может привести к сбою Lua, если переданы несовместимые спецификаторы формата. (Это больше не проблема с Lua 5.2, который сначала выполняет проверки работоспособности.)

Для подсистемы графического интерфейса Windows os.execute может раздражать, а io.popen просто не работает - в этом случае доступны библиотеки кроссплатформенных расширений.

«как общее правило» - это не противоречит тому факту, что / в качестве разделителя каталогов отлично работает в Windows в Lua.

Это просто - для некоторых, включая меня, это не работает - вполне может быть, что у меня нет установки lua, подготовленной по обычному цитируемому рецепту (или что у меня также есть установка Cygwin).

Интересно - вы случайно не путаете обработку разделителей каталогов подсистемой lua (или, скорее, ее частью пакета), которая может быть настроена в любом случае (или, возможно, для чего-то еще, например, ' для RISCOS, очевидно!), Оболочки Windows cmd или powerline, которые будут принимать оба, или ядро ​​Qt C ++, которое также будет обрабатывать оба?

Меня до чертиков смущает, что должно работать для установки lua, скомпилированной на платформе Windows - ах, может быть, msys - это POSIX, а mingw - Windowish?

Нет, это не так, и именно поэтому использование / в LuaGlobal.lua работает для многих людей в Windows в его текущем состоянии ...

Разделители путей здесь не проблема.

Предположительно, интерпретатор lua в mingw от Qt правильно настроен для Windows и использует ту же библиотеку liblua, с которой связано приложение Mudlet (я полагаю, это может быть не для всех). Например, luarocks предоставляет интерпретатор lua 5.1, который он может использовать, если другой не найден, но по тому же признаку ~ it ~

💡 Ах, интересно, @Kebap, что вы получите, если попытаетесь получить значения package.config в той настройке, которая выдает ошибку? Например, для меня в командной строке в моей запущенной системе:

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

Обратите внимание на первое значение / которое является текущим разделителем каталогов, который будет использоваться при загрузке пакетов - например, файл LuaGlobal.lua ! Конечно, без запуска / доступности внешних lua-скриптов я не могу вспомнить, можно ли запускать что- то из «командной строки» в Mudlet. Я попробую запустить свой ноутбук Doze позже и посмотрю, что у меня получится ...

Конечно можно попробовать:

Похоже, есть обратная косая черта там, где у вас была прямая косая черта

Не уверен, стоит ли мне попробовать это в Mudlet, так как вы, кажется, использовали другой способ и место ..?

Я мог бы создать нового пользователя или двух со специальными символами и без них, просто чтобы убедиться, действительно ли имя пользователя является проблемой. Как вы думаете, это полезно?

Да, пожалуйста, попробуйте

В среду, 25 апреля 2018 г., 18:48 Кебап, [email protected] написал:

Я мог бы создать нового пользователя или двух со специальными символами и без них,
просто чтобы убедиться, действительно ли здесь проблема с именем пользователя. Ты думаешь
это полезно?

-
Вы получили это, потому что прокомментировали.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Mudlet/Mudlet/issues/1616#issuecomment-384355980 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAGxjN9JHbiPCOgUf3u1u8jVg0KjDiSbks5tsKj3gaJpZM4TZAbQ
.

Насколько я понимаю, код пробует все предложенные места для файлов LuaGlobal.lua и, наконец, достигает того, где пытается:

LUA_DEFAULT_PATH "/LuaGlobal.lua"

однако из полученного сообщения об ошибке кажется, что LUA_DEFAULT_PATH - это пустая строка, поэтому используемый путь:

/LuaGlobal.lua

предполагая (и я все еще не убежден, но, надеюсь, это всего лишь моя проблема), что '/' ЯВЛЯЕТСЯ рабочим разделителем каталогов там, где он используется, это означает поиск файла в корне файловой системы - на POSIX-файлах, которые буквально корень, а в Windows это корень на текущем активном диске, вероятно, C:\ (или C:/ : wink :) - если мы действительно хотим, чтобы это был текущий рабочий каталог, тогда LUA_DEFAULT_PATH должен быть одним символом . и не должен быть полностью пустым - в этом случае сообщение об ошибке либо вернет:

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

или, если он возвращает полный путь, возможно, что-то вроде:

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

может быть? 😮

Я вижу, что сообщение об ошибке интерпретатора lua фиксируется в std::string и отправляется в cTelnet::postMessage( ... ) через преобразование std::string::c_str() в const char * но поскольку postMessage ожидает QString это должно задействовать конструктор QString :: QString (const char str), который использует преобразователь QString::fromUtf8() поэтому символы не-ASCII * должны пройти через неповрежденные ... 😌

\

lua print(package.config)

из командной строки профиля Mudlet даже с полученной ошибкой.

Это немного умозрительно, но в качестве исправления во время выполнения мне интересно, можно ли сделать что-то вроде:

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

чтобы изменить разделитель на / - хотя вы можете изменить параметр "разделитель команд" в настройках, чтобы он не разделял указанное выше на ; - а затем посмотрите, сможете ли вы "запустить" файл LuaGlobal.lua вручную? О, это не приведет к появлению сообщений об ошибках типа [ ERROR ] если это не сработает. \

Подтверждена ошибка Mudlet 3.8.1 на Win 8.1 с именем пользователя со специальным символом: ä.
Нет ошибок с именем пользователя без специальных символов.

lua print(package.config) без видимого результата
lua print('test') тоже без видимого результата
lua псевдоним доступен, но print не кажется
lua echo('test') работает должным образом

Бежал lua package.config = "/;?!_"
Журнал ошибок говорит: ERROR:[string "Alias: run lua code"]:4: [string "package.config = "/"]:1: unfinished string near '<eof>'

Изменен разделитель команд с; к чему-то другому

Бежал lua package.config = "/;?!_"
Хорошо, я думаю? Результат невидимый

Ран lua run("./LuaGlobal.lua")
Журнал ошибок говорит: ERROR:[string "return run("./LuaGlobal.lua")"]:1: attempt to call global 'run' (a nil value)

Тест с include - та же ошибка.

lua require("./LuaGlobal.lua") - интересная ошибка:
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'

На всякий случай lua require("/LuaGlobal.lua")
Журнал ошибок говорит:
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'

Странно, что print не работает - я думал, что это был встроенный lua, но:

lua echo(package.config)

тоже должно работать.

Глядя на вывод первого рабочего примера, вывод ошибки пытается загрузить файл LuaGlobal.lua - давайте посмотрим, какие имена файлов и пути пробуются:

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

Я не был уверен, где должен находиться файл, поэтому я загрузил и установил двоичный файл 3.8.1 и обнаружил, что используется следующий путь:

C: \ Users \ Стивен \ AppDataLocal \ Mudlet \ app-3.8.1 \ mudlet-lualua

также с этой версией установщика Windows у меня есть следующее для package.config:

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

поэтому пути к нему должны использовать \ чтобы обработчик пакета работал IMO. Однако до сих пор не ясно, почему разные люди получают разные вещи.

Отредактировано: цитировать список путей с помощью `а не '

Почему некоторые пути являются моджибаке, а другие правильно отображают имя пользователя, должно быть потому, что они поступают из разных источников, а некоторые из них еще не поддерживают I18n должным образом - было бы полезно, если бы мы могли отследить их и исправить их с помощью Mudlet 4.0, но они могут быть не теми, над которыми мы контролируем. Обратите внимание, что это не может быть отображаемый код или шрифты, потому что все отдельные сообщения об ошибках проходят через тот же процесс, в котором они были созданы.

Чтобы быть уверенным, что я использовал ожидаемый экземпляр (как разработчик, у меня более одной копии на этом ПК), я переименовал файл и получил тот же результат:

Также я создал нового пользователя с символами, отличными от ASCII (и, вероятно, даже не с символами Latin1 / ISO 885901), и я могу подтвердить, что для этого пользователя все запутано точно так же - Mudlet не может видеть файл в:

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

но это может для

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

: sob:

Эти вопросы и ответы на Stack Exchange не звучат многообещающе.

Однако лицензированный MIT luawinfile Windows (компилируется только на mingw НЕ MSVC) переводчик имен файлов (преобразует имена файлов UTF-8 в / из UTF-16, который должен использоваться с API обработки файлов Windows) выглядит немного лучше - он обеспечивает замену для модуля LFS, который может принимать имена файлов и путей UTF-8.

Хорошая находка. Просто чтобы бросить это там, у нас уже есть https://github.com/starwing/luautf8 в Mudlet, есть ли что-нибудь в этом, что могло бы нам помочь?

SlySven, ваш список из 15 имен каталогов кажется неправильным. Например, 13 должно читаться как .\.dll а не ..dll

А, это мешает система разметки - в некоторых контекстах здесь обратная косая черта экранирует следующий символ, который необходим, например, если вы хотите показать меньше символа в обычном тексте, таком как этот "\ <", вы не увидите обратная косая черта там ... и я использовал одинарные обычные кавычки, а не кавычки кода - отредактировал, чтобы исправить кавычки.

luautf8 - это обработка строк UTF-8 - я не думаю, что здесь это поможет, поскольку luainfile специально предназначен для взаимодействия с обработкой файлов Windows (которая работает только со строками UTF-16) C или, что более вероятно, библиотека C ++ - похоже, что ей нужно либо обернуть, либо заменить lfs только в Windows (хотя я уверен, что не Cygwin) ...

Хм, но мы не используем lfs для загрузки LuaGlobal.lua , так как luainfile решит проблему?

Это не только замена lfs . Также есть замена для dofile и loadfile . Вероятно, нам нужно будет заменить наш вызов luaL_dofile вызовом lua dofile .

Отредактируйте, чтобы добавить: ссылки библиотеки luainfile (по умолчанию) на lua 5.3 ... Не уверен, жесткая это зависимость или нет.

Похоже, мы можем просто написать нашу собственную функцию luaL_dofile которая будет работать со специальной кодировкой Windows?

Как мы можем продвигать это вперед?

Я поднял проблему в репозитории luawinfile, спрашивая о совместимости 5.1, но я взглянул, и на самом деле он использует некоторые языковые функции 5.3, которые не предоставляются lua 5.1 - есть отдельный официальный модуль совместимости 5.3, который пытается предоставить некоторые из недостающих функций в 5.2 и 5.1, но это не без некоторых других сложностей, так что это не капля решения.

Кажется, связано с # 229

Как мы можем продвигать это вперед?

Нам потребуется выполнить резервное копирование лицензированного MIT https://github.com/cloudwu/luawinfile (один файл C, содержащий около 884 строк кода {808 soc} кода) с 5.3 до 5.1, чтобы учесть некоторые функции, отсутствующие в более ранней версии. версия lua, которую использует Mudlet. Думаю, для этого потребуется кто-то, кто лучше разбирается в кодировании на lua-C, чем я чувствую до сих пор. Однако кажется, что это можно сделать и протестировать независимо, не беспокоясь об остальной части кода, хотя на самом деле это можно протестировать только на платформе разработки Windows.

Другая проблема заключается в том, что люди не могут сохранять свои профили в окнах с неанглийскими именами пользователей - история не записывается. Не думайте, что у нас есть на это билет.

@SlySven
Возможно, вы узнали кое-что во время своих недавних исправлений по доставке международных писем в Mudlet, чтобы решить эту проблему?

Не совсем, я действительно думаю, что обратное портирование luawinfile на Lua 5.1 дает нам лучшую надежду, но я просто недостаточно хорошо понимаю (пока?) C/C++ + lua API, чтобы быть уверенным в моей способности сделать это. Есть еще кто-нибудь? Думаю, нам нужно просмотреть код официальной библиотеки Lua io и посмотреть, как luawinfile заменяет некоторые (все, я не знаю?) Функций на специфичные для Windows замены.

Как люди, возможно, заметили, моя основная платформа разработки для Windows не самая подходящая (ноутбук с Windows 7 с 64-разрядным процессором, но с 32-разрядной версией) - на моем основном ПК также установлена ​​64-разрядная Windows 7, но с тройным загрузки машина не работает , что ОС в течение нескольких месяцев , так что я несколько часов смотрел на «Обновление Windows ... не выключать» экран смотреть вперед , и я не то, что мотивированы, банкомат!

Хотя теперь, когда он-лайн установщик Qt наконец-то переключился на установку только 64-битной Mingw64 Windows, по сравнению с предыдущей 32-битной только Mingw, я мог бы подумать об этом, если у меня есть несколько часов, чтобы выбросить. ..

Хорошо смотритесь...

Это благодаря https://gist.github.com/Egor-Skriptunoff/2458547aa3b9210a8b5f686ac08ecbf0, который был создан в начале года.

Будет доступно в Mudlet 3.22.