Bug 1660

Написан "пустой" тестовый драйвер, работающий в WinXP, и обращающаяся к нему программа. Драйвер создаёт файл устройства и обрабатывает вызовы CreateFile, DeviceIoControl и CloseHandle. Под Wine драйвер обрабатывает DeviceIoControl, а обработчики для CreateFile и CloseHandle не вызываются.

Драйвер собирался с помощью WinDDK в Windows.

Драйвер был модифицирован. Добавлены обработка IOCTL-запроса, при которой происходит получение дескриптора USB-устройства, и процедура AddDevice (её добавление вызвано необходимостью подключения к объекту устройства нижележащего драйвера). После модификации драйвер перестал корректно запускаться с помощью добавления записи в раздел реестра Services. По-видимому, надо создать inf-файл и установить драйвер для какого-нибудь USB-устройства.

Драйвер успешно установлен в Windows с помощью INF-файла. При обработке IOCTL_DESCRIPTOR_REQUEST_TEST он успешно получает vid и pid устройства.

Установка драйвера с помощью inf-файла в Wine, по-видимому, не поддерживается (нет "Диспетчера устройств" и не реализована UpdateDriverForPlugAndPlayDevices). Поэтому драйвер в Wine был уставновлен с помощью экспорта записей реестра, создаваемых при установке драйвера в Windows, и копирования файла драйвера в windows\system32\drivers.

Под Wine не выполняется AddDevice. В Windows она выполняется при добавлении устройства и при его включении.

Функции AddDevice необходимо передать в качестве аргументов указатели на объект драйвера (DRIVER_OBJECT) и на объект устройства (DEVICE_OBJECT) нижележащего драйвера. Экземпляр структуры объекта драйвера является глобальной переменной в device.c (programs/winedevice).

Принято решение реализовать вызов AddDevice через запросы к wineserver. Когда надо будет вызвать AddDevice, будет совершаться запрос к серверу с указанием имени драйвера, для которого надо вызвать AddDevice. winedevice будет периодически опрашивать сервер, есть ли запросы на выполнение AddDevice для драйвера с таким именем.

Вызов AddDevice реализован. Реализация неидеальна, AddDevice пока можно вызвать для каждого драйвера только один раз. Перед вторым вызовом AddDevice надо ещё раз загрузить драйвер.

Добавлено некоторое количество функций в ntoskrnl.exe (в основном это стабы), изменена функция IofCompleteRequest (теперь она вызывает IoFreeIrp). Загрузка драйвера и выполнение работающей с ним программы проходят без крэша wine.

Надо реализовать несколько функций для работы с IRP, IoAttachDeviceToDeviceStack и IofCallDriver. После этого можно будет приступать к доработке wineusb.

wineusb - сервис, который будет вызывать AddDevice для USB-устройств и, если необходимо, загружать драйверы. Сейчас он вызывает AddDevice для тестового драйвера.

Кроме того wineusb будет обрабатывать IRP, предназначенные для драйвера, расположенного в стеке под функциональным драйвером USB-устройства.

Небольшие изменения уже реализованных функций из ntoskrnl.exe. Начата реализация IofCallDriver.

Добавлена DLL wineusbhub. Она обрабатывает запросы к драйверу более низкого уровня. На данный момент работает получение выполняющимся в Wine WDM-драйвером VID и PID USB-устройства. При этом драйвер работает с первым попавшимся USB-устройством. В будущем wineusb будет сообщать драйверу, с каким устройством ему следует работать.

Имеется проблема с запуском драйвера. Программа может обратиться к файлу устройства до того, как он будет создан драйвером. Пока проблема решена переносом вызовов usb_init() и т.п. в DllMain wineusbhub.c.

Есть небольшой баг при получении размеров данных, передаваемых wineserver`у при запросе call_add_device.

Исправлен баг в запросе к wineserver.

Добавлены dlls/usbd.sys и несколько стабов в ntoskrnl.exe. Это позволило запустить драйвер ключа Eutron 3. Драйвер падает при выполнении AddDevice при записи по нулевому указателю:
0012:Call KERNEL32.InterlockedExchange(00000000,0011b970) ret=0056398e

Проблема с InterlockedExchange решена. Добавлено ещё несколько стабов. Теперь выполнение AddDevice для драйвера eusk3usb.sys (ключ Eutron 3) проходит до конца без падений.

Попробовал запустить тестовую программу из Гектор`а под Wine вместе с родным драйвером (кстати, проверил, что под Windows всё работает). Программа не находит ключа. При этом происходит обращение к создаваемому драйвером устройству Skey----. Подозрительно, что при этом в логах есть лишь вызовы KeWaitForSingleObject и KeReleaseMutex и нет, например, обращений к нижележащему драйверу с помощью IofCallDriver. Скорее всего это связано с неполным (или неправильным) заполнением структуры IRP. Происходит также обращение к отсутствующим устройствам SkeyDev0, ..., SkeyDev2. В Windows эти устройства драйвером не создаются (это можно увидеть с помощью DeviceTree), так что скорее всего это не является причиной проблемы под Wine.

В ntoskrnl.exe добавлено ещё несколько стабов. В programs/winedevice/device.c после AddDevice добавлен вызов MajorFunction[IRP_MJ_PNP] с IRP_MN_START_DEVICE. При его выполнении таки вызывается IofCallDriver. Но при обработке IOCTL драйвер пока ещё не хочет обращаться к ключу.

Немного модифицирован programs/winedevice/device.c (более корректное поведение при отсутствии USB-устройств и при неудачном завершении AddDevice). Реализовано получение дескриптора конфигурации (для случая num_altsetting == 1). Добавлено 2 стаба в usbd.sys.

Реализованы USBD_CreateConfigurationRequestEx и обработка URB_FUNCTION_VENDOR_DEVICE. Функция драйвера, обрабатывающая IRP_MN_START_DEVICE, теперь завершается нормально. Но тем не менее тестовая программа ключ по-прежнему не видит.

Добавил вызов IofCompleteRequest в обработчики IRP_MJ_INTERNAL_DEVICE_CONTROL и IRP_MJ_PNP в wineusbhub (драйвер, находящийся в стеке под драйвером USB-ключа). При этом для вызова IofCompleteRequest пришлось сделать обёртку, так как это fastcall-функция. Добавил вызов CompletionRoutine в IofCompleteRequest.

Добиться правильной работы обращающейся к драйверу тестовой программы пока не удалось. Возможно, стоит создать тестовый драйвер, создающий те же объекты устройств, запустить тестовую программу вместе с ним под Windows, посмотреть, какие структуры IRP получает драйвер, и воспроизвести их в Wine.

Надо как-то освобождать память, выделенную для IRP, например, с помощью IoBuildDeviceIoControlRequest. И делать это надо тогда, когда IRP уже никем не используется. Пока что в ряде случаев происходит утечка памяти.

Тестовая программа ключ не видит.

Написан тестовый драйвер, выводящий передаваемые ему структуры IRP, DEVICE_OBJECT и DRIVER_OBJECT.

Тестовый драйвер запущен под Windows. Теперь известно, какие функции Windows вызывает при инициализации драйвера. Соответственно изменена инициализация драйвера в winedevice. Улучшена реализация IoAttachDeviceToDeviceStack.

Тестовая программа ключ не видит.

Добиться работы тестовой программы с ключом Eutron пока не удалось.

Тестовая программа ключ не видит.

Пока не ясно, что надо изменить в Wine, чтобы тестовая программа не возвращала ошибку.

В IofCompleteRequest теперь освобождается память, выделяемая для IRP в IoBuildDeviceIoControlRequest.

Добавлены проверки на возврат NULL из функций выделения памяти в IoAllocateIrp и IoBuildDeviceIoControlRequest.

Попробовал запустить Инфо-Бухгалтер 8.5 с ключом Sentinel UltraPro. Инициализация ключа проходит нормально. Драйвер создаёт файлы устройств skeysusb и SntnlUsb. При запуске программы происходит обращение к RNBODRV0, SntnlUsb и NVKEYNT, удачно завершается, разумеется, только для второго. Для SntnlUsb несколько раз вызывается DeviceIoControl. При его обработке обращения к устройству не происходит. Инфо-Бухгалтер говорит, что ключ не обнаружен.

На машине с Windows кроме использовавшегося при запуске под Wine sntnlusb.sys есть ещё sentinel.sys и nvkeynt.sys. Я, правда, не уверен, имеют ли они отношение к данному ключу.

(In reply to comment #26)
> На машине с Windows кроме использовавшегося
> при запуске под Wine sntnlusb.sys есть ещё sentinel.sys и
> nvkeynt.sys. Я, правда, не уверен, имеют ли они
> отношение к данному ключу.
> 

For Windows NT, 2000 and XP (32-bit), Server 2003 (32-bit) and Vista (32-bit) the
following driver files will be installed in the C:\Windows\system32\drivers directory.
• Sentinel.sys (Sentinel parallel driver) and
• Sntnlusb.sys (Sentinel USB driver).

Драйверы Guardant и вспомогательные программы
Программы для управления драйверами:

INSTDRV.EXE – программа установки, конфигурации
и удаления драйверов.
INSTDRV.DLL – 16 битная библиотека, содержащая
функции API по управлению драйверами из
приложений.
INSTDRV.INI – конфигурационный файл.

Драйверы для Windows 95/98/ME:

NVKEY95.VX_         драйвер для Windows 95/98,
NVKEYU95.SYS        драйвер USB для Windows 95 OSR 2.x,
NVKEYUSB.SYS        драйвер USB для Windows 98,
NVKEY98U.SYS        вспомогательный драйвер USB для
Windows 98,
GSNUSB.IN_          служебный файл для драйверов USB.

Драйверы для Windows NT/2000/XP:

NVKEYNT.SYS         драйвер ядра,
NVKEYVDD.DLL        виртуальный драйвер для DOS,
NVKEY4NT.SYS        DOS драйвер устройства,
NVKEYUSB.SYS        драйвер USB для Windows 2000,
GSNUSB.IN_          служебный файл для драйвера USB

Кроме 2 упомянутых выше устройств драйвер создаёт ещё одно безымянное, для которого он вызывает IoAttachDeviceToDeviceStack.

Улучшена обработка запроса дескриптора конфигурации

Небольшие изменения в инициализации IRP и DEVICE_OBJECT.

Изменено выравнивание структур дескрипторов в usb100.h, чтобы их размер был как в Windows. После этого изменения sntnlusb.sys стал падать с такой ошибкой:

wine: Unhandled page fault on read access to 0xcd290b26 at address 0x7eb89d8e (thread 001b), starting debugger...
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7bc40674

Адрес 0xcd290b26 каждый раз разный.

Добавлена поддержка специфичных для конкретного устройства дескрипторов. sntnlusb.sys теперь не падает

В KeInitializeEvent структура события теперь инициализируется почти как в Windows. В посылаемых драйверам IRP irp.IoStatus.u.Status устанавливается в STATUS_NOT_SUPPORTED.

Добавил в тестовый драйвер вывод результатов обработки IRP_MN_QUERY_CAPABILITIES нижележащим драйвером.

Частично реализована обработка IRP_MN_QUERY_CAPABILITIES

Для идентификации USB-устройств теперь используются location из struct usb_bus и devnum из struct usb_device (это лучше использования vid и pid, так как позволит избежать проблем при исползовании 2-х одинаковых устройств). PDO для USB-устройств теперь именуются как в WinXP. При создании DEVICE_OBJECT теперь инициализируется поле Flags.

Под WinXP Инфо-Бухгалтер передаёт драйверу ключа Sentinel не такой код IOCTL, как в Wine

Если в WinXP отключить загрузку SENTINEL.SYS, то SNTNLUSB.SYS получает коды IOCTL такие же, как и в Wine.

В Windows в зависимости от 2 младших бит кода IOCTL используются различные методы передачи данных между вызывающей DeviceIoControl функцией и драйвером. Код 22001c, с которым Инфо-Бухгалтер обращается к драйверу, соответствует METHOD_BUFFERED. В Wine нет выбора метода передачи в зависимости от кода IOCTL и используемый метод не METHOD_BUFFERED.

Добавлена поддержка METHOD_BUFFERED в process_ioctl и URB_FUNCTION_VENDOR_INTERFACE в wineusbhub, добавлен KeResetEvent, а также произведено ещё несколько небольших исправлений.

Теперь работают Инфо-Бухгалтер с ключом Sentinel (драйвер sntnlusb.sys) и тестовая программа из Гектор`а с ключом Eutron (драйвер eusk3usb.sys). Для того чтобы пользоваться ключом, надо поместить его драйвер в system32/drivers и добавить в реестр запись о сервисе драйвера (в HKLM\System\CurrentControlSet\Services) и об устройстве (в HKLM\System\CurrentControlSet\Enum\USB).

Created attachment 482 [details]
Записи в реестре, необходимые для использования под Wine ключа Eutron с драйвером eusk3usb.sys

В какой сборке можно потестить сие чудо ?

Когда будет сборка, не знаю, но думаю, что скоро

Created attachment 485 [details]
Записи в реестре, необходимые для использования под Wine ключа SafeNet USB SuperPro/UltraPro с драйвером sntnlusb.sys

Сборка готова. На данный момент нужно проследить, чтобы были права доступа к usb-устройству ключа, ключ вставлен до запуска wine, а нужный драйвер лежал в system32/drivers

Начато написание тестов для включения патчей в оригинальный wine. Создана основа тестов для ntoskrnl.exe: драйвер и загружающая его программа.

Написал тест на обработку IOCTL. Правда, более-менее полноценно тестируется в нём только METHOD_BUFFERED, так как для тестирования METHOD_IN_DIRECT, METHOD_OUT_DIRECT и METHOD_NEITHER в Wine не хватает некоторых функций.

Написал несколько тестов для IofCompleteRequest. Тесты проходят на WinXP. Оказалось, что реализованное в eterhack поведение достаточно плохо соответствует поведению Windows. Изменил IofCompleteRequest и IofCallDriver, чтобы они соответствовали тестам.

Написан тест для IoAttachDeviceToDeviceStack

Изменил Makefile.in тестов для ntoskrnl.exe. Теперь используемый в кросстесте драйвер собирается с использование библиотек из wine, а не из mingw. Оказалось, что при таком способе сборки нельзя использовать функции, определённые в ntoskrnl.exe.spec таким образом:
@ cdecl -private strcpy(ptr str) msvcrt.strcpy
Кросстест при их использовании не собирается. Зато теперь драйвер из кросстеста загружается и под Wine.

Сделал основу для тестов usbd.sys.

Написал несколько тестов для USBD_CreateConfigurationRequest

Написал тесты для USBD_CreateConfigurationRequestEx

Благодаря тестам выяснилось, что реализованная в eterhack USBD_CreateConfigurationRequestEx при определённых условиях зацикливается.

Реализована функция USBD_CreateConfigurationRequest

Несколько незначительных изменений:
winedevice: Add missing WINAPI.
winedevice: Call IRP_MJ_PNP handler only with IRP_MN_START_DEVICE.
wineusbhub: Simplify __wine_usbhub_dispatch_pnp.
include: Add IO_TYPE_* defines.
ntoskrnl.exe: Use IO_TYPE_* defines.
ntoskrnl.exe: Use debugstr_guid and debugstr_us.

Сделал и отправил в wine-devel@lists.etersoft.ru небольшой патч, удаляющий \ перед @ в spec-файле, чтобы потом не было проблем с синхронизаций с winehq, если они добавят usbd.sys.

Исправлена пара ошибок. Патчи "Fix pdo_info size." и "wineusb: Do not call AddDevice some times for one device." Ошибка, исправленная вторым патчем проявляется, если в реестре есть несколько записей об устройстве с одинаковыми vid и pid, но с различными instance id.

А как насчет поддержки gdi принтеров МФУ ? Sharp, Canon etc ?

p.s.
просто решил пока в отдельную багу не писать...

(In reply to comment #58)
> А как насчет поддержки gdi принтеров МФУ ?
> Sharp, Canon etc ?
Как до луны.
Проблема больше в отсутствии подсистемы для загрузки драйверов принтеров.

P.S.
А вопросы и не надо в отдельную багу писать, для этого support@etersoft.ru есть.

Я думаю, багу можно закрыть. Поставленная задача решена.

*** Bug 776 has been marked as a duplicate of this bug. ***