Пытаюсь разбираться, что представляет из себя работа с COM-объектами на низком уровне с точки зрения приложения. Понял, что так или иначе получаемые интерфейсы - это (указатели на) структуры, содержащие в своих полях указатели на методы. Вижу, что эти методы с точки зрения приложения - обычные функции, не thiscall. В аргументах тоже не предается никаких this или еще каких-либо идентификаций объекта или хотя бы адреса той же самой структуры/интерфейса, из которой я имею адрес метода. То есть, в метод при вызове не попадает никакой информации о том, к чему именно они применяются. И вот тут у меня возникает непонятка - как вообще различаются между собой разные, но однотипные объекты, полученные одинаковым путем? Понятно, что для каждого объекта будет своя структура/интерфейс, но ведь адрес этой структуры в методы никак не попадает?
Объекты COM имеют виртуальную таблицу с указателями на методы интерфейса, указатель на таблицу (vtable) первое поле каждого объекта. Указатель на объект идет первым (заталкивается в стек последним) аргументом каждого вызова. pObject->QueryInterface (iid, ppv); В стеке будет: адрес возврата pObject iid ppv
Dmitry_Milk Вы просмотрели декларацию вызовов , там везде будет __stdcall , (x64 как __fastcall). Squash а вот не совсем, посмотрите ATL( DirectX DXGIFactory ), там более хитрый ипл, что бы не бухли таблицы, но в целом таки да , первый элемент будет указатель на текущию виртуальную таблицу ...
Squash Стибаитесь ? Просто мне показалось это забавным особенно когда хочешь это все перехватить и кажится сто решение, а на самом деле не все так просто, поэтому и порекомендовал, так как это очень забавно! П.С proxy objects - не подходят так как иногда происходит прямые вызовы .. Полный патчи таблиц тоже каряво.. А еще время жизни объектов и многое другое
Лучше расскажите мне, как оле элементы свои свойства в контейнерах хранят. Есть у них единая схема, или каждый кто во что горазд?
Squash НА сколько помню это обычные функты, а установка их похожая на ATL::QueryIntreface(Поиск объектов )
