Окно - это не дёшево

Это перевод Windows are not cheap objects. Автор: Реймонд Чен.

Хотя Windows основана на, хм, окнах (windows), само окно не является таким уж дешёвым объектом. Даже более того: жёсткие ограничения памяти в системах 1985-го года диктуют различные решения в дизайне системы.

Давайте возьмём для примера дизайн элемента управления list box. В современном мире вы могли бы спроектировать list box как элемент управления, принимающий список дочерних окон, каждое из которых представляет одну запись в списке. List box с 20'000 элементами имел бы 20'000 дочерних окон.

Но это было бы совершенно смехотворно в 1985-м.

Вспомните, что Windows была построена для 16-ти битного процессора. Оконные описатели были 16-ти битными значениями и внутренне они были просто ближними указателями на 64-х килобайтную кучу (heap). Объект окна занимал 88 байт (я специально подсчитал), что означало, что вы могли впихнуть только около 700 окон, прежде, чем у вас закончится память. Более того, меню хранились в той же куче, так что реальный предел был намного меньше.

Даже если бы менеджер окон использовал большую кучу (что и делала Windows 95), 20'000 окон занимали бы более 1,5 Мб. Поскольку 8086 имел максимальное адресное пространство в 1 Мб, то даже если бы вы отдали каждый байт этой памяти под окна, вам всё равно бы не хватило памяти.

Более того, делая каждый элемент списка окном, вы делаете list box, который всегда будет иметь переменную высоту элементов, что означает нагрузку по управлению таким сложным объектом. Это противоречит двум основным принципам дизайна API: (1) простые вещи должны быть просты и (2) "платить-за-шоу", что означает, что если вы делаете простую вещь, то не должны платить за неё как за сложную.

Заполнение list box-а настоящими окнами существенно усложнило бы создание виртуального list box-а. С текущим дизайном вы можете сказать: "вот миллион элементов", не создавая их в действительности (это также причина, почему оконное пространство делится на "клиентскую" и "не-клиентскую" части вместо того, чтобы создавать не-клиентскую часть из маленьких дочерних окон).

Для поддержания обратной совместимости с 16-ти битными программами (которые всё ещё запускаются на Windows XP, благодаря слою WOW; прим. пер.: некоторые из них работают даже в Windows 7 без XP Mode - правда, только на 32-х разрядной системе), у вас не может быть больше 65'536 окон в системе, потому что иначе 16-ти битные программы не смогут получить доступ к некоторым окнам (как только вы воздали 65'537-е окно, у вас получится два окна с одинаковым 16-ти битным описателем, благодаря принципу Дирихле).

(и да, взаимодействие между 32-х и 16-ти разрядными приложениями важно даже сегодня)

С ограничением в 65'536 оконных описателей, ваша папка с 100'000 файлов в ней будет иметь серьёзные проблемы.

Стоимость окна росла со временем, потому что в менеджер окон добавлялись новые возможности. Сегодня это даже объемнее, чем те стройные 88 байт прошлых лет. Это в ваших интересах, чтобы не создавать больше окон, чем необходимо.

Если дизайн вашего приложения создаёт сотни окон для под-объектов, то вам стоит рассмотреть вариант перехода на без-оконную модель приложения, как это делает Internet Explorer, Word, list box, treeview, listview и даже наша программа-пример. Переключившись на безоконную модель, вы сбросите с системы вес полноценного описателя окна, со всем дополнительным багажом, который к нему прилагается. Поскольку описатели окон видимы всем процессам, то имеются значительные накладные расходы по управлению списком окон. С другой стороны, если вы пойдёте по пути не-оконных элементов, то единственный, кто будет иметь к ним доступ - это вы. Вам не нужно заботится о маршаллинге, меж-процессной синхронизации, переводах Unicode/ANSI, внешнем саб-классинге, хуках и т.д.... И вы можете использовать сколь угодно много памяти для управления своими не-оконными данными, потому что ваши не-оконные элементы управления никак не видимы и не оказывают влияния в других процессах. Тот факт, что оконные описатели доступны другим процессам, вводит практическое ограничение на их максимальное количество.

Я думаю, что WinFX (при.пер.: .NET Framework 3.0) использует модель "всё, что на экране - элемент". В моём понимании они уже написали библиотеку не-оконных элементов, так что вам не нужно это делать (я не уверен насчёт этого, поскольку не являюсь специалистом в .NET).