1) В чем разница между идентификатором и дескриптором процесса/потока, почему нельзя было обойтись только одним из них при создании WinAPI?
2) Как связан hinstance приложения с иденфтификатором/дескриптором процесса или потока? То есть как получить дескриптор процесса/потока другого приложения зная hinstance? (если hinstance это не один из них )

Заранее спасибо)

Здравствуйте, shumar, Вы писали:

S>1) В чем разница между идентификатором и дескриптором процесса/потока, почему нельзя было обойтись только одним из них при создании WinAPI?

Как имя файла и дескриптор файла. Разница понятна?

S>2) Как связан hinstance приложения с иденфтификатором/дескриптором процесса или потока?

Никак

S>То есть как получить дескриптор процесса/потока другого приложения зная hinstance?

Никак

S>(если hinstance это не один из них )

Нет, это совсем отдельное.

А вообще — читай Рихтера.

Здравствуйте, SergH, Вы писали:

S>>1) В чем разница между идентификатором и дескриптором процесса/потока, почему нельзя было обойтись только одним из них при создании WinAPI?

SH>Как имя файла и дескриптор файла. Разница понятна?

Не совсем, имена файлов нужны по сути для людей, у процессов для этого вполне подходит имя экзешника.
Можно вкратце где в API используется идентификатор, а где дескриптор?

S>>То есть как получить дескриптор процесса/потока другого приложения зная hinstance?

SH>Никак

Тогда как иначе можно получить информацию о процессе, зная заголовок его окна?

З.Ы. Пойду читать Рихтера)

Здравствуйте, shumar, Вы писали:

S>1) В чем разница между идентификатором и дескриптором процесса/потока, почему нельзя было обойтись только одним из них при создании WinAPI?
S>2) Как связан hinstance приложения с иденфтификатором/дескриптором процесса или потока? То есть как получить дескриптор процесса/потока другого приложения зная hinstance? (если hinstance это не один из них )

S>Заранее спасибо)
Обычно дескриптор связан с процессом в котором он создан или получен, а также с неким объектом ядра. В большенстве случаев этот дескриптор невалиден в адресном пространстве другого процесса, тогда как идентификатор валиден среди всех процессов, которые показывает таск манагер
Но там вроде есть ещё какието ограничения, типа другого рабочего стола на тойже машине или другой оконной станции под которой существуют рабочие столы, блабла

Здравствуйте, shumar, Вы писали:

S>Не совсем, имена файлов нужны по сути для людей, у процессов для этого вполне подходит имя экзешника.

А если два раза запустить один exe-шник?

S>Можно вкратце где в API используется идентификатор, а где дескриптор?

думать надо, я так не вспомню Но, по смыслу, аналогия с именем файла остаётся верной.

S>Тогда как иначе можно получить информацию о процессе, зная заголовок его окна?

FindWindow + GetWindowThreadProcessId

Здравствуйте, shumar, Вы писали:

S>Можно вкратце где в API используется идентификатор, а где дескриптор?

Идентификатор обозначает собственно объект, он уникален в соответствующем пространстве имен (сессия, система, сеть и т.п.). Дескриптор (ключ) обозначает орган управления объектом (handle — "рукоятка"). Для одного объекта может быть несколько дескрипторов с разными свойствами/правами, один и тот же процесс может создавать произвольное количество дескрипторов одного объекта.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, shumar, Вы писали:

S>>Можно вкратце где в API используется идентификатор, а где дескриптор?

ЕМ>Идентификатор обозначает собственно объект, он уникален в соответствующем пространстве имен (сессия, система, сеть и т.п.). Дескриптор (ключ) обозначает орган управления объектом (handle — "рукоятка"). Для одного объекта может быть несколько дескрипторов с разными свойствами/правами, один и тот же процесс может создавать произвольное количество дескрипторов одного объекта.

плохое определение.
1. не понятно время жизни идлентификатора
2. не понятно можно ли handle передавать другому проессу,
мелось опустим

СМ>1. не понятно время жизни идлентификатора
Идентификатор — это идентификатор. Pid 288 в один момент может означать один процесс, а в другой — другой, запустившийся после помирания первого. Хэндл же например полученный от CreateProcess или OpenProcess будет юзабелен и предоставлять необходимый контроль над объектом того самого процесса на который он был открыт до своего закрытия. Тоже самое с файлам и остальным.

СМ>2. не понятно можно ли handle передавать другому проессу,
Можно. При наличии необходимых прав.
Хэндл — сущность, иденцифицирующая объект в контексте конкретного процесса + хранящая в себе некоторую дополнительную контекстную информацию и информацию о правах доступа с которыми был открыт объект. Т.е. — если открыл хэндл на файл с GENERIC_READ — сможешь этот хэндл только читать. С другой стороны — если удалось открыть на запись и чтение — то гарантируется, что ты сможешь далее писать/читать не получая в ответ ERROR_ACCESS_DENIED. Кроме того хэндл может хранить в себе некую контекстную информацию касательно предыдущих действий именно с этим хэндлом. Например текущая позиция чтения/записи файла — она у каждого хэндла своя (исключая сдуплицированные хэндлы). Да и в конце концов работать с объектами быстрее, нежели если бы приходилось при каждой операции записи/чтения файл передавать имя, контекстное состояние, флаги-хинты для подсистемы кэша, флаги необъодимости пересоздания файла etc. С процессами это не так выражено, но суть таже самая — PID — уникальный идентификатор процесса. Открыв процесс например PROCESS_VM_OPERATON можно потом выделять в нем память с VirtualAllocEx.
За всем этим скрывается менеджер объектов ядра NT, в котором проверка прав доступа конкретного процесса к конкретному объекту и установка дополнительной контекстной информации о дальнейшей работе с объектом осуществляется непосредственно при открытии хэндла на объект. Кроме того объект может и не иметь имени — например неименованные мутексы, ивенты и тп. Все это работает в ядре через один общий менеджер объектов (с процессами правда есть некоторые заморочки но суть таже)