nixp.ru v3.0

28 мая 2017,
воскресенье,
23:25:47 MSK

DevOps с компанией «Флант»
Dr. Evil написал 27 февраля 2006 года в 14:39 (403 просмотра) Ведет себя как мужчина; открыл 578 тем в форуме, оставил 3008 комментариев на сайте.

<font size=«+1»>Одной из «блестящих функций» новой версии настольной среды Linux станут ограничительные инструменты для администратора.</font>

Следующая версия GNOME будет содержать ряд инструментов, нацеленных на облегчение внедрения администраторами настольной среды Linux на предприятиях. Согласно статье разработчика GNOME Дэвида Мейдли, опубликованной на веб-сайте проекта в конце прошлой недели, версия GNOME 2.14, которая должна выйти 15 марта, будет включать новые инструменты администрирования, такие как менеджер профилей и редактор для ограничения функциональных возможностей ПК.

В своем блоге Мейдли поясняет, что он написал статью, чтобы «донести о блестящих возможностях» GNOME 2.14, хотя и предупреждает, что окончательный состав финальной версии 2.14 может измениться.

Менеджер профилей Sabayon позволяет администраторам создавать профили групп пользователей и устанавливать параметры по умолчанию и обязательные параметры для этих групп. А при помощи редактора ограничений Pessulus можно запрещать определенные функции настольной среды GNOME. «Это бывает полезно в корпоративной среде и в интернет-кафе, где пользователям нельзя позволять редактировать панели, работать с командной строкой и т. п.», — пишет Мейдли.

GNOME 2.14 должен обеспечить также «значительное» повышение производительности, благодаря новому распределителю памяти. По словам Мейдли, он выполняет операцию, которая у прежнего распределителя памяти занимала 26 с, всего за 2 с.

Хотя у GNOME много преданных сторонников в техническом сообществе, основатель Linux Линус Торвальдс не фанат этой настольной среды. В прошлом году Торвальдс заявил, что GNOME разработан «фашистами от интерфейса», и порекомендовал пользователям переходить на конкурирующую настольную среду KDE.

источник: ZDNet

// Тему переместил(а) Dmitry Shurupov из форума «Новости».

Master

делают фторую винду

Dr. Evil

думаю, что нет. просто добавляют инструментарий, который необходим для продвижения/развития продукта на рынке. а кто, что делает — это еще вопрос…;)

может, винда делает Linux ;)

Master
Dr._Evil
может, винда делает Linux ;)

все к этому и идет.

М$ намеревается же сдалать какие-то загрузочные скрипты в следующих версиях…

decvar
М$ намеревается же сдалать какие-то загрузочные скрипты в следующих версиях…

с этого места поподробнее…

Sasha2
Master
все к этому и идет.

М$ намеревается же сдалать какие-то загрузочные скрипты в следующих версиях…

Более того, уже в Windows Vista планируется разделить ядро и графическую оболочку.

Впрочем вынь настолько крив, что вряд ли им это поможет.

Думаю, что в Microsoft осознают, что даже предложи они раскрыть код своей Windows, над ними просто посмеются. Пользы уже от этого никакой.

decvar
Более того, уже в Windows Vista планируется разделить ядро и графическую оболочку.

Блин, чуваки, вы мне глаза на мир каждый день открываете. Я понимаешь ежедневно ковыряюсь в ядре nt, а там оказывается еще и графическая оболочка есть…

Линуксойды отжигают по-полной…

А еще говорят, пользователи винды пьют кровь христианских младенцев…

Master
Sasha2
Более того, уже в Windows Vista планируется разделить ядро и графическую оболочку.

Скорее всего имелось в виду следующее:

http://www.winline.ru/vista/news/1399.php

Графическая подсистема Windows Vista под кодовым названием Avalon и известная как Windows Presentation Foundation (WPF) будет вынесена из ядра новой ОС, чтобы улучшить надежность Vista, сообщил Giovanni Marchetti, разработчик архитектуры ядра ОС.

PS: <font color=«blue»>Microsoft to move graphics outside OS kernel</font>

Master
decvar
с этого места поподробнее…

самому интересно :)

decvar

буржуйские журналисты не лучше наших.

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

fly4life
decvar
буржуйские журналисты не лучше наших.

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

Сравнил… В любом случае, framebuffer из линуксового ядра выдирается легко и непринуждённо, а вот графическая подсистема из виндового… ммм… как бы это сказать.. пока никак, да? ;).

Longobard
fly4life
а вот графическая подсистема из виндового… ммм… как бы это сказать.. пока никак, да? ;).

А она там есть? Исходники 2k спижжены и лежат, например, у меня на винте. Скажи в каком файле там графическая подсистема :)

fly4life
LONGOBARD
А она там есть? Исходники 2k спижжены и лежат, например, у меня на винте. Скажи в каком файле там графическая подсистема :)

Т.е. мне посмотреть лежащие у тебя на винте спижженные исходники, и что-то в них найти и показать тебе? Клёва ;) А их вообще обязательно смотреть? Ты уверен, что ориентируешься в тех исходиках? ;)

Для начала предлагаю удалить файл win32k.sys (лежит в %windir%\system32 в случае WinXP), и ответы на вопросы: «А она там есть?», «что это за win32k.sys такой» и «каким образом он относится к ядру виндовса» — предлагаю найти в гугле самостоятельно.

decvar
А она там есть?

нет.

что это за win32k.sys такой

это: 1)драйвер минипорта графического адаптера и 2)почти все вызовы NtGdi*. Рассказать что такое gdi и почему это не графическая подсистема?

каким образом он относится к ядру виндовс

Никаким. Это во первых драйвер, во вторых kernel level runtime сисколы(syscall) которых может и не быть. Например в Windows XP Recovery Console он не загружен.

Если тебе интересно, то я могу рассказать как загрузить любую NT без него и получить девстенно чистый экран черного цвета и командный интерпритатор.

И еще, хорошо бы определиться в понимании разницы между:

- OS Kernel

- Kernel Level API

- User Level API

дабы не было недопонимания.

PS

Ликбез:

непосредственно ядро: ntoskrn.exe

подсистемы, типа dos, win16, etc : nt*.sys

HAL : hall.dll

user level syscalls : user32.dll

kernel level syscalls : kernel32.dll

PPS:

From «Inside Windows 2003 Server» book

Longobard
decvar
Если тебе интересно, то я могу рассказать как загрузить любую NT без него и получить девстенно чистый экран черного цвета и командный интерпритатор.

Мне интересно, расскажи.

fly4life
decvar
нет.

это: 1)драйвер минипорта графического адаптера и 2)почти все вызовы NtGdi*. Рассказать что такое gdi и почему это не графическая подсистема?

С удовольствием послушаю ;). А так же о том, что такое «графическая подсистема» и из чего она состоит.

decvar
Никаким. Это во первых драйвер, во вторых kernel level runtime сисколы(syscall) которых может и не быть.

Интересно, а как мне сделать, чтобы этих вызовов не было? Точнее, чтобы при отсутствии win32k.sys (я пока ещё его считаю частью графической подсистемы ;)) у меня XP не уходила в перезагрузку?

decvar
Например в Windows XP Recovery Console он не загружен.

Если тебе интересно, то я могу рассказать как загрузить любую NT без него и получить девстенно чистый экран черного цвета и командный интерпритатор.

Что из себя представляет 'recovery console' я знаю. Во-первых это не то чтобы не операционка, а не оболочка даже. А вот как выглядит «девстенно чистый экран черного цвета и командный интерпритатор» очень даже интересно увидеть. Как сделать?

decvar
И еще, хорошо бы определиться в понимании разницы между:

- OS Kernel

- Kernel Level API

- User Level API

дабы не было недопонимания.

Ой, ну да. Дабы не было недопонимания. Под: «Графическая подсистема Windows Vista под кодовым названием Avalon и известная как Windows Presentation Foundation (WPF) будет вынесена из ядра новой ОС» — как раз, подразумевается, что графическая система будет вынесена из kernel level в user level.

decvar
PS

Ликбез:

непосредственно ядро: ntoskrn.exe

подсистемы, типа dos, win16, etc : nt*.sys

HAL : hall.dll

user level syscalls : user32.dll

kernel level syscalls : kernel32.dll

PPS:

From «Inside Windows 2003 Server» book

Спасибо ;)

decvar
что графическая система будет вынесена из kernel level в user level.

Thats it!

Т.е. все уже поняли что графическая система nt не часть ядра, а в драйверы и библиотеки уровня ядра?

? Точнее, чтобы при отсутствии win32k.sys (я пока ещё его считаю частью графической подсистемы ;)) у меня XP не уходила в перезагрузку

Без него никак. Из-за того, что в этом драйвере(читай выше) минипорт графического адаптера. Т.е. без него HAL не будет знать о существовании видео карточки, вернее не будет интерфейсов взаимодействия с ней.

Можно загрузить nt без инициализации gdi.

что такое «графическая подсистема» и из чего она состоит.

графическая подсистема состоит из интерфейсов(драйверов) и библиотек обращения к ним. Т.е. фактически графическая система должна позволять зазставить ОС нарисовать пиксель заданного цвета в заданых координатах. Дальше эти(чаще всего kernel level) вызовы используют прикладные библотеки, которые тоже можно считать частью графической подсистемы). В nt над драйверами сидит непосредственно GDI(то что в linux, наверное, делает framebuffer). GDI в nt реализован в виде множества вызовов, часть из которых kernel level( в win32k.sys), а часть user level(gdi.dll) и DirectDraw(из DirectX). Дальше над GDI сидит Common Controls Library, еще выше MFC, и еще выше Windows.Forms в .NET. DirectDraw сам представляет пользовательские вызовы и сам работает непосредственно с драйверами(хотя вот тут я точно не знаю)…

Вот такая примерно картина ;)

Вывод: То что часть графической системы работает в kernel level, не делает ее(часть или всю) составной частью ядра. Так как напрямую с ядром работает только драйвер минипорта(ну а ему и положено:)

PS

Кстати, говорят что до nt 4.0, т.е. <= 3.5, GDI целиком жил в user level, но оказался слишком тормозным и переехал частично в kernel level.

fly4life
decvar
Thats it!

Т.е. все уже поняли что графическая система nt не часть ядра, а в драйверы и библиотеки уровня ядра?

Думаю, и с самого начала все подразумевали о том, что графическая подсистема винды работает на уровне ядра, а не часть бинарника ntoskrn.exe. Даже Sasha2, который, наверное, просто неудачно выразился.

decvar
Без него никак. Из-за того, что в этом драйвере(читай выше) минипорт графического адаптера. Т.е. без него HAL не будет знать о существовании видео карточки, вернее не будет интерфейсов взаимодействия с ней.

Т.е. ты всё-таки согласен с моим изначальным утверждением: «framebuffer из линуксового ядра выдирается легко и непринуждённо, а вот графическая подсистема из виндового пока никак».?

Если уогодно, то для улучшения понимания этого выражения можно перед словами «framebuffer» и «графическая подсистема» вставить слово «поддержка».

decvar
Можно загрузить nt без инициализации gdi.

Дык, как? Я ещё в прошлом письме сказал, что мне это интересно. И, вон, LONGOBARD тоже ждёт рассказа ;).

decvar
графическая подсистема состоит из интерфейсов(драйверов) и библиотек обращения к ним. Т.е. фактически графическая система должна позволять зазставить ОС нарисовать пиксель заданного цвета в заданых координатах. Дальше эти(чаще всего kernel level) вызовы используют прикладные библотеки, которые тоже можно считать частью графической подсистемы). В nt над драйверами сидит непосредственно GDI(то что в linux, наверное, делает framebuffer). GDI в nt реализован в виде множества вызовов, часть из которых kernel level( в win32k.sys), а часть user level(gdi.dll) и DirectDraw(из DirectX). Дальше над GDI сидит Common Controls Library, еще выше MFC, и еще выше Windows.Forms в .NET. DirectDraw сам представляет пользовательские вызовы и сам работает непосредственно с драйверами(хотя вот тут я точно не знаю)…

Вот такая примерно картина ;)

Вывод: То что часть графической системы работает в kernel level, не делает ее(часть или всю) составной частью ядра. Так как напрямую с ядром работает только драйвер минипорта(ну а ему и положено:)

К концу твоего сообщения до меня всё-таки дошло. По-твоему ядро — это лишь ntoskrn.exe? А я почему-то считал, что модули и ядерные библиотеки — это тоже части ядра. Потому как без них ОС работать не будет.

decvar
PS

Кстати, говорят что до nt 4.0, т.е. <= 3.5, GDI целиком жил в user level, но оказался слишком тормозным и переехал частично в kernel level.

А теперь поняли, что GDI в kernel level слишком рискован (да и, кстати, совсем не нужен) для работоспособности всей системы, и перевозят обратно в user level ;). Собственно, с чего и начался весь этот познавательный флейм ;)

decvar
А я почему-то считал, что модули и ядерные библиотеки — это тоже части ядра. Потому как без них ОС работать не будет.


Очень странно ты считал, учитывая возможность пересборки ядра в linux:)

Интересно как модули(они же драйверы) могут быть частью ядра, если они опциональны для загрузки. В linux ты можешь часть драйверов не собирать вообще. Драйвер не часть ядра, так как драйвер — это, хм, ну это просто драйвер:) и ты прекрасно знаешь что это такое. Ни драйвер, ни библиотеки не являються частями ядра. У тебя же ядром является vmlinuz, так? а модуляим /lib/modules? Ну дык в nt, ядро ntoskrnl.exe, а модули %systemdir%[system32]\*.sys.

Потому как без них ОС работать не будет.

OC безусловно не будет. А вот ядро будет. Мы же про ядра говорим, а не про ОС? Что нужно для того что бы забутить(до kernel panic) linux? Да ничего кроме загрузчика и пачки жизненно важных драйверов. Тоже самое и в nt. Часть драйверов можно не грузить совсем, часть вкомпилена в ядра, а часть загрузит само ядро тебя не спросив.

Дык, как? Я ещё в прошлом письме сказал, что мне это интересно. И, вон, LONGOBARD тоже ждёт рассказа ;)

Обязательно расскажу, надо в обеденный перерыв дойти до другого корпуса. Как получу инструкцию — напишу.

fly4life
decvar
Очень странно ты считал, учитывая возможность пересборки ядра в linux:)

Именно засчёт возможности пересобирать линуксовое ядро, объясню ниже, почему нестранно ;).

decvar
Интересно как модули(они же драйверы) могут быть частью ядра, если они опциональны для загрузки. В linux ты можешь часть драйверов не собирать вообще. Драйвер не часть ядра, так как драйвер — это, хм, ну это просто драйвер:) и ты прекрасно знаешь что это такое. Ни драйвер, ни библиотеки не являються частями ядра. У тебя же ядром является vmlinuz, так? а модуляим /lib/modules? Ну дык в nt, ядро ntoskrnl.exe, а модули %systemdir%[system32]\*.sys.

Т.е. ты утверждаешь, что если модули включить в ядро монолитно (всё одним vmlinuz), то они будут частью ядра, а если их вынести в отдельные файлы *.ko, то они автоматически перестают быть составляющим ядра? Ошибаешься. Знаешь почему? Потому что у Linux (да, и у Windows также) — макроядро. Все части макроядра работают в одном адресном пространстве, составляя при этом единое целое. Отличие модульной сборки от монолитной в таких ядрах заключается лишь в том, что отдельные модули можно подгружать лишь в момент их надобности. И всё.

То, о чём говоришь ты, скорее ближе к микроядрам (таким, как в QNX и где там ещё?).

decvar
OC безусловно не будет. А вот ядро будет. Мы же про ядра говорим, а не про ОС? Что нужно для того что бы забутить(до kernel panic) linux? Да ничего кроме загрузчика и пачки жизненно важных драйверов. Тоже самое и в nt. Часть драйверов можно не грузить совсем, часть вкомпилена в ядра, а часть загрузит само ядро тебя не спросив.

Жаль, что в виндовсе нельзя пересобирать ядро. Вот и путаются потом люди, называя ядром лишь ntoskrn.exe, а всё остальное так… модули какие-то ;).

decvar
Все части макроядра работают в одном адресном пространстве, составляя при этом единое целое.

:))) Лол. Нихрена ты про nt не знаешь. Потому что kernel level модулям не доступно адресное пространство самого ядра :) Это в linux — да. Но не в nt :)

The kernel-mode components of Windows also embody basic object-oriented design principles. For example, they don’t in general reach into one another’s data structures to access information maintained by individual components. Instead, they use formal interfaces to pass parameters and access and/or modify data structures.

from Microsoft Windows Internals, 4th edition (w2k3)

Жаль, что в виндовсе нельзя пересобирать ядро. Вот и путаются потом люди, называя ядром лишь ntoskrn.exe, а всё остальное так… модули какие-то ;).

не путай себя. :)

decvar
Т.е. ты утверждаешь, что если модули включить в ядро монолитно (всё одним vmlinuz), то они будут частью ядра, а если их вынести в отдельные файлы *.ko, то они автоматически перестают быть составляющим ядра? Ошибаешься. Знаешь почему? Потому что у Linux (да, и у Windows также) — макроядро

Мы же про NT помнишь? В Linux все именно так(хотя я точно не знаю, тебе виднее), но в NT нет. В NT — модули, не являются частями ядра, так как не имеют возможности с ним напрямую взяимодействовать. Т.е. дабы какой-нить драйвер мог что-то спросить непосредственно у ядра(через kernel level hal), то ему надо позвать так называемый system service, который обслужит его запросы.

Тоже самое в принципе можно сделать и с user level, так как на время выполнения вызова внутри system service, система переводит вызвавшую нить в ring 1, а на выходе из service назад в ting 3.

PS

Учите мат. часть. NT это вам не юникс :)

И ваще микроядра это утопия. Хотя NT гораздо к ней ближечем любой Unix.

Anarchist
decvar
from Microsoft Windows Internals, 4th edition (w2k3)

LOLx3!!!

Ссылки на столь «авторитетные» истоники не гарантируют того, что все на самом деле так. ВСЕГДА.

В куда более серьезных системах не все столь благополучно.

decvar
Ссылки на столь «авторитетные» истоники

Видишь ли. Более авторитетного источника в природе не существует. Во всех известных мне компаниях используют именно эту книгу для разработки драйверов и библиотек для windows nt. Я канешка понимаю, что анархисту не положено верить бумагомаракам всяким, но больше ничего нету. Если канешна дамп асемблера желаемых бинарей больше устроит.. ;)

Для справки, авторы : Copyright © 2005 by David Solomon, Mark Russinovich. Можно у гугла спросить кто это такие :)

Ну или предложи более авторитетный источник :))

fly4life
decvar
Мы же про NT помнишь? В Linux все именно так(хотя я точно не знаю, тебе виднее), но в NT нет. В NT — модули, не являются частями ядра, так как не имеют возможности с ним напрямую взяимодействовать. Т.е. дабы какой-нить драйвер мог что-то спросить непосредственно у ядра(через kernel level hal), то ему надо позвать так называемый system service, который обслужит его запросы.

Тоже самое в принципе можно сделать и с user level, так как на время выполнения вызова внутри system service, система переводит вызвавшую нить в ring 1, а на выходе из service назад в ting 3.

PS

Учите мат. часть. NT это вам не юникс :)

И ваще микроядра это утопия. Хотя NT гораздо к ней ближечем любой Unix.

Нда… Ну вот, напрмиер, уже во вступлении к «User-Mode Interactions: Guidelines for Kernel-Mode Drivers» написано следующее:

The operating system and most drivers run in kernel mode and have access to operating system structures, to all system memory, and to all processor instructions. Kernel-mode components implicitly trust each other—that is, they assume that addresses and parameters they receive from other kernel-mode components are valid.

(http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/KM-UMGuide.doc)

Кто из вас глючит?

decvar
parameters they receive from other kernel-mode components are valid

Блин. Они receive их, а не сами читают из чужого адресного пространства, они же не чилды одного папы:). Если ты сказал NtGetЧтоНитьИзЯдра(..) и в ответ получил const PVOID, то это по твоему разделяемое ядресное пространство? ;)

valid

значит, что компоненты будут пытаться этот PVOID приводить к каким-то структурам, веря что это они на самом деле и есть. И ессно упадут если после каста, там будет что-нить типа 0xcdcdcdcd

rgo

ланн, это я понял.

А можно всё-таки, запустить винду без gdi, и под ней, например, ftp сервер? Судя по предыдущим постам можно, но как? Я собственно, не настаиваю на подробном объяснении, меня вполне устроит ссылка.

А то, чего-то насколько я помню свой период программирования в win32: system:windows, либо system:console — третьего не дано, но ведь даже для консоли нужен gdi, чтоб окошко нарисовать. Или я где-то неправ/плохо-помню/мало-маны-читал?

decvar
system:windows, либо system:console

на самом деле их гораздо больше. например win16 или dos.

без gdi, и под ней, например, ftp сервер

можно. линк не знаю. а «носитель информации» далеко. сегодня я до него так и не дошел. но как-нить дойду и запостю в этот тред.

fly4life
decvar
Блин. Они receive их, а не сами читают из чужого адресного пространства, они же не чилды одного папы:). Если ты сказал NtGetЧтоНитьИзЯдра(..) и в ответ получил const PVOID, то это по твоему разделяемое ядресное пространство? ;)

значит, что компоненты будут пытаться этот PVOID приводить к каким-то структурам, веря что это они на самом деле и есть. И ессно упадут если после каста, там будет что-нить типа 0xcdcdcdcd

Ладно, попробую подойти с другой стороны. Руссинович и Соломон, говоришь, авторитетные для тебя авторы. Ну вот цитата из их книги «Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000», 4-е издание, Питер, 2005, стр. 18:

Хотя каждый Windows-процесс имеет свою (закрытую) память, код операционной системы и драйверы устройств, работающие в режиме ядра, делят единое виртуальное адресное пространство…

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

«Учите мат. часть» ;).

decvar
«Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000», 4-е издание, Питер, 2005

Это таже самая книга, что я приводил до этого, только перевод;)

и может обходить средства защиты Windows для обращения к любым объектам

Ну дык может. Еще бы не мог, ты же в ring 1:) Это не значит что так нужно делать.

Как известно адресное пространство ядра имеет несколько секций(сегментов), которые предназначены для разных целей. Не мог бы ты посмотреть в этой книге(в переводе) какие именно сегменты доступны другим процессам?

код операционной системы и драйверов устройств в режиме ядра получает полный доступ к системной памяти

Без условно получают доступ, потому что работают в одном ring. Без этого они не могли бы работать вообще.

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

...
struct SomeCoolGlobalStruct g_cStruct;
...

Это не значит, что ты сможешь сказать где-нить в драйвере

extern struct SomeCoolGlobalStruct g_cStruct;

и получить до нее доступ.

А возможность получить указатель на какую-нить кернельную структуру, через какой-нить syscall не являеться признаком того, что вызывающий код — часть ядра.

Т.е. не настаиваешь на том, что если ядро и драйвер работают в одном ring-е, общаються через syscall-ы, то драйвер автоматически является частью ядра, syscall-ы которого(ntdll.dll например) он дергает?

fly4life
decvar
Это таже самая книга, что я приводил до этого, только перевод;)

Да, я знаю ;)

decvar
Ну дык может. Еще бы не мог, ты же в ring 1:)

В ring 0, если быть точным ;).

decvar
Это не значит что так нужно делать.

Но и не говорит о том, что так делать нельзя ;).

decvar
Как известно адресное пространство ядра имеет несколько секций(сегментов), которые предназначены для разных целей. Не мог бы ты посмотреть в этой книге(в переводе) какие именно сегменты доступны другим процессам?

Эммм.. каким другим процессам? А зачем это вообще? ;)

decvar
Без условно получают доступ, потому что работают в одном ring. Без этого они не могли бы работать вообще.

Думаю, не потому, что работают в одном ring, а именно потому, что все работают в ring 0. Вон, user mode процессы тоже работают все в одном кольце (ring 3), но при этом доступ к ресурсам друг друга не имеют.

decvar
Только этот доступ заключается в дергание функций системного сервиса, буфера между ядром и драйвером. Даже если где-нить непосредственно в ядре есть

...
struct SomeCoolGlobalStruct g_cStruct;
...

Это не значит, что ты сможешь сказать где-нить в драйвере

extern struct SomeCoolGlobalStruct g_cStruct;

и получить до нее доступ.

Наверное, это не из-за того, что оно в принципе не может получить до неё доступ, а просто потому что так реализовано в виндовс <font size=«-2»>(чтоб ты не думал, что эти противные линуксоиды опять ни по чём гнобят винду — нет, я не на кривость намекаю ;))</font>.

decvar
А возможность получить указатель на какую-нить кернельную структуру, через какой-нить syscall не являеться признаком того, что вызывающий код — часть ядра.

Т.е. не настаиваешь на том, что если ядро и драйвер работают в одном ring-е, общаються через syscall-ы, то драйвер автоматически является частью ядра, syscall-ы которого(ntdll.dll например) он дергает?

Нет, не настаиваю. Вот, нашёл статью Соломона об архитектуре ядра NT 5.0:

http://khpi-iip.mipk.kharkiv.edu/library/extent/os/os/nt5.html

Да, судя по ней, модули (драйверы) в NT не являются частью ядра. Аналогия с Linux неуместна.

Итак, резюмирую своё участие в дискуссии по части виндового ядра:

Ядро NT — это действительно лишь некоторый набор функций в ntoskrnl.exe. Однако модули работают в режиме ядра и всё равно имеют единое виртуальное адресное пространство с ntoskrnl.exe.

Тут к консенсонсу, вроде, пришли ;).

decvar

пришли. за мною инструкция как забутить nt без графики.

В ring 0, если быть точным ;).

на сколько я знаю, часть в ring 1, а часть в ring 0. Хотя для нас это и не важно. Ибо смертным из ring 3 без разници.

Вон, user mode процессы тоже работают все в одном кольце (ring 3), но при этом доступ к ресурсам друг друга не имеют.


Не потому что не могут, а потому что выделением памяти занимаеться ОС, а она не даст:) Соответственно, как ты верно подметил, выше по уровням можно, так как нету средств защиты кусков ядра друг от друга.

myst

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

А теперь я попытаюсь объяснить враждующим сторонам, как устроены Windows и UNIX, чтобы они (стороны) друг-друга не поубивали.

Уважаемые господа, идём <font color=«green»>сюда</font> и читаем чем отличаются monolithic- (Unix), micro- (QNX) и hybrid- (NT) ядра.

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

А теперь я попытаюсь объяснить враждующим сторонам, как устроены Windows и UNIX, чтобы они (стороны) друг-друга не поубивали.

Уважаемые господа, идём <font color=«green»>сюда</font> и читаем чем отличаются monolithic- (Unix), micro- (QNX) и hybrid- (NT) ядра.

Та ну, ты брось «враждующие» ;)

Моей ошибкой было считать ядро NT макроядром (monolithic, если будет угодно) и сравнивать его с линуксовым.

Однако принципиальным моментом в этой дискуссии было то, что драйвера и в линуксовом (монолитном), и в виндовом (как оказалось, гибридном) ядрах работают в режиме ядра (kernel mode). А также то, что все компоненты, работающие в kernel mode, используют единое виртуальное адресное пространство. Это значит, что если йопнется один компонент, то может потащить за собой все остальные, в том числе и ядро ОС (с этой стороны всё одинаково для обеих систем). Откуда следует, что всю графическую подсистему (как что-то громоздкое, а посему непростое в отладке и отловке всевозможных глюков) лучше выносить из режима ядра в пользовательский. К чему и стремится MS в новой версии своей ОС. Ну а с неправильной трактовки этого факта и начался весь флейм. Всего-то ;). Никто никого убивать, вроде, не собирался ;).

В остальном я с decvar’ом уже согласился. Считать win32k.sys да и вообще графическую подсистему виндовса частью NT-ядра — ошибка.

Genie
В остальном я с decvar’ом уже согласился. Считать win32k.sys да и вообще графическую подсистему виндовса частью NT-ядра — ошибка.

ядра — да.

но так как простые пользователи само ядро мало когда замечают, то им важнее то, что GUI у Win — всё ещё неотъемлемая часть системы…

для теста: вынимаем видеокарточку из компа вообще.

как заставить win семейства nt грузиться в такой конфигурации?

fly4life
Genie
ядра — да.

но так как простые пользователи само ядро мало когда замечают, то им важнее то, что GUI у Win — всё ещё неотъемлемая часть системы…

Будешь третьим, кто ждёт от decvar’а той самой инструкции ;)

Genie
fly4life
Будешь третьим, кто ждёт от decvar’а той самой инструкции ;)

мдаа. и тогда уж и «сообразим на троих», что говорится.. :D

вообще, мне достаточно того, что описанный мною тест — не проходит в системе, установленной стандартно (с использованием штатного инструментария).

таким образом, «инструкция» будет ни чем иным, как описанием использования некоторого набора дополнительных (и, скорее всего, сторонних) утилит.

fly4life
Genie
мдаа. и тогда уж и «сообразим на троих», что говорится.. :D

Не, сообразить decvar’у надо, а мы просто выпьем, поболтаем за жисть… ;)

Genie
вообще, мне достаточно того, что описанный мною тест — не проходит в системе, установленной стандартно (с использованием штатного инструментария).

таким образом, «инструкция» будет ни чем иным, как описанием использования некоторого набора дополнительных (и, скорее всего, сторонних) утилит.

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

Другими словами, если всё упрётся в штатные утилиты, то это дело маленькое. Их отсутствие будет означать, что оно просто напросто пока никому не нужно ;).