Поздравляю!   

kms писал(а) 08. Сентября 2007 :: 15:33:


Ты смотрел? Смотря что не заведется.

На NT4 все работает по-старому. Раздавайте права на HKLM.

sedmin
По-существу, в этом решении меня интересует только один старый вопрос:

kms писал(а) 30. Июня 2006 :: 11:34:


Если пользователь включает переопределение HKCR, что будет дальше при попытке создания COM-объекта, зарегистрированного в HKLM?

+
Вот, тестик набросал.

	HKEY key;
	LPOLESTR pstr;
	StringFromCLSID(__uuidof(zlibEngine), &pstr);
	CString cs = "CLSID\\";
	cs += pstr;
	CoTaskMemFree(pstr);
	LONG res = RegOpenKeyEx(HKEY_CLASSES_ROOT, (LPCTSTR)cs, 0, KEY_READ, &key);
	if (res == ERROR_SUCCESS)
		RegCloseKey(key);
	Msg("clsid open result %p", res);

	CComPtr<IzlibEngine> zlib;
	HRESULT hr = zlib.CoCreateInstance(__uuidof(zlibEngine));
	Msg("zlib creation result %p", hr);
 

Открыть CLSID, расположенный в HKLM после переобозначения HKCR не удается.
В то же время, создание объекта проходит удачно всегда.
Причем в regmon четко видно, что процесс открывает ту же самую ветку, чтение которой только что обломалось и именно через HKCR.

It's definitely some sort of dark magic...

Но с регистрацией самой компоненты, думаю, все будет хорошо.

Вот еще среди прочего попалась статья Фила Вильсона на эту тему:
http://www.ddj.com/windows/184416328

Там есть секция "possible problems", в которой Филу пришлось переносить CLSID'ы из HKCR (HKLM, читай) в замещающую ветвь, чтобы заставить работать тот самый CoCreateInstance.
Забавно, что у меня таких проблем не оказалось.

Но, возможно, они еще у кого-то впереди.

sedmin писал(а) 08. Сентября 2007 :: 19:53:


Я не очень понял, кто "он" и куда идет и с какими правами.
Вопрос по-моему вполне внятно сформулирован: почему мы можем создавать объекты, зарегистрированные в HKLM, после того как мы переобозначили HKCR в HKCU.

Мы не имеем доступа по чтению и не можем сделать энумерацию ключей HKCR в части HKLM, но объекты создавать можем.
Странно? Мне - странно.

CLSIDfromProgID() тоже, кстати работает, к реестру обращение выглядит примерно так:
Цитата:

Т.е. мы через HKCR (который переобозначен в HKCU) спокойно читаем ключ v75.zlibEngine, который находится в HKLM.

Странно? Мне - да.

И речь не о том, что все работает.Речь о том, будет ли оно работать завтра.
Мы предполагаем, что будет, но оснований для этого я лично пока не вижу.

Цитата:

Именно.
Да я заметил, что не писал, а хотя бы обдумать это следовало бы.

Ну да ладно, поскольку нам все равно никто не ответит, давайте-ка лучше праздновать.

sedmin писал(а) 09. Сентября 2007 :: 06:18:

... из книги Савельича "клей момент: секреты бывалых"

Цитата:


Сань, все это правильно, но ты опять никак не поймаешь мою мысль.

Есть еще п.3
3) Работа подсистемы COM

Как организовано хранение информации о COM объектах мы знаем.
Это грубо ветка HKCR, которая действительно складывается из HKCU и HKLM.
В корень пишутся ProgID, в ветку CLSID пишутся (кто бы мог подумать!) CLSID, плюс интерфейсы, тайплибы, это не суть.

Предположим, из 1С мы вызвали метод РегистрироватьКомпонентыВ_HKCU(1).
И бросили, типа компоненты будут регистрироваться в HKCU.

Вопрос: сможем ли мы создавать COM-объекты, зарегистрированные ранее в HKLM?

С одной стороны, через HKCR после переназначения мы не имеем доступа в части HKLM.
С другой стороны, создание объектов продолжает работать (по крайней мере, на svr 2003 sp1)

Тут интересным оказывается факт, что RegOverridePredefKey() по-разному влияет на методы типа RegCreateEx(), RegOpenEx() и т.д, и на методы COM-системы типа CoCreateInstance(), CLSIDFromProgID() и т.п.

По моему мнению, первая группа учитывает переназначение, а вторая - игнорирует.
На данный момент, неизвестно на чем основано такое поведение, поэтому нет уверенности, что на всех системах оно будет ожидаемым.

Цитата:

Эт точно.

sedmin писал(а) 08. Сентября 2007 :: 15:47:


Вот еще что вспомнил.

На NT4 и на Win9x нет такого экспорта RegOverridePredefKey в ADVAPI32.DLL (это точно).
Так что шанс примерно 100%, что такое решение именно "не заведется".

Возможно, стоит получать адрес динамически.