1nd1g0, Может на будущем пакете Lazarus работать будет под FPC x64.

Ivann, да я, в принципе, считывал структуру и так (не знаю, всю ли, правда), если знать, что она в 2 раза больше и каждое поле тоже в 2 раза больше (то есть Integer = 8 байт, а не 4, например). Но теряюсь в догадках, они вообще это исправлять собираются, или у них в приоритете x64 и не колышет, изгаляйтесь как хотите.

Можно с Int64 попробовать
------------ Дoбавленo в 17.42:
Но даже пытаться не стану

Или удвоить количество полей, каждое второе из которых, если обнаружена работа под WOW64, считать ненужным.

Интересно посмотреть, что будет в режиме совместимости и как себя ведут готовые программы с RI, например, эмуляторы игровых приставок и аркадных автоматов и игры, работавшие с несколькими клавиатурами и мышками (есть игра, где можно играть... в восьмером на одном ПК )) )

А что, MSDN молчит по этому вопросу

Ты уже много сделал с шаблоном IC и юнитом RI. Тема RI интересна в силу отсутсвия штатного DirectInput - это единственный способ относительно просто и без ложновирусных проблем ловить почти все устройства ввода в системе, нестандартные кнопки на мышках, клавиатурах, планшетах и ноутбуках (включая жесты на тачпадах). На планшетах даже данные с датчика положения в пространстве ловить можно.[offtop] Круче только прямая работа с HID. Там вообще можно ещё и свои данные слать, например, вибратор в джойстике или руле включить. Или станком с ЧПУ управлять по USB...[/offtop]
------------ Дoбавленo в 18.15:

В самой последней статье от 5/10/2011 у этих чудиков ни слова про это.
У них даже про возможность двух разных представлений структуры (для интерпретируемых и неинтерпретируемых языков) нихрена нет, только в комментариях кто-то добрый отписался с примером кода, который компенсирует искажения структуры при использовании структуры при передаче данных между средами. Про размерность данных вообще ничего, тем более - про такой нелепый косяк, когда библиотека user32.dll в 32-хбитной среде выдаёт 64-битные данные в буфер, выделенный под 32-хбитные.

Интересно, только зачем это нужно?

Что характерно, функция GetRawInputData, предназначенная для разбора этой структуры, из той же библиотеки, похоже ожидает ... 32-хбитные данные и, естественно, выдаёт полный бред.
------------ Дoбавленo в 18.24:

Это был просто наглядный пример. HID не ограничивается вибраторами, это система двунаправленных протоколов, позволяющая делать свои и работать с чужими (USB) HID устройствами самых разных назначений БЕЗ СОБСТВЕННЫХ ДРАЙВЕРОВ. Особенно актуально станет, когда везде будут ОС x64 с навязчивой подписью драйверов, а LPT и COM порты окончательно отомрут (всё к тому идёт, медленно, но верно). Если твоёчужое устройство совместимо с HID, то оно пользуется подписанными официальными драйверами от производителя ОС и работает под максимумом ОС с ними, то есть автоматически и под Linux (встроенная в ядро поддержка), и под MacOS, не обязательно с Intel-подобными процессорами.

1nd1g0, Посмотри размер структуры под x64 Я чуть со стула не упал

Вот-вот! И эту хрень они нам скармливают, приложению x86!

Это бред
------------ Дoбавленo в 18.30:
Причем каждый раз другой размер
------------ Дoбавленo в 18.31:
А в x32 стабильно 40 байт

В смысле? Сам проверь. Дамп структуры буфера если сделать.

1nd1g0, Размер структуры каждый раз разный

Пардон, теперь, после прочтения твоих дополнений, ясно, о чём ты [offtop]Форум был не доступен.[/offtop]

Та же фигня