Значения хендлов объектов ядра иду через 4 начиная с 4. При создании процесса система сама открывает несколько объектов. Так что изначально несколько хендлов уже есть. Поэтому hFile1 будет =~50h или около того. Соответственно hFile2 = 54h и т.д.

А что касается открытия/закрытия-открытия/закрытия.... Если бы было так, как ты предполагаешь, то, например, процесс открыл 1000 объектов, а потом все их закрыл - место в таблице хендлов освободилось. Если процесс продолжает открывать объекты, то какой смысл выделять доп. память под таблицу хендлов раз в ней есть свободное место.

Это опять все теория, а у тебя практическая проблема. Не будет процесса с 1000 открытых хендлов. Ну если только автор специально этого не сделает. А сделает, ну и сам дурак ;-)

Здесь я согласен. Кстати по поводу количества хэндлов - знаю я проги с >3K количеством хэндлов (GDI) :)
Кроме того - можно посмотреть как выдаются PID процесса - тут очень похоже. К примеру в unix где многопоточность реже используется чем fork (и следовательно рождение и умирание процессов там более интенсивное чем в win32) можно наблюдать, что PID процессов растет до 32768 (если не ошибаюсь) а потом опять начинается с начала.

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

[ rst: Кстати по поводу количества хэндлов - знаю я проги с >3K количеством хэндлов (GDI) ]

Очень может быть, но мы то говорим про kernel-object хендлы, а не про User/GDI-object хендлы. Это совсем разные вещи! User/GDI-object хендлы вообще не попадают в таблицу хендлов процесса. Для них есть две глобальные для системы таблицы. Почитай раздел "USER and GDI Objects" в доке к айсу.

Дальше я не совсем понял, что ты сказал, но разумеется система пытается как то оптимизировать размер таблицы хендлов. Точного алгоритма я не знаю, но думаю, что вряд ли она будет выделять дополнительную память под нее, даже при огромном ее количестве, если в таблице хендлов имеется много свободных мест.

По поводу оптимизации таблицы хэндлов - я хотел сказать, что если процесс открыл одновременно 100 миллионов хэндлов, то размер таблицы вырастет до 100 миллионов записей, и не будет "моментально" оптимизирован при закрытии хэндлов. логично? следовательно для такого "жирного" процесса даже если он в конце концов зкроет все свои хэндлы нужно будет делать итерации не до 65535 а до 100 000 000

Теоритически может оно и так, но практически ты же понимаешь, что такого процесса никогда не будет.

И вообще. Ты практически то попробовал что-нить из обсужденного здесь? Что мы там закрываем то, сом порт? Уже не помню ;-) Если его, то это наверное будет объект порт или файл. Если файл, то в аттаче статья Ашота "Как получить список открытых файлов на Win9x". Пага, вроде, умерла - не ищи. Если нужны будут исходники - могу поискать у себя на винте. Можешь, кстати, к Ашоту обратиться - он наверняка че-нить дельное подскажет. Где его найти думаю знаешь.

ЗЫ: И заканчивай теоритизировать :-)

_38428145__OpenFilesWin9x.rar

Может я чего-то не понимаю, но нельзя ли под 9x использовать
API функцию CreateToolhelp32Snapshot ?

Так она хендлы не перебирает.

Ну статья у Ашота вроде называется "Как получить список открытых
файлов на Win9x", про хэндлы не сказано ;-)

Мда... Это я по запаре протупил конкретно ;-)))
Но, с Ашотом все равно поговорить стоит.