Рассылка закрыта
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Программирование для начинающих выпуск 6.2
Программирование для начинающихВыпуск 6.2
Ведущий рассылки: Вячеслав Мацнев | e-mail: stac@stacmv.net | |||||||
|
| В этом выпуске читайте: |
Внимание! Выпуск 6 состоит из двух частей. Это - вторая. Вы, должно быть, удивляетесь моей манере нумеровать выпуски рассылки. Что ж, удивляйтесь, вам полезно :-) Я наконец-то автоматизировал подготовку выпусков (но еще не до конца отладил эту самую автоматизацию :). "Давно пора", скажете вы и будете правы. Прошлые выпуски я делал так (рассказываю подробно, потому что вы должны это знать, вдруг придется заниматься подобным):
1. Писал текстовую версию выпуска в редакторе писем The Bat! :-) На все это уходило уйма времени, причем на второй этап тратилось почти столько же, сколько и на первый. Но зато, я отвечал за качество обеих версий рассылки ( и сейчас отвечаю), а то некоторые авторы пишут, что рассылка делается только в HTML, а текстовая версия генерируется СитиКэтом автоматически и за ее качество мы, мол, ответственность не несем. Короче, летом, еще при написании выпуска 5, я подумал: "Е-мое, что я делаю? Я, ведущий рассылки по программированию, не могу что ли написать программу, чтобы упростить подготовку выпусков?" Сказано, сделано :-) Сначала я ткнулся в Word. Ну, думаю, напишу текст выпуска, а затем макрокоманда мне сгенерит HTML вариант. Немного пописал на WordBasic'е, не понравилось. Ну, не люблю я Word. Ладно, а что я люблю? Macro HTML! Там же встроена поддержка скриптов на MHTML (язык имеющий синтаксис языка MUMPS). Стал учить этот язык и сразу его использовать для подготовки сайта (вы тоже будете использовать языки по ходу их изучения). Ну а потом написал скрипты для генерации HTML и текстового варианта выпуска из некоего черновика, имеющего, кроме текста, специальные команды форматирования. Выпуски 6.1 и 6.2. это продукты деятельности этих скриптов. Почему я не сделал один общий скрипт для обеих версий и почему выпуск 6 состоит из двух частей? Дело в том, что я не могу похвастаться стоящим у меня на столе PIII или даже PII, а генерация занимает некоторое время (работа каждого скрипта - порядка 10-15 минут :-( ). Но все равно, это удобно, пока генерился выпуск 6.1, я писал этот текст ... То, о чем, я только что говорил - отличный пример прикладного программирования, врядли вам удастся найти в Сети или в Митино программу для генерации выпусков рассылки "Программирование для начинающих" или для решения вашей личной, сугубо специальной задачи. Кстати, если выпустить полноценную программу, для генерации выпусков любой рассылки, то авторы рассылок могут оторвать руки :-) Ваши вопросы, пожелания, критику кидайте мне на email.
Мы здесь уже упоминали с вами слова "компилятор" и "интерпретатор". Настало время приоткрыть завесу тайны и разобраться с этими понятиями. Может Вам кто-нибудь говорил: "Ты мыслишь как интерпретатор!"? Сегодня Вы узнаете, что он имел ввиду. Помните, я говорил, что при общении программиста с компьютером (при написании программ) имеет место двойной перевод? Так вот, первый перевод осуществляет программист с естественного языка на язык программирования. Второй перевод осуществляет компьютер с языка программирования в машинный код. Делает он это с помощью программ трансляторов. Транслятор - от английского "translator - переводчик" (to translate - переводить, translation - перевод; любителям физики будет интересно узнать, что "translation" также означает и "поступательное движение"). Транслятор - программа переводящая исходный текст программы на языке программирования в инструкции в машинном коде. Существует два вида трансляции (перевода): интерпретация и компиляция. Интерпретатор просматривает исходный текст построчно (по командно) и сразу же выполняет соответствующие встреченной команде инструкции.
Примеры:
1) Программу ALGO помните? Там как раз реализован простенький
интерпретатор
2) Command.com - интерпретатор командных файлов ДОС
3) Интерпретируемые Бейсики используемые в бытовых компьютерах
("Микроша", "БК","Спектрум") и ранних PC
4) Perl
5) MUMPS
6) REXX
Компилятор читает программу целиком, анализирует ее (оптимизирует) и генерирует исполняемый файл (в случае с ДОС, это com или exe файл).
Примеры:
1)Компилируемые Бейсики (Turbo Basic,...)
2) Паскаль, Си и многие другие ЯВУ
3) Ассемблер
Важно ! Компилятор, в отличие от интерпретатора не выполняет программу, он ее создает, точнее, он создает исполняемый файл (в машинном коде) этой программы. -Считается, что интерпретаторы работают медленнее. -Это так. -Во время выполнения программы, интерпретатор находится в памяти, занимает ее. -А как ты хотели? -Программы для интерпретаторов распространяются в виде исходных текстов, трудно защищать авторские права. -Бывает. Но ряд интерпретаторов позволяют скомпилировать исходный текст в некий байт-код (или пи-код), что способствует борьбе за авторские права Вообще, хороший пример преимущества компилятора перед интерпретатором приведен в справочнике пользователя "Турбо Бейсика". Я этот кусочек вырезал и помещу его на сайте в соответствующем разделе ("Бейсик"). Ждите :-(
"Интерпретатор хуже компилятора, интерпретатор, вообще, @#$%!", так
думает огромное количество людей, в основном, это те кто читает
журналы про игрушки (в том числе и не компьютерные) и мало понимает в
программировании. Таких людей можно встретить в метро. Большинство из
них также ненавидят Windows и лично Била Гейтса. Короче, это люди с
"потрепанной" психикой, остро нуждающиеся в госпитализации.
С чем можно сравнить работу интерпретатора и компилятора? "Гнусавый голос" - это интерпретатор, в прямом смысле слова. Почему в прямом? Английское слово "interpreter" (интерпретатор) означает в быту "переводчик-синхронист", тот кто переводит речь с одного языка на другой синхронно. Т.е. он услышал: "There is special local bus for that purpose" и сразу сказал: "Для этой цели есть специальный местный автобус". Помните, как "гнусавые" интерпретаторы всегда мнутся при переводе, путают слова и вообще говорят всякую чушь? Уау! Я однажды смотрел фильм "Леон" Люка Бессона (рекомендую, кстати) в интерпретируемой версии с английского на русский. Пока Леон где-то там ходил, девчонка (забыл имя) нашла пистолет. (Для тех кто не смотрел фильм: Леон - наемный убийца).
Потом она говорит ему: "Я хочу быть уборщицей! Научи меня
убираться!" Я чуть со стула не упал от смеха! Поверьте, лучше всякой комедии! На самом деле фраза должна звучать так: "Я хочу стать наемной убийцей! Научи меня убивать!". Переводчик, как типичный интерпретатор перевел верно, но он, как будто, не видел контекст. Фильм про наемного убийцу, причем здесь уборщица, и зачем ей пистолет :-) В оригинале (на французском) так и говорится, "убийца". Да и при дублировании перевели все как надо. Потому что те, кто дублировал, посмотрели весь фильм целиком и только после этого уже начали переводить. (Зачем я смотрел две версии фильма? - Просто "английская" версия была полной, а во "французской" (она попалась мне первой) некоторые моменты, в частности подготовка девочки по курсу "убийство по найму", были вырезаны из этических соображений. Детям, смотреть не рекомендуется ...) Вернемся на секунду к "автобусу". Как бы перевел то предложение компилятор? Он бы дослушал всю речь до конца: "It's called VLB, VESA Local Bus. Our video accelerator is using this bus to communicate with CPU." А потом бы, перевел: "Для этого имеется специальная локальная шина." или что-то вроде этого. Смысл, как видите, совсем другой. Так же работают и компьютерные компиляторы. Теперь вы все знаете. Осталось, мне только сказать, что у интерпретаторов тоже есть свои плюсы. -Исходный текст всегда под рукой, если надо внести изменение, то сделать это очень легко. -Автор скомпилированной программы тоже имеет исходный текст и может программу перекомпилировать, если что. -Программу легко отлаживать, и эксплуатировать. Не даром CGI скрипты пишутся в основном на интерпретируемых языках -Испугал! Про отладчики слышал? А CGI-программы пишут и на DELPHI и на C. -Интерпретируемая программа может иметь доступ к исходному тексту и модифицировать САМА себя во время выполнения! -... Ну .. это ... #@%$ ... &^%@ -Что, протух?! Конечно, самомодифицирующиеся программы можно писать на Ассемблере, что с успехом делается вирусописателями. А, вот, на компилируемом ЯВУ это сделать трудно (а трудно, значит невозможно). Модификация собственного кода с последующей перекомпиляцией, конечно, не считается. А на интерпретируемом языке такими вещами заниматься одно удовольствие.
Простейший, просто примитивнейший пример на командном языке ДОС.
@echo off rem копируем файл на всякий случай, так как после иодификации rem его исходный текст будет утерян (я же говорю, простой пример) copy main.bat main1.bat >nul choice /c:123 /s Ваш любимый напиток: пиво(1), водка(2), чай(3) ? if errorlevel 3 goto tea if errorlevel 2 goto vodka if errorlevel 1 goto beer :tea echo >main.bat @echo Чай - не водка, много не выпьешь! goto end :vodka echo >main.bat @echo Чего стоишь, как не родной? Наливай! goto end :beer echo >main.bat @echo Губит дюдей не пиво, губит людей вода ... :end Запусите main.bat, выберите свой любимый напиток, нажав одну из предложенных цифр. Запустите main.bat еще раз. Посмотрите его текст в редакторе. Ну как? Вопросы есть? Ну и ладушки, идем дальше.
Приветствую тех, кто присоединился к нам только что. И довожу до их сведения, что начало нашей беседы про файловую систему было в прошлом выпуске (точнее, в первой части этого выпуска :). Смотрите выпуск 6.1. 3. Файловая система (продолжение) Advanced Хочу, чтобы вы вспомнили определение файла ("поименованная область диска") и подумали, как файлы размещаются на диске, как ДОС ищет тот или иной файл по его имени и т.п. Если бы файлы размещались на магнитной ленте, то найти какой-либо файл можно было бы только просмотрев всю кассету от начала и до тех пор, пока этот файл не встретится. Да и то, как узнать, что встретился новый файл, а не продолжается еще предыдущий? Те из вас, кто, в свое время, поработал с "кассетными" компьютерами типа "Микрош", "БэКашек", "Спектрумов" и других, помнят, что в начале каждого файла магнитофон "пищал" отлично от своего обычного "писка". Именно этот сигнал (часто имеющий более высокую частоту) и говорит компьютеру, что начинается новый файл. Он называется пилот-тон, кажется. Сразу после него идет заголовок файла в специальном формате и ОПРЕДЕЛЕННОЙ длины. Из этого заголовка компьютер узнает имя файла, его тип, длину (зная длину файла, компьютер знает, когда надо прекратить его чтение) и другие параметры, разные от системы к системе. Видите, все довольно просто. Кстати, такая файловая система называется системой последовательного доступа. Подумайте, почему. И доступ к любому файлу возможен в этой системе только последовательный, байт за байтом. Т.е. нельзя считать 50-й байт, не прочтя первых 49. Накопители на магнитных дисках (как гибких, так и жестких), могут считывать произвольный участок диска. Файловые системы, которые это используют, называются системами произвольного доступа. Доступ к файлам в таких системах возможен как произвольный (выборка нужной информации из базы данных), так и последовательный (чтение текстового файла и вывод его на экран). При хранении файлов на диске, простым присоединением к ним заголовка и пилот-тона, ограничиться не получится. Потому что, головкам дисковода придется тогда метаться по всему диску выискивая тот или иной пилот-тон (которые, между нами говоря, друг от друга никак не отличаются). А вы бы что сделали? Я бы, например, поделил диск на "страницы" одинакового размера, и на первой или последней "странице" написал "содержание" диска. Просто, да? К тому же писатели и книгоиздатели делают это уже не первый век. В общем-то, все так и сделано. Диск разбит на секторы по 512 байт каждый. На самом деле, он имеет ряд дорожек, которые представляют собой концентрические окружности (точнее кольца некой конечной толщины). А уже каждая дорожка разбита на секторы. Несмотря на то, что диски бывают разные (разное число дорожек, да и число секторов на дороже различно), операционной системе это, извините, пофиг. Для нее, все секторы, сколько бы их не было, пронумерованы от нуля и до конца. "А как эта "пофигистка" узнает на какой дорожке какой сектор находится?", спросите вы. А никак. Этим у нас заведует драйвер дисковода (НГМД или НЖМД), который находится в BIOS'е, пока кому-нибудь не пришло в голову написать свой драйвер. (Если честно, то я забыл, кто на самом деле делает пересчет секторов в дорожки/секторы, кажется это делает не драйвер, а контроллер диска, а может они вместе.) Так или иначе, мы будем рассматривать дальше только непрерывную последовательность пронумерованных секторов по 512 байт каждый. Вот, в эти секторы мы и записываем свои файлы. Если файл больше, чем 512 байт, он займет несколько секторов (сколько надо), а если меньше, то не занятая часть сектора не будет использована. Секете, к чему я? В прошлом выпуске (выпуск 6.1) рассылки я приводил пример программы, которая занимает 29 байт. Допустим, у нас есть 10 таких программ (с разными именами файлов !). Сколько они, по вашему займут места? 290 байт? В памяти, да, а на диске они займут 512 байт каждая или всего 5120 байт = 5 кб. По 483 байта в каждом секторе (всего 4,7 кб) будут не использованы. Эффективность использование диска при этом всего 6% (Примечание: На самом деле все еще гораздо хуже, читайте дальше). А если у нас двадцать таких программ? В памяти они займут 580 байт, а на диске - 10 кб. 9,4 клобайт потеряно! Другое дело, что файлы такого малого размера явление довольно редкое. Теперь, после небольшой эмоциональной встряски, давайте, займемся содержанием диска. Что нам надо от содержания? Надо иметь возможность узнать на какой "странице" находится файл с заданным именем. Сделаем таблицу, назовем ее Каталог, и, при создании файлов, будем туда записывать имя файла, его длину, номер "страницы", сектора и другие параметры. Где будем держать саму таблицу? В конце диска или в начале? Вот, какое дело. Допустим, Каталог у нас в начале. Он занимает нулевой сектор (меньше сектора он занимать не может, вы уже поняли). А сами файлы начнем записывать с какого сектора? С первого или второго? Ведь, добавляя новые и новые файлы в каталог, мы быстро заполним нулевой сектор, и куда ему потом расти? Спрашивается ... :-) Если держать каталог в конце, то проблема не исчезает. Даже, если он будет расти "с конца - в начало", то когда-то пересечется с файлами и затрет их, или они его. Вы пока, думайте, что делать, а расскажу еще об одной проблеме. Если вы посмотрите на файлы, которые во множестве имеются у вас на дисках, то заметите, что подавляющее число из них намного (ох, намного) больше 512 байт. Т.е. они занимают по много секторов. "Ну и что?", скажете вы, "У нас же длина файла в каталоге имеется, какие проблемы, браток?" "Дык, елы-палы!", скажу я вам,"Длина файла меняться может? Может, я вас спрашиваю? Молчите. То-то же". :-))) Вот, смотрите. Пишите вы реферат. Страницу написали, сохранили на диске. Какое-то число секторов заняли. Решили отдохнуть, поиграть в игру. Прошли пару уровней, пора снова работать, сохраняемся ("сэвимся"). "Сэвилка" это тоже файл, он записывается после реферата, занимает свои секторы. И тут вы, на одном дыхании, еще пару страниц реферата набрали. Сохранять надо, длина увеличилась, на старое место файл не поместится. Что делать? Тут может быть два варианта.
Пишем реферат в конец (после "сэвилки"), там еще места море. А старую копию удаляем, чтоб под ногами не путалась. А, чтоб не путаться самим, договоримся, любой файл будем писать всегда в конец, то есть, после других файлов, имеющихся на диске. Просто и удобно!
Проблемы
Решение В этой системе имеется специальная команда MOVE (не путайте с одноименной командой ДОС), которая осуществляет, так называемую, оптимизацию диска. При выполнении этой команды, все файлы (с первого по последний) по очереди переписываются в начало диска, таким образом пустые места исчезают. Демонстрирую на "рисунке" (три точки, означают свободное место):
Было Стало
файл 1 Файл 1
... Файл 2
Файл 2 Файл 3
Файл 3 Файл 4
... ...
... ...
Файл 4 ...
Или, было: "Файл 1, ..., Файл2, Файл 3, ..., ..., Файл 4". Понятно?
Создатели MS DOS пошли другим путем. Решили сделать более "интеллектуальную" систему. Можно, ведь, часть реферата записать на старое место (сколько поместится), а не поместившийся кусочек записать в конец (а точнее, в первое попавшееся свободное место, куда этот кусок поместится). Просто гениально! Вы, наверное, уже представили себе Билла Гейтса, принимающего волевое и единственно правильное решение :-) Но тут я разрушу ваше нежное чувство к заморскому миллиардеру. MS DOS писал не Билл Гейтс и даже не Пол Аллен. Эти два хитреца купили DOS у одной фирмы (не помню название), немного подретушировали (вписали, где можно "Microsoft") и толкнули IBM, вместе со своим интерпретатором Бейсика. Именно отсюда и пошла эпоха завоевания Microsoft платформы IBM PC. Кстати, тоже интересно. Сначала Билл подошел к создателю известной в прошлом системы CP/M (у меня до сих пор хранится дискета со знакомой вам игрой "Prince of Persia", в формате этой системы, между прочим, юзалась она на клоне "Спектрума" - "ATM Turbo"). То ли автор CP/M цену заломил непомерную, то ли сам хотел заработать, но права на систему Биллу с Полом не уступил. Это был переломный момент в истории человечества, о котором, кстати, мало кто знает. Ну а Билла Гейтса тогда сроки поджимали, вот он и носился, искал, где бы операционку прикупить, т.к. писать свою не было времени. У вас, должно быть, чешется уже: Билл Гейтс есть, а проблемы где? Понимаю ...
Проблемы Проблема номер два. Даже если мы будем каким-то образом помнить о расположении каждого кусочка, то все равно файл будет фрагментирован (будет иметь несколько кусков, называемых фрагментами), и при чтении файла, надо будет облазить весь диск, собирая разрозненные куски. "Это, батенька, фгагментация!", т.е. "фрагментация", всем вам знакомая до боли в желудке.
Решение Между прочим, в таких программах, как и в любых других, могут быть ошибки. Такая судьба, например, постигла Norton Utilities 7.0. Был небольшой шумок, обнаружили несколько ошибок. Угадайте где? Правильно в SpeedDisk и в Norton Disk Doctor. Подобная история, кажется, случилась и с одной из версий этого пакета утилит под Windows. Ну ладно, раз в месяц или чаще делаем дефрагментацию и проблема снята. А как хранить информацию о фрагментах файлов до дефрагментации? Была создана специальная таблица, в которой отражаются особенности размещения файлов. Она так и называется "Таблица размещения файлов" или, на языке туманного Альбиона, "File Allocation Table - FAT". Мы будем называть ее "фат", хоть, это и не верно, с точки зрения произношения английских слов. Мы же с вами русскоговорящие, в конце-то концов. Итак, какой принцип был положен в основу этой таблицы? В основу этой таблицы был положен следующий принцип :-) : Каждому данному сектору в таблице размещения соответствует своя ячейка. В этой ячейке лежит число, которое представляет собой номер сектора (он же, номер, соответствующей этому сектору ячейки FAT), в котором лежит "продолжение" файла из данного сектора. Если данный сектор - последний в цепочке, то в ячейке FAT лежит признак конца файла, какое-то определенное число, которое ДОС понимает, как конец файла. Ну зачем вам сейчас знать что это за число? Ну ладно, это число, все биты которого равны "1". Это 0fffh или 0ffffh. Ну, этого мы еще коснемся. Вы придумали, что делать с Каталогом? Уже забыли про это? Плохо. Вы не спешите прочесть выпуск за один присест. Читайте медленно, вдумчиво; дышите спокойно. Если что-нибудь не понятно, прочтите еще раз. Также полезно взять тетрадку или, на худой конец, лист бумаги и пытаться изобразить структуры, которые я описываю, чтобы сформировать о них свое представление. Да, тяжело понять это с первого раза, особенно тем, кто даже слов таких не слышал. Итак, расслабились, кое-то вернулся к началу выпуска. А мы продолжаем. Предлагаю поместить таблицу размещения файлов в самом начале диска (после загрузочного сектора). Сразу за ней поместить еще одну такую же таблицу (вторую копию). На реальных дисках так и сделано. Для надежности, так как теряя FAT, фактически мы теряем сами файлы. Подумайте, с чем это связано. После обеих копий FAT поместим Каталог. Не бойтесь таблицы размещения его не затрут, так как они имеют всегда одинаковый (постоянный размер). Это потому что число секторов на диске со временем не меняется. Но! Размер Каталога мы тогда тоже должны зафиксировать. Давайте, я приведу несколько цифр, чтобы вы оценили с какими величинами мы имеем дело. До этого мы с вами не различали жесткий диск и дискеты. Но они немного отличаются. Так, каждая ячейка FAT на дискете занимает 12 бит (FAT-12), а на винчестере - 16 бит (FAT-16). Это связано с тем, что объем винчестера и дискеты сильно отличается, но об этом ниже. Возьмем трехдюймовую дискету высокой плотности записи, т.е. обычную для сегодняшнего дня дискету. На нее можно записать 1,44 Мб или 1457664 байт. Если поделить это число на 512, то получим 2847. Именно столько на дискете секторов доступно для ваших файлов, а так их аж 2880. С помощью 12 бит можно закодировать (представить) число от 0 до 4095, а с помощью 11 бит - только до 2047. У нас секторов 2847, поэтому 11 битное кодирование нас не устраивает, берем 12 бит на ячейку FAT. Почему не 16? Для экономии места. Просьба постараться это уяснить. Так вот, вернемся к нашим .. э ... баранам. Одна копия FAT занимает 9 секторов (всего 2847*12/8 байт, делим на 512 байт в одном секторе). Две копии, значит занимают 18 секторов. Сразу же, в 19-ом секторе начинается Каталог. Он занимает 14 секторов и может содержать информацию о 224 файлах. Когда-то посчитали, что этого будет достаточно. Так и оказалось. Ну, а после Каталога, начиная с сектора 33 идут уже сами файлы. Напомню, что цифры относятся к дискете, для винчестеров они другие. Теперь я еще раз объясню, как устроена и работает FAT. Числа буду указывать в десятичной системе. Вот кусок таблицы размещения:
002 003 004 005 006 007 008 009 010 011 012 013 014 EOF 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 и т.д. Всего, как я сказал, в таблице 2847 ячеек. Первые 32 сектора, где хранятся FAT и Каталог, в самой FAT не отражены. Зачем тратить на них место, если содержимое этих секторов - копии FAT и Каталог - жестко закреплены на своих местах. Нолик в таблице означает, что данный сектор свободен, а EOF - это признак конца файла. Правила игры ясны? :-) Поехали. Сейчас, на исследуемом нами кусочке секторного пространства записан один файл. Давайте его считаем (или посмотрим, как его считывала бы ДОС). Чтение файла Имя файла, допустим, нам известно (иначе, чего суетиться?). Идем в Каталог, просматриваем записи обо всех файлах, пока не найдем нужный. Смотрим (там же, в Каталоге) номер сектора, с которого начинается этот файл (это будет сектор 33, если файл расположен сначала дискеты, но в Каталоге мы увидим цифру 1, т.к. первые 32 сектора под файлы не распределяются; получается, нуль системы отсчета как бы смещен на 32 вправо). Читаем сектор. Затем смотрим в таблице размещения ячейку с номером 1. Там написано, какой сектор читать дальше. Видите, там написано "002". Читаем второй (физически 34-й) сектор. Снова идем в FAT, смотрим ячейку 2. Там написано "003", читаем третий сектор и т.д. до 14-ого. Когда мы посмотрим 14-ую ячейку FAT, увидим "EOF". Все. Прекращаем чтение, файл считан. Домашнее задание 4: Посчитайте, сколько по максимуму мог бы занимать считанный нами файл. Запись файла Давайте запишем какой-нибудь файл. Приготовились. Начали. Посмотрели в FAT, нашли там первый свободный сектор, тот, где написан "0". В нашем примере, это сектор 15 от начала области, отведенной под файлы. Пусть записываемый файл имеет размер 6 Килобайт. Он должен занять 12 секторов (6*1024/512=12). Пишем 512 байт в сектор 15, смотрим FAT снова, следующий свободный сектор 16. Пишем в 15-ой ячейке (да, а кто же это сделает а нас?) число "16", записываем порцию файла в сектор 16 и т.д. и т.п. В конце, после записи в сектор 26, в соответствующей ему ячейке таблицы размещения файлов напишем EOF. Все, конец файла. FAT после этого будет выглядеть так:
002 003 004 005 006 007 008 009 010 011 012 013 014 EOF 016 017 018 019 020 021 022 023 024 025 026 EOF 0 0 0 0 Допустим, после какого-нибудь редактирования, первый файл стал длиннее на 3 сектора. Надо его записать. Первые 14 секторов пишутся на старое место (сектора 1 - 14). Сектор 15 тоже пишется на старое место, а потом, как в предыдущем примере, смотрим FAT, какой у нас там сектор свободен? Ага, 27-ой. В 15-ой ячейке FAT пишем "27", записываем 27-ой сектор. Ну а дальше, вы знаете.
FAT после этого будет выглядеть так:
002 003 004 005 006 007 008 009 010 011 012 013 014 027 016 017 018 019 020 021 022 023 024 025 026 EOF 028 029 EOF 0 Надеюсь, это понятно? Кстати, вот, и фрагментация в действии :). Задавайте вопросы. Да, да, слушаю... "Там, вот, когда про Каталог говорили, ты сказал, что в Каталоге мы записываем имя файла, длину и другие параметры. Как там, насчет других параметров? Проснулись :-) Ну, ладно, все равно, я хотел сказать пару слов про это. Наберите команду dir /v/p и вы увидите, что хранится в Каталоге. Это имя файла, длина (размер) файла, дата и время создания или последнего изменения и атрибуты файла. Windows 95, также хранит дату последнего открытия файла и длинное имя (довольно хитрая система используется для этого, кстати). Все и так понятно, кроме длинного имени и атрибутов. Мы с вами интересуемся ДОС, поэтому длинные имена, как говорится, свободы и могут идти ... А, вот понятие атрибута, мы рассмотрим. Есть четыре основных атрибута, которые может иметь файл. Можно представить атрибуты как бирки, навешиваемые на файл. В реальности же это просто число.
Это:
ARCHIVE A архивный Если файл имеет этот атрибут,
значит, его не архивировали.
READONLY R только чтение Файл, имеющий этот атрибут
нельзя изменить или удалить.
HIDDEN H скрытый Скрытый файл не виден
пользователю.
SYSTEM S системный Файл является частью системы.
Пояснения: 1)Архивный атрибут или атрибут архивирования используется архиваторами и программами резервного копирования. При архивировании/резервном копировании этот атрибут с файла снимается. Это говорит о том, что файл уже заархивирован и еще раз делать это не надо. Если файл изменяется, на него опять "вешается бирка с буквой "А". 2)Файл, имеющий атрибут READONLY нельзя изменить или удалить. Ваш опыт пользователя может противоречить этому утверждению. Но здесь, он вас обманывает. На CD диске все файлы имеют атрибут read-only. Ну-ка, удалите, какой-нибудь, посмешите меня :-). А, то что вы можете удалить такой файл из Нортона или другой оболочки (хоть, из Windows Explorer) после того, как ответите "Да" на вопрос "Действительно ли вы хотите сделать ЭТО?", объясняется очень легко. После получения от вас положительного ответа Оболочка просто снимает атрибут read-only с файла (в ДОС есть соответствующая команда для этого), а уже потом удаляет файл. 3)Скрытый файл не виден пользователю. Опять же, вы скажете, что Нортон может показывать и скрытые файлы. Но, извините, Нортон Коммандер, это не пользователь. Он общается с ДОС с помощью программного интерфейса, а не пользовательского. Вот, он и смотрит, где есть скрытые файлы, а потом показывает их вам. А команды ДОС типа dir, copy и др. скрытых файлов не видят. 4)Системный атрибут изначально имеют только два файла, содержащие модуль расширения BIOS и базовый модуль ДОС (помните прошлые наши беседы?). В MS DOS это файлы io.sys и msdos.sys. В других версиях имена этих файлов могут быть другими. Системный атрибут запрещает доступ к файлу со стороны программ и пользователя. Часто он используется вместе с атрибутами R и H. Команда: ATTRIB [+R | -R] [+A | -A] [+S | -S] [+H | -H][[диск:][путь]имя_файла] [/S] Отображает и изменяет атрибуты файлов.
+ Установка атрибута. - Снятие атрибута. R Атрибут "Только чтение". A Атрибут "Архивный". S Атрибут "Системный". H Атрибут "Скрытый". /S Обработка файлов во всех подкаталогах указанного пути. Квадратные скобки означают необязательность, заключенного в них параметра. Символ "конвейера" ("|"), означает альтернативу, т.е. должен присутствовать либо параметр, стоящий слева от "конвейера", либо тот, что справа. Если вы не укажете имя файла, то команда отобразит атрибуты файлов из текущего каталога. Домашнее задание 5: Разберитесь самостоятельно с командой ATTRIB. Еще вопросы? "А, вот, мы все говорим, Каталог, Каталог. А о каком каталоге идет речь? У меня на диске целая туча каталогов." Да, и диска C: у вас два, как в том анекдоте. Хоть, он и старый, все равно расскажу:
Парень, недавно купивший компьютер, звонит в службу
поддержки фирмы-продавца:
- У меня компьютер не работает!
- А что Вы делали на нем перед тем, как он сломался?
- Я сидел в Нортоне, смотрю, у два диска C:, справа
и слева. Думаю, зачем мне два, взял один и удалил.
Можете смеяться, но я на 99% уверен, что герой анекдота имеет реального прототипа. Отвлеклись мы. Так, хороший вопрос, садитесь :-)). Вообще-то, в ДОС мы имеем всего один каталог. Правда режет уши, а? Можете называть его Каталогом или корневым каталогом, даже просто корнем. "А как же подкаталоги?" А-а. "Каталог" и "подкаталог". Тут даже не надо обладать идеальным слухом, чтобы услышать разницу. Подкаталогов много, да. А каталог - один. В народе, конечно, и то и другое называть могут одинаково. Я не против этого, но мы-то с вами можем называть все своими именами, по крайней мере, когда, вот так вот, мило беседуем. А что же тогда подкаталоги, что они, где они? Друзья, внимание! Подкаталоги - это обычные файлы. Просто они содержат в себе информацию о других файлах. Как просто, да? Так как подкаталоги обычные файлы, то они не ограничены в длине и могут содержать информацию о каком угодно числе файлов. Ограничением здесь является только свободное место на диске.
Да, раз подкаталоги это файлы, то они, значит, тоже занимают место на
диске. Например, на моем диске C: подкаталоги, подминают под себя
0,35% от объема диска. Кажется, что мало. Это действительно так. Но
давайте посчитаем. Вот пяти гигабайтный диск. Сколько это будет
0,35%? А как система тогда отличает подкаталог от, например, текстового файла? Я вам сказал, что есть 4 основных атрибута. Так, вот, есть еще не основные :-)
DIRECTORY D файл с установленным атрибутом D считается
подкаталогом
VOLUME V метка диска (да, метка диска это тоже файл).
В другой раз я расскажу, как изменится процесс считывания файла, если он будет не в корневой каталоге, а также отвечу на возникшие вопросы, если такие будут :-). А сейчас мы займемся арифметикой и посмотрим, чем принципиально отличается размещение файлов на дискете и на винчестере. Заодно, познакомимся с понятием "кластера". Чем "винт" отличается от "флоппика"? Давайте мыслить как программисты, внешний вид нас не интересует.
Правильно, объемом хранимой информации. Возьмем, вот, 100-мегабайтный
диск (берем маленький, для простоты :). Он может иметь, например,
205569 секторов. FAT у нас 16-и битная. Ну-ка, сколько секторов мы
можем занумеровать, используя 16 бит? Для решения этой проблемы был разработан кластер. Точного определения я не знаю, спросите у физиков. А по сути, это объединение каких-то объектов. Слыхали про кластерные компьютерные системы? Это когда несколько компьютеров специальным образом соединяются и работают как одно целое, как один "большой" компьютер.
А у нас ... ДОС работает не с секторами, а с кластерами (хотя и с секторами тоже может). Но вы зря начинаете на меня злиться, за то, что я про кластеры раньше не сказал. Мы работали с дискетой, а там кластер равен одному сектору. Так что, все в порядке. А, вот, на винчестере... У нас 205569 секторов, в FAT хранить можем информацию только о 65536. А что если одно разделить на другое? (Чисто инженерный подход :-) 205569 / 65536 = 3.137, округляем до четырех. Так, а пускай кластер будет равен четырем секторам! 1 кластер = 4 сектора = 2048 байт Все становится на свои места. Теперь у нас не 2055569 секторов, а 51393 кластера. Правда теперь даже самый маленький файл займет 2 килобайта (это размер нашего кластера). Вернемся к началу выпуска, мы говорили о программе, которая занимает 29 байт. 10 таких программ займут 290 байт в памяти и 20 кило(!)байт на диске. Если размер вашего диска близок к 1Гб, то размер кластера будет 16 кб или больше. Это трагедия системы FAT-16. Когда ее придумали, даже не подозревали, что диски станут большие и дешевые. Поэтому сейчас есть много файловых систем, лишенных подобного недостатка (неэкономного расходования дискового пространства). В Microsoft разработали систему FAT-32 (теперь вы знаете, что значит здесь цифра 32). Использование этой системы позволяет снизить размер кластера (в секторах) и, тем самым, повысить эффективность использования дискового пространства. А вот, быстродействие от этого не повышается. Хотя многие "геймеры" устанавливают FAT-32 именно из-за этого. FAT-32 это временная полумера Microsoft, она используется лишь из любви к совместимости. Операционки Windows NT, OS/2, Linux и др. используют другие, более эффективные файловые системы. Хотя, диски с FAT они, безусловно поддерживают. Но нас это не касается, это я вам для общего развития рассказал. Мы будем (дру)жить с FAT-12 и FAT-16. По крайней мере, в рамках нашего курса по ДОС. На сегодня, пожалуй, хватит, но тема файловой системы не закрыта, мы ее еще будем подробно изучать (Ох, не знаю, в рамках ли этой рассылки?). Я жду от вас вопросов, в следующий раз постараюсь на них ответить. Email вы мой знаете, так что пишите.
Внимание! Внимание! У нас в гостях рассылка "СообЧа(СООБщество ЧАйников). Обмен опытом, вопросы, ответы". "Пользователям и программистам - начинающим, опытным, маститым профессионалам и непрофессионалам. Всем, кого не коробит слово "ЧАЙНИК". Не тот программист, кто диплом имеет, а тот, у кого голова в мониторе, локти сшибают кофе на пол, а уши совершенно не слышат ни давно охрипший свисток чайника, ни призывное воркование жены. Цель этой рассылки: объединение увлеченных людей, которые сами себе создают проблемы и потом в отчаянии рвут последние волосы с лысеющей головы. Или не с лысеющей... И не последние... И не рвут, а пляшут, потому что проблема, над которой бился полмесяца (надо же! Вроде всего пара дней.) теперь, наконец, решена. А в сущности, возможно, проблема уже давно кем-нибудь решена, и причитающиеся ей волосы давно выдраны. Пишите сюда, просите помощи и получайте готовое решение! Но не забывайте, что за все надо платить. Ваша плата - доброжелательность, отзывчивость и готовность помочь. Решайте проблемы СообЧа! И если Вы подписались на эту рассылку - Вы уже член нашего СООБщества ЧАйников, более ничего не требуется. (А вот к "суперпрограммистам", презрительно надувающим щеки при слове "ЧАЙНИК", огромная просьба не беспокоиться с подпиской.) Автор рассылки - тоже "ЧАЙНИК". А потому прочь стеснительность и другие комплексы, задавайте друг другу пусть самые, казалось бы, идиотские вопросы, получайте на них ответы и решения. Знакомьтесь, обменивайтесь опытом, текстами программ... В планах - создание совместного сайта." На сегодняшний день рассылка имеет около 4000 подписчиков. Много это или мало, я не берусь судить. Очень многие откликаются и теперь принимают участие в этом некоммерческом проекте. Создан сайт, создаются его зеркала, создаются рассылки-приложения по разным темам, от языков программирования до общепользовательских программ, создана и действует, расширяясь, электронная почтовая группа, где каждый подписчик наиболее оперативно может разрешить свои проблемы... Честно говоря, я сам не ожидал всего этого. Затеяв, казалось бы, безрассудное дело, я не успеваю хлопать глазами, как это все разворачивается. И теперь мне остается лишь всеми силами стараться не загубить это все, и я стараюсь, как могу.
Юрий Болотов,
К сожалению, я не успел рассказать сегодня, все что хотел. В частности, мы не поговорили о HTML. Еще у меня есть несколько идей насчет дальнейшей работы, которые я вам не изложил, например, это идея создания коллективного сайта. Ну, ничего, все еще у нас впереди. Я даже не ожидал, что рассказ о файловой системе займет столько места и времени. Надеюсь, вы хоть чего-нибудь поняли и запомнили. Даже запоминать не обязательно. Если вы будете себе правильно представлять, что есть файловая система ДОС (хотя бы на том уровне, на каком я рассказывал), то я буду считать, что цель этой публикации достигнута. Если у вас остались вопросы, то, конечно, пишите, будем разбираться вместе. Прощаюсь ненадолго, всего лишь ДО Следующего выпуска.
Пока.
|
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
| В избранное | ||
