Сравнение ядер: анализ ядер и ядерных компонентов Windows XP и Vista

ВЫПУСТИВ WINDOWS VISTA, MICROSOFT ПОЛНОСТЬЮ ПЕРЕПИСАЛА ИНТЕРФЕЙС (ПРОХОДЯЩИЙ ПОД КОДОВЫМ ИМЕНЕМ AERO), УДЕЛИВ ЕМУ ГОРАЗДО БОЛЬШЕ ВНИМАЯ ЧЕМ, СОБСТВЕННО, САМОМУ ЯДРУ. ПОЛЬЗОВАТЕЛЯМ ИНТЕРФЕЙС ПРИШЕЛСЯ ЯВНО ПО ВКУСУ, И ОНИ ДАЖЕ СОГЛАСИЛИСЬ «ПРОАПРГРЕЙДИТЬ» СВОИ КОМПЬЮТЕРЫ ДЛЯ УСТАНОВКИ ВИСТЫ, ПРИЧЕМ КОЛИЧЕСТВО «СОГЛАСИВШИХСЯ» ОКАЗАЛОСЬ ТАКОВО, ЧТО ПРОДАЖИ ЖЕЛЕЗА ПО ДАННЫМ КОРПОРАЦИИ DELL ПОДСКОЧИЛИ ДО 178%, И БОЛЬШИНСТВО ДОПОЛНИТЕЛЬНЫХ УСТРОЙСТВ БЫЛО КУПЛЕНО ИМЕННО ДЛЯ ДОМА.

А что насчет бизнеса? Офисный компьютер — это все-таки не роскошь и не произведение искусства, и увлечение «красивостями» ему только вредит (вспомним строгий стиль первых IBM PC, предназначенных для бизнеса и сравним его с «Амигой», значительно превосходившей своего конкурента по возможностям, но именно из-за своего «игрового» имиджа так и не сумевшей пробиться на офисный рынок, подчиненный строгому стилю IBM).

Давайте, отбросив интерфейс, посмотрим, что находится под ним и какие реальные преимущества дает Виста по сравнению с XP и насколько быстро они окупят переход на нее. Ядро — это царство абсолютной объективности. Здесь нет и не может быть места для субъективизма. В отличие от красоты и элегантности, которую каждый склонен оценивать по-своему, технические характеристики ядра однозначно определяют качество системы. А вот конкретную выгоду уже приходится определять индивидуально, исходя из определенных потребностей. Скажем, если перевести автомобиль на гусеничный ход, кто-то обрадуется, а кто-то, наоборот, завопит: «Верните мои колеса!»

Родословная Vista

Корни Vista уходят вглубь многочисленных слоев абстракции и десятилетних наслоений кода, но ведут один вовсе не к XP, как это можно было бы подумать, а к Windows 2003 Server, у которого разработчики Vista позаимствовали ядро, слегка его доработав. Собирая операционную систему для рабочих станций на серверном ядре, Microsoft упрощает себе жизнь (вместо двух разных ядер теперь будет одно), но совершает большую стратегическую ошибку, проигрывая в плане производительности на рабочих станциях, где серверная «оптимизация» превращается в «пессимизацию», поскольку серверы и рабочие станции ориентированы на принципиально различные типы операций.

Для сервера — это обслуживание множества пользователей, совершающих перекрывающие друг друга запросы к различным файлам, а также поддержка большого количества сетевых соединений и сервисов, их обслуживающих. Пользователи рабочих станций (сколько бы окон они ни открывали) в каждый момент времени взаимодействуют только с одним приложением. Даже если на фоне играет медиаплеер, скачивается несколько файлов и обсчитывается пара электронных таблиц, дисковые запросы на чтение/запись практически не перекрывают друг друга. Создание универсального ядра, одинаково хорошо работающего как на рабочих станциях, так и на серверах — вполне посильная задача, но, взяв ядро от Server 2003, Microsoft пошла по пути усиления серверных возможностей в ущерб функциональности рабочих станций, что косвенно свидетельствует о ее дальнейших намерениях.

Вполне возможно, что Vista окажется «промежуточной» или же вовсе «тупиковой» операционной системой, вроде Windows Me, которая, будучи написанной впопыхах, естественно, не прижилась.

На самом деле, более логично выглядит архитектура, при которой ядро ничего не знает о графической подсистеме, а графическая подсистема отделена от оконного менеджера, при этом браузер - это все-таки не часть системы, а отдельное приложение, которого вообще может и не быть. Windows уже рушится под собственной тяжестью, но количество уровней абстракции только растет. Ладно, оставим в стороне .NET (мы же договорились не обращать внимания на прикладной уровень) и погрузимся в ядро.

Изменения в менеджере памяти

Память — это основной ресурс, распределяемый операционной системой между приложениями и в огромных количествах употребляемый ей самой в «служебных» целях, поэтому неудачный выбор алгоритмов распределения чреват частыми обращениями к файлу подкачки, съедающими производительность и нивелирующими все остальные улучшения ядра. Microsoft непрерывно оптимизировала стратегию выделения памяти, переписывая огромные куски кода в каждой новой версии Windows.

Vista не стала исключением. Начнем с поддержки NUMA-памяти, впервые появившейся в Server 2003 SP1 и отсутствующей в более ранних версиях Windows (в том числе и в XP). Что это такое?! Аббревиатура NUMA расшифровывается как Non-Uniform Memory Architecture (архитектура с неоднородной памятью) и охватывает как многопроцессорные машины, так и целые кластеры.

В операционных системах без поддержки NUMA планировщик ставит все потоки в очередь и гоняет их по кругу, при этом в различные моменты времени каждый поток выполняется то на одном, то на другом процессоре, что снижает производительность за счет накладных расходов на обеспечение когерентности (согласованности) кэш-памяти всех уровней. Для обхода этой проблемы в Server 2003 SP1 были реализованы новые API-функции семейства ExNuma, например: VirtualAllocExNuma(..., Node), MapViewOfFileExNuma(..., Node) и CreateFileMappingExNuma(..., Node), явным образом указывающие системе, что поток предпочтительнее всего запускать на том процессоре, на котором и произошло выделение памяти. Двуядерные и HT-процессоры, разделяющие общий кэш между всеми потоками, к этому нововведению абсолютно равнодушны, и выигрыш в производительности достигается только на машинах, снабженных двумя (и более) физическими процессорами, да и то при условии, что приложение использует новые вызовы API, а такие приложения появятся не скоро… То же самое относится и к поддержке расширения AWE, преодолевающего барьер в 4 Гбайта физической памяти на x86-системах. Материнские платы, поддерживающие свыше 4 Гбайт памяти, относятся к серверному классу и стоят весьма недешево. Конечно, неуклонное снижение цен на вычислительную технику «опустит» такие платы в бюджетный класс уже через несколько лет, но никакой гарантии, что это действительно произойдет, у нас нет.

Поддержка больших объемов памяти повлекла за собой необходимость пересмотра стратегии выделения адресного пространства и переход от статической модели (выделяющей все адресное пространство при старте системы) к динамической (выделяющей адресное пространство по мере его потребления). Если раньше каталог виртуальных страниц инициализировался на ранних стадиях загрузки ОСи, резервируя 1,5 Мбайта на x86-системах, 3 Мбайта на x86-системах с поддержкой PAE (Page Address Extension) и 2,5 Гбайта на x86-64 и IA64, то сейчас выделение памяти и построение страничного каталога происходит по мере необходимости (on-demand), что слегка ускоряет загрузку, но ощутимо замедляет работу приложений, «пожирающих» память. И если на серверах, работающих на 64-битных процессорах или процессорах с поддержкой AWE, этот шаг еще хоть как-то оправдан (действительно, глупо инициализировать все адресное пространство, не будучи уверенным, понадобиться оно или нет), то рабочие станции однозначно оказываются в проигрыше.

Параллельное обнуление (zeroing) страниц, появившееся в Server 2003 SP1, также относится к кластерам и не дает никакого выигрыша даже на многопроцессорных системах, поскольку физическая память — одна. Поддержка новых типов проекций и, в частности, чередующихся виртуальных адресных дескрипторов — Rotate Virtual Address Descriptors (сокращенно VADs) - позволит видео-драйверам полнее использовать возможности шины AGP, быстрее отображая видеопамять на адресное пространство прикладных приложений с выбором одного из следующих типов проекций: cached, non-cached, write-combined AGP или video-RAM mappings. Это, несомненно, порадует любителей трехмерных игр, но никак не отразится на судьбе офисных приложений и, соответственно, корпоративных пользователей.

Разработчики Vista переписали значительную часть кода, отвечающего за подкачку страниц памяти с диска, пересмотрев базовые стратегические алгоритмы и оптимизировав его работу (точнее, попытавшись оптимизировать), но это если смотреть на ситуацию глазами Microsoft. С точки же зрения пользователей, гораздо большей оптимизации можно добиться, установив на XP порядка 1 Гбайта памяти и отключив файл подкачки. Подавляющему большинству приложений такого количества памяти окажется вполне достаточно.

Vista же потребляет намного больше этого драгоценнейшего ресурса, и для отключения файла подкачки потребуется как минимум 4 Гбайта физической памяти, но даже такого количества некоторым .NET-приложениям может не хватить и, как показывает практика, при активной работе системы им действительно ее не хватает и без файла подкачки уже не обойтись. Чтобы хоть как-то скомпенсировать разрыв в производительности и не уронить Vista в глазах пользователей XP, Microsoft была вынуждена прибегнуть к многочисленным ухищрениям, забыв о том, что оптимизация никогда не дается даром и, выигрывая в одном, мы неизбежно теряем что-то другое.

Главное архитектурное изменение заключается в том, что страницы виртуальной памяти, ранее объединенные в связанный список (linked list), теперь реализованы как сбалансированные AVL-деревья, и это при том, что каждому студенту известно, что деревья дают выигрыш только при обработке действительно больших объемов данных (которым в данном случае является не размер памяти, а количество страниц). Сколько-нибудь заметный выигрыш достигается только при интенсивном использовании десятков гигабайт виртуальной памяти, что способно удовлетворить аппетит даже очень мощного сервера или рабочей станции, обрабатывающей цифровое видео огромного разрешения, занимающейся трехмерным моделированием или решающей другие «прожорливые» в плане памяти задачи, но тогда уже имеет смысл приобретать не PC, а профессиональные рабочие станции. Про обычные приложения и упоминать не стоит. Даже если их переписать на .NET, их потребности в памяти все равно не возрастут до таких безумных размеров.

Другое интересное нововведение — уменьшение фрагментации файла подкачки (как внешней — на диске, так и внутренней — соседние виртуальные страницы выгружаются рядом) - снижает эффективность использования дискового пространства, увеличивает время позиционирования головок жесткого диска при считывании несмежных страниц и в ряде случаев несколько ухудшает производительность, но в общем быстродействие системы возрастает, причем иногда очень значительно, чуть ли не в несколько раз. Расплачиваться за это приходится размером файла подкачки, впрочем, учитывая, что жесткие диски на 500 и даже 750 Гбайт уже не редкость, о размерах можно смело забыть.
Наконец, если раньше файл подкачки, реестр и дисковый кэш представляли собой совершенно независимые системные компоненты, то теперь между ними протянулась нить интеграции, согласующая операции ввода/вывода, что самым благотворным образом сказывается на производительности. Но реально выигрыш ощущается, опять-таки, только на серверах, а на рабочих станциях разницу в быстродействии приходится измерять профилировщиком или хронометрировать с таймеров в руках.

Куча, (она же heap, она же динамическая память) представляет собой слой абстракции над менеджером памяти, позволяющий программисту выделять куски памяти заданного размера, а по завершении работы с ним — освобождать их, возвращая обратно в общий пул памяти. Динамическая память, активно используемая в С и объектно-ориентированных платформах и языках последующих поколений (С++, Java, .NET), стала своеобразным фундаментом, используемым как явно, так и неявно. Кажется очевидным, что на неудачно построенном менеджере кучи далеко не уедешь и его оптимизация способна принести большую отдачу, но в действительности это не более чем распространенное заблуждение.

Прикладные программы используют прямые вызовы функций менеджера кучи только в исключительных случаях, поскольку поверх него натянут еще один слой абстракции, создаваемый языком программирования, а точнее - поставляемой вместе с ним библиотекой времени исполнения (она же RTL). Другими словами, каждый язык имеет свой собственный менеджер кучи, запрашивающий у системного менеджера большие куски памяти, а затем «нарезающий» ее мелкими порциями. Реальная производительность определяется именно стратегией встроенного менеджера кучи и слабо зависит от системного.

Тем не менее, не стоит игнорировать работу, проделанную Microsoft, и в первую очередь следует отметить уменьшение фрагментации динамической памяти (the low-fragmentation heap — LFH), а также новые эвристические алгоритмы, автоматически подстраивающиеся под характер запроса на выделение памяти.

Вопреки расхожему мнению, фрагментация кучи приводит отнюдь не к падению производительности, а к невозможности выделения непрерывного блока требуемых размеров, хотя по «кускам» свободной памяти может быть в сотни раз больше. Как следствие, при достижении определенной степени фрагментации, часть приложений перестает работать и их приходится перезапускать. Если этим приложением окажется база данных или HTTP-сервер, то такое положение дел может привести к большим неприятностям, особенно если программист забыл обработать ситуацию невозможности выделения памяти, вследствие чего, вместо корректного завершения работы мы получаем крах с потерей всех несохраненных данных. Впрочем, как показывает практика, подобные приложения практически не встречаются, и если приложение требует периодического перезапуска, то с вероятностью близкой к единице, можно утверждать, что проблема кроется в утечке памяти. Ошибки проектирования приводят к тому, что выделенная однажды память не освобождается, продолжая выделяться вновь и вновь, вплоть до полного исчерпания всех системных ресурсов. Справиться с утечками операционная система не в состоянии, поскольку не существует никаких формальных признаков, по которым можно было бы отличить реально используемый блок памяти от блока, который просто забыли освободить.
С адаптивными алгоритмами выделения памяти (еще одна инновация Microsoft) все одновременно просто и сложно. Если они «угадают» характер поступления запросов, мы получим увеличение производительности (подчас весьма значительное), но всегда существует угроза, что они сработают с точностью до наоборот!

Но, как бы там ни было, максимальное время выделения/освобождения памяти напрямую зависит от так называемого lookup-алгоритма, естественно, переписанного в новой версии Windows, эффективность которого теперь составляет не O(n), а O(1), то есть время работы алгоритма теперь не зависит ни от каких посторонних обстоятельств (например, количества выделенных блоков), что в каком-то смысле очень даже хорошо. Плохо только то, что при небольшом количестве блоков (вполне типичном для офисных приложений) прежний алгоритм показывает большую эффективность, то есть выигрыш опять-таки достигается только на серверах, ну, или высокопроизводительных рабочих станциях, решающих серьезные задачи, к которым расчет зарплаты в Excel'е никак не относится.

Ввод/вывод — традиционно самая узкая часть в системе, своеобразное «бутылочное горлышко», сводящее на нет высокое быстродействие процессора и огромную пропускную способность подсистемы памяти. Все упирается в диск. Производительность винчестеров, конечно, растет, но объемы обрабатываемых данных растут еще быстрее, причем, зачастую к диску совершается более одного запроса одновременно (особенно на серверах), но не все запросы равнозначны по своей ценности. Windows изначально поддерживала приоритеты процессов (которыми можно манипулировать как через API-функции, так и с помощью «диспетчера задач»), но вот приоритеты потоков в ней все это время отсутствовали. И вот, наконец… появился приоритизированный ввод/вывод! И теперь потоки данных с более высоким приоритетом вытесняют потоки с более низким. Какую отдачу это дает нам в практическом плане? Хм, хороший вопрос, сейчас постараюсь подобрать под него подходящий пример. Допустим, нам необходимо скопировать большое количество файлов в фоновом режиме, при этом мы хотим, чтобы система реагировала на открытие текстовых файлов и электронных таблиц практически мгновенно (XP в этом случае заметно тормозит). А еще примеры будут? Увы! В повседневной работе офисному компьютеру приотиризированный ввод/вывод практически не нужен. Вот на серверах ситуация совсем иная, и разница в производительности ощущается даже на домашнем HTTP/FTP-сервисе, который теперь можно перевести в фоновой режим, чтобы при большом наплыве пользователей Windows Vista не «проседала» под нагрузкой, как это делает XP, вынуждая владельца сервера устанавливать жесткие лимиты на количество одновременно устанавливаемых соединений.

Вместе с появлением приоритизированного ввода/вывода также изменилась и политика сброса дисковых буферов. Если проецируемые в память файлы (memory mapped files) в XP, сбрасываются на диск маленькими кусочками, размер которых не превышает 64 Кбайт, то Vista может зараз сохранять до 4 Гбайт данных. Какой выигрыш это дает? Поскольку большинство приложений работает с файлами через API ReadFile/WriteFile без проецирования в память — ровным счетом никакого. Единственное, что ускоряется — так это работа с файлом подкачки, поскольку система проецирует его в память, но реальное ускорение удается обнаружить лишь на быстрых дисках и при интенсивном вводе/выводе, что, опять-таки, на рабочих станциях встречается не так уж часто.

Стабильность, безопасность, надежность

Хорошая новость — Microsoft перенесла часть драйверов с ядерного уровня на прикладной (точнее, предоставила программистам набор функций, способный реализовать некоторые типы драйверов, главным образом относящиеся к USB-устройствам, на прикладном уровне). И что же здесь хорошего?

Все дело в том, что Windows, в отличие от Linux, крайне болезненно реагирует на исключения, возникающие в драйверах на уровне ядра, отвечая на это аварийной остановкой системы даже тогда, когда для этого нет никаких причин. Допустим, драйвер обратился к странице памяти, которой нет. Ясно же, что остальные компоненты системы от этого никак не страдают и достаточно просто остановить «неправильный» драйвер или даже перезапустить его! Linux именно так и поступает. Естественно, если ошибка обнаружится в одном из критических драйверов (например, драйвере файловой системы), то остановка «неправильного» драйвера с высокой степенью вероятности приведет к неработоспособности всей системы, но ошибки такого типа крайне редки, а вот ошибки в драйверах сторонних разработчиков — вполне обычное явление.

В идеале, компании Microsoft следовало бы доработать ядро на манер Linux'а, но она как всегда пошла своим путем. Ошибки новых драйверов прикладного уровня вызывают критические исключения, ведущие к аварийному завершению (перезапуску) драйвера, но безвредные для всей системы в целом. Так что такой шаг можно только приветствовать, однако не стоит надеяться, что установка Windows Vista автоматически перетянет ранее написанные драйверы на прикладной уровень! Это произойдет не раньше, чем программисты выпустят обновленные версии, использующие данную возможность, а для этого разработчикам придется: а) внимательно прочитать документацию; б) научиться писать драйверы по-новому; в) переписать уже существующий отлаженный код. Вопрос: сколько программистов реально займутся этим?! Ответ: старые драйверы переписывать никто не станет, и даже драйверы для новых устройств еще долгое время будут создаваться по прежней схеме, поэтому Vista и дальше будет радовать нас «голубыми экранами смерти». Конечно, в перспективе, драйверы прикладного уровня станут вполне обычным явлением, но… не быстрее было бы просто доработать ядро, останавливая систему только в критических ситуациях?!

Плохая новость — разработчики Vista полностью переписали TCP/IP-стек, добавив в него поддержку IPv6 и повторив все ошибки, допущенные при разработке старого стека, частично позаимствованного еще из BSD. Подробный анализ дыр нового сетевого стека можно найти в статье «Windows Vista Network Attack Surface Analysis: A Broad Overview», написанной по результатам исследований первых beta-версий сотрудниками корпорации Symantec. Конечно, сейчас все эти ошибки уже исправлены, но сам факт их наличия говорит о том, что квалификация программистов, вовлеченных в это дело, оставляет желать лучшего: стек писался кое-как, а тестировался еще хуже, то есть вообще не тестировался, поскольку в противном случае сотрудники Symantec'а не обнаружили бы столько ошибок. А сколько еще дыр предстоит открыть?

Кстати, растет количество сообщений о нестабильной работе и зависаниях Vista. На самом деле, на нормальном желе Vista просто так не зависает, но где вы видели это нормальное железо?! Предъявляя более высокие требования (по сравнению с XP) к аппаратуре, Vista гоняет ее и в хвост и в гриву. Очень часто зависания удается устранить, установив дополнительное охлаждение на серверный мост чипсета (охлаждение памяти и силовых элементов стабилизаторов также не помешает), но в некоторых случаях приходится менять блок питания вместе с материнской платой, выбирая качественные модели по соответствующей цене. Другая возможная причина — конфликт с драйверами, которые еще не были протестированы производителем под Vista, так что с подбором железа придется повозиться!

Вообще, с поддержкой нового железа в 64-битной версии Vista дела обстоят далеко не самым лучшим образом. По не совсем понятным соображениям, Microsoft ввела обязательную политику цифровой подписи драйверов. Неподписанный драйвер невозможно загрузить даже с правами администратора!!! Причем процедура выдачи цифровой подписи довольно запутана и, естественно, далеко не бесплатна. Если даже крупнейшие разработчики (типа Matrox или NVIDIA) испытывают большие проблемы с ее получением (и новейшие версии драйверов обычно некоторое время остаются неподписанными), то что же тогда говорить о мелких? Не стоит также забывать о «псевдо-драйверах» — никаким оборудованием они не управляют и оформлены в виде драйвера только затем, чтобы получить доступ к необходимым ядерным функциям, недоступным с прикладного уровня. На этом принципе, в частности, построены антивирусы, персональные брандмауэры и многие другие программы, перехватывающие определенные системные функции и следящие за всеми интересующими их событиями (например, попыткой запуска исполняемого файла).

Теперь всему этому придет конец. Microsoft в целях повышения защищенности системы запретила модификацию ядра и большинства прилегающих к нему компонентов. Мотив — уж слишком много программистов (и хакеров) стало решать свои задачи путем «доработки ядра напильником», и далеко не всегда эта доработка выполняется с учетом всех архитектурных особенностей операционной системы. Как следствие — на пользователя обрушивается шквал голубых экранов смерти: специальный компонент ядра Patch Guard периодически сканирует систему на проверку целостности и при обнаружении вторжения аварийно завершает ее выполнение.

Что ж, логика Microsoft вполне понятна, только ведь программисты отнюдь не от хорошей жизни лезут править ядро. Если бы поставленные задачи решались легальными средствами, то никакой модификации не понадобилось бы! Формально, Microsoft предоставляет набор функций, позволяющих антивирусу или брандмауэру перехватывать определенные системные события, но… эти функции только для честных приложений, а нечестное может отнять у антивируса управление так, что тот об этом даже не узнает! Скажите, вам нужен брандмауэр, контролирующий трафик честных приложений, но не защищающий даже от простейших атак?!

Таким образом, мы будем вынуждены либо использовать ненадежные защитные пакеты от сторонних поставщиков, либо ограничимся тем, что уже встроено в ядро самой Microsoft. Действительно, какое-то подобие брандмауэра там есть, но, во-первых, он не всех устраивает, а, во-вторых, хакеры уже давно научились его обходить.

Самое забавное, что Patch Guard очень легко обмануть или даже вообще «оглушить», действуя хакерскими методами, так что на судьбе вирусов, червей и rootkit'ов запрет на модификацию ядра никак не отразится, а вот честные разработчики оказываются в очень неприятном положении. Они не могут отключать Patch Guard, и не только потому, что законность такого действия вызывает сомнения. Легальных способов его отключения нет и не будет, а нелегальные — не надежны и могут вызывать различные проблемы у конечных пользователей. Но если хакерам на это наплевать, то уважающие себя разработчики таким путем идти не могут. Фактически их просто выжимают с рынка в пользу решений от Microsoft, качество которых в отсутствии конкуренции лучше не станет.

Подчеркнем, что Patch Guard существует только в 64-битной редакции Windows Vista. 32-битную Microsoft решила не трогать, поскольку такое решение вызвало бы неработоспособность огромного количества уже написанного программного обеспечения, и никому из пользователей Vista оказалась бы не нужна. А вот под 64-битные платформы существует не так уж много ПО и требование обратной совместимости не стоит так остро.

Заключение

Отличия новой системы от XP носят довольно радикальный характер, но, увы, этот характер не совсем в пользу рабочих станций (а ставить Windows Vista на серверы из-за переписанного сетевого стека пока что слишком опасно). Переход на Vista влечет за собой серьезные траты (в первую очередь на качественное железо), но ничего не дает взамен.

Крис Касперски

Специалист по компьютерной безопасности и сжатию цифрового аудио/видео, системный программист, участвующий во многих проектах (большей частью под NDA) по анализу вредоносного программного обеспечения, поиску “закладок”, разработке систем защиты информации от несанкционированного досту- па/копирования информации как в качестве рядового сотрудника, так и руководителя отдела. В настоящее время работает в компании Endeavor Security, Inc, а так же занимается преподавательской деятельностью.

Обсуждение статьи

Guest guest@gameland.ru Отправлено: 31.12.2009 11:13:32

RE: Сравнение ядер: анализ ядер и ядерных компонентов Windows XP и Vista
А что, правда ядро Linux умеет выгружать драйвера? Первый раз об этом слышу. То-то поддержка дофигища устройств у них в ядро встроена.

Guest guest@gameland.ru Отправлено: 11.10.2010 5:12:55