В чем архитектурная разница между разделяемым объектом (SO) и библиотекой динамической компоновки (DLL)?

Вопрос в значительной степени содержится в заголовке: с точки зрения реализации на уровне ОС, чем отличаются общие объекты и библиотеки DLL?

Причина Я спрашиваю, это потому, что я недавно прочитал эту страницу о расширении Python, где говорится:

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

В Unix файл общих объектов (.so) содержит код, который будет использоваться программой, а также имена функций. и данные, которые он ожидает найти в программе. Когда файл присоединяется к программе, все ссылки на эти функции и данные в коде файла изменяются, чтобы указывать на фактические места в программе, где функции и данные помещаются в память. По сути, это операция компоновки.

В Windows файл библиотеки динамической компоновки (.dll) не имеет висящих ссылок. Вместо этого доступ к функциям или данным осуществляется через справочную таблицу. Таким образом, код DLL не нужно исправлять во время выполнения, чтобы обращаться к памяти программы; вместо этого код уже использует таблицу поиска DLL, а таблица поиска модифицируется во время выполнения, чтобы указывать на функции и данные.

Может ли кто-нибудь уточнить это? В частности, я не уверен, что понимаю описание общих объектов, содержащих ссылки на то, что они ожидают найти. Точно так же для меня DLL звучит примерно так же.

Это полное объяснение того, что происходит? Есть лучшие? Есть ли на самом деле какая-то разница?

Я знаю, как подключиться к DLL или общему объекту и пару механизмов (списки .def, dllexport / dllimport) для написания библиотек DLL, поэтому я явно не ищу, как на эти области; Меня больше заинтриговало то, что происходит в фоновом режиме.

(Edit: еще один очевидный момент - я знаю, что они работают на разных платформах, используют разные типы файлов (ELF против PE), несовместимы с ABI и т. Д. ...)