Новая модель ядра

Kernel architecture questions
  • Но почему из 2 Гб всего лишь 900 Мб? Не логичней ли под библиотеки 0,5 Гб отдать, под выделяемую память 1,5 Гб. Начнешь так большой документ открывать, а память то нема!
  • Mario
    Я с тобой согласен, это код надо переделывать.
    Кстати куча ограничена 1.5Гб с очень старых времён.

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

    И да, 640 Кб хватит всем.
  • Это сказал Билли, а не я. К тому же 640 Кб до сих пор для многих наших приложений хватает. Вот для данных не хватает иногда.
  • Это относится к принципам проектирования. 640 кб впишите нужное значение хватит всем. Вики пишет что Билли этого не говорил.
  • Ну не знаю кто там как проектирует. Однако если изначально задумывалось отдать приложению 2 Гб, а потом ВНЕЗАПНО задумалось 900 Мб, то второе решение неизвестно чем обосновано. Чужие тараканы, он такие... чужие что ли. :mrgreen:
  • Я поправлю код, вопрос сколько оставить ? 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 неправильно мышь обрабатывает, чем другие программы виноваты ?
  • Who is online

    Users browsing this forum: No registered users and 3 guests