Посмотрел на образы лент с резервными копиями RSTS, которые напоминали резервные копии BRU - ImagesEditor наглядно показал - насколько я ошибался. Так что, скорее всего - этот функционал будет отложен в сторону. Чем дальше займусь - пока не знаю - после доработки ImageUtils некоторое наведение порядка в файлопомойке
Чистка кода, рефакторинг и - продолжающийся отказ создания копии из исходных данных в пользу SmartArray. Наглядные последствия - время выполнения теста:
02.07.2025 -> 00:20:44.3066525
13.07.2025 -> 00:17:25.9997705
И это при том, что где-то в райне 9-10 июля была добавлена в общий списов распаковка пофиксинного образа ленты с DEC C 1.2 RSX
Пока ещё не везде и не для всех сценариев работы с данными - но процесс продолжается
Последний раз редактировалось Hunta; 24.12.2025 в 11:19.
Чистка кода, рефакторинг плюс одна идея. Но о ней позже - когда получится сделать и что-то показать
Реализация идеи несколько затянулась (заодно почистил зависимости), но результат есть
Некоторые косяки есть (скажем - нет .TITLE), но в целом - идея вполнеКод:>dir 1 Directory of 1 0 File(s) 0 bytes >ImageUtilsX.exe -unpack Src\m013.dsk 1\@m013.dsk rx01 rt >dir 1\@m013.dsk\@MetaFiles@ Directory of 1\@m013.dsk\@MetaFiles@ 28.07.2025 00:46 512 $BOOT.BLK 28.07.2025 00:46 19 732 $BOOT.LST 28.07.2025 00:46 804 $META.INF 28.07.2025 00:46 118 $ORDER.INF 28.07.2025 00:46 2 048 $SECBT.BLK 28.07.2025 00:46 10 446 $VOLUM.INF 6 File(s) 33 660 bytes >type 1\@m013.dsk\@MetaFiles@\$BOOT.LST .NLIST .INCLUDE /ASCII.MAC/ ; .INCLUDE /HWDF.MAC/ ; .INCLUDE /DSMAC.MAC/ ; .INCLUDE /MYMAC.MAC/ .LIST .IDENT /01/ TPS =: ^O<177564> TPB =: ^O<177566> .ASECT .=^O<0> START: 000000 000240 <240><0> D NOP 000002 000005 <5><0> E RESET 000004 000404 <4><1> FT BR M00016 000006 000000 <0><0> .WORD 0 000010 000000 <0><0> .WORD 0 000012 041420 <20>/C/ J_H .WORD 41420 000014 116020 <20><234> X82 .WORD 116020 M00016: 000016 000400 <0><1> FP BR M00020 M00020: 000020 004067 /7/<BS> ALW JSR R0, M00070 000022 000044 /$/<0> 6 000024 000015 <CR><0> M .WORD 15 000026 000000 <0><0> .WORD 0 000030 005000 <0><LF> AX .WORD 5000 000032 041077 /?B/ JW9 .WORD 41077 000034 047517 /OO/ L$W .WORD 47517 000036 026524 /T-/ GJD .WORD 26524 000040 026525 /U-/ GJE .WORD 26525 000042 067516 /No/ Q2N .WORD 67516 000044 061040 / b/ O. .WORD 61040 000046 067557 /oo/ Q3G .WORD 67557 000050 020164 /t / EG. .WORD 20164 000052 067157 /on/ QZ1 .WORD 67157 000054 073040 / v/ R6 .WORD 73040 000056 066157 /ol/ QM9 .WORD 66157 000060 066565 /um/ QTU .WORD 66565 000062 006545 /e/<CR> BE_ .WORD 6545 000064 005012 <LF><LF> AXJ .WORD 5012 000066 000200 <200><0> CH .WORD 200 M00070: 000070 105737 /ê/<213> VOG TSTB @#TPS 000072 177564 /tš/ ___ 000074 100375 /™/<200> TYU BPL M00070 000076 112037 <37><224> W$9 MOVB (R0)+, @#TPB 000100 177566 /vš/ ___ 000102 100372 /‡/<200> TYR BPL M00070 000104 000777 /š/<1> L1 BR . 000106 000000 <0><0> .WORD 0 ...... Тут одни нули :) 000774 000000 <0><0> .WORD 0 000776 000000 <0><0> .WORD 0 .END START
Так что теперь для всяких первичных и вторичных загрузчиков, а так же мониторов - можно будет сразу увидеть листинги
- - - Добавлено - - -
Насколько сказалось в плане быстродействия - пока не скажу, но в плане размера .exe - ImageUtilsX увеличился примерно в два раза.
- - - Добавлено - - -
Посмотрел на размер DisAsm11 - увеличение примерно на 120 кб меньше, чем размер DisAsm11 - то есть - не весь код из DisAsm11 подтянулся в ImageUtilsX
- - - Добавлено - - -
В общем, к тестам, идущим примерно 17,5 минут - добавилось ещё примерно полминуты
Последний раз редактировалось Hunta; 28.07.2025 в 00:08.
Погулял немного по исходнику F11ACP из P/Os (тот, который работает с подкаталогами третьего уровня). Первое впечатление - файл каталога определяется как файл с расширением DIR и версией 1. Не могу сказать - насколько точно, ещё рассматриваю..
- - - Добавлено - - -
Вдогонку. Для файла каталог тип записи - фиксированной длины и длина записи 16 (20(8)) байт. Но это проверяется и в F11ACP из обычного RSX
anasana(14.09.2025)
В процессе (в числе прочего) разборки файло-помойки. В том числе - распаковываются образы. В процессе распаковки налетаю периодически на образы, на которых ImageUtils валится. Обычная причина - в образе есть ошибки, которые ImageUtils не смог обойти. Пофиксил некоторое количество таких сценариев. Но интересней сценарии, когда ImageUtils валится в принципе на правильном (с точки зрения ФС) образе. Наткнулся на два таких сценария.
Первый - с файловой системой RSTS. Похоже при заведении нового UIC-а для пользователя - UFD в файловой системе для него создаётся не сразу, а при первом заходе. Надо будет проверить по докам. Но нашлись два таикх образа - UIC заведён, а UFD нет. Теперь такой сценрий обрабатывается без падения.
Второй - часто попадаются образы, размер которых меньше размера устройства, для которого образ создан или с которого он снят. Типа - в хвосте образа блоки не используются - чего держать образ полного размера, давайте его УМЕНЬШИМ. Нуу.. RT-11, например, на это наплевать. XXDP, скорее всего - тоже. А вот с RSX есть некоторые проблемы. Так как у неё в ФС присутствует файл BADBLK.SYS, куда система отправляет блоки, при чтении или записи которых возникает ошибка. Если диск был без сбоев, часто в этом файле присутствует самый последний блок - туда утилита BAD заносит информцию о том - нашлись или нет плохие блоки. Если не нашлось - только последний блок и используется. Если нашлись - возможно, что такие блоков будет не один (в определённых сценриях). Технически получается что уменьшать размер образа нельзя, а практически - если аккуратно - то можно, всё равно в BADBLK.SYS ничего инетерсного нет. Но. Есть ещё сценарий, когда BADBLK.SYS, даже при отсутствии плохих блоков, будет размером больше, чем один блок. Если диск - из семейства дисков с Last Track (или как они там называются). Если на пальцах - последняя дорожка на последнем цилиндре используется для хранения информации об обнаруженных плохих блоках, а так же их подмены. Конкретный пример - RL01 и RL02. И вот налетел я на образ RL02, где last track был частично (7 блоков из 10, если не ошибаюсь) срезан. Но в BADBLK.SYS они есть
Последний раз редактировалось Hunta; 05.01.2026 в 17:05.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием