Не совсем про доработку ImageUtils, скорей - интересный вариант работы, когда нужно иметь прозрачную связь между массивами.
Скажем, есть образ диска RT-11. Там есть home block (блок с номером 1). Допустим, хочу я его проинить - соотвественно, мне надо проинитить элементы массива со смещением (пусть массив байтовый) от 512 до 1023. А ещё есть сегменты каталога - много - со смещениями [6*512..8*512-1], [8*512..10*512-1] и так далее.. И каждый раз надо эти смещения считать.
Но в восьмой версии C# появились диапазоны (range) и можно выпилить кусок из массива, написав что то типа homeBlock = image[512..1023] и поразвлекаться с homeBlock, используя уже более простой индекс - от 0 до 511. Удобно? Да. Но есть нюанс. Это будет работа не с куском из шmage, а со вполне самостоятельным экземпляром массива, то есть, по сути - image[512..1023] - всего лишь удобный способ вызвать Array.Copy(), в нашем случае - что-то типа
Код:
homeBlock = new byte[512];
Array.Copy(image, 512, HomeBlock, 0, 512)
О да, не спорю - пришлось набить ГОРАЗДО МЕНЬШЕ символов, а реальный код, напоминающий вышенаписанное - сгенерит компилятор (традиционное название подхода - синтаксический сахар и его сейчас в C# - МНОГО 
).
Но что если я хочу проинить HomeBlock? А потом записать Image в файл? Упс.. Придётся скопировать HomeBlock обратно в Image и вспомнить про смещения. Не.. Не сильно легче и удобно
И таких моментов у меня в ImageUtils накопилось.. Много Идея появилась с примерно неделю назад, примерно со среды (вечера, плюс момент засыпания) крутилась в голове и вот сегодня я набросал код SmartArray Теперь можно написать примерно так:
Код:
SmartArray<byte> image = new SmartArray<byte>(65536);
SmartArray<byte> homeBlock = image[512..1023];
homeBlock[0] = 10;
homeBlock[1] = 12;
И записываемые значения 10 и 12 попадут куда надо - в элементы 512 и 513 массива image. Этакий эквивалент (для знатоков) оператора EQUIVALENCE в FORTRAN-е
А теперь хочу попробовать обойтись без методов работы с image на уровне блоков (помним же, что это образ диска, а на диске блоки, да ещё и бывают физические и логические, да ещё и интерлейс.. ) - аж два набора методов для чтения-записи. Брррр
И вот видется мне подход, когда на считанный image я кладу два отображения - физические блоки и логические, плюс указываю методо подсчёта интерлейса для физических блоков... Что то типа (пока это фантазия )
Код:
SmartArray<byte> image = new SmartArray<byte>(65536);
SmartArray<byte>[] logical = image[,, 512];
SmartArray<byte>[] physical = image[,, 128];
И писать что то типа logical[1][0] = 10 попадая как раз в home block (логический блок 1, физические блоки 36-38-39-40, смещения 4608..4735, 4864..4991 ну и так далее
Ну и начала крутиться в голове похожая идея, только более сложная - для DisAsm-а, поскольку там в LDA, SAV, TSK и им подобным файлам куча служебки, а уж в OBJ её на порядок больше, плюс команды бывают одно, двух, трёх, четырёх и пятисловные.. Но там её ещё надо, засыпая, покрутить
Пока попробую для ImageUtils (и TU58fs)
- - - Добавлено - - -
Засада подкралась оттуда, откуда не ждали 
range - он только int, то есть максимальный размер образа - 2 Гб Ну, если сделать блочный режим - тогда в принципе норм 1 ТБ - что перекрывает максимальный размер диска или раздела для ODS-1. Но с образами от VMS могут быть проблемы...
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
