Не съм толкова дрът да съм им светил 80-те, когато са пускали Уиндовс 1,2 и 3, но мисля че писането на Асемблер е идвало някак по- праволинейно, когато 70-те от IBM(Microsoft) и от Apple са крали идеи в прав текст (Асемблерски) за правене на GUI от Ксерокс (Пало Алто) лабораториите. Тогава електронното устройство (било то копир или компютър) е работило не с монитори и принтери, а с един точно определен модел монитор и принтер на текст/графика, с един точно определен размер, а ASCII символите(на латиница) са били 'набивани' като бинарен код директно в PROM чипа на тоя монитор/принтер. Електрониката/логиката е бутала битове и байтове на Асемблер и 'изплювала' ASCII код към чипа на монитора/принтера, резултиращ в изобразен символ/графика. С появата на повечко модели изобразяващи устройства се е появила необходимостта от написване на абстрактен междинен слой, GDI, съдържащ готови обекти и начини на работа с тях(обектно ориентирано програмиране на фронтенда) а логичния избор за създаване на обекти по това време е бил C- езика с неговото пакетиране на променливи и свойства на обекта в struct. Не е нужно някой да леак-ва код, има достатъчно примери от работещи за Майкрософт на времето като Чарлс Петцолд и др. как са писани обекти като джамове, слайдери, метрика и т.н. -като struct - ове под C. Тея идеи са залегнали изначално в NT - серията уиндоуси.
После в уравнението сме се намесили и ние -' българите на три морета' тропайки с краче и заявявайки че няма да си платим пиратския Уиндовс, докато не пропише на кирилица . Не стига, ами сме подучили и Китайците, и Арабите.... и почнало едно променяне на методите за кодиране на символи ASCII, Wide Char-ASCII, WinPage ... Unicode. И с всяка нова версия на уиондоус - по 20 нови страници #define ... #define... на дефайн-а в .dll -ите на тогавашното Platform SDK .... и така 20-30 години. Да де , ама през това време хората не са стояли, а са писали софтуер за Уиндовс - един с древен текстов редактор работещ на ASCII, друг - със символи с различна кодировка.
В днешни дни, по мои впечатления, на хората не им липсват познания как да напишат поредната Уиндо-подобна OS работеща с монитори, принтери, мишка и клавиатура, а по-скоро 20-30 годишния товар на символни стандарти, драйвери и софтуер писани специално като за тях. Какъв е смисъла от разбиране как работят стари версии на Уиндовс, като той вече не работи така и почва 'рингинг' със всякакъв софтуер писан уж за Уиндовс и Пен Чун се обажда от Китай спешно- 'ало, аркадаш - имам проблем с изобразяването на символите на Средно Комплексен Китайски с примес на Мандарински от поречието на Река Шен Джун'
Ако горните разсъждения са много лаишки и фриволни, добре дошли са корекциите и допълненията - наУчни и философски

Мен ако питаш ползвали са асемблер точно по същата причина поради която и аз го ползвам чат пат, поняког е по-бързо да го напишеш на асемблер вместо да пребориш компилатора да генерир сходен асемблерски код, еле пък при х86. За ония години с огрниченоте ресурси, и отделно писачи които най-вероятно първо са прописли на асемблер и чак тогава са минавали на езици от високо ниво ми се струва е било съвсем естествен подход.

едно време писането на asm имаше огромно влияние в/у скоростта - поне 3-10 пъти
с днешните CPU и компилатори, ефекта е малък (има смисъл само за SSE/AVX, но и там не е задължително) - L1 кеша е бърз и замества регистрите достатъчно ефективно.

аз "открих" "C" ~1988 и въпреки че съм писал стотици хиляди реда код само на асемблер - повече никога не съм писал нещо изцяло на asm

За РС в момента най-вероятно няма никакъв смисъл, аз визирам малки контролери, там ми се налага чат пат да пиша на асм.

Ок а кой Tool използва само за компилиране на определен модул Понеже си имат makefile в директориите

Затова програмите от килобайтове скочиха на гигабайтове и станаха далеч по-бъгави

@бонго - далеч си от истината!

C/C++ (жаби и питони също) позволяват да се пишат много надежни програми от "който може" - нещо което на асемблер е почти невъзможно.

+1

За който го може.
Преди време някой беше пуснал следния пример:

Добре, а варианта 0хаА и 0хАа? После бъгове имали програмите, половината възможности не са включени.

И да цитирам един писач - "Еее, голяма работа, че програмата ми заема 7-800МБ памет, една плочка гигабайт е 20 лева"

Този код е синтактично напълно валиден.
Семантично се сещам за поне 4 случая в които ако се махне "ненужното" или се добавят "липсващите" варианти, ще се наложи да викат Бай Едикойси от пенсия за да спасява положението.
1-ви случай. (Плах опит за дебоунс)
Променливата a е декларирана като volatile и при двете сравнявания се извършват две четения от адресното пространство и ако поне едно от тях отговаря на условието, се изпълнявя блока след if-a.
2-ри случай. Леко ама много леко времезакъснение. a отново е volatile, за да не оптимизира компилатора. Съответно отново две четения. Този път целта е: леко ама съвсем леко времезакъснение. А, си оптимизирал, а, както казва един титан на софтуера - "камара проблеми".
3-ти случай.
a отново е volatile, но при четене от нейния адрес всъщност се чете от малко FIFO от две позиции. Съответно с двойно четене прочитаме, постъпила във FIFO-то, 16 битова стойност. Съответно този код ще работи и при MSB first и при LSB first на числото 0xAA00 постъпило във FIFO-то.
4-ти случай.
Това е за наистина ама наистина разбирачи. Които правят тънки сметки и подравняват кода в кеша с добавяне на една-две, привидно излишни, инструкции тук-таме из кода.

И при четирите случая си личи подход специфичен за ембедед писач. Който ловко жонглира с хардуера и "side effect"-ите. Това е човек с хиляди редове изписан(и дебъгван) асемблерски код зад гърба си. Човек, когото често ще чуете да казва: "Софтуер, дело тонкое!" докато се подсмихва и засуква мустак.
Спокойно може да се използва този въпрос и на интервюта за работа за да отсеете надъханите пишлемета и зубрачите от тия на които ембедед софтуера им е в кръвта.
upper case и lower case за константата е използван тенденциозно, като уловка, за по-надеждно диференциране на лаиците.

Това не е синтактично верен код! Който не вярва - има книги, има и компилатори. Ако някъде мине изобщо, то ще е на компилатор с доста разтеглени понятия за стандарти. Оттук нататък всякакво тълкуване е за пишман-пророци

-Благодаря интересно нещо. Поне не си го спомням. Жалко за хубавата идея- сега наистина бихме напред с мат'ряла. Иначе - ето я причината:
"Along with the lack of optimization in a premature Ada compiler, this contributed to rather slow but expensive computer systems, performing typical benchmarks at roughly 1/4 the speed of the new 80286 chip at the same clock frequency (in early 1982).[7] This initial performance gap to the rather low-profile and low-priced 8086 line was probably the main reason why Intel's plan to replace the latter (later known as x86) with the iAPX 432 failed. "

-1

Ей как ме затапи
Константине, Константинеее... Константине. Няма нужда да го обръщаме на "верен", "вярва" и "пророци".
Дребните грешки лесно се откриват и поправят. Но не за това беше думата. Пък то накъде отиде... типично за буквоядска секта.