1. 32-битные ОС могут одному процессу дать адресное пространство не более 4х гигов. Другое дело что windows 1-2 гига занимает на маппинг системных данных. Сами же системы могут видеть больше, зависит действительно от системы и процессора.
В 32-битных настольных виндах захардкоден лимит 4 гига на всю ОС. Сделано якобы для повышения стабильности. Но палево в том, что разные версии серверных виндов видят разные объемы выше 4 гиг :)
Да причем тут священная корова… Вот мне например посты про убунту неинтересны, я ж не лезу туда писать что меня все задрали со своей убунтой. Хабру читает много людей, и пишут тоже, и никто не заставляет читать дальше заголовка.
Вот вопрос, зачем человеку, которому неинтересна статья читать так глубоко комменты? :)
Если где-то лежат грабли — рано, или поздно, кто-то на них наступит. Я ж не говорю что на С++ невозможно написать стабильное приложение, я говорю что в случае краша на сервере у нас последствия потенциально хуже. А согласно известному закону, или в приложении есть ошибки, или ошибкой было написание столь тривиального приложения :)
Кстати, на С тоже можно писать в объектном стиле и заворачивать всю работу с памятью в группы функций. Только функци будут сделаны в стиле ClassName_Function(ClassName *me), года два так писал без нормального дебаггера, и не крашилось ничего. Но это ведь не показатель, все зависит от цены потенциального краша :)
В случае серверов часто выгоднее пожертвовать быстродействием более низкоуровневого кода, чем безопасностью высокоуровневых песочниц. А удобная и отлаженная обёртка вокруг сокетов никак не гарантирует отсутствие ошибок работы с памятью в коде логики приложения.
И если на пользовательской машине использование С++ разумно — редкий краш native приложения от краша чего-то в виртуальной машине как правило отличается только внешним видом сообщения об ошибке, то у такого рода сервера шансов упасть сразу для всех больше в столько раз, сколько у него пользователей.
кстати все приложения для iPhoneOS содерджат скриншот первого экрана, который система любезно рисует перед запуском приложения. создавая иллюзтю мгновенного старта :)
Не проверял, но скорее всего можно повесить хук на создание окна и когда он вызовется (в контексте процесса создавшего окно) поставить AppId используя нативно апи. С вероятностью 99% это сработает, а значит такое софт скоро появится :)
дак есть же ) просто это можно дополнительно контролировать… пример — система состоящая из нескольких приложений, группирующая окна в одну пачку. или наоборот, одно приложение открывает кучу проектов и окна каждого проекта собирает в отдельную стопку.
часто ее не хотят использовать по умолчанию для обеспечения совместимости со следующими версиями оболочки…
к слову сказать — микрософтовцы как правило пытаются придерживаться совместимости со старым ПО и старыми версиями API, а причиной ломающегося софта в большинстве случаев является игнорирование всяких заметок вида «resersed for future use, must be NULL», или игнорирование вызова функций, без которых «и так работает». Бывают, конечно реальные несовместимости, но как правило разработчики «сломавшегося» приложения сами виноваты.
начнут, наконец, полномасштабно использовать кнопку «WIN» наравне со всеми
микрософт, кстати, не рекомендует использовать ее в шорткатах, клавиша считается зарезервированной для шорткатов windows shell, и ее функционал может быть расширен в следующих версиях. (впрочем я все кастомные шорткаты только на нее и вешаю)
2. Со времен появления PAE?
Прежде чем дальше минусовать, читать внимательно тут ©: en.wikipedia.org/wiki/Physical_Address_Extension#Microsoft_Windows :)
Вот вопрос, зачем человеку, которому неинтересна статья читать так глубоко комменты? :)
Кстати, на С тоже можно писать в объектном стиле и заворачивать всю работу с памятью в группы функций. Только функци будут сделаны в стиле ClassName_Function(ClassName *me), года два так писал без нормального дебаггера, и не крашилось ничего. Но это ведь не показатель, все зависит от цены потенциального краша :)
И если на пользовательской машине использование С++ разумно — редкий краш native приложения от краша чего-то в виртуальной машине как правило отличается только внешним видом сообщения об ошибке, то у такого рода сервера шансов упасть сразу для всех больше в столько раз, сколько у него пользователей.
к слову сказать — микрософтовцы как правило пытаются придерживаться совместимости со старым ПО и старыми версиями API, а причиной ломающегося софта в большинстве случаев является игнорирование всяких заметок вида «resersed for future use, must be NULL», или игнорирование вызова функций, без которых «и так работает». Бывают, конечно реальные несовместимости, но как правило разработчики «сломавшегося» приложения сами виноваты.
микрософт, кстати, не рекомендует использовать ее в шорткатах, клавиша считается зарезервированной для шорткатов windows shell, и ее функционал может быть расширен в следующих версиях. (впрочем я все кастомные шорткаты только на нее и вешаю)
А там это тихонечко сотрут :)