Довольно давно пользуюсь драйвером WinIO для доступа к портам. Проблем не возникало.

Но тут понадобилось организовать прямой доступ к памяти и появились траблы.

1. Прога, при обращении к памяти через этот драйвер временами просто тихо вылетала без ошибок.
   
   Этот вопрос удалось разрешить, когда обращения к памяти стал выравнивать по границе 4 байта.
   
2. Некоторые участки памяти при помощи этого драйвера считать никак не удается -- функции чтения возвращают ошибку. Как бороться -- непонятно.
   
3. Обратиться к памяти за границей 8000 0000h никак не получается. Если старший бит 32-х битного адреса равен 1, то все попытки записи возвращают ошибку. Причем, я использую заведомо беззнаковый тип LongWord для передачи параметров. Что за ерунда такая ? При этом тот же HWDIRECT со своим собственным драйвером прекрасно читает и пишет в сей диапазон (выше 2 Гигов).

Собственно, вопросы:

• Кто сталкивался с такими проблемами при использовании WinIO ? Как выкрутились из ситуации ?
  
• Может посоветуете какой-нибудь более продвинутый бесплатный драйвер для тех же целей (свободный доступ к памяти, в том числе за границу 2Гб; обращение к 32-х битным портам). Желательно с документацией. Если найдется соответствующий интерфейсный юнит для Дельфи, то будет вообще замечательно!

PS: Небольшое пояснение: Естественно, 4-х гигов памяти у меня нет. Обращения провожу по адресам в диапазоне F000 0000h ... FFFF FFFFh, закрепленном за "Ресурсами системной платы" в Диспетчере устройств.

xKVtor Видимо тут дело в том, как драйвер маппит память. Ведь все адресное пространство разделено на двое до 0x80000000 - адреса для пользовательских процессов, свыше 0х80000000 - для драйверов (область системное памяти).
1. Писать самому. 2. Стырить драйвер из сорцов CrystalCPUid.

Daemon



Звучит правдоподобно. Но границы драйверов/недрайверов в районе 8000 0000h, наверное, скорее логическая, чем физическая (ведь не на каждой машине по 4Гб стоит).



Насчет "стырить" идея интересная. Но оба варианта достаточно трудоемкие.

Все еще надеюсь, что найдется готовое свободнораспространяемое решение.

Кстати, WinIO тоже с исходниками идет. Но мне от них ни холодно, ни жарко, т.к. в сях я не разбираюсь.
Было бы замечательно, если бы кто пограмотнее меня заглянул в них.
Может для решения проблемы можно будет банальным патчиком обойтись...

xKVtor значит так
Да, это диапазон виртуальных адресов. Но вся фишка в том, что тебе доступ к физической памяти на прямую - никто не даст. Вместо этого физ. память маппиться в какое-то виртуальное адрессное пространство. Что и делает WinIo, как я посмотрел методом вызова ZwMapViewOfSection - собственно этот метод доступен даже из юзер мода и stargaz0r об этом в этом форуме писал. Так вот эта функция возвращает виртуальный адрес из всего диапазона. И если у тебя вылетает программа, значит тебе вернули адрес свыше 0x80000000. Может криво объяснил, но на самом деле причина в этом.
Я размахавшись шашкой решил немного пропатчить WinIo. Думал использую MmMapIoSpace - и все будет ОК, но не тут-то было, она как правило возвращает виртуальный адрес из системного пространства. Драйвер же не может выделять память в пользовательском пространстве, только в системном. Остался старый опробованный метод - IoAllocateMdl, затем MmProbeAndLockPages, а потом MmMapLockedPages (т.е. создаем маппинг, маппа участка физ памяти, но тут есть возможность явно указать в какой области памяти (пользовательской или системной) будет создаваться мапп). Но не все гладко:

1. В связи с сохранением интерфейса с WinIo, приходиться выкручиваться, довольно сильно
2. Метод работает, но в юзер моде доступно только 80 байт из замапленого пространства, но думаю это я решу.

Добавлено спустя 4 минуты, 17 секунд
PS можно просто написать драйвер, который будет копировать в буфер, предоставляемый юзер модным приложением, участок физ памяти, а также записывать в физ память. Но ведь интересно все-таки иметь дело с памятью напрямую, а не гонять куски памяти через DeviceIoControl.

xKVtor
для работы с ФИЗИЧЕСКОЙ памятью в винде есть соответствующее у-во в дереве объектов.
секция \Device\PhysicalMemory...
Добавлено спустя 1 минуту, 34 секунды
далее - рекомендую скачать с http://irazin.ru/Some.htm
С. Шрайбер, "Недокументированные возможности Windows 2000" (Англ., 24 949 Kb)
и Примеры к книгам С. Шрайбер, "Недокументированные возможности Windows 2000" (407 Kb)

xKVtor вроде бы работает, но заранее предупреждаю, что такой метод не очень безопасен Да и в целом WinIo немного ущербный, поскольку порты открывает через IOPM таблицу.
http://cp.people.overclockers.ru/cgi-bi ... =WinIo.rar
Если открыл маппинг (через MapPhysToLin), то не забудь закрыть его, иначе возможен BSOD (PFN_LIST_CORRUPTED) и долго открытым его не держи.

Daemon

Спасибо огромное!

Сегодня таки опробовал новый драйвер и спешу поделиться радостью: Get/SetPhysLong вроде работает.

До мэппинга пока еще не дошел.

Заметил, что драйвер немного "похудел". Надеюсь, не в ущерб функциональности.

Кстати, dll-ку я использовал старую (WINIO.DLL). Надеюсь, это не принципиально и больших проблем у меня в будущем не возникнет.

Еще раз СПАСИБО!

xKVtor Всегда пожалуйста
Get/SetPhysLong работают через MapPhysToLin. dll'ку можно юзать старую, потому как я сохранил совместимость.

Кстати предлагаю, более стабильное решение http://cp.people.overclockers.ru/cgi-bi ... Engine.rar
Писал сам, также есть версия для WinX64. Протестировал, вроде бы все стабильно. Интерфейсный модуль на паскале имееться. Сорцы будут доступны в новом релизе CPU Informer. Возможности - чтение/запись портов, MSR, чтение/запись физической памяти. Парольные MSR пока не читаються и не пишуться