This line: invoke MessageBox,0,szText,szCaption,MB_OK is equivalent to: stdcall [MessageBox],0,szText,szCaption,MB_OK and they both generate this code: push MB_OK push szCaption push szText push 0 call [MessageBox]
ну если хочешь пушить, тогда пожалуйста - по 4 байта текста руками загоняешь в стек, а потом передаешь указатель на текст в стеке нужной тебе функции. Тут или резервировать db, или по 4 байта руками в стек - по-другому никак. А мусор в отладчике и не видишь данных потому, что фасм скорее всего сделал так: Код (Text): call @F db 'my_text',0 @@: а дизасм постарался дизассемблировать твой текст. Потому и получился мусор вместо кода. Олька ж не всегда может отличить данные от кода. Сам подумай, насколько это сложно
ааа.! ясна! ..."а дизасм постарался дизассемблировать твой текст" - точно, теперь въехал! Про стек тоже главное знать критерии, что можно и нельзя. Я не знал. ... этсамое, а стоит ли на olly 2.0 заменить? или слишком сырой! Я просто думаю надо ли мне проблеммы с ним Или его во всю уже юзают? Главное что б принципиально не было сильных различий! Ато я в старой версии ещё нифига не соображаю, зато статьи есть.
Именно так. Код (Text): call ..continue db value,0 ..continue: Лишний раз убеждаюсь, что лучше все делать ручками, чтобы потом твой код не превратился в набор костылей, зашитых под селезенкой. Хотя здесь нужно быть очень внимательным, потому что данный фрагмент размещен не в тексте макроса вызова, а в тексте макроса, переопределяющего pushd. Я лично всегда делаю так. Код (Text): section ".code" code readable executable ... stdcall MessageBox, NULL, text1, caption1, MB_OK ... section ".data" data readable writeable ... text1 db "Click me", 0 caption1 db "Stupid message", 0 Semiono, сделай себе нормальный шаблон, чтобы постоянно не попадать на одни и те же грабли. Понятно, что код должен находиться в секции кода, т.е. executable, а то что он может быть выполнен и в секции, у которой соотв. флаг не выставлен, больше связано со спецификой конкретной системы и не должно рассматриваться как некоторая закономерность. Далее хватит экспериментировать с библиотечными вызовами, выбирая макросы вызова наобум. У каждого из них есть свои особенности и свое предназначение. Не нужно вызывать API-функции с помощью макросов, использующих Си-конвенцию вызова.
я именно это и хочу зделать, чтобы не возвращаться к этому потом. я просто думал что нибудь продвинутое "хакерское" я могу упустить при этом, и тогда не крута будет хотя круто это на самом деле когда альтернативный машинный код вместо типичного api, от чего я ещё далёк, к сожалению А по регламенту кода всё это так и есть в примерах и хелпах, значить не надо мудрить. Но у меня один вопрос, а порядок следования секций очень важен? И если я правильно понял в одной статье, то что db ? лучше размещать впереди, чем db 'zzz' это верно?
я немного не понимаю о чём речь. вообще я думаю что речь о том что надо работать без макросов, а это как я думаю push data1 push data2 call winapi или нет? хотя далее: или это к слову пример для меня лично? или есть нечто ещё?
И моё мнение по поводу макросов, я лично думаю, что если нету иного способа исполнения кода, то глупо писать то же самое вручную, то что в самом макросе итак следует. Это только для понимания, как упражнение только оправдывается. Но я наверное не в теме?
Есть ещё третье, я немного помедитирую... Видимо API очень трудно обойти как нибудь иначе? Но наверное в сумме, когда если взять много API как некий кусок программы, то видимо можно это всё выкинуть и построить другой код делающий то же самое и более оптимальный?
>И если я правильно понял в одной статье, то что db ? лучше размещать впереди, чем db 'zzz' Так и есть. Если определять неинициализиорованые данные в конце файла, то они фактически не будут записываться в exe - изменится только размер образа в памяти.
Так сделай. Можно создать новую ветку на этк тему, чтобы люди представили свои варианты, а ты бы выбрал или синтезировал, так сказать, на основе этого какой-нибудь свой вариант. Не очень, ну лучше все-таки сначала рамещать секции с кодом/инициализированными данными, а потом с неинициализированными. Лично я размещаю секции в таком же порядке, в каком это делают используемые мной Си-компиляторы: сначала код (обычно в конце этой секции помещаю и данные только для чтения), потом данные (включая таблицы импорта/экспорта), в конце этой же секции размещаю неинициализированные данные (это возможно, так как формат позволяет отдельно указать размер секции в файле и в памяти), а в самом конце служебные секции типа секции ресурсов или секции с релоками (для библиотек). Неверно - я только что об этом написал. Если речь идет об одной секции, то сначала нужно размещать инициализированные данные, а потом неинициализированные, тогда они не будут занимать место в исполняемом файле.
Я об этом недавно писал. stdcall - это мой собственные макрос. Он просто позволяет поместить параметры функции в стек в обратном порядке, а способ обращения к библиотечной функции внутри этого макроса я периодически меняю (по необходимости). Нет надобности все упрощать настолько, чтобы даже параметры явно помещать в стек. Смысл в том, что результаты работы моего собственного макроса предсказуемы, а стороннего не всегда, поэтому нужно либо в деталях изучить то, что ты используешь, либо сделать и использовать что-то свое. Лично я из пакета fasm использую только включаемые файлы из папки equates плюс файл с макросом struct. Для описания ресурсов, таблиц импорта/экспорта использую свои файлы.
API элементарно обойти, но тогда твое приложение будет завязано на конкретную версию системы. А чтобы сделать приложение инвариантным к версии системы, нужно приложить немало усилий и все равно это не будет гарантировать работоспособность твоего приложения во вновь появляющихся версиях системы. Другое дело, что некоторые подсистемы можно обойти за счет других или использовать одни функции вместо других.
