Regsvr32

Метки:  , , , , , , , ,

Regsvr32 (Microsoft Windows Register Server) — это системная утилита, предназначающаяся для регистрации и отмены регистрации элементов управления ActiveX, компонентов фильтров (кодеков) и компонентов библиотек DLL в системе Windows посредством внесения изменений в реестр.

DLL (Dynamic Link Library, Библиотека Динамической Компоновки) - динамически подключаемый набор подпрограмм (функций), логически объединенных в единый бинарный файл, которые могут быть многократно/одновременно динамически загружены (использованы) различными приложениями, требующими для своего функционирования данные функции.

История распределенного кода

Не лишним тут, я думаю, будет познакомиться с историей распределенного кода, что даст нам понимание причин возникновения и развития динамических библиотек. А это, в свою очередь, даст очевидное представление о том, какой функционал несет в себе средство regsvr32 и для чего оно, собственно, предназначается.

Линейное программирование

На заре развития языков программирования, при создании (разработке) программ использовался так называемый линейный подход, который заключался в том, что код писался/выполнялся "сверху-вниз", в четкой последовательности от начала к концу. Но как только человек научился писать код чуть сложнее, чем простой вывод фразы "Hello, World!", перед ним тут же встало несколько проблем, которые показали, что подход имеет очевидные недостатки:

  • исходный код необходимо было копировать из старого проекта в новый;
  • копирование старого кода приводило к ошибкам, путанице, нестыковкам, необходимости исправления и подгонки под новый проект;

Процедуры (функции)

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

  • позволял разделять код программы на логические части лишь в рамках одной языковой среды разработки.

Оверлеи

В условиях дороговизны оперативной памяти и отсутствия у многих операционных систем того времени (MSDOS) механизма виртуализации адресного пространства процесса (виртуальной памяти), обеспечивающего достаточное адресное пространство для приложений, появилась необходимость загружать в ограниченное пространство [дорогой] физической памяти много превосходящие по размеру код/данные приложений. Следствием всего этого явилось разбиение кода/данных программы на обособленные модули, получившие название оверлеев (overlay). Данный механизм непрямую не связан с разделением кода, тем не менее мы о нем упомянем, как о существенной вехе в развитии механизмов разделения кода.

Прерывания

Первой попыткой решения проблемы распределения кода был механизм программных прерываний, который позволял создавать (размещать в микрокоде BIOS) и вызывать сервисы, доступные любым операционным системам и программам. Таблица прерываний включала 255 векторов (адресов), каждый из которых задавал процедуру обслуживания определенного прерывания. Данный сервис мог лешгко программироваться пользователями, то есть любая программа могла [пере]назначить одно из доступных программных прерываний, предоставив, таким образом, общесистемный сервис. И не смотря на все положительные стороны подобного подхода, он имел и ряд серьёзных недостатков:

  • Фиксированное количество сервисов, ограниченное размером таблицы векторов прерываний (255);
  • Отсутствие обработки исключительных ситуаций.
  • Отсутствие системы безопасности;
  • Обособленный синтаксис, несовместимости с синтаксисом языков высокого уровня (необходимость оперировать низкоуровневыми регистрами);
  • Отсутствие контроля типов и корректности данных;

Динамические библиотеки

Дальнейшее развитие данной концепции (а так же развитие ОС) привело к появлению динамически загружаемых библиотек (называемых упрощенно динамическими библиотеками, DLL). Отличительной особенностью было то, что обращение к функционалу этих библиотек могло осуществляться из кода на любых языках и из любых средств разработки [в рамках операционной системы]. На механизме динамических библиотек построен весь программный интерфейс (WinAPI) операционных систем Mirosoft Windows, поэтому любое API, любой сервис, так или иначе базируются на DLL. Характерная особенность динамической библиотеки заключается в том, что она может использоваться сразу несколькими приложениями, а система обеспечивает присутствие в памяти всего-лишь одного экземпляра [кода] динамической библиотеки для всех приложений, которые содержат ссылки на функции данной библиотеки. DLL имели ряд выраженных недостатков:

  • при загрузке динамической библиотеки [в адресное пространство процесса] использовалось лишь её символическое имя, поскольку отсутствовал механизм устойчивой идентификации необходимых библиотек;
  • не проверяется информация о типах параметров функции;
  • не проверяется корректность передаваемых параметров функции;

Компонентная объектная модель (COM)

Следующим этапом развития концепции разделяемого кода стало появление компонентной объектной модели (COM, Component Object Model). COM обеспечивал возможность разделять код на отдельные независимые компоненты. Упомянутые компоненты, в отличие от предыдущих своих собратьев, подключались уже не по имени файла, а при помощи специального глобального идентификатора (GUID). GUID ни что иное как 128-битный глобальный идентификатор (GUID, Global Unique ID), идентифицирующий конкретный объект класса библиотеки. Каждый компонент определялся в системе собственным уникальным идентификатором, а в системе хранилась единая база информации по компонентам, в которой содержалась вся информация: начиная от имени файла, в котором расположен сам компонент, и заканчивая сетевыми настройками.
База COM хранится в реестре, в разделе HKEY_CLASSES_ROOT:

  • HKEY_CLASSES_ROOT\CLSID -- GUID идентификаторов классов компонентов;
  • HKEY_CLASSES_ROOT\Interface -- IID идентификаторов интерфейсов (для реализующих их компонентов);
  • HKEY_CLASSES_ROOT\TypeLib -- Информация о файлах, в которых хранятся библиотеки;

Причем сам HKEY_CLASSES_ROOT представляет собой комбинацию разделов HKCU\Software\Classes (для текущего пользователя) и HKLM\Software\Classes (для машины в целом).

Чтобы как-то отличать идентификаторы классов от иных [похожих] системных идентификаторов, применительно к СОМ эти идентификаторы называются идентификаторами класса, и для них используется аббревиатура CLSID.

Примером значения CLSID может служить строка вида {2DB47AE5-CF39-43C2-B4D6-0CD8D90946F4}. В глобальном смысле данные уникальные номера "не повторяются" и уникально идентифицируют компоненты системы, что говорит нам об уникальности объекта класса библиотеки в пределах системы. Подразделами в этих ветках реестра могут быть:

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

  • COM базируется на динамических библиотеках (в них то и размещаются компоненты). А как мы помним с DLL сохранялась проблема, связанная с совпадением имён файлов библиотек;
  • База данных COM располагается в реестре, и работать с ней предлагалось напрямую, без какого-либо специализированного API. При том, что раздел базы данных является общедоступным, после продолжительной эксплуатации системы он традиционно приходил в рассогласованное состояние (приводящее к множеству системных ошибок).

Сборки (assembly)

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

Сборка (assembly) - коллекция типов и ресурсов, сгруппированная в один или нескольких файлов для совместного функционирования, образующая логическую функциональную единицу.

Сборка состоит из: манифеста (описывающего сборку), метаданных (описывающих типы), откомпилированный MSIL-код сборки (.Net-байткод), ресурсы (рисунки, звуки и прч). Поскольку сборки включают в себя сведения о содержимом, версиях и зависимостях, работоспособность связанных с ними приложений не зависит от внешних источников (таких как реестр). Сборки существенно снижают риск конфликта библиотек DLL, а также повышают надежность и простоту развертывания приложений.

Смысл регистрации библиотек и элементов управления

Но, вернемся к нашим библиотекам :)

По какой причине, для использования функций DLL в системе непременно требуется их регистрация? Ответ: чтобы система смогла их найти!!

Казалось бы, ну помести ты DLL в рабочую директорию приложения, и вопрос с нахождением решен. Но ведь библиотеки бывают не только локальными, некоторые из них используются совместно множеством приложений, вот как раз для этой ситуации всё и затевалось!! Я думаю, вполне уместно было бы привести аналогию с системной переменной пути (%PATH%). Как Вы помните, файлы, которые располагаются в директориях, указанных в переменной %PATH%, можно запускать из командной строки без указания полного пути. В случае же отсутствия директорий в переменной %PATH%, указанные файлы невозможно будет запустить из произвольного местоположения в операционной системе, командный интерпретатор их попросту "не найдет". По аналогии и библиотеки, которые содержат функции, широко используемые различными программами, должны быть "объявлены" в системе, иначе программы не смогут их "найти". Можно утверждать, что при вызове функции из образа исполняемого файла, загрузчик Windows (менеджер, отвечающий за выделение памяти, подключение различных функций из образов памяти и прч.) должен знать откуда можно подгрузить библиотеку, содержащую требуемую функцию.
Если опираться на историю развития технологии распределенного кода, то можно сделать вывод, что regsvr32 обеспечивает регистрацию как классических библиотек DLL, так и продвинутых их собратьев, содержащих COM-объекты, поскольку со сборками .NET утилита уже не работает. Что же касается вопроса регистрации в системе применительно к библиотеке DLL на низком уровне, то она представляет собой алгоритм действий по модификации различных разделов реестра и каталогов файловой системы, результатом которого является "видимость" библиотеки приложениями. Если библиотека "сторонняя" (не системная), то регистрация библиотеки должна осуществляться на этапе инсталляции приложения, в состав которого она входит и для обслуживания функций которого она предназначается. В большинстве случаев сам процесс регистрации библиотеки выполняется при помощью вызова внешних специализированных системных утилит, либо определенной последовательности специализированных функций Windows API.

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

Можно рассмотреть простой пример, когда произвольно установленная в системе программа использует функцию из библиотеки, не "объявленной" в системе. В подобной ситуации загрузчик Windows на начальной стадии инициализации виртуального адресного пространства процесса выполняет импорт всех библиотек, требуемых загружаемой на выполнение программе. Если одна из библиотек, прописанных в таблице импорта исполняемого образа, отсутствует, то загрузчик выдает такое вот сообщение об ошибке:

regsvr32 запуск программы невозможен

Ошибка сообщает нам о том, что загрузчик образа cDSsvc.exe не смог найти библиотеку MFC71.DLL, необходимую ей для функционирования. Один из способов устранения данного класса ошибок состоит в повторной инсталляции программы, в ситуации, когда файл искомой библиотеки входит в состав какого-либо дистрибутива, поскольку библиотека инсталлируется автоматически скриптом инсталляции. Если библиотека входит в состав другого пакета, например Microsoft Visual C++ 2010 x64 Redistributable, то переустановить необходимо именно его. Если же описанными способами ошибку исправить все же не удается, тогда нам на помощь приходит утилита Regsvr32.

[упрощенное] описание процесса регистрации библиотеки

Утилита regsvr32 при помощи системной функции LoadLibrary загружает библиотеку и, в зависимости от того входных параметров [командной строки], выполняет:

  • ищет в библиотеке точку входа и вызывает функцию DllRegisterServer либо DllUnRegisterServer данной библиотеки и смотрит на возвращаемый результат.
  • ищет в библиотеке точку входа и вызывает функции DllInstall / DllUnInstall.

Все это говорит в пользу того, что существуют определенные требования к структуре DLL, которую вы хотите регистрировать с помощью regsvr32. Для того, чтобы управляющий элемент можно было зарегистрировать с помощью regsvr32, в DLL должны быть реализованы функции DllRegisterServer, DllUnregisterServer, а при необходимости выполнения специфичных действий еще и функции DllInstall, DllUnInstall. Функции DllRegisterServer / DllUnregisterServer содержат логику, которая фактически и выполняет регистрацию библиотеки в системе, добавляя записи в реестр, требующиеся для управляющего элемента. Функции DllInstall / DllUnInstall служат для выполнения дополнительных действий, которые планирует произвести автор DLL. Поэтому помните, что:

Далеко не все DLL могут быть зарегистрированы при помощи regsvr32!

Давайте посмотрим, что же происходит в случае, когда, к примеру, не определена функция DllRegisterServer:

regsvr32 точка входа DllRegisterServer не найдена

В этом случае мы видим на экране ошибку: "Модуль ????????.??? загружен, но точка входа DllRegisterServer не найдена". Но, давайте как перейдем, непосредственно, к самому процессу регистрации.

Новый метод

Как мы уже говорили, для регистрации библиотеки используется функция DllRegisterServer(). Функция проверяет 128-битный глобальный идентификатор (GUID, Global Unique ID) всех объектов COM/ActiveX, обнаруженных в библиотеке и последовательно прописывает информацию о них в реестр. Тут мы видим что происходит как бы не регистрация библиотеки, а регистрация объектов в библиотеках. Как мы уже говорили выше, регистрация объектов необходима, поскольку программы работают не с самими файлами DLL/OCX/ACX, а с объектами, представляющими определенный набор интерфейсов. Как мы уже упоминали, для целей регистрации DLL используется раздел реестра HKEY_CLASSES_ROOT, который представляет собой комбинацию разделов:

  • ветвь HKLM\SOFTWARE\Classes\CLSID при регистрации COM-объектов библиотек для всех пользователей системы;
  • ветвь HKCU\SOFTWARE\Classes\CLSID при регистрации COM-объектов библиотек только лишь для текущего пользователя;
  • ветвь HKLM\SOFTWARE\Wow6432Node\Classes\CLSID для регистрации 32-битных DLL в 64-битных ОС Windows;
  • Таким образом можно сделать вывод, что процесс регистрации библиотеки заключается в информировании операционной системы о том, что реализация интерфейсов, предоставляемых объектом с определенным идентификатором, располагается в соответствующем файле.

    Если вам необходимо поменять расположение библиотеки DLL в системе (например, поменять директорию размещения), то потребуется её перерегистрация.

    Старый метод

    В дополнение к современному методу работы с COM-объектами, в реестре присутствует еще и ветка HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs. Могу предположить, что она относится к устаревшему методу регистрации общих библиотек DLL, базирующемуся на подсчете количества ссылок на библиотеку. Вероятно, она оставлена для совместимости и предназначена для регистрации библиотек, которые представляют собой устаревший вид библиотек, состоящих из набора функций. В этой ветке имеются параметры типа REG_DWORD, имена которых содержат полный путь к зарегистрированным в системе общим библиотекам (например: C:\Windows\system32\VBAME.DLL). Значение параметра может варьироваться от 1 до 65535. Дело в том, что значение это - счетчик использования или, как еще называют, количество ссылок. Зачастую этот метод регистрации использовался не-MSI инсталляторами. Каждый раз, когда какой-либо подобный установщик самостоятельно регистрирует в системе библиотеку, которая до этого уже была зарегистрирована кем-либо еще (то есть присутствует в SharedDLLs), он увеличивает счетчик использования на 1, когда же (например, при удалении) библиотека разрегистрируется, то счетчик уменьшается на 1. Подобная логика была реализована в первых версиях Windows для борьбы с таким явлением как "Ад DLL"(DLL Hell). У параметров некоторых библиотек можно наблюдать достаточно большие значения (4096), полагаю, таким образом маркируются критичные для системы библиотеки, и счетчик искусственно увеличен с той целью, чтобы разнообразные пользовательские пакеты при своем удалении, случайно не уменьшили счетчик использования до 0 и не выключили DLL.

    32-битные и 64-битные версии regsvr32

    Начиная с Windows XP, в зависимости от разрядности ОС, утилита regsvr32.exe располагается либо только в директории %SystemRoot%\System32 для 32-битных систем, либо в папках %SystemRoot%\System32 и %SystemRoot%\SysWOW64 для 64-битных (присутствуют две разные версии программы). Представляет собой утилиту командной строки, то есть, иными словами, работает с консолью и может использоваться в сценариях.

    В данный момент более активно начали использоваться 64-битные версии Windows. Если в 32-битных версиях Windows всё было достаточно прозрачно и присутствовало только одна версия программы, то в 64-битных версиях ОС имеются две версии утилиты regsvr32:

    • 64-разрядная версия утилиты — %SystemRoot%\System32\regsvr32.exe (используется по-умолчанию при запуске без конкретизации пути);
    • 32-разрядная версия утилиты — %systemRoot%\SysWoW64\regsvr32.exe

    Получается, в 64-битной системе разработчики сохранили прежнюю систему именования каталогов, однако поместили туда уже "родные" 64-битные приложения. Объясняется это обеспечением совместимости приложений и уменьшением временных затрат на трансляцию кода из 32- в 64-разрядную версию Windows. Таким образом, в 64-битной версии Windows могут работать как 32-битные, так и 64-битные версии программ, соответственно, и DLL могут использоваться и 32- и 64-разрядные.
    Когда вы запускаете regsvr32 в 64-битной версии ОС для регистрации DLL, вы по-умолчанию используете 64-битную версию утилиты.

    Для 64-битных ОС Windows существует золотое правило: директория System32 системы предназначается для родных 64-битных приложений, директория SysWOW64 для 32-битных. Немного не интуитивно, однако это сложившийся факт!! WOW64 (Windows on Windows64) - 32-битная подсистема, которая запускается в 64-битной среде.

    Поэтому, если вам требуется зарегистрировать 32-разрядную версию библиотеки DLL в 64-разрядной ОС, и у вас возникает ошибка, то можно поступить следующим образом:

    1. Открыть командную строку с правами администратора;
    2. Если требуемая для регистрации 32-разрядная библиотека DLL находится в директории %SystemRoot%\System32, переместить ее в папку %SystemRoot%\SysWoW64;
    3. Выполнить команду:
      %SystemRoot%\SysWoW64\regsvr32 <полный путь к библиотеке DLL>

      то есть, к примеру: %SystemRoot%\SysWoW64\regsvr32 %SystemRoot%\SysWOW64\test.dll

    Если же перед вами стоит задача зарегистрировать 64-битную DLL в 64-разрядной ОС:

    1. Открыть командную строку с правами администратора;
    2. Если требуемая для регистрации 64-разрядная библиотека DLL находится в директории %SystemRoot%\SysWOW64, переместить ее в папку %SystemRoot%\System32
    3. Выполнить команду:
      %SystemRoot%\System32\regsvr32 <полный путь к библиотеке DLL>

      то есть, например: %SystemRoot%\System32\regsvr32 %SystemRoot%\System32\test.dll

    Синтаксис regsvr32

    Как уже говорилось выше, regsvr32 - это утилита командной строки, поэтому в целях практического использования может запускаться из-под всем уже знакомой cmd, либо использоваться в сценариях.

    В большинстве случаев, для регистрации DLL требуются повышенные привилегии, то есть права локального администратора.

    Утилита regsvr32.exe имеет следующие параметры командной строки:

    Regsvr32 [/u] [/s] [/n] [/i[:cmdline]]

    Список ключей утилиты и описание их действия приведем в следующей таблице:

    Параметр Описание

    /u

    Отменяет регистрацию DLL. Отменить можно только регистрацию DLL, команда не применима к элементам управления и фильтрам.

    /i

    вызывает функцию DllInstall, передавая ей в качестве параметра необязательную строку команд cmdline; Вызов DllInstall приводит к вызову стандартных функций регистрации DllRegisterServer/DllUnRegisterServer, однако позволяет передать строку параметров, которые могут изменить поведение регистрации, например провести регистрацию DLL более одного раза. Ключ /i при использовании с ключом /u вызывает DllUnInstall.

    /n

    не вызывает DllRegisterServer, то есть вызывается только DllInstall; это может быть использовано с ключом /i для передачи дополнительных параметров для регистрации.

    /s

    "тихий" режим; сообщения не отображаются.

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

    regsvr32 <имя_библиотеки>.dll

    Например:

    regsvr32 "C:\Windows\System32\schmmgmt.dll"

    Напоминаю, будьте внимательны с версиями утилиты regsvr32 под Windows различной разрядности. В некоторых случаях приходится уточнять путь к утилите при запуске.
    Более того, практически всегда, когда регистрируемый компонент лежит вне путей, включенных в переменную %PATH% (к примеру, если он не находится в %SystemRoot%\System32), путь к компоненту приходится уточнять!
    Пример:

    %SystemRoot%\System32\Regsvr32 %SystemRoot%\System32\macromed\Flash\Flash10a.ocx

    *Составные пути к файлу должны заключаться в кавычки по правилам синтаксиса командной строки Windows.

    Комментарии: 23

    1. Alofa

      Автору Respect и огромное Спасибо.
      Все коротко и содержательно.

      Для 64-битных ОС Windows существует золотое правило: директория System32 системы предназначается для 64-битных версий, директория SysWOW64 для 32-битных. Немного не интуитивно, не находите? Но тем не менее это сложившийся факт!! WOW (windows on windows) - 32-битная подсистема, которая запускается под 64-битной подсистемой.

      А эта особенно ценная информация (по крайней мере для меня).
      Делая дальнейшие выводы нетрудно догадаться что это касается не только "Regsvr32".

      • einaare

        Рад что смог помочь! На самом деле статья еще не полностью доработана, никак не могу к ней вернуться :)

    2. Рамиль

      Регистрирую 2 dll(Scaner1C.dll и _Scaner1C.dll) с одинаковым AddIn. Это Файлы разных версий, выпусков. При регистрации пишет, что успешно зарегистрированы. Одна перезарегистрирует другую или обе будут зарегистрированы?

      • einaare

        зарегистрированы они будут обе, потому как с большой вероятностью у них разные GUID. а вот как будут работать экспортируемые функции, это уже другой вопрос.
        а подробнее про эти dll можете рассказать? какие у них пространства имен? или кроме того, что у них одинаковые addin, более ничего не известно?

    3. Рамиль

      Больше ничего не известно. Решили все таки обойтись одной более новой версией.

      • einaare

        спасибо за комментарий. повод модифицировать статью как будет время :)

    4. Евгений

      В 64-битной версии Windows 8.1 Pro в режиме "коммандной строки" не получается запустить реестр (с локальными правами) с помощью 32-битной утилиты PsExec. Команда: psexec.exe -s -i 0 regedit.exe
      Пишет: "Отсутствует подсистема, необходимая для поддержки данного типа образа."

      • einaare

        Как мне кажется, у вас проблема с загрузчиком исполняемых файлов. 32-битные программы в системе вообще работают? Может пакет WOW64 отсутствует или поврежден? Что за версия? Были ли заражения системы?

    5. Света

      У мeня тaкaя пpoблeмa: нa кoмпьютepe двe oчeнь нyжныe пpoгpaммы иcпoльзyют oдин и тoт жe фaйл МV14.ОСХ, нo paзныx вepcий. Ecли зapeгиcтpиpoвaть oдин, тo втopaя пpoгpaммa нe зaпycтитcя (и нaoбopoт). Бeз peгиcтpaции МV14.ОСХ ни oднa из пpoгpaмм нe зaпycкaeтcя. Пoпpoбoвaлa пpocтo пoлoжить фaйл в пaпкy c пpoгpaммoй - нe cpaбoтaлo. Kaк зapeгиcтpиpoвaть OБA фaйлa?

      • einaare

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

        regsvr32 c:\program files\Programma\mv14.ocx
        C:\Program Files\Programma\program.exe

        соответственно, замените пути и имена.

        другие способы состоят в изменении CLSID библиотеки и прч. Но там придется лезть в бинарные файлы.

        • Света

          Eіnааrе, Bы aбcoлютнo пpaвы. Этo cтapыe пpoгpaммы, нo вcё жe oчeнь мнoю любимыe и пoлeзныe. Paбoтaю c ними нa XP. A paбoтaть пpиxoдитcя oднoвpeмeннo. Boт oбa фaйлa ОСХ: http://www.datafilehost.com/d/6738e8cb Boзмoжнo ли кaк-тo зacтaвить иx paбoтaть пapaллeльнo? Фaйл из пepвoй пaпки лeжит y мeня в ѕуѕtеm32, гдe eгo нaxoдит пepвaя пpoгpaммa, a втopoй фaйл ОСХ - нeпocpeдcтвeннo в диpeктopии втopoй пpoгpaммы. Ho тa eгo бeз peгиcтpaции чepeз rеgѕvr32 вcё paвнo нe видит :(

          • einaare

            А какие именно ошибки выдают программы при использовании "не своих" библиотек? просто не запускаются?

          • einaare

            В разделе реестра
            HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

            есть подразделы для обеих Ваших программ?

            • Света

              Eіnааrе, пepвaя пpoгpaммa выдaёт cooбщeниe: «Bыxoд зa пpeдeлы диaпaзoнa». Пoтoм зaгpyжaeтcя cмятый интepфeйc пpoгpaммы, a caмa oнa нe paбoтaeт. Bo втopoй пpoгpaммe зaгpyзкa пpoxoдит нopмaльнo, нo oкнo пoиcкa пo инфopмaции внyтpи пpoгpaммы oтcyтcтвyeт, a пpи пoпыткe зaпycтить пoиcк выдaётcя cooбщeниe: «Run-tіmе еrrоr '31037' Еrrоr lоаdіng frоm fіlе» и пpoгpaммa выpyбaeтcя. B yкaзaннoм Baми paздeлe peecтpa пpиcyтcтвyeт лишь пepвaя пpoгpaммa. Oбa пapaмeтpa («Пo yмoлчaнию» и «Раth») вeдyт нa пaпкy c EXE-фaйлoм.

          • einaare

            Светлана, тут без эксперимента не обойтись. В следствии чего система МОЖЕТ прийти в нестабильное или неработоспособное состояние. Если Вас это не пугает, то смогли бы Вы:
            1. Прописать в реестр и вторую программу по аналогии с первой. Соответственно, оба параметра новой записи должны уже вести на рабочую папку второй программы. Для обеих программ mv14.ocx должны лежать в папках программ, которые обозначены в параметрах Path.
            2. Произвести удаление всех ДРУГИХ записей в реестре о mv14.ocx. Конечно, лучше бы сделать бэкап реестра перед экспериментом. Можно было бы просто провести разрегистрацию через regsvr32 с параметром /u, но он не для всех ситуаций работает.

            • Света

              Я cмeлaя дeвyшкa, вeдь eщё Ииcyc гoвopил: «He чeлoвeк для Wіndоwѕ, a Wіndоwѕ для чeлoвeкa» :)))) Пpoдeлaлa oбa экcпepимeнтa. Peзyльтaт, к coжaлeнию, тoт жe: либo paбoтaeт пpoгpaммa A, либo - Б. Bмecтe - никaк :(

              • einaare

                ну а тогда в чем проблема запускать софт батниками, в которых регистрируется своя dll?

              • einaare

                а если удалить mv14.ocx из папки c:\windows\system32 ?

                • Света

                  Еіnааrе, oбe пpoгpaммы дoлжны paбoтaть oднoвpeмeннo - в этoм и бeдa (бeз mv14.осх из пaпки Sуѕtеm32 ничeгo вooбщe нe зaпycкaeтcя). Я пoпpoбoвaлa пepeимeнoвaть mv14.осх в mv15.осх и зapeгиcтpиpoвaть ОСХ. Hичeгo, кoнeчнo, нe пoлyчилocь, тaк кaк (oчeвиднo) cpaвнeниe пpoиcxoдит c чeм-тo внyтpи фaйлa, кaкoй-нибyдь тaм элeктpoннoй пoдпиcью или кoдoм, я ocoбo в этoм нe paзбиpaюcь.

              • einaare

                Светлана? Могли бы Вы описать иерархии обеих директорий. Полные пути, наименования запускных файлов, библиотек.. где лежат библиотеки mv14.ocx в обеих директориях, если лежат.. и еще, где в обеих директориях находится библиотека mvcl14n.dll? Если комментарии к статье закроются - пишите в разделе "О сайте".

    6. Здравствуйте. У меня проблема с установкой веб камеры.В одном случае пишет : You have no vidio capture hardware. У вас нет захвата видио оборудования. В другом - " не зарегистрирована библиотека" Как и что регистрировать? подскажите пожалуйста!

      • einaare

        ну, уточните какая модель, какие драйвера и какая операционная система, для начала.

    7. Kolombo

      einaare
      Для работы программы OLE/COM Object Viewer необходима iviewers.dll, которая качается отдельно и регистрируется вручную.
      Так вот OLE Viewer работает нормально с ней только при пользовательском запуске, при запуске от имени Администратора виснет.
      Где могут быть вилы?

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *