У меня есть несколько тестовых виртуалок с разными версиями винды, включая XP, и для автоматизации работы в них используются командные файлы с хоста, вызываемые через shared folders. Давно заметил, что работа мало-мальски сложных командных файлов в виртуалках совершенно неадекватно тормозит. Например, десяток скриптов, вызывающих друг друга для настройки окружения и копирования нескольких файлов с хоста, может работать по полминуты и дольше. Пару раз порывался выяснить, отчего так тормозит, но обнаружилось, что везде тормозит равномерно, а разбираться глубже руки не доходили.

Сегодня вот, наконец, дошли — догадался последить за работой cmd.exe в Process Monitor. Увидел, что для чтения каждой строки скрипта он открывает файл, устанавливает текущую позицию, читает до 8191 символа (максимальная длина строки), затем закрывает файл. Внутри одной системы спасает кэширование, а для сетевых операций то ли винда, то ли поддержка shared folders, добавляют флаг запрета кэширования, и привет.

Теперь мучительно пытаюсь это развидеть, и заодно понять, в каком бреду можно было родить такой чудовищный алгоритм. Это не CRT — чтение в cmd.exe реализовано независимо. И так оно работает вплоть до последних версий Win 11, если что.

ищите ответ
https://github.com/Vichingo455/nt5src/tree/master/Source/XPSP1/NT/base/cmd

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

ЕМ>Теперь мучительно пытаюсь это развидеть, и заодно понять, в каком бреду можно было родить такой чудовищный алгоритм. Это не CRT — чтение в cmd.exe реализовано независимо. И так оно работает вплоть до последних версий Win 11, если что.

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

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

ЕМ>...для чтения каждой строки скрипта он открывает файл, устанавливает текущую позицию, читает до 8191 символа (максимальная длина строки), затем закрывает файл.

ЕМ>Теперь мучительно пытаюсь это развидеть, и заодно понять, в каком бреду можно было родить такой чудовищный алгоритм. Это не CRT — чтение в cmd.exe реализовано независимо. И так оно работает вплоть до последних версий Win 11, если что.

Мне кажется это из MS DOS пришло. Там по дефолту files=8 — это значит, что одновременно может быть открыто только 8 файлов. Это очень мало. Я думаю именно поэтому оно каждый раз закрывает файл и заново его открывает.

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

Pzz>Наверное тот, кто это писал, держал в поле зрения тот факт, что в MS-DOS

Господь с Вами, какой еще MS-DOS в интерпретаторе NT?

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

ЕМ>Теперь мучительно пытаюсь это развидеть, и заодно понять, в каком бреду можно было родить такой чудовищный алгоритм.
Ну, реализация кривая, но дает, например, возможность реализовать частично самомодифицируемые файлы скриптов.

ЕМ>Это не CRT — чтение в cmd.exe реализовано независимо.
Ответ есть среди ответов на SO:

The command interpreter remembers the line position byte offset it's at in the batch file. You will be fine as long as you modify the batch file after the current executing line position byte offset at the end of the most recently parsed line of code.

If you modify it before then it will start doing strange things (repeating commands etc..).

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

C>дает, например, возможность реализовать частично самомодифицируемые файлы скриптов.

Для ничтожной доли самомодифицирующихся скриптов логично было бы сделать спецрежим.

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

Pzz>>Наверное тот, кто это писал, держал в поле зрения тот факт, что в MS-DOS

ЕМ>Господь с Вами, какой еще MS-DOS в интерпретаторе NT?

Культура и стиль.

ЕМ>Теперь мучительно пытаюсь это развидеть, и заодно понять, в каком бреду можно было родить такой чудовищный алгоритм. Это не CRT — чтение в cmd.exe реализовано независимо. И так оно работает вплоть до последних версий Win 11, если что.
Индусы, вестимо...