Просмотр полной версии : ImageUtils
Обнаружил некоторые ненужные действия в процессе распаковки образов :) Поправил :)
Теперь работа программы ускорилась практически в два раза :)
На тестовом наборе (разные операции, в основном распаковка, но прилично и работы с секциями) примерно в 7.5 гигов время работы было примерно 40 минут, теперь в районе 21 минуты.
Продолжаю доработку вывода тех информации. Что бы и всю и читабельно :)
К сожалению, выходные закончились, так что дальше всё будет медленней.. До следующих выходных :)
Что такое кластерный АД? Это файловая система RSTS :)
По порядку.
Достаточно быстро разрабы RSTS дошли до точки, когда выяснилось, что 16-ти битный номер блока - это мало :) И с этим надо что-то делать :)
Вспоминая другие ФС, можно увидеть три варианта - забили, с самого начала использовли больше 16-ти бит (RSX), ввели понятие секции (RT-11)
В RSTS народ пошёл своим (не оригинальным) путём - ввёл понятие кластера.
То есть, в зависимости от размера диска, вычсиляется размер кластера, так что бы номер блока оставался 16-ти битным - и вуаля. Этот размер кластера (устройства) иногда даже записывается в секретное место :)
А вот дальше начинается АД.
Помимо размера кластера для устройства - ввели ещё размер кластера для pack-а (а ля disk pack, а ля дисковый пакет). Типо - умолчание для всего файлового на диске. Тоже записан в метаинформации.
Но.
Если надо - для каталога можно ввести свой размер кластера по умолчанию - для всех файлов в этом каталоге.
И.
Если очень надо - для файла можно ввести свой размер кластера - конкретно для этого файла.
Да уж.. Гулять так гулять :)
На текущий момент - метаинформация обрабатывается вроде корректно и файлы извлекаются вроде тоже корректно.
Но вот техническая информаци, а конкретно - что в каком блоке что находится... Воюю :)
Тэкс.. вроде то, что я вижу в тех информации о записях в MFD и UFD и их распределении по блокам - меня устраивает :) Двигаемся дальше :)
Как обычно - параллельно добавлению функционала - идёт доработка внутренностей и устранение старых "проблем".
С самого начала ImageUtils писался так, что бы не гонять лишний раз данные из образа туда-сюда. Скажем, если файл в образе занимает смежные блоки (непрерывный), то вместо создания для объекта файл массива с данными файла и копирования байт в него - ImageUtils создаёт объект SmartArray - который выглядит как массив, но на самом деле просто ссылается в основной массив с данными из образа.
Всё это хорошо работает, когда файлы (или другие данные из образа) непрерывные, но ... Это технически - редкий случай. И для НЕнепрерывных файлов всё делается по старинке. Вот это я и пытаюсь исправить - пока при работе с ФС RDS.
Движение вперёд есть, но пока ещё не всё работает. Тестирую, исправляю ошибки, доработатываю, тестирую,...
Упрощение структуры SmartArray. Проверено на наборе старых тестов и на работе с ФС RSTS.
На этом пока приостановлюсь - надо кое-что оценить и подумать - как двигаться дальше во внутренних доработках.
А пока вернусь к недоделанному в ФС RSTS
Тесты по RSTS включил в общий список
С ФС RSTS вроде более менее закончил. Последние доработки - дамп метаинформации.
Дальше в планах - возможно, как обычно - рефакторинг кода и затем - разные вариант ФС RSTS на лентах.
Хе :) Недореализованный функционал - тесты споткнулись :) Так что сначала его, а уже потом - то, что выше :)
Функционал допилил, все тесты (включая с ФС RSTS) прошли - очередной коммит.
И тут я налетел (в очередной раз) на ленту BRU с ошибками (переставлены местами блоки), так что малость поразвлекаюсь с новой программой (там крайне ранняя пред-альфа версия) - ImagesEditor :)
Посмотрел на образы лент с резервными копиями 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
Пока ещё не везде и не для всех сценариев работы с данными - но процесс продолжается
Чистка кода, рефакторинг плюс одна идея. Но о ней позже - когда получится сделать и что-то показать :)
Реализация идеи несколько затянулась (заодно почистил зависимости), но результат есть :)
>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
Некоторые косяки есть (скажем - нет .TITLE), но в целом - идея вполне :)
Так что теперь для всяких первичных и вторичных загрузчиков, а так же мониторов - можно будет сразу увидеть листинги :)
- - - Добавлено - - -
Насколько сказалось в плане быстродействия - пока не скажу, но в плане размера .exe - ImageUtilsX увеличился примерно в два раза.
- - - Добавлено - - -
Посмотрел на размер DisAsm11 - увеличение примерно на 120 кб меньше, чем размер DisAsm11 - то есть - не весь код из DisAsm11 подтянулся в ImageUtilsX :) Будет время - проанализирую - что ещё можно вырезать :)
- - - Добавлено - - -
В общем, к тестам, идущим примерно 17,5 минут - добавилось ещё примерно полминуты :) Но это так - грубо и навскидку :)
Погулял немного по исходнику F11ACP из P/Os (тот, который работает с подкаталогами третьего уровня). Первое впечатление - файл каталога определяется как файл с расширением DIR и версией 1. Не могу сказать - насколько точно, ещё рассматриваю..
- - - Добавлено - - -
Вдогонку. Для файла каталог тип записи - фиксированной длины и длина записи 16 (20(8)) байт. Но это проверяется и в F11ACP из обычного RSX
В процессе (в числе прочего) разборки файло-помойки. В том числе - распаковываются образы. В процессе распаковки налетаю периодически на образы, на которых 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 они есть :) И ImageUtils успешно падал на этом :) Тоже пофиксил :) Причем сразу оба сценария. Но для второго, чтобы ImageUtils не падал, нужно будет явное указание устройства, несмотря на то, что для образов без интерлейса для RT, RSX и, похоже, RSTS это не требуется - ФС не привязывается к геометрии диска. Но как оказалось - некоторая привязка у, по крайне мере RSX, есть :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot