Board.KolibriOS.org

Евгений ограничил объём когда сделал расшареные длл.
Собственно MIN_DEFAULT_DLL_ADDR = 0x10000000 делит память приложения пополам.

Но почему из 2 Гб всего лишь 900 Мб? Не логичней ли под библиотеки 0,5 Гб отдать, под выделяемую память 1,5 Гб. Начнешь так большой документ открывать, а память то нема!

Mario
Я с тобой согласен, это код надо переделывать.
Кстати куча ограничена 1.5Гб с очень старых времён.

На все наши длл хватит нескольких Мб.

И да, 640 Кб хватит всем.

Это сказал Билли, а не я. К тому же 640 Кб до сих пор для многих наших приложений хватает. Вот для данных не хватает иногда.

Это относится к принципам проектирования. 640 кб впишите нужное значение хватит всем. Вики пишет что Билли этого не говорил.

Ну не знаю кто там как проектирует. Однако если изначально задумывалось отдать приложению 2 Гб, а потом ВНЕЗАПНО задумалось 900 Мб, то второе решение неизвестно чем обосновано. Чужие тараканы, он такие... чужие что ли.

Я поправлю код, вопрос сколько оставить ? 512Мб имхо много. Если бы в системе был файл настроек, но его нет.
MIN_DEFAULT_DLL_ADDR = 0x10000000 это не Гб, это 256Mb а верхняя 512 . Так что длл режут кучу на две неравные части. А верхняя граница кучи немного ниже 1.5Гб.

Ну, поскольку некоторые наши товарищи заняты портированием Сишных библиотек, то думаю либо 256, либо 512 Мб надо таки оставить под библиотеки.
А кстати идея - может приложению самому определять сколько оно хочет отдать под библиотеки? Или в полете это уже невозможно сделать?

З.Ы. Кстати почему верхняя граница кучи ниже 1,5 Гб - это фундаментальное препятствие или как?

Нет в полёте уже не поменять. Не помню почему меньше 1.5 Гб. Скорее всего была причина, а потом забыл исправить.

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

Базовый адрес для загрузки ДЛЛ устанавливается ядром. Он для всех приложений одинаков иначе ДЛЛ не сделать расшареными.

Мда... дилемма. Ладно давай сделаем пока 256 Мб под библиотеки.

Изменения в функции 40:
Бит 31 регистра ebx управляет фильтрацией событий мыши.
Бит 31 = 0 - окно всегда получает события от мыши.
Бит 31 = 1 - окно получает события мыши только в активном состоянии.

Планируется:
Бит 30 = 0 - окно получает события от мыши если курсор находится за пределами окна
Бит 30 = 1 - окно не получает события от мыши если курсор находится за пределами окна

Я восстановил код закомментированный в r. 2414. Этот код вводился еще в ревизиях 1466 и 1513. Без него приложения активно обрабатывающие мышь при перетаскивании окна или изменении размеров окна могут менять положение собственного курсора многократно. Как пример можно посмотреть на реакцию KFM и OpenDialog с этим кодом и без него. Если координаты курсора мыши попадают в "активную зону" приложения, то начинаются чудесатые чудеса. Это именно обработка предотвращающая некорректное поведение активного окна. Не нужно убирать этот код!

Mario
А теперь запусти плеер попробуй закрыть окно.
Если KFM неправильно мышь обрабатывает, чем другие программы виноваты ?