Board.KolibriOS.org

Вопрос первый:
Как отключить ресайзинг окна, если применяется режим со скином, если это вообще возможно?

Вопрос второй:
Когда я создаю ещё один поток, а потом в основном потоке определяю окно (стандартным способом), это окно не активизируется автоматически. В однопоточных (если можно так выразиться) процессах главное окно само активизируется, а в случае 2х потоков - нет. Как можно программно активизировать своё собственное окно? Я вижу, что есть сервис #18-3, но он требует указать слот потока (-1 тут, вроде бы, не канает). Тогда откуда мне взять слот? Через #9 я могу узнать, вроде бы, только TID, но не слот.

Пока что только эти 2 момента тормозят разработку, хотя есть ещё вопросы, но они пока не критичны.

Кстати, за последний год багов в дистрибутиве заметно поубавилось. Поздравляю! :)

Вопрос первый - откровенный боян.
Решение: Y = 4

Решение: Y = 4

Если речь идёт о параметре edx в функции #0, которая определяет окно, то данный способ не пашет: система заметно подвисает, а окно вообще не показывается. Использую последний официальный релиз (не SVN). А в документации этот способ вообще не описан.

Используй SVN. Там и в документации есть соответствующие заметки. Необходимые для работы "Y=4" изменения были внесены уже после выхода последнего релиза.

Ладно, пока я допишу набор примеров использования uFMOD для Колибри, возможно, уже выйдет следующий официальный релиз. Поэтому первый вопрос можно считать закрытым.

Так как быть с активизацией окна в 2хпоточном процессе?

И ещё вопрос:
Если я выделяю память через #68-12, могу ли я расчитывать, что менеджер кучи вернёт состояние ошибки в случае, если памяти не хватает? Короче, вернётся 0 или как? Этот момент в документации не освещён...

Quantum

68.12 не выделяет физическую память немедленно, а только резервирует диапазон адресов. Если невозможно разместить блок заданного размера функция вернёт 0. Физическая память выделяется при первом обращении к резервированной сранице. Если свободные страницы закончатся программа завершится со страничной ошибкой.

Активизация окна делается действительно через 18.3, а слот потока можно узнать по TID циклом вида "for (i=2;i<[возвращаемое значение в функции 9 в eax];i++) {fn9(i,&buf);if (buf.TID == TID) break;}"

Serge wrote:Если невозможно разместить блок заданного размера функция вернёт 0.

Т.е. куча не проверяет есть ли свободная память в наличии или нет, так? Получается, что куча может зарезервировать мне, допустим, парочку страниц, а на деле окажется, что свободной физической памяти нету больше. Тогда моё приложение вылетит при первом обращении к этим страницам. Я правильно понимаю? Если да, то как тогда можно выделить память безопасно? Кстати, я выделяю память блоками, кратными 2м страницам и не использую реаллокацию и т.д. Видел в документации системную функцию похожую на *никсовый brk(), но мне кажется, что этот способ тоже не выделяет память "безопасно".

Serge wrote:Если свободные страницы закончатся программа завершится со страничной ошибкой.

Именно это меня и беспокоит.

diamond wrote:Активизация окна делается действительно через 18.3, а слот потока можно узнать по TID циклом вида "for (i=2;i<[возвращаемое значение в функции 9 в eax];i++) {fn9(i,&buf);if (buf.TID == TID) break;}"

Ясно. Перспектива добавления такого количества кода в простенький hello world не сильно радует В идеале было бы замечательно, если бы автоматическая активизация работала и в этом случае. Можно надеяться на исправление?

Можно надеяться на исправление?

Можно, думаю даже, скоро попробую исправить.

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

Больше интересует ответ на вопрос о куче...

2 Quantum

В общем, исправление автоактивизации в данный момент для меня уже не критично.

Поздно...

Т.е. куча не проверяет есть ли свободная память в наличии или нет, так? Получается, что куча может зарезервировать мне, допустим, парочку страниц, а на деле окажется, что свободной физической памяти нету больше. Тогда моё приложение вылетит при первом обращении к этим страницам. Я правильно понимаю? Если да, то как тогда можно выделить память безопасно?

Можно проверять количество свободной физической памяти в системе через функцию 18.16.

diamond

Можно проверять количество свободной физической памяти в системе через функцию 18.16.

Мммм... Ыыыы... Ну, в принципе, какой ни есть вариант...

А при страничной ошибке нельзя просто поймать исключение, чтоб корректно завершиться с сообщением типа "not enough memory"? Или ещё лучше: чтоб менеджер кучи поддерживал режим, в котором он при резервировании страниц сразу бы их и выделял и возвращал бы ошибку, если в этот момент нет достаточного количества физических страниц. Мне, например, нужно использовать динамическую память буквально сразу после выделения, т.е. пользы от резервирования в этом случае нет. Ну, а о перспективе свопа пока лучше не говорить?

Quantum

А сколько памяти тебе надо ? Несколько сот килобайт найдётся всегда. А там где их нет нет и звука.

Есть простое решение - делать статический буфер. Если памяти нехватит программа не загрузится. В остальном никакой разницы.

Я хотел замораживать приложение при нехватке памяти и выводить окно с предложением завершить некоторые приложения или закрыть программу, но пока всё это отложено из-за нехзватки времени.

Serge
Это зависит от ХМ-файла. Крайне редко бывает нужно более 1Мб, но есть такие мега-ХМы... Обычно потребляется 8-16Кб. Поэтому я и выделяю память в движке кусками по 2 страницы.

Quantum

Тогда есть смысл сразу выделить один-два Мб. Главное не обращаться к тем страницам которые пока не нужны. Обнулять буфер не надо, ядро выделяет чистые страницы.