MIB_IFROW STRUCT wszName db 512 dup (?) ; имя интерфейса dwIndex dd ? ;516 индекс интерфейса dwType dd ? ;520 тип интерфейса dwMtu dd ? ;524 максимальная скорость передачи dwSpeed dd ? ;528 текущая скорость передачи в битах в секунду dwPhysAddrLen dd ? ;532 bPhysAddr1 dd ? bPhysAddr2 dd ? ;540 физический адрес интерфейса dwAdminStatus dd ? dwOperStatus dd ? ;548 Содержит текущий статус интерфейса dwLastChange dd ? ;552 dwInOctets dd ? ;556 Всего принято байт через интерфейс dwInUcastPkts dd ? ;560 dwInNUCastPkts dd ? ;564 dwInDiscards dd ? ;568 dwInErrors dd ? ;572 dwInUnknownProtos dd ? ;576 dwOutOctets dd ? ;580 Всего отправлено байт через интерфейс !!!!! dwOutUCastPkts dd ? ;584 dwOutNUCastPkts dd ? ;588 количество ненаправленных пакетов отправленных интерфейсом dwOutDiscards dd ? ;592 количество забракованных исходящих пакетов dwOutErrors dd ? ;596 количество исходящих пакетов содержащих ошибки dwOutQLen dd ? ;600 dwDescrLen dd ? ;604 bDescr db 256 dup (?) ;860 Наименование интерфейса (имя) MIB_IFROW ENDS invoke GlobalAlloc,GMEM_MOVEABLE,20480 mov [tcphand],eax invoke GlobalLock,eax mov [tcpmem],eax mov [reqsize],20000 invoke GetIfTable,[tcpmem],addr reqsize,FALSE mov esi,[tcpmem] add esi,4 assume esi:PTR MIB_IFROW а дальше уже понятно наверно
Чем дальше в лес, тем толще партизаны Почему скорость соединения например с Инетом полученная этим способом, совпадает со значением, показываемым Виндой, а количество отправленного и принятого траффика - нет, например: принято [edx].dwInOctets = 56716, а Винда показывает принято 57324. И для отправленного тоже есть разница, только отправленного Винда показывает чуть меньше Почему так?
хм действительно так но я не знаю даже почему может всякие там пропинговки в счет не идут ? да и принципиально ведь теряются даже не десятые а сотые процента а меня это устраивает
BLOWFISH Да это особо не мешает, просто хотелось знать, почему. И ещё один момент, может подскажешь? В каком формате выводится время последнего установления соединения: FILETIME, MS-DOS Time или ещё что? Ни под какое что-то не подходит, в т.ч. и GetTickCount тоже...
да я даже не вкурсе, както не интересовало, мне важно было только скорость и трафик а время я учитывал по другому. посмотри в msdn может что найдешь.
Я тут на одном немецком форуме только что нарыл такую инфу: Code (Text): dwLastChange Specifies the length of time, in centaseconds (10^-2 sec), that elapsed between January 1, 1601, and the last change of the operational status of the interface (connection). The value rolls over after 2^32 centaseconds. Блин, это ж надо было так зашифровать :-\ Единица времени в 100000 раз крупнее FILETIME.dwLowDateTime плюс к тому же и rollover каждые примерно 497 дней ( Т.е. у меня PrintDec [ebx].dwLastChange выдаёт на сегодняшний день и примерно на текущее время -1100862793. Теперь ещё надо попробовать подогнать под текущую дату. Маразма сплошная ... Трудно было им обычный FILETIME вставить. Попробовал в FILETIME перевести, что-то не очень срастается
а не легче ли будет крутиться в цикле пока нету соединения а когда оно повилось GetTickCount потом снова в цикле пока есть соединение и по окончании GetTickCount ?
cresta Крупнее она в 10000000 раз, FILETIME микрософт в наносекундах меряет Алгоритм перевода примерно такой: Code (Text): GetSystemTimeAsFileTime(&time); time/=10000000;//тут без 64х-битной арифметики не обойтись if(time.low<dwLastChange)//событие у нас было в прошлом time.high--;//поэтому исправим старшую часть time.low=dwLastChange;//ну а младшая часть у нас уже есть time*=10000000;
Black_mirror По-моему ты ошибаешься, не в наносекундах, а 100 нс- интервалах: The FILETIME data structure is a 64-bit value representing the number of 100-nanosecond intervals... Так что наверное, все-таки 2 порядка надо скинуть, единица для FILETIME равна 10^-7, но не 10^-9 BLOWFISH Можно конечно и так, но это несколько криво, да и необходимо все время программу крутить, чтобы не прозевать подключение
cresta Действительно ошибаюсь, я в какой-то книжке читал что в наносекундах меряется, нужно внимательно смотреть первоисточники 8)
Сделал так (правда не с 64 битной арифметикой, а просто через FpuLib) Code (Text): .data mulData db 10 Dup (0) ;для исходного divData db 10 Dup (0) ;для деленного на 100000 .code invoke GetSystemTimeAsFileTime,ADDR FTime lea eax,mulData m2m [eax],FTime.dwLowDateTime add eax,4 m2m [eax],FTime.dwHighDateTime mov eax,100000 invoke FpuDiv, ADDR mulData, eax, ADDR divData, SRC1_REAL or SRC2_DIMM lea eax,divData m2m FTime.dwLowDateTime,[eax] add eax,4 m2m FTime.dwHighDateTime,[eax] mov ecx,FTime.dwLowDateTime cmp ecx,[ebx].dwLastChange jae @F dec FTime.dwHighDateTime @@: m2m FTime.dwLowDateTime,[ebx].dwLastChange m2m [eax],FTime.dwHighDateTime sub eax,4 m2m [eax],FTime.dwLowDateTime mov eax,100000 invoke FpuMul, ADDR divData, eax, ADDR mulData, SRC1_REAL or SRC2_DIMM invoke FileTimeToLocalFileTime,ADDR mulData,ADDR FTime invoke FileTimeToSystemTime,ADDR FTime,ADDR STime PrintDec STime.wHour PrintDec STime.wMinute PrintDec STime.wSecond PrintDec [ebx].dwLastChange
invoke GlobalAlloc,GMEM_MOVEABLE,20480 mov [tcpmem],eax invoke GlobalLock,eax mov [tcpmem],eax mov [reqsize],20000 invoke GetIfTable,[tcpmem],addr reqsize,FALSE mov esi,[tcpmem] add esi,4 assume esi:PTR MIB_IFROW invoke MessageBox, 0, addr [esi].wszName, NULL, MB_OK Сори, почему не работает? =)
.wszName - вроде Unicode, как-то надо в нормальный вид привести. Пробовал lea ecx,[esi].wszName invoke WideCharToMultiByte,CP_ACP,NULL,ecx,-1,ADDR AnsiBuff,256,NULL,NULL Что-то нихрена не получается, кракозяблы одни По форумы искал, нашел только тут от q_q процедуру, что-то тоже не получается... http://www.wasm.ru/forum/index.php?action=vthread&forum=4&topic=7423
base64 дело в том что после вышеизложенной операции в esi помещается информация полностью по всем интерфейсам, поэтому add esi,860 и так далее пока не будет нужной инфы. а вообще читай msdn
