xml2bpf

Все началось с того, что я заметил, что когда пользуюсь РУДом, часто не могу сразу выставить 100 % тяги в Ил2ЗС. Приходилось долго елозить РУДом прежде, чем удавалось выставить нужное значение. Я решил выяснить, не ли способа изменить кривую отклика так, чтобы в заданном месте оси была ступенька на кривой отклика. Т.о. встал вопрос об изменении кривой отклика оси. Выяснилось, что в драйвере от Dhauzimmer заявлена такая функциональность. Редактировать двоичный файл в шестнадцатиричном редакторе мне не хотелось. Я стал искать утилиту, которая могла бы задавать конфигурацию X45 в текстовом формате и конвертировать ее в двоичный файл. В HazardScript вообще ничего нельзя делать с осями. В XD-Profile можно вешать команды на точки оси, но нельзя изменять кривую отклика. SxScript вроде позволяет даже изменять кривую отклика оси, но он у меня свалился с непонятной ошибкой.

В конце концов я решил написать свой транслятор скрипта. От транслятора мне требовалась возможность делать все то, что позволяет драйвер. Встал вопрос от том, как именно задавать конфигурацию в тестовом формате. Я остановился на XML по следующим причинам:

1. XML-формат широко распространен
2. Для XML есть много готовых хороших парсеров, в т.ч. свободных
3. Не нужно изобретать еще один скриптовый язык, нужно только задать формат XML-документа
4. Пользователям будет гораздо полезнее познакомиться с XML, чем разбираться с еще одним птичьим языком.

Сказано - сделано.

Итак, утилита xml2pf была готова.

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

Я готов поделиться с общественностью своими наработками на следующих условиях.

ЭТО ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ НЕ ЗАЩИЩЕНО ПРАВАМИ

Это программное обеспечение и его исходные коды предлагаются для свободного
использования. Вы можете их свободно использовать, изменять и распространять.

Это программное обеспечение и его исходные коды распространяются в надежде,
что они будут полезны, но БЕЗ ВСЯКИХ ГАРАНТИЙ. ВСЕ ПРЯМО ВЫРАЖЕННЫЕ ИЛИ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ НАСТОЯЩИМ ОТВЕРГАЮТСЯ. Это включает, но не
ограничивается, гарантии ГОДНОСТИ ДЛЯ ПРОДАЖИ или ПРИГОДНОСТИ ДЛЯ
ИСПОЛЬЗОВАНИЯ ДЛЯ КАКИХ-ЛИБО ЦЕЛЕЙ.

THIS SOFTWARE IS NOT COPYRIGHTED

This software and source codes is offered for use in the public domain.
You may use, modify or distribute it freely.

This software and source codes are distributed in the hope that it will be
useful but WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
DISCLAIMED. This includes but is not limited to warranties of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Драйвер собран с помощью DDK для Win2k/XP, не уверен, что это будет работать с семейством Win9x.

От оригинального Dhauzimmer'овского архива отличается только файлом x36f.sys.

Исходники драйвера. Изменен только файл Axis.c
Все изменения находятся в функции AxisQueue.
Начало и конец добавленного кода помечены соответствующими комментариями.

Рекомендация.

После установки драйвера нужно сбросить его установки. Это делается через Control Panel в свойствах джойстика. Затем нужно откалибровать джойстик посредством calib.bat или calib2.bat. Не используйте виндовые средства калибровки.

RTFM!

Ай, молодчина, Санитар! Ща возьму и буду пробовать :)

Для "особо одаренных" типа меня, разжуйте что/как/куда ставить. Ничем кроме SST не пользовался для Х45.

Цитата:

---

Originally posted by Sanitar
Драйвер собран с помощью DDK для Win2k/XP, не уверен, что это будет работать с семейством Win9x.

От оригинального Dhauzimmer'овского архива отличается только файлом x36f.sys.

---

Родил лисапед ;). В топике "Saitek X45" Vintik уже давно давал всем патченный на тему осей драйвер.

Цитата:

---

Originally posted by loz@_e
Для "особо одаренных" типа меня, разжуйте что/как/куда ставить. Ничем кроме SST не пользовался для Х45.

---

Не умею я толково объяснять. Из всей этой работы для меня самым трудным было написать документацию. Согласен, получилось коряво, но на большее я не способен. Так, что RTFM и еще здесь: http://sukhoi.ru/forum/showthread.php?threadid=8848

Эх, может кто сам разберется и напишет документацию потолковее, да поподробнее, да еще на хороший английский переведет.

Цитата:

---

Originally posted by POMAH007
Родил лисапед ;). В топике "Saitek X45" Vintik уже давно давал всем патченный на тему осей драйвер.

---

Да, действительно, вот здесь
http://vega.dyndns.org/x36/
можно найти две оригинальные версии драйвера.
x36usb2105a.zip - с включенной поддержкой изменения кривых отклика осей
x36usb2105b.zip - с выключенной поддержкой изменения кривых отклика осей

Не рекомендую использовать версию x36usb2105a.zip, т.к. в ней при определенных условиях могут возникать две ошибки:
- разыменование нулевого указателя;
- деление на ноль.
Обе эти ошибки приводят к появлению синего экрана, поскольку драйвер работает в нулевом кольце защиты.

Предполагаю, что эти ошибки и вызвали появление версии x36usb2105b.zip

В моей пропатченной версии драйвера поддержка изменения кривых отклика осей включена, и эти ошибки исправлены (я надеюсь :) ).

Цитата:

---

Originally posted by Vorobey

В моей пропатченной версии драйвера поддержка изменения кривых отклика осей включена, и эти ошибки исправлены (я надеюсь :) ).

---

Не понял :confused:
Sanitar == Vorobey ? :rolleyes:

Цитата:

---

Originally posted by POMAH007
Не понял :confused:
Sanitar == Vorobey ? :rolleyes:

---

Ну да, я же докладывал на нашем сайте =FPS= в отделе кадров.

Продолжаю разбираться с драйвером. Выяснилось следующее.

1. Всего можно задать 32 dx-кнопки, если задать кнопки со значением >32, они будут восприниматься как кнопка dx32.
Увеличить количество dx-кнопок я пока не готов.

2. Кнопки dx29, dx30, dx31, dx32 имеют корреляцию с направлениями dx-POV. Данные по этим кнопкам пишутся в те же самые 4 бита, что и данные по POV.
Вывод: если вы задаете POV, не задавайте кнопки dx29, dx30, dx31, dx32 - толку не будет.
Таким образом, на данный момент имеем либо 32 dx-кнопки без POV, либо 28 dx-кнопок и POV.
Исправить это я пока не готов.

3. Не знаю что такое dx0.

4. Если вы задаете значения кнопки мыши, отличные от 1(левая), 2(правая), 3(средняя), будет использовано значение 0 (х.з. что это такое).
Задать большее количество кнопок мыши, симулировать колесико (или даже несколько) я пока не готов.

Да не нужно больше кнопок. Что действительно нужно, так это реализация Shift. То есть нужно при переходе в новый режим запоминать каким-то образом старый. В нынешней ситуации это невозможно. Соответственно, если у тебя есть несколько режимов, ну например Air2Air, Air2Ground и TOF/LDG/CRS и тебе позарез хочется сделать одинаковые кнопки для активации связи, то приходится делать целых три режима вместо одного шифтованного, что не есть гуд. А если основных режимов штук шесть или девять(как у меня в Фэлконе), то вообще труба...

xml2bpf позволяет задавать все то же, что и бинарный файл. Фактически, xml2bpf является конвертором из текстового формата в двоичный. Т.о. xml2bpf позволяет делать все то, что позволяет делать драйвер.

HazardScript и XD-Profile позволяют задавать режимы с шифтами, делают они это средствами драйвера и никак иначе. Значит именно драйвер позволяет задавать такие конфигурации, а значит и xml2bpf.

xml2bpf является более низкоуровневым средством по сравнению с HazardScript и XD-Profile, и следовательно более многословным. Это издержки свободы и гибкости.

Ниже пример конфигурации с 27 режимами: 9 основных и по 9 модификаций для каждого из двух шифтов.

Я не тестировал эту конфигурацию (нет возможности, я сейчас на работе), только проверил на отсутствие синтаксических ошибок.

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

А вот пример "вложенного шифта".
Тоже не тестировал, только проверил отсутствие синтаксических ошибок.

Переключение режимов с помощью оси оставляю в качестве самостоятельного упражнения. :D
Вот только надо ли оно? :D

Кстати, еще можно менять кривую отклика оси в зависимости от режима.
Тоже оставляю на самостоятельную проработку. Я не пробовал.

А можно скомбинировать: вешаем на некоторую точку оси команду смены режима, а в новом режиме меняем кривую отклика этой оси. Что получится ? Х.З. Может и драйвер с синим экраном скрючит, а может и что полезное выйдет. Экспериментируйте, потом расскажете. :)

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

Пардоньте, это как же??? Я что-то пропустил? Не получается у меня в {D-Profile нормальный шифт сделать. Нет там такой возможности...

Наверное, я слишком сильно обобщил, думал, что HazardScript и XD-Profile позволяют делать шифты.

Как делать разные шифты с помощью xml2bpf я показал.

Однако, справедливости ради, нужно заметить, что каким скриптом не пользуйся (в т.ч. xml2bpf), с этим драйвером нормальных шифтов не получить.

Приведу пример.
Доспустим у нас заданы 2 режима.
Режим 1 - обычный, а режим 2 включается и выключается при нажатии и отпускании pinkie.
В режиме 1 на trigger повешены пулеметы, а в режиме 2 - пушки.
Рассмотрим, что произойдет при следующей последовательности действий:
1) нажали pinkie: драйвер переключается в режим 2
2) нажали trigger: драйвер "нажимает" кнопку, отвечающую за стрельбу из пушки, допустим dx1
3) отпустили pinkie: драйвер переключается в режим 1
4) отпустили trigger: драйвер "отпускает" кнопку, отвечающую за стрельбу из пулемета(!!!), допустим dx2; кнопка dx1 осталась нажатой!!! Т.е. боезапас пушки уходит в белый свет как в копеечку.

Тоже самое происходит при переключении режимов с помощью кнопок Mode 1-2-3, но там это как-то менее заметно.

Так что, если задаете шифты и режимы, при их переключении держите остальные кнопки отжатыми.

Вот за это я и не люблю шифты в этом драйвере. А м.б. я просто не умею их готовить :)

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

Вот пример грамотного шифта.

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

Кроме того, коль уж уважаемый Sanital залез в исходники драйвера, не сможет ли он сделать так, чтобы драйвер грузился в операционку со стандартным DirectX-овским профайлом?

Цитата:

---

Originally posted by Chist
По идее, посколько структура XML-файла повторяет структуру бинарного файла драйвера, должно быть не сложно сделать конвертор из бинарника в XML.
Я думаю, это значительно облегчит переход на XML-профайлы.

---

Интересная идея. Согласен, это было бы полезно. Проблема только в моей лени и недостатке времени. Дело в том, что то, что я сделал, было нужно мне самому, а bpf2xml - интересно, но необходимости в ней у меня нет. Может быть возмусь за это, но не сейчас. Пустых обещаний давать не буду. Мне тоже хочется играть, а не писать утилиты :). Прошу принять это без обид.

Возможно, кто-то другой захочет заняться этим?

Цитата:

---

Originally posted by Chist

Кроме того, коль уж уважаемый Sanital залез в исходники драйвера, не сможет ли он сделать так, чтобы драйвер грузился в операционку со стандартным DirectX-овским профайлом?

---

Во-первых, см. выше замечание о моей лени, недостатке времени, и желании поиграть. Опять без обид. :)

Во-вторых, я не понял вопроса. Что значит "чтобы драйвер грузился в операционку со стандартным DirectX-овским профайлом"? Дай, пожалуйста, пояснения. Это может оказаться полезным даже несмотря на "во-первых", может быть кто-то другой возьмется за это, или я когда-нибудь потом.

Во-третьих, на данный момент я не владею (в смысле знаний) технологией создания драйверов. Я в состоянии где-то что-то подкрутить, подмазать, подкрасить, но поменять внутреннюю архитектуру этого драйвера я пока не в состоянии.


И последнее. Грамотнее было бы использовать схему вместо DTD. Но мне было лень, мне и так хорошо :). Если кто возмется переделать - милости прошу.

Цитата:

---

Originally posted by Sanitar
Интересная идея. Согласен, это было бы полезно. Проблема только в моей лени и недостатке времени. Дело в том, что то, что я сделал, было нужно мне самому, а bpf2xml - интересно, но необходимости в ней у меня нет. Может быть возмусь за это, но не сейчас. Пустых обещаний давать не буду. Мне тоже хочется играть, а не писать утилиты :). Прошу принять это без обид.

---

Да, декомпозер для двоичных профайлов сделать можно, толко вот, когда делаешь XML профайл стараешься кнопкам и режимам осмысленные названия давать, а при декомпозиции bpf все эти названия будет просто неоткуда взять. То есть, оно бы неплохо, только вот нафиг надо... :)

Цитата:

---

Originally posted by Sanitar
Все-таки, скорее, я не умею их готовить. Но нужно будет больше возиться. В примере ниже это просто, а в реальной конфигурации все может оказаться гораздо сложнее.

Вот пример грамотного шифта.

---

Прости, не могу посмотреть твой профиль, но, блин... не верю!!! Понимаешь, я глубоко убежден, что драйвер не позволяет создавать шифты. То, чем мы сейчас пользуемся это просто переключатели режимов. Разницу чуешь? Ну, я имею в виду, что LOADMODE Some_Mode совсем не то, что LOADMODE Previous_Mode. Другими словами, драйвер должен иметь понятие о том, что же все таки такое previous_mode. А пока он об этом не знает, увы... А без этого нормального шифта не сделаешь... :rolleyes: :(

2 Miguel Gonsalez и всем, кому это интересно.

Да, никаких неразрешимых проблем с утилитой bpf2xml нет, дело только во времени и технике. Для нее даже libxml не обязательна.

Да, при реализации bpf2xml осмысленных имен не будет.

Жаль, что не можешь посмотреть примеры. Попробуй что-то вроде Open link in new window (или Tab). Попробую сформулировать основную идею словами, но боюсь, что получится очень коряво, пример более нагляден.

Техника создания шифта.
Да, шифты, как и режимы, создаются с помощью команды загрузки режима. Можно различать основные и шифтовые режимы. Шифтовый режим вызывается из основного путем мапирования команды загрузки шифтового режима на нажатие кнопки, назначенной быть шифтом. Возврат из шифтового режима в основной осуществяется путем мапирования команды загрузки основного режима на отпускание кнопки, назначенной быть шифтом. Поскольку известно, что данный шифтовый режим вызывается только из определенного основного режима, известно какой основной режим маппить на отпускание шифтовой кнопки, т.е. т.о. известно, что такое previous_mode. При этом важно не забыть вставить в команду переключения режима "command-event'ы" отпускания всех возможно смапленных конпок при переключении режимов, "command-event" собственно переключения режима должен идти последним в команде переключения режима. Это может оказаться доволно нудной (но не невозможной) задачей в случае сложной конфигурации.

Например, есть 3 основных режима m1, m2, m3 и соответствующая тройка шифтовых режимов s1, s2, s3. Шифтом назначен pinkie.
Тогда известно, что при нажатии pinkie
- в режиме m1 нужно переключиться в s1,
- в режиме m2 нужно переключиться в s2,
- в режиме m3 нужно переключиться в s3.
При отпускании pinkie
- в режиме s1 нужно переключиться в m1,
- в режиме s2 нужно переключиться в m2,
- в режиме s3 нужно переключиться в m3.

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

Хинт дня: команда может содержать не одно, а несколько элементарных действий, "command-event'ов".

Пример shift:
<?xml version="1.0"?>
<!-- X45 Script -->
<x45script>
<command_list>
<command value="load_mode_1">
<dx_button value="2" ><action value="release"/><time_delay value="0"/></dx_button>
<load_config value="mode_1"/>
</command>
<command value="load_mode_2">
<dx_button value="1" ><action value="release"/><time_delay value="0"/></dx_button>
<load_config value="mode_2"/>
</command>
<command value="dx1_press" ><dx_button value="1" ><action value="press" /><time_delay value="0"/></dx_button></command>
<command value="dx1_release" ><dx_button value="1" ><action value="release"/><time_delay value="0"/></dx_button></command>
<command value="dx2_press" ><dx_button value="2" ><action value="press" /><time_delay value="0"/></dx_button></command>
<command value="dx2_release" ><dx_button value="2" ><action value="release"/><time_delay value="0"/></dx_button></command>
</command_list>
<chain_list>
</chain_list>
<config_list>
<config value="mode_1">
<frobbable value="Trigger"><action value="press" /><mapped_command value="dx1_press" /></frobbable>
<frobbable value="Trigger"><action value="release"/><mapped_command value="dx1_release"/></frobbable>
<frobbable value="Pinkie" ><action value="press" /><mapped_command value="load_mode_2"/></frobbable>
</config>
<config value="mode_2">
<frobbable value="Trigger"><action value="press" /><mapped_command value="dx2_press" /></frobbable>
<frobbable value="Trigger"><action value="release"/><mapped_command value="dx2_release"/></frobbable>
<frobbable value="Pinkie" ><action value="release"/><mapped_command value="load_mode_1"/></frobbable>
</config>
</config_list>
</x45script>

2 Miguel Gonsalez
Примеры multimode и multimode2 открытым текстом дать не могу, т.к. енжина форума не дает возможности писать сообщения длиной более 10000 символов. На крайний случай давай почтовый адрес в приват - вышлю по почте.

P.S. Лучше в приват Санитару, я здесь чаще как Санитар бываю (с работы).

Хочу отдать должное Dhauzimmer'у. Этот человек дал нам драйвер, который по своим возможностям уступает только Cougar и CH, а в части конфигурирования кривых отклика осей даже превосходит их. То, что я исправил пару ошибок - дело техники, 0.1% от проделанной им работы.
В перспективе хочу написать новый драйвер, который по своим возможностям не будет успупать Dhauzimmer'овскому драйверу. Новый драйвер должен будет уметь изображать из себя несколько виртуальных джойстиков. Мне лично это даст опыт создания драйвера под Windows, можно будет написать еще одну строчку в резюме, т.е. некоторый стимул есть :). Для тех, кто не знает, сообщаю, что это достаточно высоко котируется в софтверной индустрии. Однако, я не обещаю, что даже начну эту работу, не говоря уже о ее окончании. На данный момент я только начал изучать DDK, причем очень не торопясь. Я не собираюсь менять работу в ближайшее время. Если эта работа когда-нибудь будет закончена, она также будет опубликована в public domain.

Цитата:

---

Originally posted by Vorobey
2 Miguel Gonsalez и всем, кому это интересно.
Поскольку известно, что данный шифтовый режим вызывается только из определенного основного режима, известно какой основной режим маппить на отпускание шифтовой кнопки, т.е. т.о. известно, что такое previous_mode.

---

Да нет же, нет!!! Не вызывается он только из одного режима. Задача сложнее, но ближе к реальности.

Цитата:

---

При этом важно не забыть вставить в команду переключения режима "command-event'ы" отпускания всех возможно смапленных конпок при переключении режимов, "command-event" собственно переключения режима должен идти последним в команде переключения режима. Это может оказаться доволно нудной (но не невозможной) задачей в случае сложной конфигурации.

Например, есть 3 основных режима m1, m2, m3 и соответствующая тройка шифтовых режимов s1, s2, s3. Шифтом назначен pinkie.
Тогда известно, что при нажатии pinkie
- в режиме m1 нужно переключиться в s1,
- в режиме m2 нужно переключиться в s2,
- в режиме m3 нужно переключиться в s3.
При отпускании pinkie
- в режиме s1 нужно переключиться в m1,
- в режиме s2 нужно переключиться в m2,
- в режиме s3 нужно переключиться в m3.

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

Хинт дня: команда может содержать не одно, а несколько элементарных действий, "command-event'ов".

---

Это все понятно. Именно так я и делал. Но это не то, что хочется. А хочется вот чего:
Имеем три основных режима - Air_To_Air(m1), Air_To_Ground(m2) и Cruise_Takeoff_Landing(m3). В каждом из них я хочу реализовать кнопку быстрого доступа к функциям связи. То есть мне нужен шифтовый режим Radio(s1), содержащий в себе раскладку кнопок для работы со связью. Естественно, при этом, если я вошел в этот режим при нажатии на шифт из m1, то при отпускании я должен в него и вернуться. А это невозможно, ибо я в s1 могу попасть как из m1, так и из m2 и m3!!! Пока у меня набор основных режимов ограничен (m1, m2, m3) - все нормально, хотя и геморройно и некрасиво. Просто реализуем три совершененно одинаковых режима Radio_Air_To_Air(s1), Radio_Air_To_Ground(s2) и Radio_Cruise_Takeoff_Landing(s3) и грузим их по мере необходимости, действительно не имея проблем с previous_mode. Но!!! В моем профиле для Falcon 4 таких основных режимов 9!!! Получается, что я должен тупо вбить еще девять режимов для радио. А смысл? Размер профиля при этом увеличивается, а функциональность почти не растет.

Да, без дублирования здесь не обойтись, таков драйвер. Геморройно конечно, но это работает.

Про мои намерения по отношению к драйверу см. выше.

Цитата:

---

Originally posted by Sanitar
Во-вторых, я не понял вопроса. Что значит "чтобы драйвер грузился в операционку со стандартным DirectX-овским профайлом"? Дай, пожалуйста, пояснения. Это может оказаться полезным даже несмотря на "во-первых", может быть кто-то другой возьмется за это, или я когда-нибудь потом.

---

Т.е. что б кнопки работали стандартно без заливки парофайла. Драйвер при загрузке грузится с пустым профайлом. Вот наполнить бы его стандартной DirtectXовской конфигурацией.

Цитата:

---

Originally posted by Sanitar
Во-третьих, на данный момент я не владею (в смысле знаний) технологией создания драйверов. Я в состоянии где-то что-то подкрутить, подмазать, подкрасить, но поменять внутреннюю архитектуру этого драйвера я пока не в состоянии.

---

А стректуру драйвера менять и не придется. Я так думаю...

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

Вообще, я думаю, Dhauzimmer не просто так пустой профайл вставил. Если бы была конфигурация по умолчанию, или профайл запоминался между перезагрузками компьютера, могли бы быть проблемы. Допустим пользователь составил такой профайл, что по нему драйвер вылетает с синим экраном. Тогда, если профайл не запоминается, спасает перезагрузка, а если запоминается - драйвер станет валить систему при каждой загрузке. С профайлом по умолчанию тоже могут выявиться свои сюрпризы. Нужно тщательно разбираться, а я играть хочу :)

Я сталкивался с тем, что после загрузки другого профайла (например, летали в Ил-2 - загрузили профайл для Ил-2, затем захотели полетать во Фланкер - загружаем Фланкеровский профайл), иногда возникали глюки (кнопки не работали, оси отлетали). приходилось перезагружаться. Может быть поэтому Даузиммер и не сделал загрузку профайла по умолчанию?

И я о том же говорю.

У меня пока глюков с драйвером не было, но это ничего не значит. Я написал себе профайл для Ил-2 и несколько примеров. Я не пишу профайлы целыми днями. :) Думаю, вполне возможны такие профайлы, от которых драйвер заглючит.

Интересно было бы посмотреть на твои профайлы, от которых так скрючивается драйвер. Пришли я посмотрю. Если найду причину и окажется, что нужно только мелкое исправление - подправлю.

query.exe -c

Такое пробовал? Не помогало?

Не, не пробовал. А скрипты могу выслать. Куда посылать?

2 arkady: см. приват