OSDev

Решил завести отдельную тему.
Как известно в DOS для работы с файлами используются хэнделы. Вопрос был в том сколько хэнделов может выделить дос и где они хранятся?
А вот что оказалось. Оказалось что число хэнделов находится в заголовки программы. Откуда дос резервирует требуемое число памяти. Т.е программа знает сколько ей хэндел-файлов понадобиться. 1-2 или N. На N можно сделать пул.

Более того подобная технология используется для задания стека. Глубина стека определяется вложенностью функций.

Что самое удивительное, то в PE есть в заголовке место для задания размера кучи.

Собственно интересует ваше мнение о причинно-следственной связи. И в чём плюсы минусы детерминированного подхода по сравнению с другими подходами.

А ещё есть пример. Числа int, long int. Можно выделить разные подходы.
а). Предсказания переполнения своевременная проверка.
б). Увеличение типа результата операции(IMUL).
в). Использование самого большого типа(Pascal, первые компиляторы Cи до приняеия стандарта).
г). Длинная арифметика.


PS. ногами не бить ухожу спать времени проверить факты нет. Т.е заголовки я не изучал. Изучал другой матерьал.

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

> Вопрос был в том сколько хэнделов может выделить дос и где они хранятся?
В config.sys (в нормальном ms|pc dos, про фришное поделие я хз) можно указать директиву FILES=число ( http://www.geos-infobase.de/ND_DOCS/206.HTM ), указывающую сколько хэндлов может выделить система (есть и дефолтное значение). Где хранятся - очевидно, где-то в выделенной для себя ядром памяти (в секции данных или в куче). Но в современных операционках эти костыли не очень-то нужны.

Насчёт проверок - давно известное дело. Собственно, если почитать насчёт типизации в языках (и про языки за пределами сишечки, пхп и жабы, впрочем, в них это тоже есть), то ВНЕЗАПНО можно обнаружить что идея с помощью статического анализа программы узнавать где и какие пределы могут быть - совсем не нова, да ещё и в той или иной мере много где реализована. Выражаясь более по-человечески:

> Что самое удивительное, то в PE есть в заголовке место для задания размера кучи.
Не сильно удивительно, туда чего только не тащили.

> Собственно интересует ваше мнение о причинно-следственной связи. И в чём плюсы минусы детерминированного подхода по сравнению с другими подходами.
Что значит плюсы, звучит как будто этот подход мешает другим, в то время как он совсем не мешает и может применяться вместе с другими подходами. А плюсы очевидны: чем больше проверишь заранее, тем меньше надо будет дёргаться в рантайме (т.е. во время выполнения), соотв. система может работать шустрее и кода может быть меньше. А может и не быть, но хуже не будет.

Массив хэндлов в заголовке программы ДОС нужны для того, чтобы системе знать какие хэндлы закрывать при выходе из программы. А также для того, чтобы программы не использовали слишком много хэндлов. Обычно в системе 40 дескрипторов, а в заголовке программы 20 хэндлов.

Если рассматривать детерминированность в глобальном смысле, то чем больше детерминированности, тем больше будет вычислено на этапе компиляции. Идеальная программа вообще может быть выполнена на этапе компиляции.

> Идеальная программа вообще может быть выполнена на этапе компиляции.
Щито. Не знаю как там в мире идеальных, а у полезной программы есть в том или ином виде входные данные и от них должен зависеть (иначе зачем было писать программу) результат. Это я так, чтобы Остапа не несло.