Какая форма является DLL и что делает ее зависимой от процессора - PullRequest
0 голосов
/ 18 ноября 2009

Я знаю, что DLL содержит одну или несколько экспортируемых функций, которые компилируются, связаны и хранятся отдельно.

Мой вопрос не о том, как его создать. Но все дело в том, в какой форме он хранится. Будет ли он в форме 0 и 1 или в командах сборки ADD, MUL DIV, MOV, CALL, ВОЗВРАТ и т. Д. Кроме того, что делает его зависимым от процессора .. (например, x86, x87, набор команд IBM 700) ..

Может кто-нибудь объяснить, пожалуйста, немного вкратце ..!

Ответы [ 5 ]

4 голосов
/ 18 ноября 2009

Прежде всего, все в компьютере имеет вид «0 и 1». Тот факт, что компьютер может отображать некоторые из них в виде текста, изображений, звуков, 3D-моделей и т. Д., Зависит только от того, как вы их интерпретируете. Но там, в металле, все это просто «0 и 1» (также известные как биты). Обратите внимание, что они всегда сгруппированы в группы по 8, и они называются «байтами». Это действительно ради эффективности, потому что работать с каждым битом по отдельности было бы слишком утомительно. На самом деле, современные компьютеры даже не работают с одиночными байтами (точнее, они делают это очень редко). В основном вы работаете с 4 или 8 байтами за раз, в зависимости от того, есть ли у вас 32-битный или 64-битный процессор (это с точки зрения непрофессионала, на самом деле это немного сложнее).

Что касается файла .DLL - например, файла .EXE, он содержит байты, которые описывают инструкции, которые может выполнять ЦП. Процессор берет эти байты непосредственно из .DLL / .EXE и выполняет их без каких-либо дальнейших изменений. Вот почему эти файлы зависят от процессора. В разных архитектурах ЦП одна и та же комбинация байтов означает разные вещи, поэтому .DLL / .EXE будет корректно работать только на ЦП, для которого он был разработан. На других процессорах эти байты будут означать некоторые другие инструкции, и при запуске программа, скорее всего, немедленно совершит какую-то ерунду и вылетит.

Упомянутые вами команды сборки также заслуживают объяснения. «Ассемблер» - это не тот язык, который процессор может понимать. Это язык, который человек может понять. Он был создан потому, что писать непосредственно в машинном коде (байты, которые процессор на самом деле понимает) очень сложно. То, что вы получаете, это полная чепуха на экране (попробуйте открыть какой-нибудь файл .EXE в Блокноте!), Но каждый бит должен быть точно установлен, чтобы он работал.

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

Итак, вы видите, что нет даже одного языка ассемблера. Каждая архитектура ЦП имеет свой собственный язык ассемблера, потому что у каждого из них разные инструкции.

Обратите внимание, что все это относится к собственным файлам .DLL / .EXE. Файлы .NET отличаются - они содержат не машинный код, а инструкции для абстрактного несуществующего процессора. Это как байт-коды Java. Когда запускается .NET .DLL / .EXE, среда выполнения .NET переводит его из абстрактных инструкций в инструкции, понятные конкретному ЦП. Они используют множество приемов, чтобы сделать это очень быстро, поэтому эти файлы работают почти так же быстро, как и простые файлы .DLL / .EXE.

Это проясняет ситуацию? :)

2 голосов
/ 18 ноября 2009

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

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

2 голосов
/ 18 ноября 2009

Собственные библиотеки DLL (не сборки .NET) обычно содержат машинный код, который может быть запущен только на определенной платформе. Машинный код - это последовательность байтов, которую процессор обрабатывает как инструкции (ADD, MOV и т. Д.).

1 голос
/ 18 ноября 2009

это зависит от вашей DLL. Как правило, DLL содержит исполняемый код в виде файла EXE. эти DLL-библиотеки кода зависят от процессора, так как код может выполняться только на конкретной платформе. код хранится в том же «формате», что и файл EXE (двоичный машинный код).

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

обратите внимание, что многие библиотеки DLL являются гибридами: они содержат как код, так и ресурсы. Например, большинство библиотек DLL, которые включают пользовательскую часть операционной системы Windows, являются гибридными: вы можете открыть их с помощью Visual Studio или Resource Explorer, чтобы просмотреть содержащиеся в них ресурсы (сегменты данных), или открыть их с помощью Dependency Walker или мусорной корзины, чтобы см. функции (сегменты кода), которые они содержат.

(конечно, этот ответ действительно специфичен для Windows, я не знаю, для файлов .so, которые являются эквивалентом Linux для Linux)

0 голосов
/ 18 ноября 2009

И DLL, и EXE содержат исполняемый код.

В случае DLL она не имеет необходимых частей для непосредственного выполнения. Он должен вызываться из другого фрагмента исполняемого кода. Одна DLL может вызывать другую, но в конечном итоге все они должны вызываться из EXE.

Таким образом, правила о том, что совместимо с тем, какой процессор применяется к EXE-файлам, также применяются к DLL.

...