Чи потрібне виконуваному файлу ядро ​​ОС?

Я знаю, що коли компілюється вихідний код, скажімо, C ++, вихід із компілятора - це машинний код (виконуваний файл), який, на мою думку, був інструкцією безпосередньо до процесора. Нещодавно я читав на ядрах і виявив, що програми не можуть отримати доступ до апаратного забезпечення безпосередньо, але повинні пройти через ядро.

Отже, коли ми компілюємо простий вихідний код, скажімо, лише за допомогою printf()функції, і компіляція створює виконуваний машинний код, чи буде кожна інструкція в цьому машинному коді безпосередньо виконуватися з пам'яті (як тільки код завантажується в пам'ять ОС) або буде кожну команду в машинному коді все-таки потрібно пройти через ОС (ядро) для виконання?

Я прочитав подібне запитання . Він не пояснив, чи машинний код, який генерується після компіляції, - це інструкція безпосередньо до центрального процесора, чи потрібно буде знову пройти через ядро, щоб створити правильну інструкцію для ЦП. Тобто, що відбувається після завантаження машинного коду в пам'ять? Чи пройде воно через ядро ​​чи безпосередньо поговорить з процесором?

Як хтось, хто написав програми, які виконуються без ОС, я пропоную остаточну відповідь.

Чи потрібне виконуваному файлу ядро ​​ОС?

Це залежить від того, як ця програма була написана та побудована.
Ви можете написати програму (за умови, що у вас є знання), яка взагалі не потребує ОС.
Така програма описується як окрема .
Завантажувачі та діагностичні програми - типове використання для автономних програм.

Однак типова програма, написана та побудована в якомусь середовищі хост-ОС, буде за замовчуванням виконуватись у тому ж середовищі ОС-хоста.
Для написання та створення окремої програми необхідні дуже чіткі рішення та дії.

... висновок від компілятора - це машинний код (виконуваний файл), який, на мою думку, був інструкцією безпосередньо до процесора.

Правильно.

Нещодавно я читав на ядрах і виявив, що програми не можуть отримати доступ до апаратного забезпечення безпосередньо, але повинні пройти через ядро.

Це обмеження, накладене режимом процесора, яке ОС використовує для виконання програм і сприяє певним інструментам збирання, таким як компілятори та бібліотеки.
Це не суттєве обмеження для кожної програми, коли-небудь написаної.

Отже, коли ми компілюємо простий вихідний код, скажімо, лише за допомогою функції printf (), і компіляція створює виконуваний машинний код, чи буде кожна інструкція цього машинного коду виконуватися безпосередньо з пам'яті (як тільки код завантажується в пам'ять ОС ) чи кожній команді в машинному коді все ж потрібно буде пройти ОС (ядро) для виконання?

Кожна інструкція виконується процесором.
Інструкція, яка не підтримується або є незаконною (наприклад, у процесу недостатньо привілеїв), викличе негайний виняток, і CPU замість цього виконає процедуру поводження з цим незвичним умовою.

Функція printf () не повинна використовуватися як приклад "простого вихідного коду" .
Переклад з об'єктно-орієнтованої мови програмування високого рівня в машинний код може бути не таким тривіальним, як ви маєте на увазі.
І тоді ви вибираєте одну з найскладніших функцій з бібліотеки часу виконання, яка виконує перетворення даних та введення-виведення.

Зауважте, що ваше запитання визначає середовище з ОС (і бібліотекою виконання).
Після завантаження системи та управління ОС над комп'ютером встановлюються обмеження щодо того, що програма може робити (наприклад, введення / виведення повинне виконуватись ОС).
Якщо ви розраховуєте виконати окрему програму (тобто без ОС), тоді ви не повинні завантажувати комп'ютер для запуску ОС.

... що відбувається після завантаження машинного коду в пам'ять?

Це залежить від навколишнього середовища.

Для окремої програми вона може бути виконана, тобто управління передається, перейшовши на початкову адресу програми.

Для програми, завантаженої ОС, програма повинна бути динамічно пов'язана із спільними бібліотеками, від яких вона залежить. ОС повинна створити простір виконання для процесу, який буде виконувати програму.

Чи пройде воно через ядро ​​чи безпосередньо поговорить з процесором?

Машинний код виконується процесором.
Вони не "проходять через ядро" , але також не "розмовляють з процесором" .
Машинний код (що складається з оп-коду та операндів) - це інструкція до центрального процесора, яка розшифровується та виконується операція.

Можливо, наступна тема, яку ви повинні вивчити, - це режими процесора .

Ядро - це "просто" більше коду. Просто цей код є шаром, який знаходиться між найнижчими частинами вашої системи та фактичним обладнанням.

Все це працює безпосередньо на процесорі, ви просто переходите через його шари, щоб зробити що-небудь.

Вашій програмі "потрібне" ядро ​​так само, як і стандартним бібліотекам C, щоб використовувати printfкоманду в першу чергу.

Фактичний код вашої програми працює на процесорі, але гілки, коди яких змушують надрукувати щось на екрані, проходять код для функції C printf, через різні інші системи та інтерпретатори, кожен з яких робить власну обробку, щоб зрозуміти, як саме hello world! насправді друкується на екрані.

Скажімо, у вас є програма терміналу, що працює на диспетчері вікон робочого столу, працює на вашому ядрі, що в свою чергу працює на вашому обладнанні.

Існує набагато більше, але продовжуємо просто ...

1. У своїй термінальній програмі ви запускаєте програму для друку hello world!
2. Термінал бачить, що програма записала (через вихідні процедури C) hello world!на консоль
3. Програма терміналу піднімається до менеджера вікон на робочому столі, кажучи: "Мені hello world!написали, чи можете ви поставити його x, yбудь ласка?"
4. Менеджер вікон на робочому столі підходить до ядра з "однією з моїх програм хоче, щоб ваш графічний пристрій помістив текст у цю позицію, дістайтеся до нього чувак!"
5. Ядро передає запит драйверу графічного пристрою, який форматує його таким чином, що графічна карта може зрозуміти
6. Залежно від того, як підключена відеокарта, потрібно викликати інші драйвери пристроїв ядра, щоб виштовхувати дані на шинах фізичних пристроїв, таких як PCIe, обробляти такі речі, як переконайтесь, що вибрано правильний пристрій, і щоб дані могли проходити через відповідний міст або перетворювачі
7. Обладнання відображає речі.

_{Це масштабне спрощення лише для опису. Тут будуть дракони.}

Ефективно все, що ви робите, потребує апаратного доступу, будь то дисплей, блоки пам’яті, біти файлів чи щось подібне, має пройти через якийсь драйвер пристрою в ядрі, щоб зрозуміти, як саме спілкуватися з відповідним пристроєм. Будь це драйвер файлової системи поверх драйвера контролера жорсткого диска SATA, який сам сидить над мостовим пристроєм PCIe.

Ядро знає, як зв'язати всі ці пристрої разом, і представляє порівняно простий інтерфейс для програм, щоб робити речі, не знаючи про те, як все це робити самостійно.

Менеджери вікон на робочому столі надають шар, який означає, що програми не повинні знати, як малювати вікна та добре грати з іншими програмами, які намагаються відображати речі одночасно.

Нарешті, програма терміналу означає, що вашій програмі не потрібно знати, як намалювати вікно, ні як поговорити з драйвером графічної картки ядра, ні всю складність роботи з буферами екрана та тимчасовим відображенням, а також фактично перемикання рядки даних до дисплея.

Все це обробляється шарами на шарах коду.

Це залежить від навколишнього середовища. У багатьох старих (і простіших!) Комп’ютерах, таких як IBM 1401, відповідь буде "ні". Ваш компілятор і лінкер випустили окремий "двійковий", який працював без жодної операційної системи. Коли ваша програма перестала працювати, ви завантажили інший, який також працював без ОС.

Операційна система потрібна в сучасних умовах, оскільки ви не запускаєте лише одну програму за один раз. Спільний доступ до ядер CPU, оперативної пам’яті, пристрою масового зберігання даних, клавіатурі, миші та дисплею між кількома програмами одночасно потребує координації. ОС забезпечує це. Тому в сучасних умовах ваша програма не може просто читати і записувати диск або SSD, вона повинна попросити ОС зробити це від свого імені. ОС отримує такі запити від усіх програм, які хочуть отримати доступ до пристрою зберігання даних, програм, таких як елементи управління доступом (не можуть дозволити звичайним користувачам записувати у файли ОС), чергати їх на пристрій і сортувати повернуту інформацію до правильних програм (процесів).

Крім того, сучасні комп’ютери (на відміну, скажімо, від 1401) підтримують підключення дуже широкого спектру пристроїв вводу / виводу, а не лише тих, які IBM продавав би вам у старі часи. Ваш компілятор і лінкер, можливо, не можуть знати про всі можливості. Наприклад, ваша клавіатура може бути пов'язана через PS / 2 або USB. ОС дозволяє встановлювати специфічні для пристрою "драйвери пристроїв", які вміють спілкуватися з цими пристроями, але представляють загальний інтерфейс для класу пристроїв для ОС. Таким чином, вашій програмі, і навіть ОС, не потрібно робити нічого іншого для отримання натискань клавіш з USB на клавіатурі PS / 2 або для доступу, скажімо, локального диска SATA проти USB-накопичувача та накопичувача, який десь вимкнений на NAS або SAN. Ці деталі обробляються драйверами пристроїв для різних контролерів пристроїв.

Для пристроїв масового зберігання ОС надає всі ті драйвери файлової системи, які представляють один і той же інтерфейс для каталогів і файлів незалежно від того, де і як реалізовано сховище. І знову: ОС турбується щодо контролю доступу та серіалізації. Взагалі, наприклад, один і той же файл не повинен відкриватися для запису більш ніж однією програмою одночасно, не перестрибуючи деякі обручі (але одночасне читання, як правило, нормально).

Так що в сучасних умовах загального призначення так - вам дійсно потрібна ОС. Але навіть сьогодні є такі комп’ютери, як контролери в режимі реального часу, які не є досить складними, щоб мати потребу в цьому.

Наприклад, в середовищі Arduino насправді ОС не існує. Звичайно, існує купа бібліотечного коду, який середовище збирання включає в себе кожен "бінарний", який він створює. Але оскільки немає коду від однієї програми до іншої, це не ОС.

Я думаю, що багато відповідей неправильно розуміють питання, яке зводиться до цього:

Компілятор виводить машинний код. Цей машинний код виконується безпосередньо процесором, чи його "інтерпретує" ядро?

В основному, процесор безпосередньо виконує машинний код . Було б значно повільніше, щоб ядро ​​виконувало всі програми. Однак є кілька застережень.

1. Коли ОС присутня, прикладні програми, як правило, не мають можливості виконувати певні інструкції або отримувати доступ до певних ресурсів. Наприклад, якщо програма виконує інструкцію, яка модифікує таблицю переривань системи, CPU замість цього перейде до обробника винятків ОС, так що програма, що порушує порушення, буде припинена. Крім того, додатки зазвичай не можуть читати / записувати в пам'ять пристрою. (Тобто «спілкування з обладнанням».) Доступ до цих спеціальних областей пам’яті - це те, як ОС спілкується з такими пристроями, як відеокарта, мережевий інтерфейс, системний годинник тощо.

2. Обмеження, розміщені ОС на додатки, досягаються спеціальними функціями процесора, такими як режими привілеїв, захист пам’яті та переривання. Хоча будь-який процесор, який ви знайдете у смартфоні чи ПК, має ці функції, певні процесори цього не роблять. Цим процесорам дійсно потрібні спеціальні ядра, які "інтерпретують" код програми для досягнення бажаних функцій. Дуже цікавий приклад - Gigatron , який є 8-інструкційним комп'ютером, який ви можете створити з мікросхем, який імітує 34-інструкційний комп'ютер.

3. Деякі мови, як Java, "компілюються" на щось, що називається Bytecode, що насправді не є машинним кодом. Хоча в минулому їх інтерпретували для запуску програм, в наші дні зазвичай використовується те, що називається компіляція Just-in-Time, тому вони в кінцевому підсумку працюють безпосередньо на процесорі як машинний код.

4. Запуск програмного забезпечення у віртуальній машині використовується для того, щоб вимагати "його інтерпретації" машинного коду програмою під назвою Hypervisor . Завдяки величезному попиту в галузі на віртуальні пристрої, виробники процесорів додали такі функції, як VTx, до своїх процесорів, щоб дозволити більшість інструкцій гостьової системи виконуватись безпосередньо процесором. Однак при запуску програмного забезпечення, призначеного для несумісного ЦП у віртуальній машині (наприклад, емулювання NES), машинний код потрібно буде інтерпретувати.

Коли ви компілюєте свій код, ви створюєте так званий "об'єктний" код, який (у більшості випадків) залежить від системних бібліотек ( printfнаприклад), тоді ваш код загортається лінкером, який додасть вид завантажувача програм, який може виконати ваша конкретна операційна система розпізнайте (саме тому ви не можете запустити програму, скомпільовану для Windows в Linux, наприклад) і знати, як розгортати код і виконувати. Тож ваша програма - як м'ясо всередині бутерброда, і його можна їсти лише як пачку, в цілому.

Нещодавно я читав на ядрах і виявив, що програми не можуть отримати доступ до обладнання безпосередньо, але доведеться пройти через ядро.

Ну це на півдорозі; якщо ваша програма є драйвером режиму ядра, тоді ви фактично можете отримати доступ безпосередньо до обладнання, якщо ви знаєте, як "говорити" з обладнанням, але зазвичай (особливо для незадокументованого або складного обладнання) люди використовують драйвери, які є бібліотеками ядра. Таким чином ви можете знайти функції API, які вміють спілкуватися з обладнанням практично зрозумілим для людини способом без необхідності знати адреси, регістри, терміни та купу інших речей.

чи буде кожна інструкція в цьому машинному коді виконуватися безпосередньо з пам'яті (як тільки код завантажується в пам'ять ОС) або кожна команда в машинному коді все ще повинна пройти через ОС (ядро) для виконання

Ну, ядро ​​- це офіціантка, відповідальність за яку - підвести вас до столу і подати вам. Єдине, чого він не може зробити - це їсти для вас, ви повинні робити це самостійно. Як і ваш код, ядро ​​розпакує вашу програму в пам'ять і запустить ваш код, який є машинним кодом, виконаним безпосередньо процесором. Ядро потрібно просто контролювати вас - що вам дозволено, а що вам заборонено.

це не пояснює, чи машинний код, що генерується після компіляції, - це інструкція безпосередньо до центрального процесора чи потрібно буде знову пройти ядро, щоб створити правильну інструкцію для процесора?

Машинний код, який генерується після компіляції, - це інструкція безпосередньо до процесора. У цьому немає жодних сумнівів. Єдине, про що потрібно пам’ятати, не весь код у складеному файлі - це фактичний код машини / CPU. Linker обернув вашу програму деякими метаданими, які тільки ядро ​​може інтерпретувати як підказку - що робити з вашою програмою.

Що відбувається після завантаження машинного коду в пам'ять? Чи пройде воно через ядро ​​чи безпосередньо поговорить з процесором.

Якщо ваш код - це просто прості коди, такі як додавання двох регістрів, то він буде виконуватися безпосередньо процесором без допомоги ядра, але якщо ваш код з використанням функцій з бібліотек, то такі виклики будуть допомагати ядром, як, наприклад, офіціантці, якщо ви хочете щоб поїсти в ресторані, вони дадуть вам інструменти - виделку, ложку (і це все ще є їхніми активами), але що ви з цим зробите, - це до вашого "коду".

Ну, просто для запобігання полум'я в коментарях - це дійсно надто спрощена модель, яка, сподіваюся, допоможе ОП зрозуміти базові речі, але хороші пропозиції щодо покращення цієї відповіді вітаються.

Отже, коли ми компілюємо простий вихідний код, скажімо, лише за допомогою функції printf (), і компіляція створює виконуваний машинний код, чи буде кожна інструкція цього машинного коду виконуватися безпосередньо з пам'яті (як тільки код завантажується в пам'ять ОС) чи кожну команду в машинному коді все ж потрібно пройти через ОС (ядро), яку потрібно виконати?

По суті, до ядра йдуть лише системні виклики. Що завгодно з введенням-виведенням або розподілом / розподілом пам'яті, як правило, врешті-решт призводить до системного виклику. Деякі instructiosn можуть бути виконані лише в режимі ядра, і це призведе до запуску ЦП виключення. Винятки викликають перехід у режим ядра та перехід до коду ядра.

Ядро не обробляє кожну інструкцію в програмі. Він просто робить дзвінки та перемикання між запущеними програмами для спільного використання процесора.

Визначення пам'яті в режимі користувача (без ядра) неможливо, якщо ви отримуєте доступ до пам'яті, у вас немає дозволу на доступ, MMU, попередньо запрограмований ядром, помічає і спричиняє виняток "помилки сегментації" на рівні ЦП. , що запускає ядро, і ядро ​​вбиває програму.

Виконувати введення / виведення в користувальницькому режимі (без ядра) неможливо, якщо ви отримуєте доступ до портів вводу / виводу або регістрів для пристроїв або адрес, підключених до пристроїв (один або обидва необхідні для виконання будь-якого вводу / виводу), вони запускають тригер виняток таким же чином.

Чи потрібне виконуваному файлу ядро ​​ОС?

Залежить від типу виконуваного файлу.

Ядра, крім посередництва спільного доступу до оперативної пам’яті та обладнання, виконують також функцію завантажувача.

Багато "виконуваних форматів", таких як ELF або PE, мають додаток до коду метаданих у виконуваний файл, а також завдання завантажувача для його обробки. Прочитайте детальні відомості про формат PE в Microsoft для отримання додаткової інформації.

Ці виконувані файли також посилаються на бібліотеки ( файли .dllоб'єктів з спільним Windows або Linux .so) - їх код повинен бути включений.

Якщо ваш компілятор створює файл, призначений для обробки завантажувачем операційної системи, і цього завантажувача немає, він не працюватиме.

• Чи можете ви включити код, який виконує роботу навантажувача?

Звичайно. Вам потрібно переконати ОС якось запустити ваш необроблений код, не обробляючи жодних метаданих. Якщо ваш код викликає API ядра, він все одно не працюватиме.

• Що робити, якщо воно не викликає API ядра?

Якщо ви якось завантажите цей виконуваний файл з операційної системи (тобто, якщо він дозволяє завантажувати і виконувати необроблений код), він все ще буде в режимі користувача. Якщо ваш код отримує доступ до речей, заборонених в режимі користувача, на відміну від режиму ядра, наприклад, нерозподілена пам'ять або адреси / регістри пристроїв вводу / виводу, він вийде з ладу з порушеннями привілеїв або сегментів (знову ж таки, винятки переходять у режим ядра та обробляються ними там) і все одно не працюватиме.

• Що робити, якщо запустити його з режиму ядра.

Тоді це спрацює.

TL; DR No.

Розвиток Arduino приходить до тями як поточне середовище, де немає ОС. Повірте, у одного з цих дітей у вас немає місця для операційної системи.

Крім того, ігри для Sega Genesis не мали ОС, яку надав Sega для використання. Ви щойно створили свою гру в асемблері 68K, записуючи прямо на голий метал.

Або там, де я ріжу зуби, виконуючи вбудовані роботи над Intel 8051. Знову, коли у вас є лише 2716 eprom із слідом 2k * 8, у вас немає місця для операційної системи.

Звичайно, це передбачає дуже широке використання слова додаток. Як риторичне питання, варто запитати себе, чи ескіз Ардуїно насправді є додатком.

Хоча я не хочу натякати на те, що інші відповіді самі по собі не відповідають правилам, вони надають занадто багато деталей, які, я боюсь, все ще дуже незрозумілі для вас.

Основна відповідь полягає в тому, що код буде виконуватися безпосередньо на процесорі. І ні, машинний код ні з ким не "розмовлятиме", це навпаки. Процесор - це активний компонент, і все, що ви робите на своєму комп’ютері, буде виконано цим процесором (я трохи спрощую тут речі, але зараз це нормально). Процесор прочитає код і виконає його і виплюне результати, машинний код - це лише їжа для процесора.

Ваша плутанина випливає з використання апаратного слова. Хоча поділ не такий чіткий, як раніше, краще, якщо ви думаєте з точки зору периферійних пристроїв, а не просто називати все обладнання. Отже, якщо на вашій машині є операційна система або подібне, ваша програма повинна використовувати свої послуги для доступу до периферійних пристроїв, але сам процесор не є периферійним пристроєм, це основний блок обробки, над яким працює ваша програма безпосередньо.

Ядра, операційні системи та подібні інтервенційні шари, як правило, використовуються лише у великих системах, де очікується запуск декількох програм і необхідність в системі управління тим, як ці програми можуть використовувати периферійні пристрої комп'ютера (досить часто на той же час). У цих випадках запущені програми можуть отримувати доступ до цих периферійних пристроїв лише за допомогою системи, яка вирішить, як їм поділитися, і переконається, що немає конфліктів. Невеликі системи, де немає необхідності в управлінні серед конкуруючих програм, оскільки їх немає, часто взагалі немає базової системи, і єдина програма, яка зазвичай працює на цих системах, більш-менш вільна робити все, що хоче з периферійними пристроями.

BIOS, який працює на вашому комп'ютері при включенні живлення, - це виконуваний код, що зберігається в ПЗУ. Він складається з інструкцій на машині плюс даних. Існує компілятор (або асемблер), який збирає цю BIOS з вихідного коду. Це особливий випадок.

Інші спеціальні випадки включають програму завантаження, яка завантажує ядро ​​і саме ядро. Ці особливі випадки зазвичай кодуються мовою, відмінною від C ++.

У загальному випадку набагато практичніше компілятор виробляти деякі інструкції, які викликають системні послуги, що надаються ядром або підпрограм бібліотеки. Це робить компілятор набагато легшим. Це також робить складений код більш легким.

На іншому кінці спектра - Java. У Java компілятор не переводить вихідний код в машинні інструкції, як цей термін зазвичай розуміють. Натомість вихідний код перекладається на "машинні інструкції" для уявної машини, що називається Java Virtual Machine. Перш ніж програма Java може запуститися, її потрібно поєднувати з програмою виконання Java, яка включає в себе інтерпретатор віртуальної машини Java.

У старі добрі часи ваша програма відповідала за те, щоб зробити все, що потрібно було зробити під час виконання вашої програми, чи ви самі це робили, чи додаючи бібліотечний код, який інші написали до вашої програми. Єдине, що працює за комп’ютером - це код, який слід прочитати у вашій складеній програмі - якщо вам пощастило. Деякі комп'ютери повинні були вводити код через комутатори, перш ніж вони могли зробити більше (оригінальний процес "завантажувального"), або навіть вся ваша програма входила таким чином.

Було швидко встановлено, що було приємно мати код, здатний завантажувати та виконувати програму. Пізніше було встановлено, що комп'ютери були достатньо потужними для підтримки одночасного запуску декількох програм за рахунок перемикання між ними процесора, особливо якщо апаратне забезпечення могло допомогти, але при цьому додаткові складності програм не наступали на пальці один одного (наприклад, , як обробити кілька програм, які намагаються надсилати дані на принтер одночасно?).

Все це призвело до того, що велика кількість допоміжного коду було переміщено з окремих програм та в «операційну систему», із стандартизованим способом виклику довідкового коду з програм користувача.

І саме там ми сьогодні. Ваші програми працюють на повній швидкості, але коли їм потрібно щось, що управляється операційною системою, вони викликають допоміжні процедури, передбачені операційною системою, і цей код не потрібен і не присутній у самих програмах користувачів. Це включало запис на дисплей, збереження файлів, доступ до мережі тощо.

Було написано мікроядер, які забезпечують саме те, що потрібно для виконання даної програми без повноцінної операційної системи. Це має деякі переваги для досвідчених користувачів, віддаючи більшість інших. Ви можете прочитати про це сторінку Вікіпедії - https://en.wikipedia.org/wiki/Microkernel - якщо хочете дізнатися більше.

Я експериментував з Microkernel, здатним запустити віртуальну машину Java, але пізніше виявив, що найкращим місцем для цього є Docker.

У типових настільних операційних систем, ядро саме по собі є виконуваним. (У Windows ntoskrnl.exe; у Linux є vmlinuxі т.д.) Якщо для запуску виконуваного файлу вам потрібне ядро, ці ОС не могли існувати.

Те, для чого вам потрібно ядро, - це робити те, що робить ядро. Дозвольте запускати декілька виконуваних файлів одночасно, судити між ними, абстрагувати апаратне забезпечення тощо. Більшість програм не здатні робити це вміло грамотно, і ви не хотіли б, щоб вони навіть могли. За часів DOS - яку навряд чи можна назвати самою операційною системою - ігри часто використовували ОС як трохи більше, ніж завантажувач, і безпосередньо отримували доступ до обладнання, як і ядро. Але вам часто доводилося знати, які марки та моделі обладнання знаходяться у вашій машині, перш ніж купувати гру. Багато ігор підтримували лише певні сімейства відео- та звукових карт і дуже погано працювали на конкуруючих брендах, якщо вони взагалі працювали. Це '