Serge
Я конечно уважаю твое мнение и заинтересованность, но давай вспомним как мы почти год назад обсуждали буфер обмена и где сейчас поезд?
Больной кстати по прежнему лежит и ждет - какую ногу ему отрежут...

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

Между тем мне очередной раз предлагается реализовать чьи-то идеи. Реализацию которых еще предстоит значительное время осмысливать - потому что это не крутилось в моей голове. А чужие мысли не так то просто уложить в свой поток рассуждений.

Учитывая что работаю я исключительно для своего удовольствия (Just for fun), то удовольствия от этого я не получу никакого. А значит моя заинтересованность стремится к нулю.

Я очень надеюсь - без обид, поскольку только честно выражаю свое мнение и стараюсь сделать это корректно, поскольку уже было много недопонимания между мной и отдельными участниками сообщества.

З.Ы. Если ты готов сам реализовать эти сервисы для ядра, то я могу ими воспользоваться, как в свое время воспользовался расшаренными областями - а их кстати и не намечалось, пока я не спросил у тебя об этой возможности.

Mario

Я предлагал сделать буфер обмена в ядре, потому что это самый простой и надёжный способ. Но другим хотелось расшареной памяти.

В данном сучае предлагается освободить ядро от необязательного для него кода. Причём это не требует переделки оконной системы.

Еще раз для понимания - если ты готов сделать эту работу для ядра, то я могу воспользоваться. В противном случае я буду делать по своему, либо как вариант при значительном недовольстве других - опять ничего не буду делать.

Mario

Легко. Только надо с API определиться.

Для доступа к фону есть ф15.6 и 15.7.

Для вывода картинки использовать ф.65 с модификацией. В старшей половине esi указывать флаги отрисовки или номер слота для проверки.

Для проверки принадлежности пикселя функция, возвращающая значение из WinMapAddress для данной точки.

EDIT.

Есть другой вариант.

calculatescreen заполняет карту WinMap значениями для фонового рисунка.
Если записать в esi не 1, а номер интересуещого нас слота, этот поток сможет рисовать на месте фоной картинки, что нам и требуется. Поток должен получать от ядра сообщения о необходимости перерисовать фон и сообщение об изменении фона. Для этого можно задействовать get_event, правда придётся работать в отдельном потоке (только отрисовка фона и обработка изменения фона. Никаких окон и пользовательского ввода).

Serge

Для доступа к фону есть ф15.6 и 15.7.

А как насчет того, что это будет жрать тем больше памяти, чем больше разрешение.
Например на современных мониторах вполне себе уже стоит разрешение 1920*1080? Это ведь 1920*1080*4=7,91 Мб. Ладно на современных компьютерах не жалко, но допустим на старом компьютере с объемом памяти в 8-12 Мб в текущем ядре можно отвести всего 4 Кб на фоновую картинку. А в новой системе получится 640*480 от 0,8 до 1,2 Мб (в зависимости от глубины цвета) не слишком ли большая жертва?
К тому же использование 15 функции не отменяет твоего-же тезиса о:

Существующий сейчас код выполяет ресемплинг картинки при каждой отрисовке, что не очень оптимально, особенно если работаешь в Боше.

А для вот этого

Для вывода картинки использовать ф.65 с модификацией. В старшей половине esi указывать флаги отрисовки или номер слота для проверки.

теперь еще и придется все программы перетрясти на предмет установки ESI полностью. Может стоит просто задействовать новый номер функции?

Для проверки принадлежности пикселя функция, возвращающая значение из WinMapAddress для данной точки.

И это тоже поместить в новую функцию.

Mario

Если модифицировать calculatescreen (см. выше) то
нет необходимости в изменении ф65, хотя такой вызов и не помешал бы. Да и перерасхода памяти не будет. Полный доступ, рисуй как хочу.

Итого получаются два новых вызова
set_background_thread() - делает текущий поток ответственным за отрисовку фоновой картинки.
Этот поток получает сообщения если надо перерисовать фоновую картинку.
get_thread_pos(x,y) - возвращает номер слота потока, которому принадлежит верхняя точка экрана с координатами x,y.

set_background_thread() - делает текущий поток ответственным за отрисовку фоновой картинки.

Т.е. просто переносится код ядра в приложение?

Этот поток получает сообщения если надо перерисовать фоновую картинку.

Как?

get_thread_pos(x,y) - возвращает номер слота потока, которому принадлежит верхняя точка экрана с координатами x,y.

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

1) Да, весь код отрисовки фоновой картинки.
2) Поток выполняет обычный оконный цикл и получает сообщения о перерисовке. Или более перспективный вариант с получением событий через 68.14. Потребуется некоторый допил ядра, зато можно сообщать об изменении фоновой картинки другим приложением.
3)Сейчас все приложения, те же потоки Icon, самостоятельно определяют факт клика и ничего, работают. Ядро здесь совсем не причём.

Еще раз проIMHUю, что менеджеру иконок - место в нулевом круге, а не в третьем.
Вынос его в юзерспейс прорубит еще одну дыру в системной защите.

Но если уж вы так решили, то надо по крайней мере

1) повысить его в звании до десктоп-менеджера, и

2) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого).

Иначе будет бардак.

art_zh wrote:) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого)

А если он упадет?

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

Sorcerer wrote:

art_zh wrote:) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого)

А если он упадет?

А если его сдуру закроют?

Или повесят второй (третий, десятый) ?

Может быть, не всем нужны иконки на рабочем столе.
Бороться с повторными запусками не так уж сложно. Проверка при запуске - а нет ли еще одного процесса с таким же именем? А для перезапуска использовать например параметр "--replace", как в *никсах. Сомневаюсь, что на это способен человек, не знающий, что именно он хочет получить.

Sorcerer

А если он упадет?

Не страшно - просто не будет перерисовываться фон.

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

Это пожалуй самое простое из задуманного.

Может быть, не всем нужны иконки на рабочем столе.

А кто нам мешает запускать процесс-сервер занимающийся работой с параметром отключающим загрузку иконок или вообще в INI файле прописать.

art_zh

Еще раз проIMHUю, что менеджеру иконок - место в нулевом круге, а не в третьем.
Вынос его в юзерспейс прорубит еще одну дыру в системной защите.

Но если уж вы так решили, то надо по крайней мере

1) повысить его в звании до десктоп-менеджера, и

2) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого).

Иначе будет бардак.

Фатального ничего нет, а то что ты предлагаешь требует значительной переделки ядра.
Если готов взяться за такую работу - то никто не запрещает, но чужие идеи желающих реализовывать нет.

А если его сдуру закроют?

Абсолютно ничего - просто сервис отрисовки фона не будет работать и на фоне будут артефакты от других ранее нарисованных элементов.

Или повесят второй (третий, десятый) ?

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