Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Монтаж пожарного шкафа шпк. | ствол пожарный переносной лафетный, с30у

Тип файлу

Легко зрозуміти, що структуровані файли надають системі і програмістові інформацію про структуру даних, що зберігаються, але не дають жодних відомостей про форму вистави і сенс цих даних.
Наприклад, з точки зору системи вихідний текст програми на мові З
і документ у форматі LATEX абсолютно ідентичні: і те, і інше є текстовим файлом (або, якщо завгодно, файл із записами змінної довжини). Проте, якщо ми спробуємо подати наш документ на вхід С-компілятора, ми отримаємо безліч синтаксичних помилок і жодного Корисного результату.
Цей приклад показує, що у багатьох випадках бажано пов'язати з файлом — неважливо, чи структурований це файл або байтовий потік — якусь метаінформацію: у якому форматі зберігаються дані, які операції над ними допустимі, а інколи і відомості про той, КТО і навіщо ці дані потрібні.
Мабуть, найбільш спільним вирішенням цієї проблеми був би об'єктно-орієнтований підхід, в якому файл даних розглядається як об'єкт, а допустимі операції — як методи цього об'єкту. Ні у одній з відомих авторові ОС ця ідея повною мірою не реалізована, але призначені для користувача інтерфейси багатьох сучасних ОС надають можливість асоціювати певні дії з файлами різних типів.
Так, наприклад Explorer — призначена для користувача оболонка Windows 95 і Windows NT 4.0 — дозволяє пов'язати ту або іншу програму з файлами, що мають певне розширення, наприклад, програму MS Word з файлами що мають розширення DOC. Коли користувач натискує ліву кнопку миші на значку, що представляє такий файл, то автоматично запускається MS Word. Ці ж асоціації доступні і з командного рядка — можна надрукувати start Доповідь. DOC, і знову-таки запуститься MS Word.
Таке скріплення дуже просто в реалізації і зроблено не лише в Explorer, але і в простих текстових оболонках начеб Norton Commander. Від ОС при цьому потрібно лише дати можливість якимсь чином розрізняти типів файлів.
Перші спроби асоціювати з файлом ознаку типа були зроблені ще в 60-і роки. При цьому ідентифікатор типа додавався до імені файлу у вигляді короткої, але мнемонічної послідовності символів — розширення (extension). У більшості сучасних ОС розширення відділяється від імені символом ".", але прослідити витоки цієї традиції авторові не удалося. При цьому, наприклад, файли на мові З матимуть розширення "с", на
C++ — "С", а документи у форматі LATEX — "tex".
У ОС сімейства Unix ім'я файлу може містити декілька символів ".", і, таким чином, файл може мати декілька розширень, що каскадують. Наприклад, файл "main.С" — це програма на мові C++; "main.C.gz" — це програма на мові C++, упакована архіватором GNU Zip з метою заощадити місце; "main.C.gz.crypt" — це програма, яку упакували і потім зашифрували, щоб ніхто сторонній не зміг її прочитати; нарешті, "main.C.gz.crypt.uue" — це упакована і зашифрована програма, перетворена в послідовність друкованих символів коди ASCII, наприклад, для пересилки по електронній пошті.
В принципі, розширення є цілком прийнятними і у багатьох відношеннях навіть дуже зручним способом ідентифікації типа файлу. Одна із зручностей полягає в тому, що для використання цього методу не потрібно жодних або майже жодних зусиль з боку ОС: просто програми домовляються інтерпретувати ім'я файлу певним чином.

Приклад 11.1. Командний рядок компілятора

її main.С с-code.c asm-code.s obj-code.o\ libraryl.a Iibrary2.so -o program

Наприклад, стандартний драйвер компілятора в системах сімейства Unix — програма з — визначає тип файлу саме по розширенню. Командний рядок, приведений в прикладі 11.1, інтерпретуватиметься таким чином.

  • main.С — текст на мові C++. Його потрібно обробити препроцесором і відкомпілювати компілятором C++, а потім передати те, що вийде, редакторові зв'язків. Більшість компіляторів в Unix генерують код на асемблері, тобто виведення компілятора ще потрібно пропустити через асемблер.
  • с-code.c — текст на мові С. Он обробляється так само, як і програма на З ++, лише замість компілятора C++ використовується компілятор С.
  • asm-code.s — програма на мові асемблера. Її потрібно обробити асемблером і отримати об'єктний модуль.
  • obj-code.o — об'єктний модуль, який безпосередньо можна передавати редакторові зв'язків.
  • library1.a — об'єктна бібліотека, яку потрібно використовувати для дозволу зовнішніх заслань нарівні із стандартними бібліотеками.
  • library2.so — бібліотека, що розділяється, яку треба пов'язати із створюваним динамічним модулем.

Багато ОС, розроблені в 70-і роки, такі як Rt-11, Rsx-11, Vax/vms, Cp/m, нав'язують програмістові розділення імені на власне ім'я і розширення, інтерпретуючи крапку в імені файлу як знак перепинання. У таких системах ім'я може містити лише одну крапку і відповідно мати лише одне розширення. Навпаки, в ОС нового покоління — Os/2, Windows NT і навіть в Windows 95 — реалізована підтримка імен файлів вільного формату, які можуть мати декілька розширень, що каскадують, як і в Unix.
Проте жодні засоби операційної системи не можуть нав'язати прикладним програмам правил вибору розширення для файлів даних. Це приводить до неприємних колізій. Наприклад, майже всі текстові процесори від Лексикону до Word 2000 включно використовують розширення Файлу .doc (скорочення від document), хоча формати файлів в різних процесорів і навіть в різних версій одного процесора сильно розрізняються.
Інша проблема пов'язана з виконуваними завантажувальними модулями. Зазвичай система використовує певне розширення для виконуваних файлів.
Так, VMS і системи сімейства Ср/м використовують розширення .ехе: скорочення від executable (виконуваний). Проте у міру розвитку системи формат завантажувального модуля може змінюватися. Так, наприклад, Os/2 v3.0 підтримує принаймні шість різних форматів завантажувальних модулів.

  • 16-розрядні сегментовані завантажувальні модулі: формат Os/2 х
  • 32-розрядні завантажувальні модулі, що використовують "плоску" (flat) модец, пам'яті: формат Os/2 2.x (LE — Linear Executable).
  • 32-розрядні модулі нового формату, що використовують упаковку коди даних: формат Os/2 3.x (LX — Linear executable extended).
  • ехе- і corn-модули DOS.
  • Завантажувальні модулі Win 16 (NE).
  • Завантажувальні модулі Win32s (РЕ — Portable Executable).

Для виконання останніх трьох типів програм Os/2 створює віртуальну машину, що працює в режимі сумісності з 8086. Це завдання запускає копію ядра DOS і, якщо це необхідно, копію MS Windows, які вже виконують завантаження програми. Завантажувальні модулі всіх трьох "рідних" форматів завантажуються системою безпосередньо. Так або інакше, завантажувач повинен уміти правильно розпізнавати всі формати. При цьому він не може використовувати розширення файлу: файли всіх перерахованих форматів мають однакове розширення ЕХЕ.
Схожа ситуація має місце в системах сімейства Unix, де бінарні завантажувальні модулі і командні файли взагалі не мають розширення. При цьому більшість сучасних версій системи також підтримують декілька різних форматів завантажувального модуля, що історично склалися.
Розробники Unix зіткнулися з цією проблемою ще в 70-і роки. Як рішення вони запропонували використовувати магічні числа (magic number) або сигнатури (signature — підпис) — угода про те, що файли певного формату містять на початку певний байт або послідовність байтів. Первинно це були чисельні коди; файл /etc/magic містив коди, відповідні відомим типам файлів. Пізніше як магічні числа почали використовуватися довгі текстові рядки. Так, наприклад, зображення у форматі Compuserve GIF 87а повинні починатися з символів Gif87a.
Легко зрозуміти, що магічні числа анітрохи не краще розширенні, а у багатьох відношеннях навіть гірше. Наприклад, користувач, проглянувши вміст каталога, не може відразу взнати типів файлів, що містяться в нім. Ще гірше ситуація, коли розширення файлу не відповідає його реальному типові. Це вводитиме в оману не лише користувача, але і деякі програми, що вважаються при визначенні формату на розширення замість магічного числа.
З довгими мнемонічними текстовими рядками пов'язана ще одна забавна проблема, яка може мати неприємні наслідки. Наприклад-текстовий файл наступного вмісту:
Gif87a — це дуже поганий формат зберігання зображень. Він буде сприйнятий деякими програмами як зображення у форматі Compuserve (GIF 87а, яким він, безумовно, немає.
Оригінальний розвиток ідея магічних чисел отримала в сучасних системах сімейства Unix, де сигнатура вигляду #!/bin/sh означає, що даний файл є програмою, що інтерпретується, інтерпретатор якої зберігається у файлі /bin/sh (в даному випадку це стандартний командний процесор).
Намагаючись якось вирішити проблему ідентифікації типа файлу, розробники Macintoch відмовилися як від розширень, так і від магічних чисел. У MACOS кожен файл складається з двох частин або гілок (forks): гілки даних (data fork) і гілки ресурсів (resource fork). Окрім ідентифікатора типа файлу, гілка ресурсів зберігає інформацію про:

  • значку, пов'язаному з цим файлом;
  • розташуванні значка у відкритій теці (folder);
  • програмі, яку потрібно запустити при відкритті" цього файлу.

Ще далі в цьому ж напрямі пішли розробники системи Os/2. У цій системі з кожним файлом пов'язаний набір розширених атрибутів (extended attributes). Атрибути мають вигляд "Імя:значеніє". При цьому значення може бути як текстовим рядком, так і блоком двійкових даних довільного формату і розміру. Деякі розширені атрибути використовуються оболонкою Workplace Shell (WPS) як еквівалент гілки ресурсів в MACOS: для ідентифікації типа файлу, пов'язаного з ним значка і розміщення цього значка у відкритому вікні. Тип файлу ідентифікується текстовим рядком. Наприклад, програма на мові З ідентифікується рядком З code. Це різко зменшує вірогідність конфлікту імен типів — ситуацію, що досить часто виникає при використанні розширень або магічних чисел.
Інші атрибути можуть застосовуватися для інших цілей. Наприклад, LAN Server — файловий сервер фірми IBM — використовує розширені атрибути для зберігання інформації про власника файлу і права доступу до нього. Деякі текстові редактори застосовують розширені атрибути для зберігання положення курсора при завершенні останньої сесії редагування, так що користувач завжди потрапляє в те місце, де він зупинився минулого разу.
Крім того, розширені атрибути можуть використовуватися і для зберігання відомостей про призначення файлу. У Os/2 існують зумовлені розширені атрибути з іменами subject (тема), comment (коментарі) і Кеу phrases (ключові фрази)які можуть, наприклад, використовуватися для пошуку документів, що відносяться до заданої теми. На жаль, такий пошук можливий, лише якщо творець документа поклопотався про прісвоє нді цим атрибутам правильних значень.

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017