Определить, предоставляет ли исполняемый файл COM-интерфейс?

[kiber_punk]

Какие есть способы (минимально достаточные и желательно без обращения к WinAPI, [интересны все]) для идентификации файла как COM-объекта?

Пока на ум приходит только проверка на существование в файле функции DllGetClassObject.
Может есть другие простые способы и без вызовов API? (Пишу WSH-скрипт - он не имеет работать с WinAPI, а хочется обойтись штатными средствами системы).
Спасибо за любые идеи и подсказки.

[kiber_punk]

* проверка на существование в таблице импорта файла функции DllGetClassObject.

[NashRus]

Если под исполняемым подразумевается только EXE файл, то тогда с определенной степенью надежности можно смотреть реестр.
Если совсем на шару, то искать в файле ключи запуска, такие как /regserver или как-то так.
Если все таки смотреть еще и DLL, то дополнительно можно смотреть функции экспорта, которые юзает, например, regsvr32.

ну т.е. как-то детектировать признаки COM-а.

[kiber_punk]

Под исполняемым файлом подразумевается кгхм..."исполняемый файл" - вполне официальное название типа файлов - exe,dll,ocx*
*ocx - это всегда COM, так что с ним вопросов быть нет.
exe в принципе не так важен, всё ради dll - отличить обычную dll-ку от COM-сервера (в целях катологизации и дальнейшей обработки).

Если совсем на шару, то искать в файле ключи запуска, такие как /regserver или как-то так.

Эмм...как Вы себе это представляете?

Если все таки смотреть еще и DLL, то дополнительно можно смотреть функции экспорта

Ну да об этом я сразу упомянул, DllRegisterServer всегда идёт вместе с DllGetClassObject (вторая функция в данном случае релевантнее).

Повторюсь: WSH-скрипт (vbs), доступа к WinAPI нету.

И только что в голову пришла true'шная идея ^_^
- однозначно идентифицировать сигнатуру\шапку ActiveX-либы.

[NashRus]

..."исполняемый файл" - вполне официальное название типа файлов - exe,dll,ocx*

проверка на существование в таблице импорта файла функции DllGetClassObject.

Официальное, официальное, как и официальное название таблицы: таблица экспорта.
Отсюда я и не понял, при чем тут таблица импорта.

Эмм...как Вы себе это представляете?

Что именно? Как в файле искать или что?
Эта фраза относилась к EXE, где в теле файла есть специфичные строки - ключи запуска.
Наверное стоит повториться, чтобы не быть опять процитированным: на шару.
А вообще искать любые признаки COM.

вторая функция в данном случае релевантнее

Релевантнее 4 функции смотреть.

Повторюсь: WSH-скрипт (vbs), доступа к WinAPI нету.

Есть много способов: встроенные объекты шелла, утилиты командной строки, да и dllhost.exe никто не отменял.
Не считая, если допускается возможность регистрации своих самописных библиотек.

[kiber_punk]

Отсюда я и не понял, при чем тут таблица импорта.

Перепутал "экспорт" и "импорт" когда писал сообщение.

Есть много способов: встроенные объекты шелла, утилиты командной строки, да и dllhost.exe никто не отменял.
Не считая, если допускается возможность регистрации своих самописных библиотек.

Объекты шелла ("wscript.shell" и иже с ним) отпадают сразу - ибо нет таковых способных выполнить данную задачу, утилиты ком. строки в туже стопку (насколько я знаю).

Можно конечно подключить DynamicWrapper[X] и к нему обращаться. Но задача обойтись штатными средствами системы, поэтому доп. библиотеки отпадают (да и не по-кодерски это - в каждом случае сторонние компоненты юзать ).

А вот про dllhost.exe поподробнее, если можно. Похоже что-то интересное.

[iGrok]

А что, прочитать документацию по формату PE, прочитать заголовки, разобрать их и найти там таблицу экспорта и список экспортируемых функций - это уже не ТРУъ, да?

[kiber_punk]

iGrok:
А что, прочитать документацию по формату PE, прочитать заголовки, разобрать их и найти там таблицу экспорта и список экспортируемых функций - это уже не ТРУъ, да?

Эмм.. я это и имел ввиду когда писал:

- однозначно идентифицировать сигнатуру\шапку ActiveX-либы.

[iGrok]

Правда, что ли? И что же это за зверь такой, эта "сигнатура\шапка ActiveX-либы", и каким именно образом ты собираешься её "идентифицировать"?