>>> Реально ли вырезать MZ-header целиком, и как-нить укоротить PE?
>> Насколько мне известно, полностью нельзя.

> Можно только в фасме сделать так:
> format PE GUI 5.0 at $10000 on 'null.stub'
> где "null.stub" — это файл, размером 0 байт.
> Вот.
stub - это dos-заглушка.
а разговор шел о заголовке. драйвера могут грузиться без ms-dos заголовка, но не win32-файлы. транслятор тут не причем. такова природа загрузчика

для интересу можете посмотреть
Xp 97byte и 157byte проги на
board.anticrack.de

замечания по статье "зарядка для ума: самый маленький РЕ"

> (ждем новый линкер)
уже есть ms link. позволяет создавать самые маленькие PE из всех других линкеров, которые к тому же еще и работают ;)


> Размер опционального заголовка, его (заголовок) можно сократить ;)
нельзя. выкинуть все ненужное с DATA_DIRECTORY можно, но вот системный загрузчик закладывается на ее полный размер и если не принять дополнительных предосторожностей будут кранты.

> Запихиваем несколько переменных прямиком в остатки dos stub
хотя old-exe заголовок вместе со всеми своими причиндалами и проецируется в память,
транслятор адресов загрузчика в w2ksp3 (другие не проверял) не может транслировать его адреса, т.к. работает только с таблицей секций, так что пихать в него служебные структуры
это смерти подобно. теоретически это возможно, но здесь "приживаются" далеко не все из
них, а только те, чей адрес загрузчику неинтересен.

> Таким образом, нам нужен ассемблер, который умеет делать бинарники
пародия на "линкер", собирающий obj в PE пишется с пол-пинка,
расписывать структуры файла вручную дольше. уже при создании двух-трех
файлов монтаж "линкера" себя вполне оправдывает

> Во-первых, в GPA_proc используется блок данных PEB для поиска базы kernel32.dll,
> указатель на который находится в регистре fs по смещение 0x30...
не надежно. в любой момент может измениться. лучше исходит из того, что дефлотный
обработчик SEH, который можно вытащить из fs:[0], смотрит в KERNEL32.DLL,
после чего останется лишь найти его базовый адрес, который должен быть кратен
64 КБ содержать MZ-PE заголовки. кода чуть-чуть больше, зато на 100% надежно.


> Если все сходиться, то переходим к массиву AddressOfNameOrdinals,
> с помощью которого ищем индекс массива AddressOfFunctions,
> в котором и находиться смещение функции относительно kernel'a.
при разбора импорта системных dll можно обойтись и без таблицы
ординалов, т.к. индекс в таблице имен всегда совпадает с индексом
в таблице адресов


> Значение полей этого заголовка не важно, ибо они не обрабатываются,
> если обнулены, а если не обнулены, то обрабатываются только жизненно важные поля.
загрузчик w2k проверят лишь "MZ" и извлекает указатель на PE, остальные поля его
вообще не интересуют, но другие загрузчики могут вести себя иначе, дотошно
проверяя все поля в соответствии со спецификацией

> Начнем с того, что тут есть очередной magic, неизвестно кому он нужен, правда
раньше это был тип процессора, сейчас правда процессоры иных типов
уже не используются и magic должен соответствовать I386. забавно, но сначала ms
ввела еще и 486, 586 но теперь она им отказала в поддержке.

> Несомненно важное поле SizeOfCode, которое определяет сколько будет выделено
> памяти для секции кода при загрузки приложения
а ты проверял? это поле вообще игнорируется и смысла никакого не имеет,
кроме того все линкеры его заполняют по разному. существуют две стратегии:
одна предписывает вычислять размер кода как сумму размеров всех секций,
имеющий атрибут "секция кода", независимо от наличия остальных атрибутов,
а другая стратегия говорит, что секция кода, это секция _только_ с атрибутом кода,
т.е. секция с атрибутами код + данные кодовой секций уже не считается.
как нетрудно сообразить это было сделано на тот случай, чтобы одни и те же секции
не были подсчитаны дважды - как код и как данные. причем, если у нас есть всего
одна "комбинированная" секция (код+данные) некоторые линкеры дезореентируются
и ставят sizeofcode и baseofcode в ноль, что саксь. хотя, как уже говорилось, системному
загрузчику на эти поля начхать.

> AddressOfEntryPoint я определял экспериментальным путем, ища свой код в отладчике...
это RVA адрес: если твой код в заголовке, то он равен сырому смещению точки входа
в файл, если же он в секции, то он равен va + (raw_ep - raw_off), где va - виртуальный адрес
начала секции, raw_ep смещение точки входа в файле, а raw_off - виртуальный адрес секции
в файле. кстати говоря, если направить точку входа прямо в ядро, такой файл будет
нормально исполнен и его можно будет еще сократить ;)

> FileAlignment очень капризно воспринимается многими загрузчиками... Установим в
> минимальное значение 512 байт, да и этого не соблюдем... Если ХР позволяет, то все ОК ;)
> ImageSize должен быть выровнен, но нам в принципе на него наплевать :)
в XP (и вообще в NT) минимальное значение равно 2, хотя меньше 20h я бы использовать
не стал. это частично описано в спецификации на PE и основано на том факте, что в NT
один и тот же загрузчик обслуживает как драйвера (а драйвера в NT это PE-файлы) и
аплеушные приложения. кстати, говоря, ms link такие файлы умеет формировать - для
этого нужно ему указать ключ /DRIVER
к "невыровненному" файлу предъявляются следующие требования: FileAlign == SecAlign
и виртуальные адреса всех секций равны физическим (вообще-то на самом деле правило
не настолько жестко, но подробно описывать стратегию загрузчика лениво, тем более,
что это уже описано в моей статье "внедрение в pe - путь воина", которая скоро выйдет
в сусадмине), причем если размер последний секции меньше imagesize, то винда уходит
в голубой экран смерти (во всяком случае w2ksp3), это-то с прикладного уровня!!!
да! в 9x невыровненные файлы не работают ;(

> Такой фокус не прокатит если вы делаете библиотеки, так как вам понадобиться как минимум
> таблица экспорта
если сделать файлу bind, экспорт не понадобиться. читайте описание на ms editbin

> для интересу можете посмотреть
> Xp 97byte и 157byte проги на
> board.anticrack.de
если бы они еще и работали ;)

157byte работает на чистом XP.

Замечания к замечаниям по статье "зарядка для ума: самый маленький РЕ"


> (ждем новый линкер)
уже есть ms link. позволяет создавать самые маленькие PE из всех других линкеров,
которые к тому же еще и работают ;)

да, я тоже люблю ml =)


> Размер опционального заголовка, его (заголовок) можно сократить ;)
нельзя. выкинуть все ненужное с DATA_DIRECTORY можно, но вот системный загрузчик закладывается на ее полный размер и если не принять дополнительных предосторожностей будут кранты.

а) о каком загрузчике ты говоришь??? К тому же если есть поле, то есть потенциальная возможность того что оно поддерживается;
б) DATA_DIRECTORY относится к опциональному заголовку ;)

IMAGE_OPTIONAL_HEADER32 STRUCT
  Magic                         WORD       ?
...
  NumberOfRvaAndSizes           DWORD      ?
  DataDirectory                 IMAGE_DATA_DIRECTORY IMAGE_NUMBEROF_DIRECTORY_ENTRIES dup(<>)
IMAGE_OPTIONAL_HEADER32 ENDS

> Запихиваем несколько переменных прямиком в остатки dos stub
хотя old-exe заголовок вместе со всеми своими причиндалами и проецируется в память,
транслятор адресов загрузчика в w2ksp3 (другие не проверял) не может транслировать его адреса, т.к. работает только с таблицей секций, так что пихать в него служебные структуры это смерти подобно. теоретически это возможно, но здесь "приживаются" далеко не все из
них, а только те, чей адрес загрузчику неинтересен.

У меня же работает ;) Ты говоришь о w2ksp3, а я о ХР. Вначале статьи было сказано, что все под ХР.

> Во-первых, в GPA_proc используется блок данных PEB для поиска базы kernel32.dll,
> указатель на который находится в регистре fs по смещение 0x30...
не надежно. в любой момент может измениться.

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

лучше исходит из того, что дефлотный
обработчик SEH, который можно вытащить из fs:[0], смотрит в KERNEL32.DLL,
после чего останется лишь найти его базовый адрес, который должен быть кратен
64 КБ содержать MZ-PE заголовки. кода чуть-чуть больше, зато на 100% надежно.

Я в курсах как это делается, но это не более надежно, чем то, что я предложил. К тому же по-короче и по-быстрее ;) А если говорить о том, что прога должна работать только на ХР - самый лучший вариант.

> Значение полей этого заголовка не важно, ибо они не обрабатываются,
> если обнулены, а если не обнулены, то обрабатываются только жизненно важные поля.
загрузчик w2k проверят лишь "MZ" и извлекает указатель на PE, остальные поля его
вообще не интересуют, но другие загрузчики могут вести себя иначе, дотошно
проверяя все поля в соответствии со спецификацией

Я все ручками тестил и у меня часто ничего не работало даже из-за неправильного стаба

> Начнем с того, что тут есть очередной magic, неизвестно кому он нужен, правда
раньше это был тип процессора, сейчас правда процессоры иных типов
уже не используются и magic должен соответствовать I386. забавно, но сначала ms
ввела еще и 486, 586 но теперь она им отказала в поддержке.

хм... а как бы влияло это поле на работу проги если бы оно работало =)

> AddressOfEntryPoint я определял экспериментальным путем, ища свой код в отладчике...
это RVA адрес: если твой код в заголовке, то он равен сырому смещению точки входа
в файл, если же он в секции, то он равен va + (raw_ep - raw_off), где va - виртуальный адрес
начала секции, raw_ep смещение точки входа в файле, а raw_off - виртуальный адрес секции
в файле. кстати говоря, если направить точку входа прямо в ядро, такой файл будет
нормально исполнен и его можно будет еще сократить ;)

что ты имеешь в виду под ядром? kernel32? и куда же его можно там направить, чтоб еще и работало? 8)

> FileAlignment очень капризно воспринимается многими загрузчиками... Установим в
> минимальное значение 512 байт, да и этого не соблюдем... Если ХР позволяет, то все ОК ;)
> ImageSize должен быть выровнен, но нам в принципе на него наплевать :)
в XP (и вообще в NT) минимальное значение равно 2, хотя меньше 20h я бы использовать
не стал. это частично описано в спецификации на PE и основано на том факте, что в NT
один и тот же загрузчик обслуживает как драйвера (а драйвера в NT это PE-файлы) и
аплеушные приложения. кстати, говоря, ms link такие файлы умеет формировать - для
этого нужно ему указать ключ /DRIVER
к "невыровненному" файлу предъявляются следующие требования: FileAlign == SecAlign
и виртуальные адреса всех секций равны физическим (вообще-то на самом деле правило
не настолько жестко, но подробно описывать стратегию загрузчика лениво, тем более,
что это уже описано в моей статье "внедрение в pe - путь воина", которая скоро выйдет
в сусадмине),
причем если размер последний секции меньше imagesize, то винда уходит
в голубой экран смерти (во всяком случае w2ksp3), это-то с прикладного уровня!!!
да! в 9x невыровненные файлы не работают ;(

интересно! жду статью.

> а) о каком загрузчике ты говоришь???
о системном. том самом который этот файл и загружает.

> есть поле, то есть потенциальная возможность того что оно поддерживается;
"...потеницально мы миллионеры, а практически у над дома две бл$ли ;)" посмотри на ulink - там уйма "обвязочного" кода, обеспечивающего поддержку "кастрированной" DATA_DIRECTORY. а теперь посмотрим в системный загрузчик и покажи мне где он проверяет размер DATA_DIRECTORY перед обращением к ней ;) и обрати внимание, что ms и багланд всегда юзают полную DATA_DIRECTORY, даже если ее целиком не используют и отнюдь не потому, что дураки там все.

> б) DATA_DIRECTORY относится к опциональному
заголовку ;)
ну и кто ж спорит ;) а ты не пробовал создавать файлы, где размер опционального заголовка не совпадает с заявленным концом DATA_DIRECTORY? попробуй. а потом посмотри код загрузчика и грязно выматерись ;)

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

> Ты говоришь о w2ksp3, а я о ХР. Вначале статьи было сказано, что все под ХР.
законный прием! я тоже под час злоупотребляю им, когда лень тестить всю осевую линейку. типа конфинигурацяия под которой это работает - оговорена, а большего вам и не обещали. однако, это не честно по отношению к читателю. я вот сильно сомневаюсь насколько полезны файлы FileAlignment == 20h, о которых кстати говоря пока известно далеко не всем, т.к. они работают только под NT-based системами, хотя доля рынка, занимаемая ими неуклонно растет, а 9x вымирает. а вот лично меня коробит, когда простешая утилита, чуть-чуть сложнее hello, world! занимает по меньшей мере 4-16 кил... но вырубать выравнивание это означает отсекать многих пользователей, что не есть хорошо ;( а уж закладываться на одну-единственную XP, это... хотя для разных там compo вполне сойдет, т.к. на них такие извращения как раз и демонстриуются ;)

> мы сами пишем прогу, поэтому знаем когда че в ней
> изменится. Изменить/затереть стандартный сех обработчик тоже возможно.
PEB вы тоже сами заполняете? ;)
а он в любой момент может претерпеть изменение.
если на то пошло - можно сделать файлу bind, выкинув весь импорт нафиг - это будет предельно компактное решение, которое только может быть (хоть и работающее не везде), или заюзать native-API - все равно этот файл под 9x работать не будет, так чего уж там останавливаться на пол-пути...

> Изменить/затереть стандартный сех обработчик тоже возможно.
ничего подобного! он всегда смотрим в KERNEL.DLL, это даже слегка документировано, и он не может быть изменен, т.к. это естественный его интерфейс.

> Я в курсах как это делается, но это не более надежно, чем то, что я предложил.
если ms изменит SEH то рухнет 100% программ, созданных компиляторами MS VC/borland во всяком случае те, что используют RTL, а на это ms никогда не пойдет.
PEB же она уже меняла. и не раз. ну ладно, хрен с ними, с исключениями. давайте искать импорт полностью вручную, спускаясь по 64 кб от половины адресного пространства вниз.

> хм... а как бы влияло это поле на работу проги если бы оно работало =)
если прога хочет 486, а ее запускают на 386, ей отказывают в загрузке.

> что ты имеешь в виду под ядром? kernel32?
> и куда же его можно там направить, чтоб еще и работало?
можно и в KERNEL32, но там мало постоянных мест - и будет работать только на одной машине, а начиная с 0x80000000 есть много более или мене постоянных структур, которые можно заюзать, хотя это и буде крутым извратом. еще можно передавать управление на библиотеки типа MFC фиксированных версий (младшие версии уже давно не обновляются, но поставляются с осью по дефлоту, так что закладываться на них все-таки можно)

>интересно! жду статью.
это хорошо, что интересно!
а статья выйдет в июне

посмотри на ulink - там уйма "обвязочного" кода, обеспечивающего поддержку "кастрированной" DATA_DIRECTORY. а теперь посмотрим в системный загрузчик и покажи мне где он проверяет размер DATA_DIRECTORY перед обращением к ней ;) и обрати внимание, что ms и багланд всегда юзают полную DATA_DIRECTORY, даже если ее целиком не используют и отнюдь не потому, что дураки там все

че-та я не понял, о каком "обвязочном" коде ты говоришь?
насколько я помню, у него там урезанная DATA_DIRECTORY, но системный загрузчик спокойно грузит такой файл.
а то, что что-то там падает при работе с таким файлом, это уже проблемы разработчика, который не предусмотрел такую ситуацию.
я когда писАл свой РЕ-вьюер, наступил как раз на эти самые грабли, и именно с ulink.exe :)

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

> че-та я не понял, о каком "обвязочном" коде ты говоришь?
исходников ulink'а у меня нет, а дизассемблерные листинги - громоздки. если что - обращайся непосредственно к самому Харону.

> насколько я помню, у него там урезанная DATA_DIRECTORY,
я не говорил, что кастрировать DATA_DIR нельзя, я лишь говорил, что при этом необходимо принять комплекс мер предостарожности

> но системный загрузчик спокойно грузит такой файл.
грузит. но системный загрузчик при обращении к DATA_DIR не провеяет ее границ, а импортирование функций всегда начинается с BOUND_IMPORT'a (во всяком случае в NT/98/W2K) и загрузчик рассчитывает увидеть в соотв. месте либо нули (BOUND'а нет), либо валидный поинтер, в противном случае ждите сюрпризов. в XP этот баг, возможно, исправлен. по слухам там исправлено много багов в загрузчике... но XP еще не настолько распростанена, чтобы отсекать все более ранние версии...

> а то, что что-то там падает при работе с таким файлом,
> это уже проблемы разработчика, который не предусмотрел
> такую ситуацию.
какого разработчика? разроботчика оси? разработчика данного файла? падает ведь не "что-то", падает данный файл при загрузчике в NT/W2K.

> я когда писАл свой РЕ-вьюер, наступил как раз на эти
> самые грабли, и именно с ulink.exe :)
там у него еще в IAT мусор ;)
а импорт берется руками ;))
причем, берется очень быстро, мудро и элегантно!

> з.ы. где вообще можно скачать новую версию юнилинка?
> я к нему на фтп лезу, а меня пароль спрашивают
лезешь, наверное, FAR'ом? ;)
ты не обидешься, если я попрошу тебя почитать любой фак по работе с ftp? :-)
имя юзера - anonymous (аноним в смысле), а пароль your_name@mail.ru, нормальные FTP-клиенты его сами подставляют, например, ReGet, т.к. это типичная организация входа на сервер, вроде сам сервер об этом и пишет, если ты не anonymous, но не знаешь пароля.

последнняя версия вроде бы 23.01 лежит на ftp. там же лежит doswin32 - эмулятор виндузы, работающий под dos и целиком помещающая на одну дискету вместе с far'ом - все wine и рядом не лежали. раньше он входил в ulink, но теперь это отдельный проект.
там же шикарный русификатор для 9x, рекомендую!

> а) о каком загрузчике ты говоришь???
о системном. том самом который этот файл и загружает.

я о том под какую ось ;) Мы щазз с тобой как китаец с киргизом спорим что лучше ;) я говорю об ХР.

> есть поле, то есть потенциальная возможность того что оно поддерживается;
"...потеницально мы миллионеры, а практически у над дома две бл$ли ;)"

знаю этот анекдот :)

посмотри на ulink - там уйма "обвязочного" кода, обеспечивающего поддержку "кастрированной" DATA_DIRECTORY. а теперь посмотрим в системный загрузчик и покажи мне где он проверяет размер DATA_DIRECTORY перед обращением к ней ;) и обрати внимание, что ms и багланд всегда юзают полную DATA_DIRECTORY, даже если ее целиком не используют и отнюдь не потому, что дураки там все.

никто и не говорит, что там дураки ;) но если есть возможность кастрировать DATA_DIRECTORY - я это делаю ;) Я жжж кастрировал - и все работало.

> б) DATA_DIRECTORY относится к опциональному
заголовку ;)
ну и кто ж спорит ;) а ты не пробовал создавать файлы, где размер опционального заголовка не совпадает с заявленным концом DATA_DIRECTORY? попробуй. а потом посмотри код загрузчика и грязно выматерись ;)

Что такое "заявленный конец DATA_DIRECTORY"? Если со стандартным концом (полный DATA_DIRECTORY), то пробовал ;) именно в статье и пробовал =)

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

расслабься. это просто разговор. незачем превращать это в базар с наездами ;) и не надо меня учить. приглядись к статье. там в начале сказано, что она не несет никакой практической ценности. Это просто развлекаловка для меня. Не более.

> Ты говоришь о w2ksp3, а я о ХР. Вначале статьи было сказано, что все под ХР.
законный прием! я тоже под час злоупотребляю им, когда лень тестить всю осевую линейку.

у меня просто не было такой цели ;) а так я попробовал "на всякий пожарный" почти всю линейку ;)

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

читателю наплевать на этот Кб, который мы съэкономим ;) - ему нужно, чтобы в нем разжегся азарт, интерес к проблеме. Подумай сам - кому серьезно нужен этот Кб??? В наш-то век многогигабайтных винтов ;) Это просто интересная тема. Я не обещал серьезной статьи. Если бы у меня было достаточно времени и желания (а это главное) - я бы подумал и о серьезной статье. Только у меня нет ни того ни другого ;) Не буду я тратить свое время на никому не нужную работу ;) Я делал это чтобы развлечься - и я достиг своей цели ;) Посмотри на комментарии. По-моему я заинтересовал читателя. И хоть в итоге получилось мягко говоря не очень (признаю, мало я поработал над оптимизацией, очень мало) - я добился своего. Я получил удовольствие от написания и по-моему развлек других, подкинув им задачку. Be easy ;)

я вот сильно сомневаюсь насколько полезны файлы FileAlignment == 20h, о которых кстати говоря пока известно далеко не всем, т.к. они работают только под NT-based системами, хотя доля рынка, занимаемая ими неуклонно растет, а 9x вымирает. а вот лично меня коробит, когда простешая утилита, чуть-чуть сложнее hello, world! занимает по меньшей мере 4-16 кил... но вырубать выравнивание это означает отсекать многих пользователей, что не есть хорошо ;( а уж закладываться на одну-единственную XP, это... хотя для разных там compo вполне сойдет, т.к. на них такие извращения как раз и демонстриуются ;)

А че такое compo? Я тоже хочу поизвращаться :)

> мы сами пишем прогу, поэтому знаем когда че в ней
> изменится. Изменить/затереть стандартный сех обработчик тоже возможно.
PEB вы тоже сами заполняете? ;)
а он в любой момент может претерпеть изменение.

как это в любой момент??? Кто его может изменить? зачем кому-то изменять список? если мы загружаем модуль - он добавляется в конец списка, если выгружаем, удаляется оттуда. Начало списка не изменяется. Или я не прав?

если на то пошло - можно сделать файлу bind, выкинув весь импорт нафиг - это будет предельно компактное решение, которое только может быть (хоть и работающее не везде), или заюзать native-API - все равно этот файл под 9x работать не будет, так чего уж там останавливаться на пол-пути...

А причем тут NA? В смысле системными вызовами пользоваться? sysenter бла бла бла... Как это в ntdll выглядит ;) Неплохая мысль, она мне вроде приходила в голову, но я благополучно про нее забыл =) Прям как в линухе будет - int 0x80 =)

> Изменить/затереть стандартный сех обработчик тоже возможно.
ничего подобного! он всегда смотрим в KERNEL.DLL, это даже слегка документировано, и он не может быть изменен, т.к. это естественный его интерфейс.

...
    _SEH  struct
     	 m_pSEH		dd	0
     	 m_pExcFunction	dd	0
    _SEH ends        
...
	assume fs: nothing
          mov eax, fs:[0]
          assume eax: PTR _SEH
	.while ([eax].m_pSEH!=-1)
		mov eax, [eax].m_pSEH
	.endw       
	xor ebx, ebx
;	mov [ebx].m_pExcFunction, 0
	mov dword ptr [ebx], ebx
exit: 	invoke ExitProcess, 0

Если раскомментировать строчку - стандартный обработчик не будет вызван - прога просто завершится ;)

> Я в курсах как это делается, но это не более надежно, чем то, что я предложил.
если ms изменит SEH то рухнет 100% программ, созданных компиляторами MS VC/borland во всяком случае те, что используют RTL, а на это ms никогда не пойдет.
PEB же она уже меняла. и не раз. ну ладно, хрен с ними, с исключениями. давайте искать импорт полностью вручную, спускаясь по 64 кб от половины адресного пространства вниз.

брррр... кто говорит о том, что мс изменит SEH? я говорю о том, что любой, кто имеет к нам доступ может так же свободно изменить SEH, как и список модулей из PEB'a

> хм... а как бы влияло это поле на работу проги если бы оно работало =)
если прога хочет 486, а ее запускают на 386, ей отказывают в загрузке.

не фига себе платформенная зависимость =) я понимаю почему мс от этого отказалась... Таких прог-то наверно и нет в природе :)

> что ты имеешь в виду под ядром? kernel32?
> и куда же его можно там направить, чтоб еще и работало?
можно и в KERNEL32, но там мало постоянных мест - и будет работать только на одной машине, а начиная с 0x80000000 есть много более или мене постоянных структур, которые можно заюзать, хотя это и буде крутым извратом. еще можно передавать управление на библиотеки типа MFC фиксированных версий (младшие версии уже давно не обновляются, но поставляются с осью по дефлоту, так что закладываться на них все-таки можно)

я наверно тормоз... Ну передадим мы управление в кудa-нить 8) и че? Исполнится это ["куда-нить"], а что дальше? Че-то не верится что можно передать управление в ядро... Ты проверял? Работает только из-под админа?

>интересно! жду статью.
это хорошо, что интересно!
а статья выйдет в июне

уже почти июнь =)

> Мы щазз с тобой как китаец с киргизом спорим что лучше ;) я говорю об ХР.
XP не юзал, там загрузчик еще более другой ;)

> но если есть возможность кастрировать DATA_DIRECTORY - я это делаю ;)
попытаюсь объяснить еще раз. возможности кастрировать DATA_DIR нет, ну или почти нет. наличие поля длины DATA_DIR и размера опционального заголовка (в спецификации!) еще не означает, что реально существующие загрузчики это поле вообще говоря учитывают. мы сейчас же не сферических коней в вакууме обсуждаем, верно?
BOUND обязан быть, т.к. загрузчик некоторых осей считает, что он есть всегда, интерпретируя соотв. поля как указатели.

> Я жжж кастрировал - и все работало.
"работало" на одной конкретно взятой ос, и возможно на одном конкретном содежимом файла. в общем случае бить DATA_DIR не желательно. а у Харона BOUND есть ;)

> Что такое "заявленный конец DATA_DIRECTORY"?
"тайна веков" (с) Пелевин.
что-то среднее между NumberOfRvaAndSizes и SizeOfOptionalHeader, эти поля нуждаются в синхронизации, которую мало кто проверяет.

> расслабься. это просто разговор. незачем превращать это в базар с наездами ;)
Уже и поворчать нельзя ;)

> читателю наплевать на этот Кб, который мы съэкономим ;)
> ему нужно, чтобы в нем разжегся азарт, интерес к проблеме
проблема в комбинировании секций и выкидывании RTL. чтобы создать предельно компактный файл, который только можно создать компилятором, попробуй переменуй main в my_main, а потом линкеру укажи My_main в качестве точки входа. файл сразу похудет кил на 50, а то и больше. тоже самое относится к DLL.
а еще есть комбинирование секций, которые так же сокращает размер файла, хотя и создает некоторые проблемы.
или множественное проецирование - кода одина часть файла проецируется более чем на один участок памяти (правда, обратное невозможно).
хитрые оверлени, размещенные в середине, техника разблокирования исполнеяемых файлов для внесения в них изменений (ну например, хранении конфигурации как это было в dos), да много чего можно сделать с линкером!
тот же Bind, о котором я уже упоминал или форвардинг функций, или обход "расщепления" страниц совместо используемых dll, модифицируемых перемещаемыми элементами?
а предельно компакнтный файл - это com/bin, вызывающий функции native API ну или на худой конец win32.

> Подумай сам - кому серьезно нужен этот Кб???
вот и я говорю. кому нужен 1 кб. а вот уменьшить размер 1 мб файла на полметра уже акутально ;)

> я добился своего. Я получил удовольствие от написания и по-моему развлек других, подкинув им задачку.
побольше бы таких статей, поменьше бы пинали винды ;)

> А че такое compo? Я тоже хочу поизвращаться :)
ну вроде ж намечается очередное, краем уха слышал, правда уже не помню где... там вроде конкус на самое компактное интро.

> как это в любой момент??? Кто его может изменить?
парни из ms. PEB это сугубо внутренняя структура. и она _уже_ менялась неоднократно...

> Кто его может изменить? зачем кому-то изменять список?
да он запросто в следующей оси может оказаться по другим смещениям или вообще будет исключен ;)

> если мы загружаем модуль - он добавляется в конец списка, если выгружаем, удаляется оттуда.
> Начало списка не изменяется. Или я не прав?
а ты задумайся - зачем NT этот список? он сейчас сохранен только по историческим соображениям, чтобы ось могла быстро выяснить, какими dll владеет процесс, но похоже, что он отмирает. поставь точки останова на него и посмотри когда, кто и при каких обстоятельствах его использует. будешь приятно удивлен ;)

> Если раскомментировать строчку - стандартный обработчик не будет вызван - прога просто завершится ;)
посмотри куда указывает fs:[0] в момент вызова программы

> я говорю о том, что любой, кто имеет к нам доступ может
> так же свободно изменить SEH, как и список модулей из PEB'a
"изменит" не в смысле "модифицирует в памяти", а ms пересмотрит формат данных. SEH - надежен, а вот на PEB в долговременной переспективе никакой здравомыслящих программист не рискует закладываться.

> Таких прог-то наверно и нет в природе :)
раньше были. я вперые NT устаналивал именно на 486, а пара моих товарищей и вовсе не 386, потому что других машин тогда просто не было. а теперь смотри, если в какой-то ветке программы встретится пневая инстукция, программа даст дуба, при этом все данные окажутся несохранены, а этого нормальная ось доступать не должна. вот и было введено поле требований минимального ЦП.

> Че-то не верится что можно передать управление в ядро... Ты проверял? Работает только из-под админа?
работает без прав админа, но с CPL3. обычно этим грешат черви, которые подменяются адрес возврата на инстукцию JMP ESP, которую можно легко найти в ядре...

> уже почти июнь =)
ждите сусадмина. скоро выйдет

> Мы щазз с тобой как китаец с киргизом спорим что лучше ;) я говорю об ХР.
XP не юзал, там загрузчик еще более другой ;)

я люблю хр =) по-моему лучшая ось из линейки... правда я w2003 server ни разу не видел, но из того, что видел - мне больше всего понравилось 8)

> но если есть возможность кастрировать DATA_DIRECTORY - я это делаю ;)
попытаюсь объяснить еще раз. возможности кастрировать DATA_DIR нет, ну или почти нет. наличие поля длины DATA_DIR и размера опционального заголовка (в спецификации!) еще не означает, что реально существующие загрузчики это поле вообще говоря учитывают. мы сейчас же не сферических коней в вакууме обсуждаем, верно?
BOUND обязан быть, т.к. загрузчик некоторых осей считает, что он есть всегда, интерпретируя соотв. поля как указатели.

опять "некоторых осей"... я жжж про хр говорю =) там загрузчик учитывает это поле, чем я и пользуюсь... конечно, в общем случае ты прав. я не спорю - это очевидно, что это поле обрабатывается не всеми загрузчиками, но хр-то это поле юзает ;)

> Что такое "заявленный конец DATA_DIRECTORY"?
"тайна веков" (с) Пелевин.
что-то среднее между NumberOfRvaAndSizes и SizeOfOptionalHeader, эти поля нуждаются в синхронизации, которую мало кто проверяет.

ясно =)

> расслабься. это просто разговор. незачем превращать это в базар с наездами ;)
Уже и поворчать нельзя ;)

:)

> читателю наплевать на этот Кб, который мы съэкономим ;)
> ему нужно, чтобы в нем разжегся азарт, интерес к проблеме
проблема в комбинировании секций и выкидывании RTL. чтобы создать предельно компактный файл, который только можно создать компилятором, попробуй переменуй main в my_main, а потом линкеру укажи My_main в качестве точки входа. файл сразу похудет кил на 50, а то и больше. тоже самое относится к DLL.

ну вот опять =) я жжж про ассемблер, а ты про vc судя по всему... к тому же выкинув эти самые 50 кило ты потеряешь многие возможности, предоставляемые компилятором... А по-моему, лучше уж в таком случае использовать ассемблер. Тогда и размер будет минимальный - 1 Кб и Сшные ф-ии можно заюзать просто импортировав <уж не помню какую :)> dll'ку из поставки vc и машинную оптимизацию можно будет использовать без извратов и перепалок с сшным компилятором... ну хотя все это звучит довольно субъективно (кто что лучше знает)... я бы сказал - это дело вкуса.

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


или множественное проецирование - кода одина часть файла проецируется более чем на один участок памяти (правда, обратное невозможно).

уххх ты... а это как? 8)

хитрые оверлени, размещенные в середине, техника разблокирования исполнеяемых файлов для внесения в них изменений (ну например, хранении конфигурации как это было в dos), да много чего можно сделать с линкером!
тот же Bind, о котором я уже упоминал или форвардинг функций, или обход "расщепления" страниц совместо используемых dll, модифицируемых перемещаемыми элементами?
а предельно компакнтный файл - это com/bin, вызывающий функции native API ну или на худой конец win32.

насчет com ты конечно загнул =) все com'ы обслуживает ntvdm и он есесно не даст вызывать Native API ;) Хотя... тоже широкое поле для изврата... в последнем номере 29а была статья Ratter'a о ntvdm ;)+Chemiker нашел пару интересных фишек ;)

> Подумай сам - кому серьезно нужен этот Кб???
вот и я говорю. кому нужен 1 кб. а вот уменьшить размер 1 мб файла на полметра уже акутально ;)

нуууу... честно говоря, я думаю, что и полметра невпечатлят неискушенного (а их 90% сети) юзера ;) Я имею в виду, если ты напечатаешь статью и распространишь ее по сети - мало программеров будут пользоваться этой техникой... и не только из вражденной лени, а потому что еще и юзеру это не так уж и надо... а если взять условия рынка, когда есть 2 программы одинаковые (А и Б) по возможностям и разные по размерам (А>Б) - неизвестно еще, что юзер выберет... зависит от ситуации... диалапщик конечно закатает ту, что поменьше, а вот чел в выделенкой еще подумает... программа с чуть большим размером выглядит "по-солидней" бла бла бла (типа скупой платит дважды ;))... так что неизвестно еще... да, это не говоря про то, что полметра в любом солидном приложении ничего не значат.

> А че такое compo? Я тоже хочу поизвращаться :)
ну вроде ж намечается очередное, краем уха слышал, правда уже не помню где... там вроде конкус на самое компактное интро.

ааа... типа конкурс демок? ;) щаззз на гугле поищу...

> как это в любой момент??? Кто его может изменить?
парни из ms. PEB это сугубо внутренняя структура. и она _уже_ менялась неоднократно...

ааа... ты про "от версии к версии"... опять же я про хр =)

> если мы загружаем модуль - он добавляется в конец списка, если выгружаем, удаляется оттуда.
> Начало списка не изменяется. Или я не прав?
а ты задумайся - зачем NT этот список? он сейчас сохранен только по историческим соображениям, чтобы ось могла быстро выяснить, какими dll владеет процесс, но похоже, что он отмирает. поставь точки останова на него и посмотри когда, кто и при каких обстоятельствах его использует. будешь приятно удивлен ;)

я и не спорю, что он может быть удален мс ;)

> я говорю о том, что любой, кто имеет к нам доступ может
> так же свободно изменить SEH, как и список модулей из PEB'a
"изменит" не в смысле "модифицирует в памяти", а ms пересмотрит формат данных. SEH - надежен, а вот на PEB в долговременной переспективе никакой здравомыслящих программист не рискует закладываться.

я и не надеюсь, что это будет работать на других осях... это уже сейчас не работает :), дык почему бы не воспользоваться ситуацией и PEB'ом если я и так делаю все очень платформозависимым ;)

> Таких прог-то наверно и нет в природе :)
раньше были. я вперые NT устаналивал именно на 486, а пара моих товарищей и вовсе не 386, потому что других машин тогда просто не было. а теперь смотри, если в какой-то ветке программы встретится пневая инстукция, программа даст дуба, при этом все данные окажутся несохранены, а этого нормальная ось доступать не должна. вот и было введено поле требований минимального ЦП.

круто... только забота ли это оси? спорный вопрос... cpuid может юзаться из 3го кольца - значит и прикладной программист ее поюзать может...

> Че-то не верится что можно передать управление в ядро... Ты проверял? Работает только из-под админа?
работает без прав админа, но с CPL3. обычно этим грешат черви, которые подменяются адрес возврата на инстукцию JMP ESP, которую можно легко найти в ядре...

блин, хочу попробовать... у тебя нет какого-нить сорса? если есть скинь пожалуйста на e_f_i_m@ rambler.ru

> уже почти июнь =)
ждите сусадмина. скоро выйдет

жду с нетерпением =) а где его заказать можно?

> я люблю хр =) по-моему лучшая ось из линейки...
вкусы бывают разные... у меня XP вызывает стойкое отвращение, побуждающее на переход в лагерь unix-based систем.
хотя... тендеция монстроузности проникла даже на спектурум. 128/258 кб современным кодерам мало, уже хотят, чтобы как минимум был установлен 1 мб. кошмар!

> опять "некоторых осей"... я жжж про хр говорю =)
ну не серьезно это привязываться к одной оси!
ты уверен, что установив очередной сервис-пак, ты не лишишь этим свои программы невинности? ;)
ладно, если тебе нужно быстро расчитать плотность поля в ванне с электролитом, тут можно и позвращаться...
знаешь, сколько раз я проклинал себя, когда "изращался" подобным образом, экономя пару байт из любви к искусству? это только сейчас кажется, что вот у тебя есть XP и ты с нее никуда не съедешь, а пройдет несколько дней и ты захочешь установить что-то другое?
впрочем, выбирать политику проектирования и кодирования - тебе, я даже не пытаюсь лезть со своими советами, просто обращаю внимание окружающих на то, что эти приемы далеко не везде работают...
а то как-то один кульный хакер (не буду показывать пальцем), однажды провозгласил, что сокеты это теже самые дескрпиторы и что их можно наследовать. вот с той поры неработчие эксплоиты и поперли. теоритически они должны давать удаленный щелл, практически я никак не могу найти ни одной выни, в которой это работает...

> ну вот опять =) я жжж про ассемблер, а ты про vc судя по всему...
ассемблер это, конечно, хорошо, но если можно создать столь же компактный код и на Си, почему бы им не воспользоваться? здесь ассемблер не дает абсолютно никаких преимуществ. те, кто сравнивают hello, world на ассемблере и на Си, просто не убивают у последнего RTL, если же его убить, результаты будет равны.

> к тому же выкинув эти самые 50 кило ты потеряешь многие возможности, предоставляемые компилятором...
и какие например? в Си завязка на RTL очень слабая. в Си++ без этого не работает RTTI, но я бы не назвал последнюю "многими возможностями компилятора". к тому же RTL нужна преимущество подсистеме ввода-вывода, остальные функции вызывать можно и без нее. ну во всяком случае можно юзать RTL самой системы, даром что ли она с ней идет ;)

> А по-моему, лучше уж в таком случае использовать ассемблер.
ну здрастье! на Си писать быстрее и удобнее, а если еще при этом писать эффективно не перекладывая заботу об оптимизации исключительно на компилятор, то полученный код навряд ли будет можно улучшить по скорости/эффективнсти даже на ~3% ~5%.
ассемблер использовать нужно с умом и не лезть с мотыгой на колхозное поле. но не нужно впадать в другую крайность, обрабатывая дачный участок ворованным трактором беларусь ;)
я горячо люблю ассемблер (хотя сейчас это давным-давно интерпретируемый код ;), но все же... это именно любовь, а не оголтелый фанатизм ;))

> Тогда и размер будет минимальный - 1 Кб
попробуй напиши программу, состоящую более чем из нескольких тысяч строк на асме и тогда ты поймешь, что соперничать с комилятором невероятно трудно (хотя и не невозможно). практически все большие проекты, написанные на асме написаны крайне небрежно и занимают ого-ого.

> Сшные ф-ии можно заюзать просто импортировав <уж не помню какую :)> dll'ку из поставки vc
MSVCRT.DLL наверное ;)

> уххх ты... а это как? 8)
очень просто - несколько секций своим raw offset + raw size ссылаются на один и тот же участок файла и он послушно проецируется куда нужно. например, тебе нужна некоторая стуктура данных и ее копия, тогда ты можешь не дублировать ее на диске, а "разножать" непосредственно в памяти. вполне законный прием.

> машинную оптимизацию можно будет использовать без
> извратов и перепалок с сшным компилятором...
все машинно-оптимизированное лучше выносить в отдельные библиотеки, сводя их объем к миним. а целиком оптимизировать все - понапрасну терять время.

> насчет com ты конечно загнул =) все com'ы обслуживает ntvdm и он есесно не даст вызывать Native API ;)
у com'а нативными будут 2F и 21, через которые можно дотянуться и до нативных функций ядра. читай брауна, он рулез ;)

> дык почему бы не воспользоваться ситуацией и PEB'ом если я и так делаю все очень платформозависимым ;)
не использовать потому, что не нужно ;) тогда уж лучше сделать bind.

> круто... только забота ли это оси? спорный вопрос...
> cpuid может юзаться из 3го кольца - значит и прикладной программист ее поюзать может...
будда тебе в помощь! cpuid появился лишь на пнях, а мы говорим о 386 и 486 машинах!
что забота оси, а что нет - сложный вопрос, но согласись, неплохо иметь в файле поле, описывающее требование к ЦП, коль скоро есть поля, описывающее требования к оси. ведь Функцию GetVersion программа и сама вызвать может, но... видишь ли тут как. программы обычно создаются компилятором и компилятору пихать код проверки ЦП не в радость, он лучше загонит требования к процу в поле, которые линкер перепихнет в целевой файл и которое проверит ось. чем тебе такая схема не нравится?

> блин, хочу попробовать... у тебя нет какого-нить сорса?
да какой там сорец? просто прыгаешь и все. естественно, на ту страницу на которую у тебя есть права доступа. сущестует несколько способов их заполучить. если интересно могу описать, но по-моему их все и так знают...

> жду с нетерпением =) а где его заказать можно?
прямо и не знаю. на сайт статью они вряд ли выложат.
остается поискать журнал по киоскам...

> опять "некоторых осей"... я жжж про хр говорю =)
ну не серьезно это привязываться к одной оси!
ты уверен, что установив очередной сервис-пак, ты не лишишь этим свои программы невинности? ;)
ладно, если тебе нужно быстро расчитать плотность поля в ванне с электролитом, тут можно и позвращаться...
знаешь, сколько раз я проклинал себя, когда "изращался" подобным образом, экономя пару байт из любви к искусству? это только сейчас кажется, что вот у тебя есть XP и ты с нее никуда не съедешь, а пройдет несколько дней и ты захочешь установить что-то другое?

я тебя очень хорошо понимаю, но я не собираюсь делать какие-то важные программы с помощью моего метода :] Я вообще дальше mboxa ничего и не делал... мне до этих 500 б... я жж говорил. Это просто была интересная тема вот и все. А если не будет этого самого "из любви к искусству" разве интересно будет программировать? жить? :)

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

я сам обратил на это внимание в начале статьи ;)

> А по-моему, лучше уж в таком случае использовать ассемблер.
ну здрастье! на Си писать быстрее и удобнее, а если еще при этом писать эффективно не перекладывая заботу об оптимизации исключительно на компилятор, то полученный код навряд ли будет можно улучшить по скорости/эффективнсти даже на ~3% ~5%.
ассемблер использовать нужно с умом и не лезть с мотыгой на колхозное поле. но не нужно впадать в другую крайность, обрабатывая дачный участок ворованным трактором беларусь ;)
я горячо люблю ассемблер (хотя сейчас это давным-давно интерпретируемый код ;), но все же... это именно любовь, а не оголтелый фанатизм ;))

я тоже не фанатик, но как-то я с С не очень дружу... Тобишь у меня есть пару книжек, синтаксис я разбираю, сам могу че-нить простое написать, но... че-то не то :)... дело привычки, наверное...

> Тогда и размер будет минимальный - 1 Кб
попробуй напиши программу, состоящую более чем из нескольких тысяч строк на асме и тогда ты поймешь, что соперничать с комилятором невероятно трудно (хотя и не невозможно). практически все большие проекты, написанные на асме написаны крайне небрежно и занимают ого-ого.

если я напишу несколько тысяч строк кода мне незачем будут эти самые 500б :) А насчет больших проэктов на асме... посмотри хотя бы fasm ;)

> Сшные ф-ии можно заюзать просто импортировав <уж не помню какую :)> dll'ку из поставки vc
MSVCRT.DLL наверное ;)

угу ;)

> уххх ты... а это как? 8)
очень просто - несколько секций своим raw offset + raw size ссылаются на один и тот же участок файла и он послушно проецируется куда нужно. например, тебе нужна некоторая стуктура данных и ее копия, тогда ты можешь не дублировать ее на диске, а "разножать" непосредственно в памяти. вполне законный прием.

а выравнивание секции+ее описание не "окупит" эту самую "экономию"? Хотя конечно зависит от размера структуры... IMHO useless, но красиво :)

> машинную оптимизацию можно будет использовать без
> извратов и перепалок с сшным компилятором...
все машинно-оптимизированное лучше выносить в отдельные библиотеки, сводя их объем к миним. а целиком оптимизировать все - понапрасну терять время.

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

> насчет com ты конечно загнул =) все com'ы обслуживает ntvdm и он есесно не даст вызывать Native API ;)
у com'а нативными будут 2F и 21, через которые можно дотянуться и до нативных функций ядра. читай брауна, он рулез ;)

как дотянутся? 8) Где его можно почитать? С удовольствием почитаю :)

> дык почему бы не воспользоваться ситуацией и PEB'ом если
я и так делаю все очень платформозависимым ;)
не использовать потому, что не нужно ;) тогда уж лучше сделать bind.

ну да, ты прав - мой косяк :) А еще можно не искать адреса ф-ий, а забивать их вручную ;)

> круто... только забота ли это оси? спорный вопрос...
> cpuid может юзаться из 3го кольца - значит и прикладной программист ее поюзать может...
будда тебе в помощь! cpuid появился лишь на пнях, а мы говорим о 386 и 486 машинах!

уууппсс :) это я глупость сморозил :)

что забота оси, а что нет - сложный вопрос, но согласись, неплохо иметь в файле поле, описывающее требование к ЦП, коль скоро есть поля, описывающее требования к оси. ведь Функцию GetVersion программа и сама вызвать может, но... видишь ли тут как. программы обычно создаются компилятором и компилятору пихать код проверки ЦП не в радость, он лучше загонит требования к процу в поле, которые линкер перепихнет в целевой файл и которое проверит ось. чем тебе такая схема не нравится?

не нравится тем, что зависящих от проца ехешников ничтожно мало. Такие проги могут и сами потрудится и проверить версию проца ;) (почти уверен, что 99% из них так и делают не смотря на присутствие поля в заголовке :))

> блин, хочу попробовать... у тебя нет какого-нить сорса?
да какой там сорец? просто прыгаешь и все. естественно, на ту страницу на которую у тебя есть права доступа. сущестует несколько способов их заполучить. если интересно могу описать, но по-моему их все и так знают...

под нт? я не знаю, опиши пожалуйста :) давай на мыло раз все знают ;)
мой pgp (если ты такой же параноик, как я ;)):
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQDPA0BoVmsAAAEGALzFWzj8pU+h7iXEq0tf3qhDYkBUlZ3xGA2gmuMkJpK/rc/r
9DWQgPkzXSS+9yw+s5+OVNE9SWHvJra1J/erxEU7j32rWoFoo7fIyE8d47NBWBaO
qmRiJJLGH3fuu3gfkVAKjc5aEwdTDlNLayFQKdFpzQ/P+cQOrR6LJpdM37ZVlXpO
aTlUorDZtCTdMgLBnsQo4i+DM6z7KaeKEd16+6g6swR3uK61rsny2SNBeDAwC3Jd
mxmyVqOcUOve+k4qKQARAQABtBlSNERYIDxFX0ZfSV9NQHJhbWJsZXIucnU+iQDV
AwUQQGhWa5xQ6976TiopAQG7BAYAh3Ln7NTcyU07gMOdgU+/MdeI+MzS1NTC5ixv
+DRbaRvAqMjmb10UhYRZ3zq1eyhdXp6RRrb0j/IfiMPj/paDd3g5LhJgzURXJ1N1
7vNpTYxx6PCnJ7JVfaTSRYvrt5LlpfaJE067YhhR0jdQiDddnY6wlQ0ODNM+s/j4
uClmNDtx16TIulHdfTXINgcLm5OLFLCz3e8rVSTfL/3nisLYZ3AcVsxVXjlWfbzc
mHMQ8fOnfSouCR+LoD0OZ1e4gyxR
=4TPI
-----END PGP PUBLIC KEY BLOCK-----



> жду с нетерпением =) а где его заказать можно?
прямо и не знаю. на сайт статью они вряд ли выложат.
остается поискать журнал по киоскам...

ок, обязательно поищу... Как еще раз полностью журнал называется?

Оффтопик конечно, но...

на Си писать быстрее и удобнее, а если еще при этом писать эффективно не перекладывая заботу об оптимизации исключительно на компилятор, то полученный код навряд ли будет можно улучшить по скорости/эффективнсти даже на ~3% ~5%.

Ну дело-то не всегда в оптимизации по скорости или размеру. Я и на С смогу написать и на делфи и даже на васике (sigh :)), но образ мышления уже не позволяет :)

ассемблер использовать нужно с умом и не лезть с мотыгой на колхозное поле.

Я вот сейчас с такой мотыгой и на колхозном поле :) - и ничего - управляюсь :))

я горячо люблю ассемблер (хотя сейчас это давным-давно интерпретируемый код ;), но все же... это именно любовь, а не оголтелый фанатизм ;))

Надеюсь, что тех, у кого к асму _просто_ оголтелый фанатизм, не подкрепленный ни опытом, ни знаниями на этом форуме нет

cpuid появился лишь на пнях, а мы говорим о 386 и 486 машинах!

Если быть точным на некоторых 486 (последних) он уже был.