Такой, немного флеймовый, вопрос..
Развивается ли сейчас АСМ?
Да, я знаю, энтузиасты сейчас делают много всяких компиляторов, но, например, создается ли Microsoft'ом новый masm?
Как поживает TASM?
Просто последние версии данных компиляторов сделаны этак до 2000г.
Можно ли будет в будущем создавать на нем прикладные, десктопные программы? (как вы поняли, меня волнует .NET)
Или останутся только драйвера?
Можно ли на АСМе генерировать приложения под ДотНЕТ?

З.Ы. Если уж очень флеймово - прошу прощения..

Это сообщение отредактировал(а) Kurt - 26.2.2004, 19:43

Kurt
RadAsm есть
рисуй себе там окошки как в дельфи
а обработку на асме пиши все лехко и понятно
.NET думаю на асме не выдет писать
онож интерпритируемое г...но
работает там себе гдето через виртуальную машину и процессора не видит как такогого

А не может ли сложиться ситуация, когда нельзя будет создавать КОНКУРЕНТНОСПОСОБНЫХ без ДотНЕТ?
Тогда АСМу кронты..

вполне может если весь софт будет работать в некой виртуальной машине
останется дрова писать и ехплоиты

Печально, однако..
Хотя я слышал мнения, что вроде когда win32 появился, все АСМ хоронили, ан нет..
И тут обещают, что первый же ассемблер (мне кажется, это будет нечто такое, что действует в обход виртуальной машины - ведь она все равно будет обращаться к каким-то платформозависимым библиотекам..) напишет.. сама Microsoft..
Возможен такой вариант?
Или все, хороним?
Просто я тока сел изучать АСМ - ка-то не хочется изучать язык, к-й через пару лет коньки отбросит - хочется уметь программить на нем все - от декстопного приложения до дров..
Есть шанс?..

Цитата

онож интерпритируемое г...но

я б не стал так заявлять, к тому же не интерпретируемое а компилируемое в рантайме

Цитата

работает там себе гдето через виртуальную машину и процессора не видит как такогого

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

для .NET есть что-то вроде надстройки над ASM назывемое CIL (Common Intermidiate Language)
именно в этот промежуточный язык компилируются все приложения написанные на языках, подведенных под .NET
поэтому может быть можно будет писать на CIL, хотя не вижу в этом смысла

Вот-вот..
Т.е. программить на АСМе десктопные приложения станет невозможно -> тады зачем учить? (только не надо "для общего развития, знать, как устроен комп" etc.)..
Жаль..
А по поводу нового масма? Кто-нибудь верит, что Microsoft такое напишет?
Кстати, я где-то слышал такое словосочетание "masm v 7"..
Есть такое?

З.Ы. Один мой знакомый, довольно неплохой специалист, утверждает, что дотНЕТ - тупиковая ступень эволюции..

Кстати, по поводу дотНЕТ - виртуальная машина ведь все равно использует вызовы API?
Значит, можно будет и без нее? Или как?..

Парни, бросайте эти сопли ! Нас ждёт вторая серия !
АСМ будет всегда. Основательнее его только машинный код.

Ну.. лозунги и я умею кричать..
А вот ОБОСНОВАНИЕ..
Если все через VM - в чем будет преимущество АСМовых прог?
Ну, да, будут они работать как все остальные win32-приложения - через эмуляюцию - как сейчас ДОС-приложения..
Толку-то?

Для начала, ASM используется не только для PC. Сейчас бешенно расширяется область применения микроконтроллеров. Растет их количество. Причем, новые модели разрабатываются так быстро, что даже обычный C не всегда успевают под него создать. Поэтому часто надолго (а для некоторых моделей и навсегда) единственным (!!) средством их программирования остается старый, добрый АСМ. Правда, для каждого проца он свой (по крайней мере имеет специфику)

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

Код

mov hff, eax    .WHILE eax        mov eax, ffSkins.dwFileAttributes        and eax, FILE_ATTRIBUTE_DIRECTORY        .IF eax            .IF ffSkins.cFileName != '.'                invoke lstrcmpi, addr szSkinsDefault, addr ffSkins.cFileName                .IF eax                    invoke SendMessage, hList, CB_ADDSTRING, 0, addr ffSkins.cFileName                .ENDIF                .ENDIF        .ENDIF        invoke FindNextFile, hff, addr ffSkins    .ENDW

это кусок из примера скинового окна.
здесь мы видем только 2 асмовые команды - mov и and...
а что будет дальше? сделают поддержку сложных вырожений, типа mov eax, ebx*ecx+edx/edi или if eax*ebx == ecx*edx then ...
куда это все катиться?
ЗЫ извените за оффтоп... :|

Serzh
согласен
приведенный пример есть изврашение

Ассемблер предназначен для своего круга задач. И пока будут процессоры - будет и ассемблер 

Вообще, на мой взгляд, masm-это одно большое извращение. Если нужны структуры и массивы-почему бы не писать на С. А если нормальный ассемблер - тогда на TASM. 

ау, некрофилы, остыньте!  тема флеймовая, да еще и изрядно подгнившая - нафига ее ворошить? 

Я слышал от одного близкого знакомого, что на Западе хорошо платят за АСМ.

Учим асм и летим на запад зарабатывать...   

Будущее у асма есть, он не истребим в принципе.

Другое дело что его "важность" будет угасать и стремиться к нулю (никогда не опускаясь до самого нуля)

Простой пример, раньше когда не было кеша, а частота процессора равнялась частоте внешней шины компиляторы не могли угнаться за людьми в вопросах оптимизации скорости кода. На данный момент чтоб программисту учитывать все возможные варианты оптимизаций (SSE/SSE2/и.т.д.) надо будет изрядно постараться, в то время как компилятор сделает эту работу на 0.01% хуже, но в миллионы раз быстрее.

ИМХО, зависит от видя деятельности. Понятное дело, если, например, я пишу на интерпретируемых или скриптовых языках, таких как Java, С#, Perl и т.д., то, скорее всего, ассемблером я не воспользуюсь  С другой стороны, если я работаю, например, инженером ядра Linux,  и пишу архитектурно зависимый код для какой либо платформы, то без ассемблера, думаю не обойтись никак.

Вредоносный код программы не проверишь без дизассемблера.

Так и есть, деньги реальные - рассказывал один знакомый америкос по-переписке. Тока спецов там и своих хватает. А жаль...

как сказать. Есть такая штука - strace называется  В большинстве случаев может заменить дизассемблирование.

JackYF, 
strace работает с форматными файлами
он не поможет в случае с бинарным shell-кодом
кроме того, если использовать strace, трассируемая программа все равно выполняется, что нежелательно для "вредоносного кода"

Это сообщение отредактировал(а) MAKCim - 1.10.2007, 15:32

гм... с этого места поподробнее



ну тут нам поможет chroot...

с этого места поподробнее   

иначе говоря strace не работает не с ELF файлами
например, я хочу реверсить GRUB
тут поможет только связка дизассемблер + dd

ясно



ну например


и прога не сможет испортить ничего, кроме содержимого каталога /home/jackyf/dummyroot, разве что зажрать ресурсы. Но прогу мы всегда можем убить.

ну это не решение, имхо
программе могут понадобиться библиотеки для запуска или еще чего-нибудь

ну как сказать... я не раз встречал данное решение как не панацею, но хороший приём, от разных людей...

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

JackYF, 
не, все-таки я склоняюсь больше к дизассемблированию   
не уверен только, может ли GDB работать без отладочной инфы

я в линухах - как в лопухах, но gdb'ил точно без отладочной инфы пару раз... 

dumb, 
да, ты прав, я проверил