OSDev

Сделал ещё исправление. Чтобы драйвер мыши запускался нормально, мне приходилось загружать его перед драйвером клавиатуры. Проблема оказалась в том, что команды управления мышью возвращают через порт 0x60 коды ответа, и если порт клавиатуры не заблокирован, то они попадают в буфер клавиатуры, а драйвер клавиатуры от непонятных ему кодов зависал. Поэтому надо перед настройкой мыши отправлять команду "выключение первого порта PS/2" 0xAD в порт 0x64. И ещё на время настройки мыши желательно запретить прерывание клавиатуры в PIC или APIC.

Обнаружил, что установка загрузчика на диск с помощью SetupWin перестала работать. Выпустил исправленную версию системы.
Проблема возникла с новой версией MinGW 5.3.0-2, там ошибка в заголовочном файле ntdddisk.h
строка с ошибкой

Курсор мыши отображён. Окнам отправляются сообщения WM_MOUSEMOVED, WM_LBUTTONDOWN и т.п. Ни каких элементов управления пока нет.

Сделана поддержка колёсика мыши и 2 дополнительных кнопок для WheelMouse и IntelliMouse.
Для проверки, при вращении колёсика, на экране печатаются символы + и -. Это только в окне выбора режима экрана. К этому окну можно вернуться по Ctrl+Alt+Esc.
В процедуре настройки мыши сделана доработка. Оказалось, что после отправки команд к мыши, перед чтением ответа надо делать паузу 20мс. Невнимательно читал спецификацию
https://yadi.sk/d/RJ_W8nEqctQuJ

По поводу разделением кода системы на ядерную и пользовательскую части для защиты от хакерских атак и случайных ошибок программ.
Проблема в том, что пользователю часто надо выполнять манипуляции с объектами (драйверами, файлами, спрайтами и т.п.) используя вызовы ядерных процедур. Предположим для этого используется текстовый командный скрипт. В процессе его исполнения происходит множество системных вызовов с затратами на переходные процессы. Очевидно, что имеет смысл поместить интерпретатор на уровень ядра, а пользователь через один системный вызов передаёт только указатель на буфер команд, и получает результат всей программы.
В ядро можно поместить разные интерпретаторы, типа Shell, Bash, .Net, Mono, Ruby, серверы SQL и т.п.

Ага и получить WIN 98 КОТОРАЯ РАЗ В 1 час зависала.

Падало часто там, где компьютеры глючными были и вирусов полный диск.
А чего в Win98 запускалось с привилегиями ядра? Мне кажется, почти ничего. Это как раз в Win2000 начали всё переносить в ядро, и система стала работать лучше.
На уровне ядра - тоже защищённый режим. Для отлова ошибочных операций вполне достаточный.

У меня есть предположение, что в Windows-7 и выше, программы запущенные "от имени Администратора" выполняются в защищённом режиме. Кто-нибудь может подтвердить или опровергнуть этот факт? Написать тестовоую программу дело не простое, многие системные инструкции Windows может сэмулировать даже в пользовательском режиме.

Не понял что надо подтвердить? А что опровергнуть?

Любая эмуляция приводит к замедлению. Так что меряется по RDTSC. Если работаем под виртуализацией, то RDTSC будет иметь дискретность в мкс. В нормальном режиме десятки или единицы наносекунд.
Но до интерпретации команд они не скатываются так как это через чур медленно. А VMMCALL будем считать исключением которое подтверждает правило.

С каждой новой версий ОС прав у администратора всё меньше и меньше.

Извиняюсь, неправильно сформулировал вопрос. В смысле, в привилегированном, режиме ядра.
Механизм защиты пользовательских программ от "администраторских" привилегий похоже что аппаратный. Когда программа работает на пользовательском уровне, то обращения к привилегированным функциям вызывает исключение, а когда код работает на том же уровне, то всё работает без исключений. Фактически, программы запущенные от имени Администратора полностью контролируют систему.