авторДа и чтозначит фраза - для ассемблера нет таких-то библиотек? Что имеется в виду - LIB файлы? Так LIB файлы вовсе лишний гемор. Загружаем с помощью LoadLibrary нужную DLLку и с помощью GetProcAddress находим точки входа функций. Все DLL библиотеки доступны, будь они хоть на дельфи написаны.

Вот-вот - нет нативных библиотек на асме. Даже какой-нибудь sprintf -
надо велосипед изобретать или брать написанный дядей код.
А с системой пообщеещься тока через syscalls.
В итоге все "ассемблерное" программирование сводится к вызову из асма системных вызовов. Это с не меньшим успехом делается в С.

И накладные расходы при выполнении системных вызовов практически всегда
гораздо больше, чем любая логика - на асме она написана, на C или на чем-то еще. За исключением редких критичных мест, о чем все твердят.

А проги полностью на асме - нахрен не нужны. Они заточены не только под одну архитекруру , но и только под одну ось.

Вот в микроконтроллерах асм оправдан, хотя программаторы тоже есть.

И про перетаскивание окошек - это миф. Да, есть такие. Но есть очень много хороших и грамотных программистов на Delphi, как и на С, Asm etc. :-)

И бездарных программ на асме было полно во времена DOS - например многие вирусы глючили :-)

Тогда просто асм был действительно широко распространен и владение им не считалось чем-то эзотерическим, школьники вирусы писали.

А сейчас он - редкость и возможно поэтому код на нем качественный - остались немногие профессионалы.
Может еще какую-нить херню новую придумают - и то же с Delphi произойдет :-)

Поговорка есть "нет плохих кораблей - есть плохие капитаны"


P.S. если что - я на Delphi не писатель так что, надеюсь, объективен.

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

Да его довольно много, такого кода.
Жабу и интерпретаторы - тока влет (конечно желательно чтоюы версии интерпретатора или jvm совпадали и модули наличествовали)

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

SQL еще переносим :-) чем не языкк :-)

кроме того, все это переносимо между платформами в смысле осями и платформами в смысле апаратными архитектурами; первое для асма иногда возможно, но весьма трудоемко, а последнее просто недостижимо .

Да и между осями... посмотрю я , как из MS DOS асмовую прогу под винду перенесут :-)

kolobok0угумс...только почему то в "лёт" она сопротивляется...приходится ОПТИМИЗИРОВАТЬ под ОСь !!!
(енто основываясь на КОНКРЕТИКУ из жизни, а не теоретические хотелки) -1


скажем, perl скрипты примерно одинаково отрабатывают, на всех платформах.
Вообще, я тут в основром говорил о скриптовых языках. Интерпретаторы и VM пусть разработчики под ось оптимизируют - это их уровень абстракции. Что они и делают с переменным успехом :-)


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

про то и речь... просто недостижимо.



kolobok0(иф дэфы договорились не считать, ну лано...пущай плюс одын..) +1

Зачем так высокомерно?
Высказывание из серии "Visual Basic мастдай, ибо он для дошкольников"
На них пишут довольно сложные вещи, не тока ифдефы.
Например - видел банковский опредень, написанный на shell.
И слышал о подобном же чуде, написанном на REXX.
Вообще, на shell+unix utils можно задачи любой сложности решать.



kolobok0угумс... например nvl(...) под ораклом... перенесём в .... попу... (а если Вы заведёте речь о стандарте, и попробуете на нём писать...гы...даже не смешно...-грустно) -1

Спекуляция-с :-)
Имелась в виду переносимость между _аппаратными платформами_

Transact SQL Sybase или PL/SQL Oracle вполне себе будет работать в соответствующих СУБД, скажем, на SPARC или на Intel.

Собственно, мой пост - о том, что прикладной код сейчас все чаще выполняется в виртуальных машинах - рантаймах типа Java,
скриптовых языках либо с СУБД. И они скрывают различия. Так что о "непереносимости" надо вести речь не в категориях
аппаратных платформ и асма (что прошлый век), а в категоиях соответсвующих VM и СУБД, к чему Вы, уважаемый kolobok0 и пришли

kolobok0("угумс... например nvl(...) под ораклом... перенесём в .... попу... (а если Вы заведёте речь о стандарте, и попробуете на нём писать...гы...даже не смешно...-грустно)...")

Или может быть, спецы по Oracle объяснят нам коренные различия работы nvl(...) в Oracle под разные платформы (например, Win32 и Solaris? На разных процах - intel и sparc?) Это будет на уровне асма, то есть сабж.
А остатльное плиз в топик "сравнение баз данных" :-)

A.V.странно что никто про защиту программ не упомянул. без асма тут никак

Это все было актуально в первой половине 90-х, когда действительно можно было создать некую защиту и большинство "ламеров" не могли ее сломать.
А сейчас что толку корпеть - когда через неделю какой-нибудь такой же хацкер ее ломанет, а через две недели - кряк будет уже на всех "асталавистах" лежать. Непроизводительный труд.

авторнапример чтобы прогу редкую поломать
то-то что редкую. Для не редких и общеполезных кряки ппо инету разбросаны.
Получается - асм реально нужен тока "профи-крякерам"

авторпроверить является ли прога вирусом...
и чувакам, работающим в антивирусных конторах.
Правда еще не забыть учесть, что 80% вирусов пишутся на vbs и прочем :-)