OSDev

Ещё проблема слежения за языком ввода усугубляется многооконным интерфейсом, а именно сохранением текущего языка в каждом отдельном окне. Тоесть, пользователь должен помнить не просто язык который он выбрал сейчас, а язык каждого окна. При переходах с окна на окно пользователь не трогает кнопку переключения языка, пишет текст, а тут "опаньки", язык другой. Значёк в трее казалось бы должен помочь, но... в трее значёк красиво стоит только на чистой, только что установленной системе. После установки нескольких программ, в трее уже не просто значёк, а куча-мала, причём индикатор клавиатуры без фиксированного места, его надо ещё поискать. Его поиск среди 10 значков может затянуться на долго. В общем, всё очень плохо.
Кстати, я цветной курсор уже реализовал в своей поделке
http://code.google.com/p/express-os/downloads/list

Наконец-то принято принципиальное решение. До сегодняшнего дня объектная модель COM использовалась в "пилотном", тоесть пробном режиме. Теперь решено, что система будет базироваться именно на COM. Но это решение не налагает ни каких ограничений на другие компоненты ОС. Например, на более низком уровне может существовать POSIX API, а на более верхнем может работать платформа .Net, Mono, Web движки или другие библиотеки. Универсальности COM достаточно, чтобы любые библиотеки на любых уровнях могли использовать его интерфейсы.

Пост про переключение языков напоминает проблему, которая была придумана после того, как придумано ее решение... То есть тебе понравилось решение, поэтому ты придумал проблему...

в XP/Viste языковая панель имеет вполне определенное место (и это место можно менять), и у каждого окна свой язык, при переходе на другое, язык меняется на тот который там использовался в последний раз... Вот это мне кажется очень удачным решением, так как переключаясь между допустим студией и квипом не надо менять раскладку (а в макоси это надо делать постоянно, вот счас допечатаю включу ХКод и опять надо переключать раскладку)...

pushkoff, какая разница, где стоит языковая панель? Пользователь при печати сморит на курсор, а не на языковую панель. Ладно, посторюсь, что это вообще не решение чего-то там, это просто как бы сказать улучшение, красивость, и ничего более. Проблемы нет.

В многопроцессорной синхронизации я мало понимаю. Есть вопрос. После установки флага занятости некого ресурса с помощью xchg [lock],1, достаточно ли при освобожении ресурса обнулить флаг простой записью нуля командой mov [lock],0, или нужны другие синхронизирующие операции? Вообще-то у меня работает и так.

Да, хотя в многопроцессорной синхронизации я тоже мало понимаю :)

Edited. В смысле достаточно.

Достаточно, но с одним ограничением: переменная lock (лучше, хтати, её так не называть, чтобы не путать с префиксом) должна быть выровнена по естественной границе. Т.е. если это двойное слово (4 байта), то она должна располагаться по 4-байтовой границе, и т.п. Для байтовой, есно, пофиг, где она лежит. Причина здесь в том, чтобы MOV обеспечил атомарный доступ (запись сразу во все байты, занимаемые переменной), что гарантируется только при правильном выравнивании.

Да, больше байта в общем-то и не нужно. Другое дело битовые поля... (bt*)

SII, с выравниванием понятно. Ещё Intel рекомедует выравнивать на 128 байт для скорости.
Я кажется понял суть вопроса. На многоядерном процессоре используется единый кэш первого уровня для всех ядер, поэтому там нет преград для обмена кэшированной информацией между ядрами. Вот почему у меня работает без проблем. А на системах с физически разными процессорами, кэши первого уровня физически разделены, и там его нужно обходить с помощью некэшированных страниц (у страниц есть такой атрибут запрета кэширования).

О кэше представление неверное в корне ;) У каждого ядра свой личный кэш первого уровня, кэши второго и третьего могут быть как общими, так и индивидуальными, ну и так далее. Это, вообще говоря, зависит от модели процессора (например, у Core 2 Quad на каждую пару ядер приходится общие 6 Мбайт кэша третьего уровня, поэтому в сумме объём получается 12 Мбайт, но это "нечестно" из-за разделения; а вот у Core i7 8 Мбайт кэша третьего уровня, но он общий для всех ядер независимо от их числа, и в этом случае 8 Мбайт оказывается лучше, чем 12 у Core 2). Кроме того, у процессоров ИА-32 предусматриваются аппаратные механизмы обеспечения когерентности кэшей (отсутствующие в большинстве других архитектур), так что запрет кэширования не требуется, а вот некоторые другие пляски с бубнами могут быть нужны. В общем, это надо внимательно вникать в определённые разделы руководства...