Что в DLL и как оно работает?

Я всегда ссылаюсь на библиотеки DLL в своем коде на С#, но они остались загадкой, которую я хотел бы уточнить. Это своего рода мозговой свалкой вопросов относительно DLL.

Я понимаю, что DLL - это динамически связанная библиотека, что означает, что другая программа может получить доступ к этой библиотеке во время выполнения, чтобы получить "функциональность". Однако рассмотрим следующий проект ASP.NET с Web.dll и Business.dll (Web.dll - это функциональность переднего конца и ссылается на Business.dll для типов и методов).

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

1а. Кроме того, что загружает и связывает DLL - ОС или некоторые рамки времени выполнения, такие как .NET framework?

1b. Каков процесс "связывания"? Выполнены ли проверки совместимости? Загрузка в ту же память? Что означает связь?
Что на самом деле выполняет код в DLL? Выполняется ли это процессором или есть еще один этап перевода или компиляции, прежде чем процессор поймет код внутри DLL?

2а. В случае DLL, встроенного в С#.NET, что работает:.NET framework или операционная система напрямую?
Является ли DLL из Linux работать в системе Windows (если такая вещь существует) или они зависят от операционной системы?
Являются ли библиотеки DLL конкретными для конкретной структуры? Может ли DLL, построенная с использованием С#.NET, использоваться DLL, построенной с помощью, например, Borland С++?

4а. Если ответ на 4 "нет", то в чем же суть DLL? Почему различные фреймворки не используют свои собственные форматы для связанных файлов? Например:.exe, встроенный в .NET, знает, что тип файла .abc - это то, что он может связать с его кодом.
Возвращаясь к примеру Web.dll/Business.dll - для получения типа класса клиента мне нужно ссылаться Business.dll на Web.dll. Это должно означать, что Business.dll содержит некоторую спецификацию относительно того, что на самом деле представляет собой класс клиента. Если бы я скомпилировал мой файл Business.dll, скажем, в Delphi: понял бы С# и сможет создать класс клиента, или есть какая-то информация заголовка или что-то, что говорит: "извините, вы можете использовать меня только от другого Delphi DLL"?

5а. То же самое относится к методам; могу ли я написать метод CreateInvoice() в DLL, скомпилировать его на С++, а затем получить доступ и запустить его с С#? Что останавливает или позволяет мне это делать?
Что касается захвата DLL, то, конечно, замена (плохая) DLL должна содержать точные подписи и типы методов, которые находятся под угрозой. Я полагаю, это было бы непросто сделать, если бы вы могли узнать, какие методы были доступны в исходной DLL.

6а. Что в моей программе на С# решает, могу ли я получить доступ к другой DLL? Если бы моя захваченная DLL содержала точно такие же методы и типы, что и оригинал, но была скомпилирована на другом языке, работала бы она?

Что такое импорт DLL и регистрация DLL?

Ответ 1

Здесь я иду, не стесняйтесь указывать на какие-либо ошибки. Я не совсем эксперт с внутренними компонентами Windows...

Прежде всего, вам нужно понять разницу между двумя очень разными типами DLL. Microsoft решила пойти с теми же расширениями файлов (.exe и .dll) как с .NET(управляемым кодом), так и с собственным кодом, однако управляемые DLL файлы и собственные DLL файлы сильно отличаются друг от друга.

1) В какой момент web.dll динамически ссылается на business.dll? Вы много заметят в жестком диске Windows для кажущихся небольшие задачи, когда используя Word и т.д., и я считаю, что это Слово уходит и динамично ссылки на функциональность из других DLL?

1) В случае .NET DLL обычно загружаются по требованию, когда выполняется первый метод, пытающийся получить доступ к чему-либо из DLL. Вот почему вы можете получить TypeNotFoundExceptions в любом месте вашего кода, если DLL не может быть загружена. Когда что-то вроде Word внезапно начинает доступ к жесткому диску, он, вероятно, меняет местами (получая данные, которые были выгружены на диск, чтобы освободить место в ОЗУ)

1a) Кроме того, какие нагрузки и ссылки DLL - O/S или некоторые среда выполнения, такая как .Net framework?

1a) В случае управляемых DLL, платформа .NET - это то, что загружается, JIT компилирует (компилирует байт-код .NET в собственный код) и связывает библиотеки DLL. В случае родных DLL это компонент операционной системы, который загружает и связывает DLL (компиляция не требуется, потому что собственные DLL уже содержат собственный код).

1b) Каков процесс "связывания"? Проверяются ли проверки совместимость? Загрузка в ту же память? Что связывает на самом деле означает?

1b) Связывание - это когда ссылки (например, вызовы методов) в вызывающем коде на символы (например, методы) в DLL заменяются фактическими адресами вещей в DLL. Это необходимо, потому что возможные адреса объектов в DLL не могут быть известны до того, как они будут загружены в память.

2) Что фактически выполняет код в DLL? Выполняется ли оно процессор или есть другой этап перевода или компиляции до того, как процессор поймет код внутри DLL?

2) В Windows файлы EXE и DLL файлы совершенно идентичны. Файлы Native.exe и .dll содержат собственный код (тот же самый материал, который выполняет процессор), поэтому нет необходимости переводить. Управляемые файлы .exe и .dll содержат .NET bytecode, который сначала скомпилирован JIT (переведен в собственный код).

2a) В случае DLL, построенного из С#.net, что это такое?.Net или операционная система напрямую?

2a) После того, как код был скомпилирован JIT, он работал точно так же, как и любой код.

3) Говорит ли DLL, что Linux работает в системе Windows (если такая вещь существует) или они зависят от операционной системы?

3) Управляемые DLL файлы могут работать как есть, при условии, что рамки на обеих платформах обновлены, и тот, кто писал DLL, не намеренно нарушал совместимость, используя собственные вызовы. Собственные библиотеки DLL не будут работать как в режиме, так как форматы разные (хотя машинный код внутри один и тот же, если они оба предназначены для одной и той же процессорной платформы). Кстати, в Linux "DLL" известны как файлы .so(shared object).

4) Являются ли они конкретными для конкретной структуры? Может ли DLL построить с использованием С#.Net будет использоваться DLL, построенной с Borland С++ (только пример)?

4) Управляемые DLL файлы относятся к платформе .NET, но, естественно, они работают с любым совместимым языком. Собственные библиотеки DLL совместимы до тех пор, пока все используют одни и те же соглашения (вызывающие соглашения (как передаются аргументы функции на уровне машинного кода), именование символов и т.д.)

5) Вернемся к примеру web.dll/business.dll. Чтобы получить класс тип клиента Мне нужно ссылаться на business.dll из web.dll. Эта должен означать, что business.dll содержит спецификацию какого-либо рода что на самом деле представляет собой класс клиентов. Если бы я скомпилировал свой файл business.dll файл в Delphi будет С# понимать его и иметь возможность создать класс клиента - или есть какая-то информация заголовка или что-то который говорит: "Эй, извините, вы можете использовать меня только из другой delphi dll".

5) Управляемые библиотеки DLL содержат полное описание каждого класса, метода, поля и т.д., которые они содержат. AFAIK Delphi не поддерживает .NET, поэтому он будет создавать собственные DLL файлы, которые не могут использоваться в .NET прямо. Вероятно, вы сможете вызывать функции с помощью PInvoke, но определения классов не будут найдены. Я не использую Delphi, поэтому я не знаю, как он хранит информацию о типе с DLL. Например, С++ использует файлы заголовков (.h), которые содержат объявления типов и должны быть распространены с помощью DLL.

6) Что касается захвата DLL, то, конечно, замена (плохая) DLL должен содержать точные сигнатуры метода, типы, которые являются будучи захваченным. Я полагаю, это было бы непросто сделать, если бы вы могли найти какие методы и т.д. были доступны в исходной DLL.

6) Действительно, это не сложно сделать, если вы можете легко переключить DLL. Чтобы избежать этого, можно использовать подписание кода. Чтобы кто-то заменил подписанную DLL, они должны были знать ключ подписи, который он сохранял в секрете.

6a) Здесь немного повторяющегося вопроса, но это связано с тем, что в моем Программа С# решает, могу ли я получить доступ к другой DLL? Если моя захваченная DLL содержал точно такие же методы и типы, что и оригинал, но он был скомпилирован в другом lanugage, если бы он работал?

6a) Это будет работать до тех пор, пока это управляемая DLL, сделанная с любым языком .NET.

Что такое импорт DLL? и регистрации dll?

"Импорт DLL" может означать много вещей, обычно это означает ссылку на DLL файл и использование в нем вещей.

Регистрация DLL - это то, что сделано в Windows, чтобы глобально регистрировать DLL файлы как COM-компоненты, чтобы сделать их доступными для любого программного обеспечения в системе.

Ответ 2

1) В какой момент web.dll динамически ссылается на business.dll? Вы много заметят в жестком диске Windows для кажущихся небольшие задачи, когда используя Word и т.д., и я считаю, что это Слово уходит и динамично ссылки на функциональность из других DLL?

1) Я думаю, вы путаете связь с загрузкой. Ссылка - это когда все проверки и противовесы проверены, чтобы быть уверенным, что запрашивается. Во время загрузки части DLL загружаются в память или заменяются на файл подкачки. Это активность HD, которую вы видите.

Динамическое связывание отличается от статической привязки тем, что при статической привязке весь объектный код помещается в основной файл .exe во время ссылки. При динамической компоновке объектный код помещается в отдельный файл (dll), и он загружается в другое время из .exe.

Динамическое связывание может быть неявным (например, соединение с импортом lib) или явным (например, приложение использует LoadLibrary (ex) для загрузки dll).

В неявном случае /DELAYLOAD можно использовать для откладывания загрузки dll до тех пор, пока приложение действительно не понадобится. В противном случае, как минимум часть его загружается (отображается в адресное пространство процесса) как часть инициализации процесса. DLL также может запрашивать что он никогда не будет выгружен, пока процесс активен.

COM использует LoadLibrary для загрузки COM-библиотек. Обратите внимание, что даже в неявном случае система использует что-то похожее на LoadLibrary для загрузки DLL либо при запуске процесса, либо при первом использовании.

2) Что фактически выполняет код в DLL? Выполняется ли оно процессор или есть другой этап перевода или компиляции до того, как процессор поймет код внутри DLL?

2) Dll содержат объектный код так же, как и .exes. Формат DLL файла почти идентичен формату EXE файла. Я слышал, что в заголовках этих двух файлов есть только один бит.

В случае библиотеки DLL, построенной из С#.net, инфраструктура .Net запускает ее.

3) Говорит ли DLL, что Linux работает в системе Windows (если такая вещь существует) или они зависят от операционной системы?

3) Библиотеки DLL специфичны для платформы.

4) Являются ли они конкретными для конкретной структуры? Может ли DLL построить с использованием С#.Net будет использоваться DLL, построенной с Borland С++ (только пример)?

4) Dll могут взаимодействовать с другими фреймворками, если будет предпринята особая осторожность или будет написан дополнительный код клея.

Dll очень полезны, когда компания продает несколько продуктов, которые имеют перекрывающиеся возможности. Например, я поддерживаю dll растрового ввода-вывода, который используется более чем 30 различными продуктами в компании. Если у вас установлено несколько продуктов, одно обновление DLL может обновить все продукты до новых растровых форматов.

5) Вернемся к примеру web.dll/business.dll. Чтобы получить класс тип клиента Мне нужно ссылаться на business.dll из web.dll. Эта должен означать, что business.dll содержит спецификацию какого-либо рода что на самом деле представляет собой класс клиентов. Если бы я скомпилировал свой файл business.dll файл в Delphi будет С# понимать его и иметь возможность создать класс клиента - или есть какая-то информация заголовка или что-то который говорит: "Эй, извините, вы можете использовать меня только из другой delphi dll".

5) В зависимости от платформы возможности dll представлены различными способами, через .h файлы,.tlb файлы или другие способы в .net.

6) Что касается захвата DLL, то, конечно, замена (плохая) DLL должен содержать точные сигнатуры метода, типы, которые являются будучи захваченным. Я полагаю, это было бы непросто сделать, если бы вы могли найти какие методы и т.д. были доступны в исходной DLL.

6) dumpbin/exports и dumbin/import - интересные инструменты для использования на .exe и .dlls

Ответ 3

Файл .dll содержит скомпилированный код, который вы можете использовать в своем приложении.

Иногда инструмент, используемый для компиляции .dll, иногда имеет значение. Если вы можете ссылаться на .dll в своем проекте, не имеет значения, какой инструмент использовался для кодирования открытых функций .dll.

Связывание происходит во время выполнения, в отличие от статически связанных библиотек, таких как ваши классы, которые связаны во время компиляции.

Вы можете думать о .dll как о черном ящике, который обеспечивает то, что требует ваше приложение, которое вы не хотите писать сами. Да, кто-то, кто понимает подпись .dll, может создать другой DLL файл с другим кодом внутри него, и ваше вызывающее приложение не сможет узнать разницу.

НТН

Ответ 4

Файл Dll скомпилирован с выходом нашего исходного кода. Что мы пишем в VS или каком-либо другом инструменте, будем называть исходным кодом. После написания на компьютерах необходимо понимать выполнение необходимых действий. Так что мы выполняем операцию сборки, где код будет преобразован в языки машинного уровня.
Таким образом, встроенный файл известен как Dll файл.