Прелюдия: Это, по общему признанию, довольно широкий вопрос, касающийся компьютерной архитектуры, но тот, который я слышу от других, и задаюсь вопросом довольно часто о себе. Я также не думаю, что есть прямой или быстрый ответ на это. Тем не менее, я надеялся, что кто-то хорошо разбирающийся в архитектуре систем сможет дать некоторое представление.

Немного предыстории: я в основном разработчик полного стека, специализирующийся в основном на веб-технологиях и базах данных У меня есть некоторый опыт работы с языком Си и работа с большим количеством низкоуровневых вещей, но это было очень давно и не было академическим. Таким образом, я никогда не углублялся в архитектуру ОС, и это одна вещь, которая ускользает от меня. Мне известны различные методы и методы выполнения этих задач (особенно на более высоком уровне с технологиями, предназначенными для этой цели), но мне не хватает целостного представления / понимания низкоуровневой логистики о том, как это происходит - особенно на уровне ОС ,

Общий вопрос: как приложения, работающие внутри «контейнера», фактически взаимодействуют с работающим экземпляром этого контейнера? Под «контейнером» я подразумеваю экземпляр запущенного кода, который уже загружен в память (примерами такого кода могут быть операционная система, интерфейс графического рисования, сервер приложений, драйвер и т. Д.).

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

Например

Допустим, я создаю простую библиотеку, цель которой - нарисовать пиксель на экране. Давайте также скажем, что у этой библиотеки есть один метод,drawPixel(int x, int y).

Сама библиотека управляет своим собственным контекстом рисования (который может быть чем угодно, от необработанного буфера SVGA до окна рабочего стола). Приложения, использующие этот API, просто динамически связываются с библиотекой и вызываютdrawPixel метод, без какой-либо осведомленности о точных действиях библиотеки после вызова.

Под капотом этотdrawPixel метод должен рисовать в окне на рабочем столе, создавая его, если он не существует при первом вызове.

Тем не менее, технически, что произойдет, если установка будет такой простой и понятной, так это то, что каждое вызывающее приложение будет «извлекать и запускать» весь код вdrawPixel и его зависимостей, фактически заставляя каждое запущенное приложение иметь собственный запущенный экземпляр всей цепочки вызовов (и, таким образом, если бы оно вызывалось 5 разными приложениями, вы бы получили 5 разных окон вместо общего контекста для одного окна). ). (Я надеюсь, что я объясняю это правильно)

Итак, мой вопрос: как происходит это «совместное использование» в современных операционных системах?

Будет ли код дляdrawPixel на самом деле заменить на код IPC? Или это будет обычный графический код, но каким-то образом «загруженный» в ОС таким образом, что существует один общедоступный работающий экземпляр, который другие приложения вызывают по желанию?

Некоторые случаи, о которых я знаю

Я знаю, что есть много подходов к этой проблеме, и знаю о некоторых из них.Тем не менее, все они, кажется, относятся к конкретным нишам и имеют недостатки; ни один из них не обладает достаточной полнотой для объяснения невероятных возможностей (в отношении взаимосвязанности ОС и служб приложений) современных экосистем приложений.

Например:

В старые (ДОС) дни я верюapp <-> OS связь осуществлялась через системные прерывания.В мире UNIX это делается черезstdin/stdout каналы на консоли и сетевой протокол в X Windows.Существовали платформы IPC, такие как COM + / DCOM / DCOP / DBus для Windows и Linux, но, опять же, они, похоже, предназначены для определенной цели (создание и управление компонентами в масштабе; предшественники современной SOA).Вопрос

Каковы другие способы облегчения такого общения? Или, более конкретно, как «это делается» в традиционном смысле, особенно когда речь идет об ОС API?

Некоторые примеры более конкретных вопросов:

Как ядро ​​«загружает» драйвер устройства при загрузке, который запускает свой собственный код (в изолированном пространстве?), Но все еще взаимодействует с ядром над ним, которое в данный момент работает в памяти? Как происходит это общение?

Как взаимодействуют оконные подсистемы (за исключением X и Quartz, которые используют сокеты)? Я думаю, что WIN32 использовал прерывания (возможно, это все еще делает?), Но как работает более новый материал? Я был бы очень удивлен, обнаружив, что даже в наши дни сложные среды, такие как WPF или Metro, все еще сводятся к вызову прерываний. Я на самом деле не уверен, что API-интерфейсы WIN32 даже используются этими системами.

Как насчет низкоуровневых графических подсистем, таких как GDI + и Linux Framebuffer?

Примечание: я думаю, что в случае WIN32 (и, возможно, GDI +), например, вы получаете указатель (дескриптор) на контекст, поэтому концепция фактически является «разделяемой памятью». Но так ли это просто? Было бы довольно небезопасно просто получить необработанный указатель на необработанный ресурс. Это означает, что есть вещи, которые защищают вас от записи произвольных данных в этот указатель, поэтому я думаю, что он более сложный, чем этот.

(это может быть немного вне контекста, поскольку это специфично для JVM) Как сервлеты, работающие на сервере приложений, общаются с реальным сервером приложений? Имеется в виду, как они загружают себя "в контексте" текущего запущенного сервера?

Тот же вопрос для IIS - как точно настроена сантехника, чтобы IIS могла контролировать и взаимодействовать с отдельным процессом, выполняющим приложение ASP.NET?

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

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