1. USB-драйвер ldevusbu.sys (v5 от 09.04.08) из последнего lcomp (от 10.04.08) и эта же библиотека вызывают перезагрузку компьютера (все гаснет, компьютер перегружается) при работе с модулем E20-10 (рев.А). Сбой возникает при 2-3 запуске сбора или при изменении частоты сбора.

2. Этот же ldevusbu.sys (v5 от 09.04.08) при работе с предыдущей lcomp.dll (от 09.01.08) вызывает перезагрузку немедленно при первой же попытке обратиться к E20-10 (рев.А).

3. Новая lcomp.dll (v5 от 07.04.08) не работает с предыдущим драйвером ldevusbu.sys (v4 от 22.03.08) - не может загрузить биос в модуль E20-10 (рев.А).
Может быть это связано с появлением в библиотеке новой DIOC_SEND_BIOS, тогда почему это "обновление" приводит к нарушению работы?
!!!ОСТАВЬТЕ СОВМЕСТИМОСТЬ НОВЫХ БИБЛИОТЕК С СУЩЕСТВУЮЩИМИ ДРАЙВЕРАМИ.

4. В readme.txt для нового lcomp v5 написано:
"для модуля E20-10 реальное значение IrqStep и FIFO получается умножением на 8, те IrqStep=1024 реально 8192 и надо умножать все в своей программе.... драйвер умножает внутри себя..."
... и как по вашему программа должна догадываться какой драйвер установлен (4 или 5),
нужно или не нужно умножить IrqStep на 8?
Вы хотя бы понимаете, что это опять нарушение совместимости - по разному вычисляется размер буфера lcomp при одном и том же IrqStep?
А если завтра Вы "выпустите" другой драйвер, который умножает IrqStep на 16? Что опять придется перекомпилировать программу и гадать на кофейной гуще какие драйверы поставит пользователь?

Все как обычно - одно лечим (L-791), другое калечим (E20-10).
Видно слово СОВМЕСТИМОСТЬ у Вас не в почете.

В lusbapi v3.2 тот же драйвер ldevusbu.sys почему-то IrqStep на 8 не умножает.

1 не наблюдаю...вроде погонял только что и все в порядке...

2 и 3 связано с унификацией windows и linux кодов библиотеки, совместимость стараюсь сохранить на интерфейс библиотеки... по отдельности не выйдет.... но для 2010 маловат размер IrqStep в виде ushort, поэтому приходиться в рамках интерфейса умножать...может и на 16 если выйдет что 8 мало....

по 4-  в программе можно предусмотреть файл настроек и тюнить его в зависимости от версии драйвера..

Вобщем все сейчас в разработке идет, особенно часть для 2010 тк новая ревизия подключается...

Совместимость подразумевает не только интерфейс библиотеки, а еще и функциональную совместимость.
Какой смысл в интерфесной совместимости, если нет функциональной совместимости? Может и запуститься, но правильно работать не будет, а выяснить причины будет еще сложнее.

Допустим, что IrqStep в виде ushort маловат для чтения данных по USB на высоких частотах, но проблема не в самом IrqStep, а в размере буфера драйвера. Программы заказывают lcomp буфер определенного размера IrqStep*Pages и естественно считывают данные из буфера этого размера, а несовместимость получается из-за того, что драйвер использует буфер другого размера.
IrqStep здесь не играет роли, так как заполнение буфера отслеживается программами по переменной Sync, а как она меняется с шагом 1024 или 8192 уже безразлично.
Умножайте IrqStep в драйвере на что хотите, но СОХРАНИТЕ РАЗМЕР БУФЕРА, который заказывает программа = IrqStep*Pages, тогда останется совместимость и вашим пользователям не придется пределывать программы каждый раз, когда Вы решите в драйвере умножать IrqStep на что-нибудь.
Размер чтения данных по USB это внутреннее дело вашего драйвера, а программе (по вашей же идеологии lcomp) нужно только копировать данные из буфера известного размера, отслеживая его заполнение по счетчику.
Делите в драйвере Pages на то же число и это решит проблему совместимости.

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

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

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

Непонятно, что значит "обеспечить функциональную совместимость невозможно", если для любого устройства всего то и требуется отслеживать заполнение буфера драйвера по счетчику и копировать данные из этого буфера. Но для этого необходимо знать размер буфера и адрес счетчика.
Неужели "невозможно" обеспечить получение от библиотеки и драйвера реального размера буфера? Черт с ним с драйвером, пусть умножает IrqStep на что хочет, но программе он должен хотя бы сообщить буфер какого размера он будет заполнять.

Когда менялись интерфейсы lusbapi (при переходе с версии 2 на 3) никого не волновало, что "все старое совсем порушится". Какой смысл в сохранении совместимости интерфейсов, если все равно приходится перекомпилировать программы из-за нарушения функциональной совместимости. Может быть один раз очень хоршо подумать над изменением интерфейсов, чтобы потом не приходилось нарушать функциональную совместимость и не заставлять всех "минимизировать доработки"?

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

вобщем принял волевое решение заменить все типы USHORT на ULONG... все остальное кривизна и полумеры.... будем надеяться что этого хватит надолго. И версию на 6....

Эти изменения будут касаться только самой библиотеки lcomp или придется менять и драйверы  *.sys?
Можно ли будет ожидать, что версия 6 сможет работать с существующими драйверами ldevusbu.sys, например, из предыдущего lcomp от 09.01.2008 или из lusbapi 3.2?
Тоже тот же вопрос по PCI платам - придется ли менять сам драйвер ldevpci.sys?

За несколько дней 5-я версия возможно не успела "уйти в массы", может изменения сделать в ней без перехода сразу на 6-ю?

И еще пожелание - раз в библиотеке появились ресурсы, возможно добавить биосы плат и модулей в собственные ресурсы библиотеки и грузить их из ресурса при передаче пустой строки, как это делается в lusbapi?

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

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

Позвольте реплику по поводу

"вобщем принял волевое решение заменить все типы USHORT на ULONG..."

Вот выдача давно известной проги (забыл где лежит) для 64-битной системы:

Integer types:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8

Pointers:
sizeof(void*) = 8

Floating point types:
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16

Sizes from stddef.h:
sizeof(size_t) = 8
sizeof(ptrdiff_t) = 8

Откуда следует, что sizeof(long) = 8, те различается для 32 и 64 битных компов.

А вот sizeof(int) = 4 для всех, причем давно, причем для win64 тоже.

Поэтому предлагаю забыть традиции Borland,
и все long переделать в int. При этом всем наступит счастье!

P.S.
Замена ULONG, PULONG на простой unsigned int приводит к практически полной работоспособности драйвера в системе
Linux radio3 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC x86_64 x86_64 x86_64 GNU/Linux

как на Aphlon, так и на Core 2 Duo. А других сейчас и не сыскать вовсе.

ULONG в VC в Windows 4 байтовый как и long и int... а в Linux надо было просто typedef в stubs.h изменить на unsigned int.... а для 64 битности введено ULONG64...

Все верно, в Linux x86 тоже самое.
Однако, еще раз

sizeof(long) = 8 , причем как для Linux x86_64,
так и для windows 64 bit edition, поэтому все структуры, связанные с железом расползаются.

Вас сбило отсутствие русской версии windows ХР 64 bit edition. В таком случае можно попробовать на украинской версии (в multi lang такая есть, как есть сербская, белорусская), хотя этот теперь не актуально, т.к. wista 64 бит, вроде есть.

На счет stubs.н. К сожалению не только там. ULONG пролез и в драйвер в несколько мест, несмотря на родные u32 и u64.

ничего меня не сбило... в дистрибутиве лежат x64 дрова для XP... и я проверил размерности те что написал....