В будущем я хочу разобраться с асемблером. Но сразу это будет сложно, поэтому сейчас я знакомлюсь с C++, мне надо писать на нем с минимальным количеством библиотек. Поэтому я начал изучать win32 api.
Что то на win32 api у меня немного получается. Но есть проблема. Я не понимаю смысл, почему в win32 api что то работает именно так или так. Потому что у меня мало знаний в области того как вообще работает компьютер и операционная система.
Встречаются мне регулярно понятия такие как - поток, ядро, дескрипторы. Иногда я представляю интуитивно что все это примерно значит, но глубокого понимания всего этого нет.
Теперь вопрос. Что мне стоит почитать, что изучить чтобы получить эти знания? Что позволит мне лучше понять почему те или вещи в win32 api и в дальнейшем в низкоуровневом программировании работают так или иначе, что именно надо учитывать.
Стремлюсь к низкоуровневому программированию ради интереса. Как то зарабатывать на этом не планирую да и просто не смогу, даже если захочу. Времени на все это у меня много. Думаю лет 10 есть.
Язык ассемблера в понимании winapi тебе особо не поможет.
Ознакомься с потоками и процессами, распараллель эту свою tcp-шную хреновину на несколько потоков, или типа того.
Вот тебе и горы практики на полгода вперёд. После этого будешь лучше ориентироваться в системном программировании, а после этого можешь и ещё ниже углубляться.
У меня такое видение, по крайней мере. Просто своими мыслями поделился.
Не еби мозги и просто иди читать Столярова, дальше уже сможешь сам разобраться куда двигаться
>Теперь вопрос. Что мне стоит почитать, что изучить чтобы получить эти знания?
Эндрю Танненбаум, Современные операционные системы
Столяров, как советовал анон выше
Windows Internals, Руссинович
>почему в win32 api что то работает именно так или так
Потому что люди которые писали эти библиотеки и функции действительно шарят, они прошли тяжелейшие испытания в виде отбора на должность. В отличии от linux, где борцун с системой в обосраных труханах возомнил себя вумным и что-то накалякал.
Ответ:
Это просто пиздато работает, пользуйся и не выёбывайся.
В целом верно. Костяк WinAPI писали старики, что начинали инженерить ещё на компах предыдущих поколений. Но в какой-то момент такие люди, знающие винду снизу до верху, в Microsoft закончились. Часть проблем по итогу осталась не решена (пример - дефолтное ограничение полного пути файла на 255 символов). Новички, сколь пиздатыми они не были, не решаются проводить рефакторинг, боготворить их не надо.
Как бы я не ругался на винду в целом, но winapi это идеально сделано. Да, есть недоработки вроде ограничения в 255 символов, но это такое..
Я хотел сказать, что это действительно достойный труд и он должен быть защищен и приносить этим людям прибыль, и они сами(уверен) знают цену того что они сделали.
А тут ОП(или я, неважно), а почему это работает именно так?
Да потому что не твоего ума дело(и не моего).
А то привыкли что запросто так им все дают на линуксе.
Толсто
>>3714566
>>3714625
Я не знаток винапи, имел с ним дело только в вузе 12 лет назад, но разве там не какой-то пиздец? Я помню, что графическая подсистема была интегрирована в винапи, все функции принимали какое-то адское кол-во параметров и в целом все выглядело очень запутано. Когда я потом учил линукс, то минималистичность его апи выглядела очень привлекательно.
Почитай Кетов - внутреннее устройство Линукс. Если будет много не понятного то начни с таненбаума - современные ос. У Кетова ещё есть лекции на ютубе, но там как и в книге очень академический стиль. Это если база нужна о том как работает ос. Если хочешь ещё на уровень ниже Morris - Logic and Computer Design Fundamentals.
Если интересно как работают компиляторы почитай дракончика Compilers: Principles, Techniques, and Tools
Есть классические книги по ассемблеру и программированию под win32.
По win32 - это книга Петцольда - Программирование для windows 95
А для ассемблера можешь почитать Зубкова Assembler - язык неограниченных возможностей. Или древнюю книжку Питера Абеля. Ассемблер и программирование для IBM PC. Там везде рассказываются основы.
Но про ассемблер надо понимать главное - что он аппаратно зависим. Ассемблер для x86 это одно. Для Motorola 68K, Zilog Z80, SPARC, MIPS, микроконтроллеров всяких - это всё другое. Так что изучи лучше язык Си, прежде чем соваться к ассемблерам.
А вообще, чтобы экспериментировать с Win32 GUI можно взять C++ Builder (скажем 6.0). Там очень удобно клепать интерфейсы. Удобнее, чем с MFC в Visual C++. MFC ты тоже можешь проштудировать. Есть книжки. На самом деле - мало кто вменяемый в те времена писал на голом Win32 API. Скорее MFC использовали.
А сейчас используют Qt какой нибудь, или wxWidgets.
>Зубкова Assembler - язык неограниченных возможностей
Зубкова, кстати, надо ещё поискать полную версию. То, что я находил в интернете - там усечённая версия с неполным материалом.
Я на ассемблере под Z80 развлекаюсь, пишу. Достал себе эмулятор компа на базе Z80, и запускаю под него мои программы. А ещё есть сайт asm80.com. Там прям в отладчике можно прогнать онлайн свою нетленку. Немножко кода какого-нибудь. Дяже ничего ставить не надо. Чисто, в блокнотике у себя на компе пишешь немножко кода, копируешь в браузер и запускаешь.
Кстати чтобы писать на древнем WinAPI лучше использовать Visual C++ 2008 наверное какой. Вместе с локальными библиотеками MSDN тех годов. Они ещё не настолько раскурочены, как нынешние.
И да - Win32 API гораздо лучше изложен именно в старых MSDN.
>MFC
Недалеко ушло от WinAPI, делать GUI убожество и головняк. MFC годится разве что как библиотека, для тех же строк, а GUI делали на Дельфи/C++Builder.
>>3716862
Зачем древнее WinAPI когда есть новое с новыми возможностями, старое же никуда не делось. Винда же не линукс, новое не отрицает старое.
Не, просто на C++ Builder ты навороченную приложуху не наваяешь. И компилятор убогонький, и баги, и вообще функционал ограниченный.
Для крутого софта нужен Visual C++. Что-нибудь из десктопных приложений масштаба MS Word, каких-нибудь 3D Studio MAX, браузер Firefox или Chrome - это всё Visual C++. С MFC или без. На C++ Builder такое не пойдёт.
Тупые фантазии.
Мс-офис пишется майкрософт на неизвестных внутренних тулкитах.
Браузеры вообще на javascript.
Повторяю, на MFC ничего не напишешь, это портянки гемора как на винапи, бесполезный кал, можно высрать примитивный хеллоуворлд, из приложений только документная модель, диалоги делать не выйдет. Сколько-нибудь серьезное приложение пишется только на VCL, это единственное что доступно публично для работы и не говно, остальное закрыто в крупных фирмах для себя, по сути не существует. Пердольное говно вроде wxwidgets или qt даже не рассматривается, детектор пиздабола.
На qt довольно много всего сложного написано, это один из самых популярных UI фреймворков за последние лет 10 точно.
wxwidgets реально мертвая залупа. VCL, MFC, TCL и прочее - это все кал мамонта.
сейчас гуи делается
- электрон (де факто стандарт и много лет как топ1 gui фреймворк для десктопа)
- qt (тоже стандарт)
И на этом по сути выбор кончается. Но при этом еще есть
- целая портянка из swing/awt, javafx, compose multiplatform для java/kotlin
- winforms/wpf для сишарпа + avalonia
- tauri для раста
- wails для Go
- swiftUI для swift/macos
и этот список можно продолжать бесконечно.
в любом случае, какими бы хорошими фреймворки и либы не были - кроссплатформенный UI это очень больно даже в 2026 году.
По сути ситуация стала чуть лучше с появлением электрона и прочих UI фреймворков которые тянут за собой хромиум и v8 движок где нативно рисуют хтмл/цсс/js.
Вот пока что ничего лучше хтмл/цсс/js тупо нет.
Делфи в каком-то смысле был неплох и для своих лет был крайне удобной шуткой. Другое дело что borland сдох, как и embarcadero собственно, ничего нового там уже последние лет 10 наверное не происходило, продукт тупо на поддержке живет чтобы оставшиеся старые энтерпрайз клиенты не разбежались, но в остальном судьба c++ builder, delphi, vcl де-факто давно решена.
Взвизги повесточных пердоликов с консолью в сраке, у которых из гуёв только браузер, никому не интересны. Под шконку, шваль, тебя вообще не существует, болванчик перехрюкивающий пропаганду корпораций.
Пердолики в софте буквально фемки в играх, сами не играют, но зато визга издают много мешая людям жить.
>Мс-офис пишется майкрософт на неизвестных внутренних тулкитах.
Прочти внимательнее, что я написал. Office пишется с применением Visual C++ с MFC или без. Если на внутренних тулкитах - то без MFC. Про это я и написал. Впрочем, ранние версии Office скорее использовали MFC, я полагаю.
>Браузеры вообще на javascript.
А про браузеры - я открываю исходники Chrome и вижу C++.
Основная моя мысль была - что на C++ Builder ты софт такого уровня не напишешь. Непосильно это.
> на C++ Builder ты софт такого уровня не напишешь. Непосильно это.
Написать-то можно, только VCL тут скорее будет мешать, чем помогать.
>А про браузеры - я открываю исходники Chrome и вижу C++.
Всё что нужно знать про еблана не понимающего даже на чем браузер написан. Отсюда и такие же тупорылые домыслы про "полезный MFC" и "бесполезные Дельфи/Сибилдер". Бабки на лавочке болтали, а еблан шел мимо и краем уха слышал, вот и повторяет.
> как можно ближе к машинному коду
Бери ФОРТ http://www.forth.org.ru/ язык проще некуда, очень близко к асемблеру, есть примеры на русском как писать под winapi
>Сейчас ещё ботохуета помочь может
Но не написать весь код
мимо джава господин
>очень близко к асемблеру
Где вы-дебилы нахватались этой галиматьи?
Неа. Функционал того же Билдера 6.0 слабенький. Там например нет даже настройки Pre-Build, Post-Build steps. Не поддерживаются makefiles. Скудные настройки компилятора и проч. сборки.
А ещё VCL там не поддерживает Unicode. Это вообще позор.
>Встречаются мне регулярно понятия такие как - поток, ядро, дескрипторы
>Windows Internals
В таких книгах про это пишут. Или про внутрянку линухов книги.
>>3718425
Ну вообще там если поверхностно, то все просто:
поток - можно сказать единица исполнения. Т.е. кусок кода, расположенный в памяти и на регистрах проца. ОСь и проц, умеют жанглировать потоками - типа менять их местами, с сохрарненим данных, магически, как фокусники. Здесь не помешает понимаение выполнения ф-й на ассемблере. Все из-за регистров (стэка и других), которые нужно сохранять и восстанавливать.
ядро - ну эта сама ОСь и драйвера. Они крутится в защищенной области памяти, куда нет доступа (если не использовать дыры), обычным программам (играм и браузерам и т.п.). ОСь и дрова, имеют прямой доступ к железу. Еще драйвера, могут так поднасрать, что мало не покажется. Поэтому, опасно ставить таблетки на базе гипервизора. И поэтому на винде, можно без бубна, установить только подписанные (с соглашения m$) драйвера.
* дескриптор - любой объект ядра, имеет идентификатор - дескриптор. Файл, сокет, область памяти, семафор, мутекс, поток.. Когда ПО (браузер или видеоплеер) открывает файл, то ОСь открывает файл, а в юзерспес ПО отдает только его дескритор (handle (DWORD)). Ну и если надо в файл что-то записать или прочитать, то ПО через ф-ю, обращется к ОСи -
запись_в_файл(дескриптор, буфер_в_памяти, смещение и всякие парметры). ОСь берет находит нужный файл по дескриптору и пишет в него из памяти. Кстати, при обращении к системным ф-ям (т.е. ф-ям ОСи) происходит переключение контекста - т.е. переключение из режима юзерспеса (когда проц вертит код юзерского ПО), на режим, когда проц вертит код ядра или драйверов. Это сделано для безопасности и отжирает время. Поэтому такие расходы стараются минимизировать. Например писать в файл сразу буфер из памяти, а не по байту. Ну и есть более современные приемы.
Но если ты будешь писать прикладное ПО, глубокое понимание таких процессов, тебе пригодится, в 99% случаев, только чтобы получить одобрение, от какого-нибудь ботана, на собеседовании и вкатиться в конторку. Далее, будешь использовать популярные фреймворки по перекладыванию json-ов. :)
>>3718433
>>3711150 (OP)
какие нахуй книги
гитхаб.ру/виндовс_нт_слитые_исходники
и пошёл читать как деды складывали дворды в уме и неистово ебашили событийную архитектуру
в актуальных окнах поменялось примерно нихуя
У Зубкова в книге по ассемблеру приводится пример, как можно организовать многопоточное выполнение программ. Вот буквально приводится код, который организует жонглирование вот этими вот потоками. Манипуляции по переключению стека. Плюс приводятся сведения про всякие там организации системных вызовов ОС - все эти Гейты, Ловушки, переключения контекста и прочая. Про прерывания тоже рассказывается.