У этой штуки очень много приколов и хитростей (один только доступ к статусам через PEEK чего стоят). Про неё уже где-то писали интересное, в 90-х (возможно, у Волкова или у Серкова).

п1 как бы даже не удивляет. Не тот уровень разработки, а виласапет новый.
"Танк секретный, физики могли не знать" :)

п2 ... так же как и добавить новых багов.

Понятно, что раз они перетаскивали всё на новые адреса, исходники у них были.
И мы даже примерно представляем себе - какие.
Не то, чтобы подробные, но это не мешало их править во все стороны.

В ИКП, например, команда BLOAD умеет читать текстовые файлы. В DOS3.3 такое даже вообразить невозможно было.

----

Однажды, когда нибудь, я причешу все эти исходники и разберу их по частям.
Но не в этом десятилетии, видимо :(

И после любого IF с проверкой ошибочной ситуации стоит просто LDA#<код ошибки> / JMP на эту точку.

Кажется, все сложнее. Например, в коде LOAD есть принудительное закрытие всех открытых файлов, поэтому RUN и LOAD будут работать корректно.

К своему стыду обнаружил, что никогда не читал файлы на Агатовском Бейсике :) Пришлось повозиться с написанием тестовой программки, которая открывает 4 файла неправильных типов. Без ONERR GOTO этого не сделать (программа вылетает), но RESUME передает управление в то место, где возникла ошибка, поэтому файл начинает открываться до бесконечности. Плюс, у ONERR GOTO какие-то странные отношения с циклом FOR. Но ничего, выкрутился. Программка тоже отработала корректно - открытые файлы не накапливаются. По крайней мере, у OPEN проблем нет.

Интересный момент - это то, что в тексте кода BLOAD есть комментарий "(CHANGED 11/1/78 FOR TYPE MISMATCH)". Дело в том, что к 1 ноября 1978 разработчик ДОС над ней больше работал - он еще летом передал код Apple. То есть, эту проверку типов добавляли программисты Apple. И, видно, что-то пошло не так :)

И еще два наблюдения навеянные этой багой:
1) Если в современных операционках написать программу на C, которая открывает два раза один и тот же файл, то получится два разных дескриптора. Используя их, можно, например, читать файл из разных точек. Но если попытаться то же самое сделать в ДОС (например, через вызовы файлового менеджера), то в момент второго вызова OPEN ранее открытый файл закроется и первый дескриптор станет недействителен. То есть в ДОС в принципе другой подход (один файл - один дескриптор).

2) Файл-менеджер для ИКП явно переделывали - структуры данных для открытых файлов больше по размеру и устроены иначе. То есть, исходники у разработчиков были достаточно подробные и поправить баг они в теории могли.

Если так, то не только ошибка "Mismatch type file" будет приводить к незакрытым файлам, но и другие, связанные с открытием/закрытием файлов. LOAD, RUN, OPEN, READ, WRITE...

Но, в рамках топика, это всё равно возвращает к тому, что нужно выкопать указатель на последний выделенный блок и работать от него. Либо воткнуть в начало проги "MAXFILES 3".

2) попытаться найти указатель на последний используемый буфер. Мне этот вариант не очень нравится, потому что ошибочно выбранный файл остается открытым. А если пользователь три раза ошибется, то программа все равно сломается.

3) попробовать обработать ошибку и закрыть файл. Как оказалось, команда MAXFILES принудительно закрывает все открытые файлы, поэтому можно добавить такой обработчик ошибок:

96 ONERR GOTO 5000

5000 ER = PEEK(222)
5010 IF ER = 6 THEN STOP
5020 IF ER <> 13 THEN GOTO 5050
5030 PRINT "НЕВЕРНЫЙ ТИП ФАЙЛА": GET A$
5040 PRINT: PRINT CHR$(4)"MAXFILES 3"
5050 RESUME

В ячейке 222 лежит код ошибки ДОС. В строке 5010 сделана проверка на код ошибки "файл не найден". Я сделал тут выход из программы если вместо выбора файла нажали "РЕД". Если такая проверка не нужна, можно эту строку убрать.
В строке 5020 сделана проверка на код ошибки "Неверный тип файла", в строке 5030 вывод текста ошибки, а в строке 5040 - собственно выполнение команды MAXFILES.

Понятно, что костыль, и лучше бы исправить ДОС, но это уж очень тяжелый вариант.

Вообще, пора уже как у Майкрософта базу знаний багов заводить (Knowledge Base). И все ошибки туда под номерами складывать, а то информация растекается по разным темам форума и фиг ее потом найдешь.

Видимо, проблемы именно с закрытием файла, использующего первый буфер.

А, нет. Неправильно проверил :)

Я выбирал для BLOAD один и тот же файл. И похоже, что ДОС видит, что такой файл уже открыт и не пытается выделять ему новый буфер.

Но если попытаться через BLOAD загрузить 3 разных файла типа A, то буфера тоже будут использоваться разные. И после трех ошибок подряд на очередную попытку загрузки ДОС выдает ошибку "МНОГО ОТКРЫТЫХ ФАЙЛОВ".

Так что BLOAD файла типа A просто оставляет незакрытым файл. Независимо от номера буфера.

Так если его можно менять через MaxFiles - это и есть динамическая память.

Динамическая она с некоторой натяжкой. Хоть там и связанный список, но реально выделяется сплошная область памяти с фиксированного адреса. Причем, вся эта динамичность происходит только при запуске ДОС или вызове MAXFILES.
В тот момент, когда происходит ошибка в примере выше - никакая память не выделяется и не освобождается.

Насколько я понимаю, происходит следующее.
При старте ДОС создает набор буферов под 3 одновременно открытых файла. (3 - это настройка MAXFILES по умолчанию.)
Под каждый файл выделяется примерно 600 байт места (буфер данных, буфер TSL, имя файла и что-то еще).
При каждой операции с файлом ДОС выбирает свободный буфер. Если нет других открытых файлов, то этот буфер один и тот же, в данном случае $B107.
Но когда в примере выше происходит ошибка, то ДОС после этого по какой-то непонятной причине в качестве свободного выбирает следующий буфер, с адреса $B35A. И дальше пользуется им.

ДОС, как я понимаю, для освобождения буфера записывает нуль в первый байт имени файла. Как я вижу в эмуляторе, после ошибки имя файла, вызвавшего ошибку, сохраняется (адрес $B334). То есть, кажется файл не закрывается. Но в то же время, если спровоцировать ошибку еще несколько раз, то все продолжает работать, исчерпания количества открытых файлов не происходит. Видимо, проблемы именно с закрытием файла, использующего первый буфер.

Я проверял под ИКП-9.

Я помню ошибку с очисткой таких же буферов под Школьницей.
На форуме писал, несколько лет назад.

В ДОС же можно открыть файл и не закрывать его в одной операции. Сколько таких файлов будет - заранее неизвестно. Во всяком случае текстовых - легко. Другие типы - тоже можно, но посложнее (через FileMan).

Т.е. под один файл выделяется какой-то один кусок, под другой файл будет уже выделятся другой кусок.
Пусть даже формально этот кусок как будто и так зарезервирован ДОСом, но важно то, что некий произвольный по счёту файл может попасть в разные адреса памяти.

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

какой-то блок памяти забывают освободить

Прикол в том, что у ДОС даже диспетчера памяти нет. Практически все данные размещены статически, поэтому ничего не выделяется и не освобождается.
Есть только связанный список буферов файлов, размер которого можно поменять через MAXFILES. Но и этот список размечается либо в момент инициализации ДОС, либо в момент вызова команды MAXFILES, а потом никак не меняется.

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