Дружим Total Commander (64 bits) и plugins (32 bits)

Я расскажу вам про маленький проект, позволяющий использовать 32 битные версии расширений в 64 битной версии Total Commander-а (далее TC). Проект находится на стадии demo и позволяет использовать WCX модули с минимальным, необходимым набором функции (просмотр и извлечение содержимого архивов или все что можно представить в виде архивов). Ну и в конце опрос о востребованности такого решения и доведения проекта до некого уровня, покрывающего всю возможную часть API и все возможные категории модулей.

Постановка задачи и её решение

Модули для TC представляют собой DLL фалы имеющие расширения WCX, WFX, WLX, WDX и содержащие определенный набор экспортируемых функций (согласно категории модуля). Все бы хорошо, только не все авторы позаботились об 64 битных версиях. А исходный код не доступен, как правило…

Вопрос — Можно использовать существующие 32 битные версии?
Ответ — Да, но не все так просто.

Если обобщить до загрузки динамической 32 битной библиотеки в 64 битный процесс, то окажется, что задача не нова и поиск решения в интернете не заставит ждать. Все сводится к созданию суррогатного процесса, способного загрузить библиотеку и взаимодействию с этим процессом посредством IPC (меж процессное взаимодействие). К исходникам TC у нас нет доступа и добавить механизм работы с суррогатным процессом мы не можем. Но можем создать библиотеку. Библиотека будет выдавать себя за модуль и общаться с суррогатным процессом, а тот в свою очередь будет дергать функции модуля и возвращать результат. И выгладить все это будет вот так:



С возможными вариантами IPC можно ознакомится на MSDN — Interprocess Communications. Для своего проекта я выбрал Pipes. Это возможно не самый быстрый способ, но он позволяет неявно следить за здоровьем суррогатного процесса. Если падает суррогатный процесс, то и разрывается канал pipe-а и наша библиотека узнает об этом. Далее описание происходящих процессов.

При подключении библиотеки

• генерация уникального имени для pipe-а
• создание pipe-а
• создание суррогатного процесса
• передача суррогатному процессу имени pipe-а
• ожидание и подключение клиента через pipe

Для генерации уникального имени воспользуемся функцией UuidCreate(). Она сгенерирует UUID(GUID). Преобразуем его в строку (UuidToString) и заполним путь для pipe. Создадим pipe(CreateNamedPipe) работающий в блокирующем режиме и передаче сообщений. Запустим суррогатный процесс (CreateProcess). Имя pipe-а передадим в качестве параметра командной строки. И будем ждать клиента (ConnectNamedPipe).

При отключении библиотеки

• отключить клиента от трубы
• завершить суррогатный процесс
• закрыть pipe (в общем освободить выделенные ресурсы)

Отключим клиент (DisconnectNamedPipe), завершим суррогатный процесс (TerminateProcess), закроем pipe и почистим ресурсы (CloseHandle)

При запуске суррогатного процесса

• получить имя pipe
• подключиться к pipe-у как клиент
• загрузить модуль
• ожидать сообщение

Подключимся к pipe-у (CreateFile) и сконфигурируем его на работу в блокирующем режиме и передачу сообщений. Загрузим модуль (LoadLibrary) и сохраним адреса экспортируемых функций (GetProcAddress). Войдем в цикл ожидания сообщений. В случае необходимости завершить процесс выйдем из цикла.

При завершении суррогатного процесса

• отключится от pipe-а
• выгрузить модуль

Отключимся от pipe-а (CloseHandle) и выгрузим модуль(FreeLibrary).

При вызове функции из библиотеки

• запаковать параметры в сообщение
• передать запрос через pipe
• получить ответ
• распаковать результат и выйти с функции

Вызов функции рассмотрим на примере

__declspec(dllexport) HANDLE __stdcall OpenArchive(tOpenArchiveData *ArchiveData)
{
        if (s_init && ArchiveData)
        {
                // serialize
                uint8_t *p = s_buff;
                SET_FUNC(p, OPENARCHIVE)
                SET_CALLTYPE(p, CALL_QUERY)
                SET_STR_A(p, ArchiveData->ArcName)
                SET_INT(p, ArchiveData->OpenMode)
                // send
                DWORD writeSize = p - s_buff;
                DWORD writedSize;
                while (WriteFile(s_pipe, s_buff, writeSize, &writedSize, NULL))
                {
                        assert(writeSize == writedSize);
                        // recv
                        DWORD readedSize;
                        if (ReadFile(s_pipe, s_buff, PIPE_BUFF_SIZE, &readedSize, NULL))
                        {
                                // deserialize
                                uint8_t *p = s_buff;
                                uint8_t func; GET_FUNC(p, func)
                                uint8_t callType; GET_CALLTYPE(p, callType)
                                if (callType == CALL_ANSWER)
                                {
                                        assert(func == OPENARCHIVE);
                                        GET_INT(p, ArchiveData->OpenResult)
                                        HANDLE r; GET_HANDLE(p, r)
                                        // result
                                        return r;
                                } else
                                if (callType == CALL_QUERY)
                                {
                                        CALL_PROC
                                }
                                assert(0);
                        }
                }
                ArchiveData->OpenResult = E_NOT_SUPPORTED;
        }
        return NULL;
}

OpenArchive — первая функция которую вызывает TC после загрузки модуля. Ей передается указательна структуру типа tOpenArchiveData.

typedef struct {
    char* ArcName;
    int OpenMode;
    int OpenResult;
    char* CmtBuf;
    int CmtBufSize;
    int CmtSize;
    int CmtState;
  } tOpenArchiveData;

Мы не можем передать указатель на структуру, процессы изолированны и не видят память друг друга. Мы так же не можем передать структуру просто скопировав её в сообщение, из за указателя на строку (ArcName) и выравнивания полей. Плюс некоторые поля предназначены для передачи данных в функцию (ArcName, OpenMode), а некоторые служат буфером для возврата результата (OpenResult), последние и вовсе не используются (Cmt*). Мы должны произвести маршалинг, т. е. преобразовать данные в формат пригодный для передачи. Для этого служат ряд написанных макросов SET_*. SET_INT записывает int как 32 битное число в буфер. SET_STR_A записывает в буфер признак валидности указателя на строку и в случае валидности записывает размер строки с терминальным нулем и массив символов на который указывает указатель. В начало буфера помещаются два значения: что это за функция и что это — запрос. Далее надо посчитать размер данных записанных в буфер и записать их в pipe. Подождать ответа от другой стороны. При получении ответа прочитать два значения: что это за функция и что это — ответ или запрос на исполнение функции обратной связи. Если это ответ, получаем результат, записываем часть в структуру и выходим из функции. Если это запрос на вызов функции обратной связи, получаем параметры для неё, выполняем, возвращаем результат и ждем очередного ответа (всё это спрятано в макросе CALL_PROC). Отдельно стоит упомянуть тип результата рассмотренной функции. Это HANDLE, но в действительности указатель. Он понадобится в качестве параметра для вызова остальных функции самим TC. Но значимость его играет роль только в пределах модуля. В 32 битных процессах указатель 32 битный, в 64 соответственно 64 битный. И создается он в 32 битном процессе. Поэтому преобразование его в 64 а потом в 32 не приведет к потере данных.
Две функции (SetChangeVolProc, SetProcessDataProc) регистрируют функции обратной связи в модуле. Мы со своей стороны просто запомним их, а передадим сам факт регистрации. Они понадобятся в CALL_PROC.

При получении сообщения

• получить сообщение
• распаковать параметры
• вызвать функцию из расширения
• запаковать результат
• передать сообщение с результатом

Цикл получения сообщений

        while (s_loop)
        {
                DWORD readedSize;
                if (ReadFile(s_pipe, s_buff, PIPE_BUFF_SIZE, &readedSize, NULL))
                {
                        // deserialize, process, serialize
                        uint8_t *p = s_buff;
                        uint8_t func; GET_FUNC(p, func)
                        uint8_t callType; GET_CALLTYPE(p, callType)
                        assert(callType == CALL_QUERY);
                        if (func == OPENARCHIVE)
                        {
                                tOpenArchiveData openArchiveData = {0};
                                GET_STR_A(p, openArchiveData.ArcName)
                                GET_INT(p, openArchiveData.OpenMode)
                                HANDLE r  = OpenArchive(&openArchiveData);
                                p = s_buff;
                                SET_FUNC(p, OPENARCHIVE)
                                SET_CALLTYPE(p, CALL_ANSWER)
                                SET_INT(p, openArchiveData.OpenResult)
                                SET_HANDLE(p, r)
                        } else
                        ...

                        ...
                        {
                                assert(0);
                        }
                        DWORD writeSize = p - s_buff;
                        DWORD writedSize;
                        if (!WriteFile(s_pipe, s_buff, writeSize, &writedSize, NULL) || writeSize != writedSize)
                        {
                                return -6;
                        }
                } else
                if (GetLastError() != ERROR_TIMEOUT)
                {
                        break;
                }
        }

Все приблизительно так же. Получим сообщение, выясним какую функцию просят вызвать, произведём процесс обратный маршалингу (GET_*), вызовем функцию, получим результат и отправим его библиотеке. В процессе вызова функции может произойти вызов функции обратной связи.

int __stdcall ChangeVolProc(char *ArcName, int Mode)
{
        uint8_t *p = s_buff;
        SET_FUNC(p, CHANGEVOLPROC)
        SET_CALLTYPE(p, CALL_QUERY)
        SET_STR_A(p, ArcName)
        SET_INT(p, Mode)
        DWORD writeSize = p - s_buff;
        DWORD writedSize;
        assert(WriteFile(s_pipe, s_buff, writeSize, &writedSize, NULL) || writeSize == writedSize);
        DWORD readedSize;
        assert(ReadFile(s_pipe, s_buff, PIPE_BUFF_SIZE, &readedSize, NULL));
        p = s_buff;
        uint8_t func; GET_FUNC(p, func)
        uint8_t callType; GET_CALLTYPE(p, callType)
        assert(func == CHANGEVOLPROC && callType == CALL_ANSWER);
        int r; GET_INT(p, r)
        return r;
}

Вызываются наши подставные функции, которые проведут связь (с библиотекой).

Все это сопровождается обработкой ошибок в виде аварийного завершения суррогатного процесса, подстановкой функций-заглушек и возврат дефолных значений.

Отрицательная сторона решения: все это замедляет скорость работы модуля.

Пожалуй на этом все…

Что осталось

В действительности есть еще целый ряд вопросов, для которых надо выбрать решения. Реализован только минимум в рамках demo. Набор функций в рамках модуля расширения несколько больше, а о доступных возсожностях модуля говорит таблица экспорта. Динамически подстраиваться по это нельзя. Не все понятно с WLX модулями, в частности взаимодействие с окном. И т.д.

С полным исходным кодом можно ознакомится по ссылке source. Собрать можно с помощью Pelles С for Windows. Полученные приложение и библиотеку надо переименовать в соответствии с модулем (пример: модуль msi.wcx, программа msi.exe, библиотека msi.wcx64) и положить рядом с модулем.

И хотелось бы узнать ваше мнение