Как установить DLL файлы на Windows?

Файл DLL – компонент динамически подключаемой библиотеки, чьи элементы используют практически все программы. Библиотека DLL файлов расположена в корневой папке системы. Компоненты должны быть все в наличии, иметь цифровую подпись, правильно работать и быть актуальными по версии. Если одно из требований не соблюдено, при запуске программы пользователь получит информационное уведомление: ошибка DLL. Неисправность свидетельствует о том, что отсутствует DLL файл, поврежден или устарел.

Как установить DLL файл

Чтобы программы, приложения и игры снова начали работать, необходимо установить вручную недостающие компоненты библиотеки. Просто поместить файл в папку недостаточно ─ нужно знать как их зарегистрировать.

Помещение и регистрация файлов библиотеки

Перед тем как установить DLL файл на Windows 7,8,10, их нужно скачать, причем точно под разрядность системы.

Давайте определим, какая разрядность у Вашей системы (если вы точно знаете, может пропустить этот шаг)

Шаг 1. Кликаем правой кнопкой мыши по «Мой компьютер» и выбираем «Свойства»

Шаг 2. В открывшемся окне, мы может прочитать свойства компьютера, версию операционной системы и её разрядность 32 (х86) или 64 бит. В нашем случаи стоит 64-разрядная операционная система Windows 10.

·

Шаг 3. После скачивания файлов их нужно поместить в корневую папку, зарегистрировать

для х32 (х86) систем компонент необходимо заменить или поместить в папку C:\Windows\System32;

для х64 необходимо выполнить замену или переместить в папку C:\Windows\ SysWOW64;

Шаг 4. Файл нужно зарегистрировать в системе.

Сделать это можно, открыв командную строку комбинацией «Win» + «R», или нажать «Пуск» и «Выполнить»;

в открывшемся окне ввести через пробел следующее: regsvr32 имя файла.dll – где, «regsvr32» ─ команда для регистрации, а «имя файла.dll» – полное имя вставленного компонента;

или же можно прописать расположение файла вручную — regsvr32.exe + путь к файлу

Шаг 5. Нажмите «ОК», и перезагрузите компьютер, и новые параметры вступят в силу.

Сразу хочется отметить, что при регистрации возможны появления ошибок. Например: «Не удалось загрузить модуль». Обычно они возникают по 3 причинам

1. Не правильно прописан путь к файлу, или файл не был перемещен в каталог System32 или SysWOW64
2. Не все файлы DLL вообще нуждаются в регистрации, иногда достаточно просто скопировать их в каталок System32 или SysWOW64 или поместить в корень проблемной игры или программы
3. Файлы уже были зарегистрированы ранее

Второй способ регистрации

Шаг 1. Зарегистрировать файл можно с помощью командой строки, которую нужно запустить от имени администратора.

Шаг 2. Пишем команду regsvr32.exe + путь к файлу и жмём «Enter»

Шаг 3. Появится сообщение что «Всё прошло удачно», и просто перезагружаем компьютер

Вот и всё, файл зарегистрирован, можете пробовать запускать вашу игру или программу

А вот, некоторые советы, которые могут вам пригодиться.

• Помещайте элементы только в указанную папку (возможно, она будет скрыта по умолчанию). Вам нужно убрать галочку «Не показывать скрытые папки» в настройках отображения.
• Если при замене файла требуется разрешение администратора – подтвердите действие.
• Выбирайте только актуальные файлы на момент загрузки и сохраните их себе в компьютер отдельно. Вам они могут еще пригодиться. В случае если проблема образуется вновь, вы быстро восстановите работоспособность системы.
  

Как windows ищет dll

В каком порядке производится поиск нужной приложению dll?
Сначала в каталоге с exe, потом в системных виндовса, а потом в переменных path. Вроде я сам ответил на свой вопрос, но на самом деле это не полный ответ. Из этого ответа не понятно как получить путь к dll которая реально будет загружена.
Или может есть какая функция для этого? (но я её не нашёл)

ps. Вопрос получился немного сумбурным, но я честное слово переписывал его несколько раз — это лучший вариант 🙂

← →
Skier ( 2003-08-13 14:41 ) [1]

Цель-то конечная какая ?

← →
Dimka Maslov ( 2003-08-13 14:47 ) [2]

Используй функции LoadLibrary и GetProcAddress, а не статическую компоновку.

← →
Reindeer Moss Eater ( 2003-08-13 14:55 ) [3]

LoadLibrary тоже может не дать прямого ответа на вопрос какая библиотека загрузилась.

← →
clickmaker ( 2003-08-13 15:07 ) [4]

А GetModuleFileName на что?

Где ищутся DLL?
Ответ для 9х:
1) Каталог откуда запустился exe»шник
2) Текущий каталог
3) System32
4) System
5) Windows
6) %PATH%

Если в реестре для данной библиотеке прописан специальный путь поиска, то используется он.

Если в памяти уже есть библиотека с таким же именем, то используется она.

← →
Reindeer Moss Eater ( 2003-08-13 15:12 ) [6]

Если в реестре для данной библиотеке прописан специальный путь поиска, то используется он.

Поправка:
Если в реестре для данного приложения прописан специальный путь поиска, то используется он.

← →
Dimka Maslov ( 2003-08-13 15:16 ) [7]

>Reindeer Moss Eater © (13.08.03 14:55) [3]
LoadLibrary позволяет явным образом указать путь к загруженной библиотеке.

Второй путь — сделать из библиотеки COM-сервер c пропиской в реестре, тогда можно быть уверенным, что загрузится нужная библиотека

← →
Reindeer Moss Eater ( 2003-08-13 15:20 ) [8]

Dimka Maslov
LoadLibrary тоже может не дать прямого ответа на вопрос какая библиотека загрузилась.

← →
AlexKniga ( 2003-08-13 15:31 ) [9]

Reindeer Moss Eater © (13.08.03 15:12) [6]
Да.

> Dimka Maslov © (13.08.03 14:47) [2]
> Используй функции LoadLibrary и GetProcAddress, а не статическую компоновку.
Забыл сказать, что это два разных приложения: одно которое собственно загружает (требует) dll, а второе которое должно «угадать» какую из dll загрузит первое приложение. И находятся эти два приложения в совершенно разных каталогах и друг с другом никак не связаны.

Я провёл маленький эксперимент — написал приложение которое требует dll которого не существует, и изменил переменные окружения «path» следующим образом: пользовательский «path»: «c:\apath», а системный «path»: «d:\apath». После запуска этого приложения естественно появляется сообщение об ощибке такого содержания:

TestPath.exe — Unable To Locate DLL
The dynamic link library kernel34.dll could not be found in the specified path E:\Programs\Delphi6\Projects\Test\path;.;E:\WINNT\System32;E:\WINNT\sy stem;E:\WINNT;E:\Programs\Far1705;d:\apath;c:\apath.

Т.е. сначала ищет в текущем каталоге (потом в какойто точке[?] какая разница между текущим каталогом и точкой я не понял), потом в системных папках, потом в системной «path» и наконец в пользовательском «path».
И тут возникает сразу два вопроса:
1. Откуда берётся информация о расположении системных каталогов (ведь под другой версией винды они могут быть и другими).
2. Что это за странную информацию мне возвращает функция GetEnvironmentVariable : E:\Programs\Delphi5\Bin;d:\apath;c:\apath?

Но это всё относится к «ручному» способу, а вот может есть какая стандартная функция?

← →
AlexKniga ( 2003-08-13 15:45 ) [11]

Borealis (13.08.03 15:36) [10]> пользовательский «path»: «c:\apath», а системный «path»: «d:\apath»
.

← →
Reindeer Moss Eater ( 2003-08-13 15:51 ) [12]

1. Откуда берётся информация о расположении системных каталогов (ведь под другой версией винды они могут быть и другими).

Хочешь сказать что странно, когда Windows знает где у нее её системные каталоги и странно когда Windows знает кто она — Nt или 9x?

← →
Borealis ( 2003-08-13 16:02 ) [13]

> AlexKniga © (13.08.03 15:45) [11]
> Borealis (13.08.03 15:36) [10]>пользовательский «path»:
> «c:\apath», а системный «path»: «d:\apath»
> .
🙂
Ну если нажать правой кнопкой на иконке «My Computer», щёлкнуть по «Properties», выбрать закладку «Advanced» и нажать кнопку «Environment variables. » появится окно с двумя ListView»ами, верхнее озаглавлено как «User variables for Borealis», нижнее как «System variables» и там и там можно добавлять/изменять переменные окружения, в том числе и «Path». Но это собственно не важно — функция GetEnvironmentVariable возвращает эти переменные слитно, хотя и с каким то мусором 🙁
Да и ещё в сообщении о ненайденой dll присутствует какая то непонятная строка: «E:\Programs\Far1705» откуда она взялась?

ps. Вышеприведённая последовательность действий относится только к англоязычной Win2k

← →
Borealis ( 2003-08-13 16:23 ) [14]

> Reindeer Moss Eater © (13.08.03 15:51) [12]
Хочешь сказать что странно, когда Windows знает где у нее её системные каталоги и странно когда Windows знает кто она — Nt или 9x?
Было бы странно есди бы я сказал что это странно 🙂 Я спрашивал откуда взять эту информацию (порядок тоже имеет значение!)

Но это уже сильное отклонение от моего первоначального вопроса, наверно мой вопрос неправильно поняли поэтому я его немного перефразирую:
Если удалить нужные приложению dll»ки, то при его запуске появится сообщение которое я приводил выше, т.е. что я dll искал-искал по таким путям: «E:\Programs\Delphi6\Projects\Test\path;.;E:\WINNT\System32;E:\WINNT\s ystem;E:\WINNT;E:\Programs\Far1705;d:\apath;c:\apath» но не нашёл.
Вопрос: как узнать вышеприведённую строку «поиска» (т.е. по каким путям приложение искало — точнее по каким искало бы). Фух. Ну проще я уже наверно не смогу объяснить свою проблему 🙁

т.е. по каким путям приложение искало — точнее по каким искало бы.

Ищет не приложение. Ищет Windows.

← →
AlexKniga ( 2003-08-13 16:29 ) [16]

Borealis
В коммандной строке запусти команду Path

← →
Borealis ( 2003-08-13 16:43 ) [17]

> Reindeer Moss Eater © (13.08.03 16:27) [15]
> т.е. по каким путям приложение искало — точнее по каким
> искало бы.
> Ищет не приложение. Ищет Windows.
Согласен. Но знание этого, меня не пододвинуло к решению проблемы ни на шаг 🙁

> AlexKniga © (13.08.03 16:29) [16]
> Borealis
> В коммандной строке запусти команду Path
Запустил. Получил тоже, что и функцией GetEnvironmentVariable : «E:\Programs\Far1705;d:\apath;c:\apath»

← →
Reindeer Moss Eater ( 2003-08-13 16:50 ) [18]

Согласен. Но знание этого, меня не пододвинуло к решению проблемы ни на шаг 🙁

Тут никто в суть твоей проблемы не может въехать.

← →
Borealis ( 2003-08-13 17:27 ) [19]

> Reindeer Moss Eater © (13.08.03 16:50) [18]
> Согласен. Но знание этого, меня не пододвинуло к решению
> проблемы ни на шаг 🙁
> Тут никто в суть твоей проблемы не может въехать.

Ок. Объясню во всех подробностях.
Есть некое (рабочее) приложение и находится в некотором каталоге. (Кто написал это приложение и в каком каталоге находится не имеет значения). Это приложение для своей работы требует кучу dll. Стоп! На самом деле кучу bpl. Теперь уже моё приложение из PE заголовка того приложения получает спиок требуемых библиотек, отсеивает от *.dll — остаются только *.bpl. Теперь моё приложение должно найти все эти *.bpl и собрать в один каталог. Можно конечно втупую просканировать весь винчестер(!). Но во-первых хочется както более рационально, а во-вторых на винте могут быть устаревшие *.bpl с которыми то приложение работать не будет(!). Устаревшие *.bpl могут быть как и в «непрописанных» каталогах, но приложение тем не менее работает, так как устаревшие *.bpl находятся в более «поздних» каталогах и до них очередь не доходит. Это наверно стОит объяснить подробнее: например устаревшая(нерабочая) *.bpl находится в каталоге «E:\WINNT», а более новая(рабочая) в каталоге «E:\WINNT\System32», тем не менее приложение работает нормально так как путь «E:\WINNT\System32» стоит в очереди просмотра раньше чем путь «E:\WINNT» и соответственно загружается новая(рабочая) *.bpl из каталога «E:\WINNT\System32».

ps. Вы извините если я немного резко отвечаю, просто я немного нервничаю (скоро уже нужно показывать результат) и разговаривать на отвлечённые темы меня не тянет. 🙁

← →
Borealis ( 2003-08-13 17:28 ) [20]

> Reindeer Moss Eater © (13.08.03 16:50) [18]
> Согласен. Но знание этого, меня не пододвинуло к решению
> проблемы ни на шаг 🙁
> Тут никто в суть твоей проблемы не может въехать.

Ок. Объясню во всех подробностях.
Есть некое (рабочее) приложение и находится в некотором каталоге. (Кто написал это приложение и в каком каталоге находится не имеет значения). Это приложение для своей работы требует кучу dll. Стоп! На самом деле кучу bpl. Теперь уже моё приложение из PE заголовка того приложения получает спиок требуемых библиотек, отсеивает от *.dll — остаются только *.bpl. Теперь моё приложение должно найти все эти *.bpl и собрать в один каталог. Можно конечно втупую просканировать весь винчестер(!). Но во-первых хочется както более рационально, а во-вторых на винте могут быть устаревшие *.bpl с которыми то приложение работать не будет(!). Устаревшие *.bpl могут быть как и в «непрописанных» каталогах, но приложение тем не менее работает, так как устаревшие *.bpl находятся в более «поздних» каталогах и до них очередь не доходит. Это наверно стОит объяснить подробнее: например устаревшая(нерабочая) *.bpl находится в каталоге «E:\WINNT», а более новая(рабочая) в каталоге «E:\WINNT\System32», тем не менее приложение работает нормально так как путь «E:\WINNT\System32» стоит в очереди просмотра раньше чем путь «E:\WINNT» и соответственно загружается новая(рабочая) *.bpl из каталога «E:\WINNT\System32».

ps. Вы извините если я немного резко отвечаю, просто я немного нервничаю (скоро уже нужно показывать результат) и разговаривать на отвлечённые темы меня не тянет. 🙁

← →
Reindeer Moss Eater ( 2003-08-13 17:31 ) [21]

Теперь моё приложение должно найти все эти *.bpl и собрать в один каталог.

1. Определи ОС
2. Воспользуйся перечнем каталогов для поиска конкретной ОС
3. Посмотри в реестр на предмет каталогов поиска, зарегистрированных для того приложения.
4. Ищи в том же порядке, что и Windows

← →
Borealis ( 2003-08-13 17:45 ) [22]

> Reindeer Moss Eater © (13.08.03 17:31) [21]
> 1. Определи ОС
> 2. Воспользуйся перечнем каталогов для поиска конкретной ОС
Т.е. однозначного ответа не существует?

> 3. Посмотри в реестр на предмет каталогов поиска, зарегистрированных
> для того приложения.
?

> 4. Ищи в том же порядке, что и Windows
» том же порядке, что и Windows» Вот именно этого я и пытаюсь добиться. 🙁

← →
Reindeer Moss Eater ( 2003-08-13 17:48 ) [23]

Т.е. однозначного ответа не существует?
Существует

«том же порядке, что и Windows» Вот именно этого я и пытаюсь добиться. 🙁

То, чего ты добиваешься, находится в ЛЮБОЙ книжке по Delphi, в которой есть описание работы с DLL.
Там описана последовательность перебора системой каталогов прии загрузке бибиотек.

Впрочем, уверен, что и во встроенной документации это описано.

← →
Reindeer Moss Eater ( 2003-08-13 17:49 ) [24]

В посте №5 тебе уже показали этот порядок поиска для Win9x.

← →
Borealis ( 2003-08-13 18:19 ) [25]

> Reindeer Moss Eater © (13.08.03 17:48) [23]
> То, чего ты добиваешься, находится в ЛЮБОЙ книжке по Delphi,
> в которой есть описание работы с DLL.
> Там описана последовательность перебора системой каталогов
> прии загрузке бибиотек.
И я их читал. Т.е. описанная последовательность является жёсткой и её ничем нельзя нарушить?

> Reindeer Moss Eater © (13.08.03 17:49) [24]
> В посте №5 тебе уже показали этот порядок поиска для Win9x.
Я только что заметил что функция GetEnvironmentVariable возвращает «E:\Programs\Delphi5\Bin;d:\apath;c:\apath», а path в командной строке: «E:\Programs\Far1705;d:\apath;c:\apath». Почему они так отличаются?

← →
Reindeer Moss Eater ( 2003-08-13 18:22 ) [26]

Т.е. описанная последовательность является жёсткой и её ничем нельзя нарушить?
Ну почему же ничем. Вот издаст B.Gates распоряжение по конторе переписать код загрузки DLL и все изменится в один час.

Я только что заметил что функция GetEnvironmentVariable возвращает «E:\Programs\Delphi5\Bin;d:\apath;c:\apath», а path в командной строке: «E:\Programs\Far1705;d:\apath;c:\apath». Почему они так отличаются?

в командной строке FAR»A?

← →
Borealis ( 2003-08-13 20:04 ) [27]

> Reindeer Moss Eater © (13.08.03 18:22) [26]
> Т.е. описанная последовательность является жёсткой и её
> ничем нельзя нарушить?
> Ну почему же ничем. Вот издаст B.Gates распоряжение по конторе
> переписать код загрузки DLL и все изменится в один час.
Т.е. совет по поводу » ЛЮБОЙ книжке по Delphi, в которой есть описание работы с DLL» считается недействительным?

Вот буквально только что нашёл в инете такую ссылку: http://www.listsoft.ru/tips/456/

-=begin=-
Эта настройка может пригодиться, чтобы заставить программу, запускаемую по сети использовать локальные dll-ки, а также в тех случаях, когда первой загружается неправильная версия dll.
Запустите regedit и найдите ветвь
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager

Создайте новый DWORD ключ с именем «SafeDllSearchMode» (или измените существующий) и установите его значение в 1, если вы хотите заставить Windows сначала искать библиотеки в System и Windows папках, или в 0, если вы хотите, чтобы сначала проверялась текущая директория.

Для того, чтобы настройка заработала понадобится перезагрузить компьютер.
-=end=-

Т.е. ответ, что однозначный ответ сеществует тоже считается недействительным?

> Я только что заметил что функция GetEnvironmentVariable
> возвращает «E:\Programs\Delphi5\Bin;d:\apath;c:\apath»,
> а path в командной строке: «E:\Programs\Far1705;d:\apath;c:\apath».
> Почему они так отличаются?
>
> в командной строке FAR»A?
Понятно, этот вопрос снимается.

← →
Reindeer Moss Eater ( 2003-08-14 09:03 ) [28]

Т.е. ответ, что однозначный ответ сеществует тоже считается недействительным?

Ответ считается действительным. И ответ этот однозначный.

Приведенный выше пример ничего не меняет. Он лишь говорит, что существует еще одно правило поиска DLL. И правило это выполняется при вполне определенных условиях.

← →
AlexKniga ( 2003-08-14 10:00 ) [29]

Borealis
Твоя задача (Borealis (13.08.03 17:28) [20]) решается совсем другим путем.
Внедряешься в АП целевого приложения и GetModuleFileName.
Можно сделать это и чисто пользовательским путем, не кодируя не одной строки.
Юзай ProcExp от www.sysinternals.com

← →
Игорь Шевченко ( 2003-08-14 11:59 ) [30]