Войти
ФлеймФорумПрограммирование

Если бы вы писали WinAPI - как бы вы рассылали сообщения окнам? (22 стр)

Страницы: 121 22 23 2429 Следующая »
#315
13:02, 14 мая 2021

Вий
> Но это ведь чисто косметический апдейт, суть то не меняется.

Суть всегда будет в том чтобы вызвать окну реакцию на событие.
И сабж лишь про то как это сделать чтобы было получше, чем то что есть в WinAPI.


#316
13:32, 14 мая 2021

=A=L=X=
Ну вот косметически причесать и слать сообщения. В приложениях останется тот же свитч

#317
14:00, 14 мая 2021

Вий
> В приложениях останется тот же свитч
который мало кто увидит.

#318
(Правка: 14:10) 14:02, 14 мая 2021

Mirrel
Потому что мало кто пишет на винапи
Я вот писал раньше, но пару лет назад бросил

#319
14:10, 14 мая 2021

=A=L=X=
Еще можно предположить, что в давние времена, когда оперативы бил какой-нибудь жалкий Мб
было бы сильно жирно хранить для каждого окна таблицу на 100500 указателей.

#320
14:15, 14 мая 2021

Вий, есть не мало людей, кто уже много всего сделал на WinAPI. И даже больше, есть люди, которые работают (или работали) на чистом ассемблере с ним.
В сети очень не мало информации, но найти нужную довольно сложно, в этой помойке.

#321
14:15, 14 мая 2021

nes
> Еще можно предположить

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

#322
(Правка: 14:30) 14:30, 14 мая 2021

Mirrel
Ну конечно. Тысячи таких людей. Но миллионы других людей не работают с вин апи потому что первые тысячи делают для них обертки, движки и библиотеки

#323
14:33, 14 мая 2021

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

есть такое понятие как основа

#324
(Правка: 17:41) 17:41, 14 мая 2021

=A=L=X=
> Реальная задача про то как написать на Си-ABI подсистему GUI в Операционной
> Системе совместимой с максимумом языков програмирования?

тогда я снова могу сослаться на Gtk. Gtk под капотом это кресты!
но всё очень аккуратно обёрнуто в Си, чтобы на выходе было "максимум языков программирования".

Если я задолбал людей с Gtk, то могу рассказать ещё про Carbon
Для обработки сообщений, опять же необходимо регистрироваться InstallEventHandler
НО, вызывать "следующий" обработчик нужно обязательно и явно внутри своего CallNextEventHandler
Что есть потенциальные грабли. Но легче в управлении, чем gtk-шиний подход с "до стандартой обработки" или "после стандартной обработки"


ЗЫ: Carbon это Си-апи для МакОСи, которое существовало ещё до macOS (Mac OS X), в так MacOS Classic.
При появлении MacOSX Карбон и Кока (ныне здравствующая сосуществуют)

#325
(Правка: 19:02) 18:59, 14 мая 2021

Вий
> С вопросами владения все просто: владеть оконными сообщениями может только ОС.
> При отправлении сообщение копируется (при желании конечно можно позволить
> приложению получить буфер заранее и заполнить его, но это микрооптимизация),
> при получении читатель может читать из буфера до конца вызова обработчика. Если
> нужно больше - читатель волен делать копии
Пример такой орхетектуры я видел в QNX - не оконные, а микроядерные, но тоже сообщения, с начала до конца транзакции под контролем микроядра (и ещё там обработчик должен был записать ответ в буфер, но это второстепенные детали). И там от этого приключался занятный эффект: если обработчик по какой-то причине зависал во время обработки, то отправителя (естественно, заблокированного в ожидании ответа) нельзя было прибить никакими средствами, включая sigkill. Ну, то есть, формально можно, только фактический момент убийства откладывался до того момента, как обработчик соизволит-таки ответить, или хотя бы упасть. И это было вообще-то довольно-таки гнусно.

=A=L=X=
> Маршаллингу в COM посвящён огромный жирнейший кусок документации и он крайне
> важен, т.к. без него не работало бы OLE, а на OLE MS бросила лучшие умы нации.
Заметим, что OLE к сегодняшнему дню мертво.

#326
19:19, 14 мая 2021

Sbtrn. Devil
> отправителя (естественно, заблокированного в ожидании ответа) нельзя было
> прибить никакими средствами, включая sigkill

Это не является проблемой подхода, там намудрили в деталях реализации, причём возможно чего-то вообще другого. Ну потому что очевидно что убить процесс можно в любой момент, очереди сообщений от этого ни тепло ни холодно, процесс ей не владеет.

#327
(Правка: 23:58) 23:54, 14 мая 2021

Вий
> Потому что мало кто пишет на винапи
> Я вот писал раньше, но пару лет назад бросил
Не понял, допустим ты же все равно под винду пишешь? Так в чем разница? Взял другую обертку и че? Это же тоже самое winapi под капотом.

#328
0:00, 15 мая 2021

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

#329
(Правка: 0:20) 0:11, 15 мая 2021

На самом деле WinProc - это собирательный образ, по этому он плох. Приходиться пилить конвертеры под стандарт сообщения. Допустим вместо того чтобы ловить лишние сообщения, было бы достаточно просто проверять буфер клавиш. Конечно это было бы прямым прослушиванием для любой программы, но лучше подхода не будет.
=A=L=X=
> WndProc из WinAPI хренова тем что гигантский switch может образоваться без
> возможности сильных оптимизаций - поле кодов сообщений гигантское.
Оптимизируется оно процедурным деревом. Тобиш простой map с функциями. Или кейсы на диапазон, а потом выбирается конкретное - это быстро.

Страницы: 121 22 23 2429 Следующая »
ФлеймФорумПрограммирование