Многозадачность

[Vitamin]

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

зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят

ща поправлю %)

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

так как довольно большая часть приложений не нуждается в расширенной памяти, копирование происходит не так часто как кажется

[GriV]

Пока ещё не ясно, каким приложениям может понадобиться быстрый доступ к верхней памяти (т.е. не через окно проекций), но я думаю что реализовать такие функции можно просто через стандартный монгопольный режим. Единственно, что будет отличать приложение, находящееся в монопольном режиме, от тех, что используют разделение процессорного времени - это положение.
В плане программирования, естественно, система не уходит в глубокий аут при запуске монопольного режима, просто отключаются некоторые из уже ненужных механизмов - многозадачность, окно менеджера и т.д.
Работа же со всеми остальными ресурсами производится всё равно через систему - никаких прямых выводов на контроллер FDD и т.п.

[Corpsegrinder]

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

На вскидку:
о AceEdit при редактировании 65 кб текста (вместо Ace Edit - вообще любой редактор, у которого планируется быстрая работа с блоками)
о BGE лбой версии, когда пытается например обработать скрин плугином...

да мало ли вообще всего? Но подход, когда часть функций регистрируются в системе как библиотека вполне мормально эту проблему решает.

[GriV]

На вскидку:
о AceEdit при редактировании 65 кб текста (вместо Ace Edit - вообще любой редактор, у которого планируется быстрая работа с блоками)
о BGE лбой версии, когда пытается например обработать скрин плугином...

да мало ли вообще всего? Но подход, когда часть функций регистрируются в системе как библиотека вполне мормально эту проблему решает.

Как раз в приведённых примерах монопольный режим меньше всего нужен... Он нужен для демок, больших игр, в общем для мультимеда контекста...