информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеПортрет посетителяВсе любят мед
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Oracle выпустила срочный патч для... 
 Атака на WPA2 
 Outlook полгода отправлял зашифрованные... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
В принципе согласен. Но небольшое уточнение 05.01.05 15:26  Число просмотров: 1491
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> NT4 менее стабильна, старшие версии NT5 нестабильны
> вследствие перегрузки никчемными прибамбасами.
NT4 это еж с ужом. Мощи командной строки УЖЕ нету, а гуй ЕЩЕ настолько неудобен, что говорить о какой либо воркстейшене не имеет смысла.

> Мечтаю выдрать из 2к все лишьнее: ИЕ поганый, всяких
> "скрепок", "выползающие меню" и прибить саму потенциальную
> возможность их подключения, чтобы проверки не отжирали
Скрепки и выползающие меню - это навороты 3-го кольца и выдираются аж запросто. Пожалуй, единственное против чего не попрешь это то, что ntoskrnl сращен с win32k. То бишь ядро с пользовательской (в том числе и графической) подсистемой. Выдрать это можно только изрядно полатав это самое ядро.

> ресурсы. Сверхмечта: перепахать ядро, чтобы обеспечить
> полный контроль за распеделением процессорного времени и
> настроить это для двух вариантов: системы реального
> времени, которая гарантировала бы блокировку всех процессов
> до окончания обслуживания запросившего прерывание
> устройства (только не говорите мне, что это и так возможно:
Это проблемы драйвера. Можешь написать драйвер, который будет держать запрос, пока не обработает ПОЛНОСТЬЮ. Пока не сделаешь iret (или его за тебя не сделает винда после того, как ты вернешь ей управление) - никто твое время не заберет. Вот только пользы от этого будет меньше, чем вреда. Не для того обработчики прерываний ВО ВСЕХ известных мне более-менее серьезных системах делят на два уровня: один, который очень быстро работает с устройством и вычитывает/записывает в порты все необходимые данные, второй - который на общих основаниях дообрабатывает очередь запросов, которые произошли (в отдельном потоке или средствами системных WorkerThread-ов).

> мастдай поганый ухитряется вырывать управление даже у
> Винайса - сам видел) ну и пользовательского варианта, в
Это только если чего-то неправильно сделать. :-)

> котором был бы абсолютный приоритет у мыша, т.е. при
> поступлении прерывания от мыши все процессы полностью
> останавливаются до полной обработки сообщения.
А кому как не процессам нужны события мыши? Собственно я уже описывал всю цепочку. win32k-шный RawInputThread получает событие мыши от ядра практически мгновенно. Хромает уже рассылка юзерских сообщений. Вот если открутить win32k и сделать все по своему

> Ну, а для сервера "Мастдай", как коньки для футбола. Его
> идея в корне противоречит идее сервера. Станция, это машина
> для человека, сервер, это "машина для машины". Главное
Согласен
<operating systems> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2017 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach