Оправдывает ли себя программирование на ассемблере под Win32?

И все-таки если задуматься о существовании "золотой серидины" при выборе языка программирования, какой набор можно порекомендовать, опираясь на простое написание пользовательских приложений.....а не драйверов, вирусов и т.п., где знание ассемблера необходимо наверняка??

 

Morskoivolk

Думаю просто: зайди на крупный сайт посвященный поиску работы. Там наверняка будет неплохая выборка, какие требуются программисты прикладного толка. Сейчас можно утверждать, что знание С++ - актуально, С# / Java - перспективно, Python / Ruby - экзотично но тоже перспективно. С учетом деформации рынка в сторону Web, можно так-же рекомендовать и скриптовые технологии изучать (JavaScript, PHP, HTML) - приложения в этом плане тоже надо уметь делать, в ряде случаев.

 

PHP,HTML.....я отношу к категории "познал за день, учил год".....ассемблер же - "учил год познал за день".....думаю после ассма...перейти на логику другого языка уже не есть проблема.
Спасиба вам огромное дружищи!!!! за наставление на путь истинный, я тоже руководствовался такими же соображениями.....хотелось услышать непредвзятое мнение строннего наблюдателя)).
Может кто порекомендует прогу для C++ чтобы как всегда .....меньше размера, больше скорости))) в моих кругах юзают Visual C++ послених версий...вроде 6....говорят рульная штука......еще Borland C++ Builder....говорят тож вроде ничего. Каково ваше мнение?

 

Morskoivolk
Компиляторы неплохие предоставляются и MS и Intel. Если ориентироватся на все платформы - GnuC C (фронтенд, что транслирует Си в асм, и уже асм в бинарный код). Не надо стремится в данном случае к идеализму, особенно сейчас. Пока у тебя экспиренс дойдет до уровня опытного программиста, этих компиляторов сменится много поколений, и к тому времени тебе возможно эти качества компилятора будут до фонаря

 

Ой не всегда!!! )) Вот чтобы хорошо понят ООП, так сказать проникнуться мне пришлось не один день с другом пить пиво и читать Гради Буча! Но щас не жалею
Просто у каждого языка, свой аппарат мышления, это по мимо синтаксиса, бывает так что ты вроде бы все гда знал как нарисовать график, а на новом языке как слепой катенок! Дело тут не в опыте, а в мышлении!!!

 

Шестерка была последней лет 5-6 назад. Сейчас актуальна линейка Visual Studio 2005: http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx

Visual Studio 2005 Express на халяву дают
http://msdn.microsoft.com/vstudio/express/support/install/

Но нужна относительно мощная машина. В шестой студии без проблем можно работать на слабой тачке, что я и делаю.

Насчёт Билдера ничего не скажу. Сходи на форум rsdn.ru. Там много религиозных войн на эту тему. Через неделю чтения может сложится своё мнение

"Меньше размера, больше скорости", IMHO, больше от рук зависит. Среды разработки - это всего лишь инструмент, а остальное от мастера зависит.

 

Вобщем "Оправдывает ли себя программирование на ассемблере под Win32?" - ДА оправдывает.
А если ктото думает иначе, то ненужнобыло постить тему в этом форуме

 

alpet
<offtopic>
GCC == GNU Compiler Collection
не ограничивается C и C++ (см. gpc, gcj, etc.)
</offtopic>

 

недавно ломал прогу....и встретил таку вот беду.....в Нете нашел урок по взлому этой же проги тока ранней версии......так вот генерация алгоритма была представлена в 2-х варинтах: на Дельфи с ассемблерными вставками и с помощью чистого API без ресурсов и библиотек.....это получается что при добавлении библиотеки в файл посредством includelib мы тем самым его увеличиваем и снижаем производительность проги??
и как вообще работает обращение к конкретной функции в таком случае??
можно ли таким макаром вообще писать??
кейген получился около 18 кб.....я считаю неплохо

 

а чем же мы здесь все занимаемся? этим только и занимаемся

 

)))) так точно! не важно что и писать и где писать, важно какими руками и прежде всего головой)))

 

но все-таки чем Windows Api может быть привлекательным в его использовании?

 

дзеном

 

а подробнее?

 

Morskoivolk

Тем же, чем libc в *nix -- абстрагированием от низлежащей системы. Т.е. функции WinAPI работают (с оговорками) одинаково на всех Windows (речь не идёт о <=3.11), а вот совместимость системных вызовов между поколениями/направлениями никто гарантировать не станет.

 

Тем, что это самый короткий путь обращения к системе. Любая библиотека - это посредник. Посредник берет на себя часть работы, упрощая обращения к себе, но при этом ограничивая твои возможности. Например, в WinAPI CreateFile требуется передать много параметров и флагов. Чтобы со всеми ними разобраться, требуется весьма много времени.

Code (Text):

1. HANDLE hFile = CreateFile(
2.                            TEXT("myfile.txt"),
3.                            GENERIC_READ,
4.                            FILE_SHARE_READ,
5.                            NULL,
6.                            OPEN_EXISTING,
7.                            FILE_ATTRIBUTE_NORMAL,
8.                            NULL );

Проще вызвать обёртку CreateFile: fopen("myfile.txt","r");. Возможностей управления fopen практически никаких, но зачастую они и не нужны, зато просто и быстро. А fopen сама знает как вызвать CreateFile. Вот и вся парадигма. Если нужно иногда открывать файл, то с какой скоростью будет работать fopen не имеет большого значения и можно смириться с небольшим увеличением размера программы из-за кода библиотеки-обёртки. Могут быть и другие плюсы, например кросплатформенность, т.е. ты обращаешься к библиотеке, а она сама разбирается в какой системе мы щас работаем. Ну это так... очень примитивно объяснил.

ЗЫ: Что-то я разговорился Исправлюсь.

 

Morskoivolk

Про динамические библиотеки вообще и про динамическую линковку в частности в 2х словах нормально не обьяснить. На сайте в разделе документов есть литература по этим вопросам, которой хватит на парочку недель вдумчивого чтения. Авансом могу сказать только, что при использовании внешних библиотек (они обычно имеют расширение DLL) в экзешнике создаётся таблица импорта (формат этой таблицы и куча нюансов по теме описаны в спецификации PE32/PE32+ COFF). В данной таблице хранятся имена используемых библиотек и имена публичных символов (функций), импортируемых из данных библиотек. Обращения к данным функциям в экзешнике проецируются на таблицу импорта. Когда лоадер загружает экзешник, он обрабатывает таблицу импорта, подгружая по ходу дела заданные библиотеки в адресное пространство процесса и занося реальные адреса импортируемых функций в таблицу.

 

Four-F Спасибо тебе огромное, это именно то что мои уши хотели услышать! точнее внутренний голос! по философски объяснил....миросозидающе! теперь я стал светлее!
еще раз спасибо! заходи почаще в мой топик, я думаю нам будет о чем поговорить)))

 

Morskoivolk

На мой взгляд самую правильную мысль высказал комрад EvilsInterrupt:

Первое что обязан знать программист "Язык программирования это средство для выполнения поставленной задачи". Отсюда: "Какая задача?"

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

 

к посту Four-F, ещё прога становится зависимой от библиотек и без них не
работает, а вот "чиcтый" Win API поставляется вместе с виндой, но это хорошо если
ориентируемся только на винду, а вот если кросплатформенность, то без какой-нибудь
либы абстрагирующей от осей не обойтись (исключение написать код этой либы в своём
приложении )

асм близок к машинному коду его постижение позволяет заглянуть на уровень железа,
и в то же время посмотреть вверх и увидеть суть ОСей, приложений под них...

писать под асмом так же как на с/с++ просто в с/с++ поумолчанию к
приложению приложена () стандартная библиотека с, а для асме с аналогами
пока туго, можно конечно просто заюзать эту сишную либу (причём довольно просто),
но это не дзенно: в проге на асме юзать либу писаную на си ...