- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
DWORD getDirectoryIndex()
{
STATIC_OBJECT_ATTRIBUTES(oa, "\\");
HANDLE hFile;
DWORD ObjectTypeIndex = 0;
if (0 <= ZwOpenDirectoryObject(&hFile, DIRECTORY_QUERY, &oa))
{
NTSTATUS status;
PVOID buf = 0, stack = alloca(guz);
DWORD cb = 0, rcb = 0x10000;
do
{
if (cb < rcb) cb = RtlPointerToOffset(buf = alloca(rcb - cb), stack);
if (0 <= (status = ZwQuerySystemInformation(SystemExtendedHanfleInformation, buf, cb, &rcb)))
{
PSYSTEM_HANDLE_INFORMATION_EX pshti = (PSYSTEM_HANDLE_INFORMATION_EX)buf;
if (ULONG NumberOfHandles = (ULONG)pshti->NumberOfHandles)
{
PSYSTEM_HANDLE_TABLE_ENTRY_INFO_EX Handles = pshti->Handles;
ULONG_PTR UniqueProcessId = GetCurrentProcessId();
do
{
if (Handles->UniqueProcessId == UniqueProcessId && Handles->HandleValue == (ULONG_PTR)hFile)
{
ObjectTypeIndex = Handles->ObjectTypeIndex;
break;
}
} while (Handles++, --NumberOfHandles);
}
}
} while (STATUS_INFO_LENGTH_MISMATCH == status);
ZwClose(hFile);
}
return ObjectTypeIndex;
}
ZOBJECT_ALL_TYPES_INFORMATION()
{
_TypeInformation = 0, _NumberOfTypes = 0;
if (DWORD DirectoryTypeIndex = getDirectoryIndex())
{
PVOID stack = alloca(guz);
OBJECT_ALL_TYPES_INFORMATION* poati = 0;
DWORD cb = 0, rcb = 0x2000;
NTSTATUS status;
do
{
if (cb < rcb)
{
cb = RtlPointerToOffset(poati = (OBJECT_ALL_TYPES_INFORMATION*)alloca(rcb - cb), stack);
}
if (0 <= (status = ZwQueryObject(0, ObjectAllTypeInformation, poati, cb, &rcb)))
{
if (DWORD NumberOfTypes = poati->NumberOfTypes)
{
if (OBJECT_TYPE_INFORMATION* TypeInformation = (OBJECT_TYPE_INFORMATION*)LocalAlloc(0, rcb))
{
_NumberOfTypes = NumberOfTypes;
_TypeInformation = TypeInformation;
STATIC_UNICODE_STRING_(Directory);
OBJECT_TYPE_INFORMATION* pti = poati->TypeInformation;
PWSTR buf = (PWSTR)(TypeInformation + NumberOfTypes);
int Index = 0;
do
{
if (RtlEqualUnicodeString(&Directory, &pti->TypeName, TRUE))
{
_firstObjectTypeIndex = DirectoryTypeIndex - Index;
}
DWORD Length = pti->TypeName.Length, MaximumLength = pti->TypeName.MaximumLength;
memcpy(buf, pti->TypeName.Buffer, Length);
*TypeInformation = *pti;
TypeInformation++->TypeName.Buffer = buf;
buf = (PWSTR)RtlOffsetToPointer(buf, Length);
pti = (OBJECT_TYPE_INFORMATION*)
(((ULONG_PTR)pti + sizeof(OBJECT_TYPE_INFORMATION) + MaximumLength + sizeof(PVOID)-1) & ~(sizeof(PVOID)-1));
} while (Index++, --NumberOfTypes);
}
}
}
} while (status == STATUS_INFO_LENGTH_MISMATCH);
}
}
Follow us!
Ааааа, опять пидорасы со своим Йодапетухом.
А присваивание в if это классика из K&R. Проблема в том, что идиоты суют это куда ни попадя.
* кресты дают
** в while - есть
А я потом думаю, какого хера компилеры не ругаются на присваивания в условиях.
Вот она крестопедерастия: сайд-эффект неявным конвертом погоняет.
Кстати в жабах похожая вайл гомосятина тоже в моде:
while (null!=(str=inputStream.readLine()))
Было б неявное преобразование в булеан писали б так, инфа 100%
while ( str=inputStream.readLine() )
Было бы счастье...
И как прикажете приводить строку к bool? true - Если ссылка не равна null?
К чему должны привестить во "вменяемой системе типов" такие значения, например: " TrUe ", "On", "Нет", "Maybe".
Параметр - строка.
Внутри - сравнение с образцом.
Напомнило библиотеку http://www.gamedev.ru/flame/forum/?id=170447 такой же бессмысленный и беспощадный пародийно-быдлоынтерпрайзный код.
Какая?
Плохо, что строки не контейнеры? - Ну, я не так понимаю качество. На мой взгляд, плохо, это когда система заведомо некогерентная. А в том, что если мы определили строку как список, и получили, что пустая строка = false, нет ничего плохого. Это непосредственно следует из определения. Есть задачи, где желательно иметь контейнеры, а есть - где лучше без них. Например, с контейнерами, когда пустые контейнеры вдруг оказываются разного типа становится очень неудобно жить. С другой стороны, без контейнеров тяжело со ссылками (как передать куда-то пустой список на модификацию?).
А Наутилиус Помпилиус наоборот пел.
Вот дальше уже становится интереснее, т.как в разных языках под строкой понимаются разные вещи. Где-то у строки есть контейнер, и тогда строка никогда не может быть ложью, либо контейнера нет, и тогда пустой список - одна из разновидностей строк, которая может быть ложью.
В сишкоблядских религиях под строкой может пониматься указатель на массив, и до нуля.
>Строку можно в таком случае описать как список из чисел.
Строку можно описать как указатель. 0 - false, остальное - true.
Но выше и ведется речь об том что это не есть хорошо. Пользы особой не вижу.
Ведь всё-равно понадобится какой-то parseBool.
P.S. А, понял, это драйвер.
нет это не может быть драйвером.
LocalAlloc в коде - уже usermode
память выделяется в стеке ( alloca ). а стека в ядре 3-5 страниц всего. а там 0x10000 как минимум выделяется. сразу bsod.
100% user mode
Во-первых таки да: не в стеке, а в куче. В-вторых дело не в количестве страниц, а в том что из ядра негоже обращаться к выгружаемой памяти. Потому для ядра есть специальный невыгружаемый пул (тоесть память которая никогда не засвапица на диск). Почему? Да потому что когда некто обращается к засвоплиной памяти, то случае page fault, обработчик которого запускается и загружает страницы в память. А это во-первых слишком долго для ядра, во-вторых код в ядре может выставить такой Interrupt Request Level, что обработчик пейджфолта обосрется с IRQ_NOT_LESS_OR_EQUAL и упадет в BSOD, как ты правильно сказал.
Так что в ядре мы почти всегда хотим работать с невыгружаемой памятью, а её (как ты правильно сказал) аллоцируют специальными функциями из WDK вроде ExAllocatePoolWithTag и иже с ними, а не LocalAllocом.
И вообще LocalAlloc это легаси говно мамонта времен когда были глобальные и локальные кучи отдельно (что-то времен Win16), а теперь вроде как надо юзать HeapAlloc.
if (cb < rcb) cb = RtlPointerToOffset(buf = alloca(rcb - cb), stack);
безусловно выделяет память в стеке а не в куче. и само название функции - http://msdn.microsoft.com/en-us/library/x9sx5da1.aspx и семантика выделения.
2)а в том что из ядра негоже обращаться к выгружаемой памяти... - безграмотный и идиотский бред
3)вызов LocalAlloc(0, cb) эквивалентен вызову HeapAlloc(GetProcessHeap(), 0x14000, cb) . так что никакой разницы с HeapAlloc
2) Што?;)
[quote]
Drivers use the NonPaged Pool for many of their requirements because they can be accessed at any Interrupt Request Level (IRQL). The IRQL defines the hardware priority at which a processor operates at any given time (there's a link to a document covering Scheduling, Thread Context and IRQL's in the Additional Resources section at the end of this post).
[/quote]. Речь конечно именно о драйверах, а не о ЛЮБОМ коде уровня ядра. (fixed)
3) да?
[quote]
The local functions have greater overhead and provide fewer features than other memory management functions. New applications should use the heap functions unless documentation states that a local function should be used. For more information, see Global and Local Functions.
[/quote]
по пунктам
1.)из ядра негоже обращаться к выгружаемой памяти - бред. возмите хотя бы любой запрос из юзер мода с буферами - как его выполнить если к выгружаемой памяти негоже обращаться D) ? большинство объектов ядро размещает в выгружаемой памяти. в невыгружаемой - только то что реально необходимо.
2.)Потому для ядра есть специальный невыгружаемый пул - ну и что ? paged pool(который гораздо больше чем nonpaged) тоже есть. ни и что ??
3.)А это во-первых слишком долго для ядра - а для не ядра, не слишком долго ? ) к чему все эти рассуждения ? что они доказывают ? да, память иногда выгружается в своп. при обращении к ней page fault (не важно из ядра или не ядра). если адрес корректный - страница загружается (скорость загрузки страницы не зависит от того, кто к ней обратился. и дальше что ??
4.)во-вторых код в ядре может выставить такой Interrupt Request Level.. - можно много чего сделать. НУ И ЧТО ??? вы увидели в данном коде игры с IRQL ?
так что код ядра постоянно обращается к выгружаемой памяти. если когда нибудь начнёте писать драйвера, а не просто читать msdn - может быть это поймёте.
3) да?
да! именно так ( LocalAlloc(0, cb) эквивалентен вызову HeapAlloc(GetProcessHeap(), 0x14000, cb))
если умеете пользоваться дебаггером и понимать asm - это очень легко увидеть. и это так от win2000 до win10
"The local functions have greater overhead" - в случае когда флаги равны 0 - фунции эквиваленты и нет никакого overhead.
кстати множество системных api - когда выделяют память сами (а пользователь должен затем освободить её) - то используют именно LocalAlloc(0, cb)
ну например:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379912%28v=vs.85%29.aspx (смотри CRYPT_DECODE_ALLOC_FLAG)
3) Вполне верю Вам что получившийся код одинаков.
Даже без дебагера можно прочитать "Starting with 32-bit Windows, GlobalAlloc and LocalAlloc are implemented as wrapper functions that call HeapAlloc using a handle to the process's default heap. "
Правда всё равно непонятно зачем использовать старое API, про которое сказано что "New applications should use другое API", кроме конечно случаев "documentation states that a local function should be used" (и это видимо как раз приведенный Вами CRYPT_DECODE_ALLOC_FLAG, где "..and the LocalFree function must be called to free the memory.").
Какой смысл объявлять API депрекрейтед черте-когда, и все равно предагать пользователю им пользоваться?
Короче говоря достаточно того что LocalAlloc лежит в kernel32.dll, и потому наврядли будет встречен в кернел-спейсе потому что в native его нельзя юзать, и никакие пулы тут не причем, верно?