Это перевод Larry vs. Crap. Автор: Ларри Остерман.
Я действительно получил больше удовольствия, чем я думал, делая эти посты - я честно не думал, что у меня будет столько содержания по этому вопросу. Поскольку я заканчиваю эту серию, я хочу поговорить о том, что я лично думаю о апплетах.
...when altering one's mind becomes as easy as programming a computer, what does it mean to be human?..
четверг, 26 февраля 2009 г.
Лучшие методы для апплетов
Это перевод Applet best practices. Автор: Ларри Остерман.
Первое и самое главное, что нужно сделать человеку, желающему написать апплет, - это остановиться и подумать, а нужен ли им апплет вообще?
Конечно же, ответ может быть и "да", но проблема в том, что намного чаще ответ будет "нет".
Первое и самое главное, что нужно сделать человеку, желающему написать апплет, - это остановиться и подумать, а нужен ли им апплет вообще?
Конечно же, ответ может быть и "да", но проблема в том, что намного чаще ответ будет "нет".
Минимизация ущерба от апплетов - системные службы
Это перевод Applet mitigations - services. Автор: Ларри Остерман.
Как старший разработчик в Microsoft, вы часто будете участвовать в работе ряда V-команд. Одна из V-команд, в которой я состою, ответственна за утверждение новых служб в Windows. Как я уже говорил ранее, я очень требователен к вещам, которые работают у меня на машине, а системные службы относятся к вещам, которые особенно меня волнуют.
Как старший разработчик в Microsoft, вы часто будете участвовать в работе ряда V-команд. Одна из V-команд, в которой я состою, ответственна за утверждение новых служб в Windows. Как я уже говорил ранее, я очень требователен к вещам, которые работают у меня на машине, а системные службы относятся к вещам, которые особенно меня волнуют.
суббота, 21 февраля 2009 г.
Минимизация ущерба от апплетов - иконки в трее
Это перевод Applet mitigations - notification area handlers. Автор: Ларри Остерман.
Сначала (как всегда), пересмотрите своё решение по поводу того, нужен ли вам вообще обработчик области уведомлений. Я серьёзно: подумайте, подходяще ли будет для вашего приложения иметь иконку в трее. Вы действительно верите, что он обеспечивает достаточную функциональность, чтобы оправдать трату такого ценного ресурса, как свободное место в трее? Правда?
Сначала (как всегда), пересмотрите своё решение по поводу того, нужен ли вам вообще обработчик области уведомлений. Я серьёзно: подумайте, подходяще ли будет для вашего приложения иметь иконку в трее. Вы действительно верите, что он обеспечивает достаточную функциональность, чтобы оправдать трату такого ценного ресурса, как свободное место в трее? Правда?
четверг, 19 февраля 2009 г.
Минимизация ущерба от апплетов - обновлялки
Это перевод Applet mitigations - updaters. Автор: Ларри Остерман.
Так как вы можете сделать обновлялку не такой страшной?
Для начала, как я уже советовал для всех апплетов: вообще не заводить такое. Например, каждое приложение Collectorz.Com проверяет наличие новой версии при своём запуске. Таким образом функциональность обновлялки внедрена в саму программу и снимает необходимость волноваться о внешней обновлялке.
Если ваше приложение является плагином (ну к примеру Flash, Quicktime, Java или драйвер (любого рода)), тогда у вас нет обычного приложения, которому можно было бы прицепить свою обновлялку. В этом случае, что бы вы ни делали - не заводите отдельный процесс, чья задача только проверять обновляения раз в месяц. Вместо этого используйте встроенный в Windows планировщик заданий (task scheduler) для задания расписания проверок на обновления. Планировщик заданий - это очень гибкий механизм для выполнения периодических действий. Даже используя интерфейсы Task Scheduler 1.0 (которые были доступны в Windows ещё во времена Windows ME), вы можете задать тригеры, которые будут запускать задачу ежедневно, раз в неделю, ежемесячно, раз в месяц в определённый день недели, параметры входа, простоя и т.п. Для Vista список тригеров расширился, включая теперь в себя тригеры на системные события, группы тригеров и т.п.
Огромным плюсом планировщика является возможность указать контекст пользователя, из под которого будет выполняться ваша задача - она может запускаться из-под консольного пользователя, системного контекста, контекста интерактивного пользователя, запускаться только при наличии вошедшего в систему пользователя и т.п.
Использование планировщика заданий означает, что ваша обновлялка сможет работать, но при этом не занимать ресурсов при обычной работе.
Как только обновлялка находит обновление, вам нужно его скачать. В действительности у вас есть два варианта. Либо вы предполагаете, что пользователю нужно ваше обновление и скачиваете его заранее, либо вы сначала уведомляете пользователя о наличии обновления, а затем уже скачиваете его. В любом случае в Windows есть полезная возможность, называемая "BITS" (Wiki), которая позволяет вам скачать данные с web без прерывания пользователя - в частности, служба BITS осведомлена о трафике, который генерируется интерактивным пользователем, и снижает свою активность, если она видит, что пользователь активно использует сеть. Она также поддерживает докачку в случае обрывов связи. Качалка Windows Update построена поверх BITS, но я не в курсе, есть ли сторонние программы, использующие BITS (*) (весьма жаль, потому что BITS - действительно крутая фишка). BITS доступна начиная как минимум с Windows XP и позже, так что это не очередная "ещё одна возможность, доступная только в Vista".
Также, чтобы вы ни делали - не требуйте элевации для вашей обновлялки! Я не могу себе даже представить, зачем обновлялке может потребоваться элевация (**) - это будет только раздражать пользователя, который начнёт жаловаться на эти постоянно всплывающие подтверждения запуска.
Далее: минимизация ущерба от обработчиков иконок в системной области уведомлений.
Примечания переводчика:
(*) См. List of non-Microsoft applications that use BITS.
(**) Имеется в виду при плановом запуске. Разумеется, если приложение обнаружит новый апдейт - ему потребуется элевация для изменения файлов в Program Files.
Так как вы можете сделать обновлялку не такой страшной?
Для начала, как я уже советовал для всех апплетов: вообще не заводить такое. Например, каждое приложение Collectorz.Com проверяет наличие новой версии при своём запуске. Таким образом функциональность обновлялки внедрена в саму программу и снимает необходимость волноваться о внешней обновлялке.
Если ваше приложение является плагином (ну к примеру Flash, Quicktime, Java или драйвер (любого рода)), тогда у вас нет обычного приложения, которому можно было бы прицепить свою обновлялку. В этом случае, что бы вы ни делали - не заводите отдельный процесс, чья задача только проверять обновляения раз в месяц. Вместо этого используйте встроенный в Windows планировщик заданий (task scheduler) для задания расписания проверок на обновления. Планировщик заданий - это очень гибкий механизм для выполнения периодических действий. Даже используя интерфейсы Task Scheduler 1.0 (которые были доступны в Windows ещё во времена Windows ME), вы можете задать тригеры, которые будут запускать задачу ежедневно, раз в неделю, ежемесячно, раз в месяц в определённый день недели, параметры входа, простоя и т.п. Для Vista список тригеров расширился, включая теперь в себя тригеры на системные события, группы тригеров и т.п.
Огромным плюсом планировщика является возможность указать контекст пользователя, из под которого будет выполняться ваша задача - она может запускаться из-под консольного пользователя, системного контекста, контекста интерактивного пользователя, запускаться только при наличии вошедшего в систему пользователя и т.п.
Использование планировщика заданий означает, что ваша обновлялка сможет работать, но при этом не занимать ресурсов при обычной работе.
Как только обновлялка находит обновление, вам нужно его скачать. В действительности у вас есть два варианта. Либо вы предполагаете, что пользователю нужно ваше обновление и скачиваете его заранее, либо вы сначала уведомляете пользователя о наличии обновления, а затем уже скачиваете его. В любом случае в Windows есть полезная возможность, называемая "BITS" (Wiki), которая позволяет вам скачать данные с web без прерывания пользователя - в частности, служба BITS осведомлена о трафике, который генерируется интерактивным пользователем, и снижает свою активность, если она видит, что пользователь активно использует сеть. Она также поддерживает докачку в случае обрывов связи. Качалка Windows Update построена поверх BITS, но я не в курсе, есть ли сторонние программы, использующие BITS (*) (весьма жаль, потому что BITS - действительно крутая фишка). BITS доступна начиная как минимум с Windows XP и позже, так что это не очередная "ещё одна возможность, доступная только в Vista".
Также, чтобы вы ни делали - не требуйте элевации для вашей обновлялки! Я не могу себе даже представить, зачем обновлялке может потребоваться элевация (**) - это будет только раздражать пользователя, который начнёт жаловаться на эти постоянно всплывающие подтверждения запуска.
Далее: минимизация ущерба от обработчиков иконок в системной области уведомлений.
Примечания переводчика:
(*) См. List of non-Microsoft applications that use BITS.
(**) Имеется в виду при плановом запуске. Разумеется, если приложение обнаружит новый апдейт - ему потребуется элевация для изменения файлов в Program Files.
Минимизация ущерба от апплетов
Это перевод Applet mitigations. Автор: Ларри Остерман.
Как я упоминал ранее, апплеты могут стать чумой вашей машины. Самое противное, что при этом ведь возможно писать апплеты так, чтобы они не были столь ужасны. И большинство таких техник это просто применение здравого смысла - в них нет совершенно ничего сложного.
Как и в предыдущих постах серии, некоторые из этих способов применимы к любым типам апплетов (и приложениям тоже), а другие являются особенными для конкретного типа.
Давайте начнём с общих способов...
Для апплетов, которые работают постоянно:
Вам ДЕЙСТВИТЕЛЬНО необходимо, чтобы ваш апплет работал всё время? Лучшим апплетом является такой, который не запускается вообще. Нельзя ли переместить функциональность апплета в ваше приложение, которое запускает пользователь? Меню Пуск подсвечивает недавно установленные программы, так что ваше приложение будет хорошо заметно. В худшем случае есть и другие механизмы, чтобы показать вашу программу пользователям (например: рабочий стол (хотя у него тоже есть свои особенности)).
Теперь, когда вы решили, что вам нужен постоянно работающий апплет - пересмотрите это решение. Я серьёзно! Да, я знаю, что я только что уже просил вас подумать об этом. Стив Балмер сказал, что когда-нибудь в 2008, целый миллиард людей будет использовать хоть одну версию Windows - а это КУЧА народу. Если ваш продукт станет успешным - весьма вероятно, что вы продадите его парочке миллионов из них - вы действительно полагаете, что ваш апплет несёт на себе такую полезную функциональность, что будет настолько нужен всем и каждому из этих нескольких миллионов, что вы можете швырнуть его им в лицо? Правда?
Если вы всё же решили, что вам ДЕЙСТВИТЕЛЬНО нужно держать апплет работающим - убедитесь, что у пользователя есть способ его отключить. Нет ничего более раздражающего, чем осознавать, что программа, прилагающаяся к какой-то железяке, которую я используя раз в несколько месяцев, работает постоянно на моей машине.
Если вы собрались писать апплет для того, чтобы пользователь узнал о какой-то новой классной возможности вашей программы, то почему бы вам не использовать ключ RunOnce и сказать пользователю, где он может всё это узнать, затем заткнуться и никогда больше не возникать?
Для всех апплетов (и всех приложений, которые работают постоянно):
Подумайте о том, как уменьшить влияние апплета на систему. Уменьшайте число загружаемых DLL, где это только возможно. Каждая DLL, которую вы загружаете, тратит минимум 4 частных страницы (private page) (16 Кб на x86) и требует от 500К до 1М процессорных циклов для загрузки. Чем меньше у вас DLL - тем лучше. Если вы сможете использовать только kernel32.dll и библиотеку run-time поддержки языка - это хорошо. Рассмотрите возможность отложенной загрузки тех DLL, которые вы редко используете.
Уменьшите размер стека для всех потоков в вашем апплете - по-умолчанию потоки Windows получают по 1 Мб выделенной памяти и 10 Кб резерва (которые на самом деле равны 12 Кб из-за округления на размер страницы). Это означает, что каждый поток гарантировано жрёт как минимум размер своего стека в виртуальной памяти (есть и хорошая новость: поскольку это виртуальная память - то обычно это просто место, зарезервированное в файле подкачки, а не физическая память).
Уменьшайте число процессов, которые требует ваш апплет. Очень редко есть стоящая причина для использования более чем одного процесса. Единственное, что мне сейчас приходит в голову - это разделение функциональности между высоко и низко-привилегированным кодом. Пример этого можно увидеть, например, в Windows Vista, где аудио-стек работает в двух раздельных процессах - службе AudioSrv и службе AudioEndpointBuilder. Это потому, что лишь малая часть звукового движка требует привилегий класса LocalSystem, в то время как большая часть аудио-стека работает отлично с привилегиями простой LocalService. Поэтому служба AudioEndpointBuilder содержит высоко-привилегированный код, а сервис AudioSrv - всё остальное. Если вы думаете, что вам нужен второй процесс для увеличения надёжности (вы запускаете код во внешнем процессе на случай, если он упадёт), то Windows Vista предоставляет вам ещё одну классную возможность под названием "restart manager". Restart manager позволяет ОС перезапускать ваше приложение, если оно вылетает, снижая необходимость для запуска второго процесса.
Не забывайте, что Windows - это многопользовательская система. Некоторое из пользователей одной машины могут не хотеть ваш апплет, а другие - хотеть. Так что убедитесь, что настройка для включения/выключения апплета является пользовательской (per-user). Очень сильно раздражает, когда вы щёлкаете правой кнопкой мыши по иконке в трее и видите, что пункт "выключить эту хрень" не работает, потому что вы работаете из под обычного пользователя (что является обычной ситуацией в Vista). Всякий раз, когда я это вижу, я понимаю, что автор программы не рассматривал (и не тестировал) работу своей программы в случае обыкновенного пользователя.
Если вы можете нацелиться только на Vista, расмотрите вариант понижения приоритетов потоков и ввода-вывода своих апплетов. Если ваш апплет выполняет обработку, не связанную явно с действиями пользователя - используйте новую опцию PROCESS_MODE_BACKGROUND_BEGIN для функции SetPriorityClass, чтобы указать системе, что ваш процесс нужно рассматривать как вспомогательный фоновый процесс - таким способом ваш апплет не отнимет ресурсы у задач пользователя. Вы также можете использовать новый метод FileIoPriorityHintInfo у функции SetFileInformationByHandle для указания ОС низкого приоритета для вашего ввода-вывода.
Далее: минимизация ущерба от обновлялок.
Как я упоминал ранее, апплеты могут стать чумой вашей машины. Самое противное, что при этом ведь возможно писать апплеты так, чтобы они не были столь ужасны. И большинство таких техник это просто применение здравого смысла - в них нет совершенно ничего сложного.
Как и в предыдущих постах серии, некоторые из этих способов применимы к любым типам апплетов (и приложениям тоже), а другие являются особенными для конкретного типа.
Давайте начнём с общих способов...
Для апплетов, которые работают постоянно:
Вам ДЕЙСТВИТЕЛЬНО необходимо, чтобы ваш апплет работал всё время? Лучшим апплетом является такой, который не запускается вообще. Нельзя ли переместить функциональность апплета в ваше приложение, которое запускает пользователь? Меню Пуск подсвечивает недавно установленные программы, так что ваше приложение будет хорошо заметно. В худшем случае есть и другие механизмы, чтобы показать вашу программу пользователям (например: рабочий стол (хотя у него тоже есть свои особенности)).
Теперь, когда вы решили, что вам нужен постоянно работающий апплет - пересмотрите это решение. Я серьёзно! Да, я знаю, что я только что уже просил вас подумать об этом. Стив Балмер сказал, что когда-нибудь в 2008, целый миллиард людей будет использовать хоть одну версию Windows - а это КУЧА народу. Если ваш продукт станет успешным - весьма вероятно, что вы продадите его парочке миллионов из них - вы действительно полагаете, что ваш апплет несёт на себе такую полезную функциональность, что будет настолько нужен всем и каждому из этих нескольких миллионов, что вы можете швырнуть его им в лицо? Правда?
Если вы всё же решили, что вам ДЕЙСТВИТЕЛЬНО нужно держать апплет работающим - убедитесь, что у пользователя есть способ его отключить. Нет ничего более раздражающего, чем осознавать, что программа, прилагающаяся к какой-то железяке, которую я используя раз в несколько месяцев, работает постоянно на моей машине.
Если вы собрались писать апплет для того, чтобы пользователь узнал о какой-то новой классной возможности вашей программы, то почему бы вам не использовать ключ RunOnce и сказать пользователю, где он может всё это узнать, затем заткнуться и никогда больше не возникать?
Для всех апплетов (и всех приложений, которые работают постоянно):
Подумайте о том, как уменьшить влияние апплета на систему. Уменьшайте число загружаемых DLL, где это только возможно. Каждая DLL, которую вы загружаете, тратит минимум 4 частных страницы (private page) (16 Кб на x86) и требует от 500К до 1М процессорных циклов для загрузки. Чем меньше у вас DLL - тем лучше. Если вы сможете использовать только kernel32.dll и библиотеку run-time поддержки языка - это хорошо. Рассмотрите возможность отложенной загрузки тех DLL, которые вы редко используете.
Уменьшите размер стека для всех потоков в вашем апплете - по-умолчанию потоки Windows получают по 1 Мб выделенной памяти и 10 Кб резерва (которые на самом деле равны 12 Кб из-за округления на размер страницы). Это означает, что каждый поток гарантировано жрёт как минимум размер своего стека в виртуальной памяти (есть и хорошая новость: поскольку это виртуальная память - то обычно это просто место, зарезервированное в файле подкачки, а не физическая память).
Уменьшайте число процессов, которые требует ваш апплет. Очень редко есть стоящая причина для использования более чем одного процесса. Единственное, что мне сейчас приходит в голову - это разделение функциональности между высоко и низко-привилегированным кодом. Пример этого можно увидеть, например, в Windows Vista, где аудио-стек работает в двух раздельных процессах - службе AudioSrv и службе AudioEndpointBuilder. Это потому, что лишь малая часть звукового движка требует привилегий класса LocalSystem, в то время как большая часть аудио-стека работает отлично с привилегиями простой LocalService. Поэтому служба AudioEndpointBuilder содержит высоко-привилегированный код, а сервис AudioSrv - всё остальное. Если вы думаете, что вам нужен второй процесс для увеличения надёжности (вы запускаете код во внешнем процессе на случай, если он упадёт), то Windows Vista предоставляет вам ещё одну классную возможность под названием "restart manager". Restart manager позволяет ОС перезапускать ваше приложение, если оно вылетает, снижая необходимость для запуска второго процесса.
Не забывайте, что Windows - это многопользовательская система. Некоторое из пользователей одной машины могут не хотеть ваш апплет, а другие - хотеть. Так что убедитесь, что настройка для включения/выключения апплета является пользовательской (per-user). Очень сильно раздражает, когда вы щёлкаете правой кнопкой мыши по иконке в трее и видите, что пункт "выключить эту хрень" не работает, потому что вы работаете из под обычного пользователя (что является обычной ситуацией в Vista). Всякий раз, когда я это вижу, я понимаю, что автор программы не рассматривал (и не тестировал) работу своей программы в случае обыкновенного пользователя.
Если вы можете нацелиться только на Vista, расмотрите вариант понижения приоритетов потоков и ввода-вывода своих апплетов. Если ваш апплет выполняет обработку, не связанную явно с действиями пользователя - используйте новую опцию PROCESS_MODE_BACKGROUND_BEGIN для функции SetPriorityClass, чтобы указать системе, что ваш процесс нужно рассматривать как вспомогательный фоновый процесс - таким способом ваш апплет не отнимет ресурсы у задач пользователя. Вы также можете использовать новый метод FileIoPriorityHintInfo у функции SetFileInformationByHandle для указания ОС низкого приоритета для вашего ввода-вывода.
Далее: минимизация ущерба от обновлялок.
воскресенье, 15 февраля 2009 г.
Так чем же плохи апплеты?
Это перевод So why are applets so bad, anyway? Автор: Ларри Остерман.
А на это есть простой ответ. И я дал его в самом первом посте этой серии: "это мой компьютер, козёл". Простой ответ заключается в том, что апплеты тратят ваши ресурсы вместо того, чтобы эти ресурсы использовались вами.
Как абсолютный минимум, каждый процесс апплета занимает процесс (да ты что, кто-бы мог подумать! - да, Ларри, это было весьма глупое заявление). Но при этом нужно не забывать, что каждый процесс в Windows тратит значительное количество системных ресурсов - вы можете видеть это в Диспетчере Задач Vista.
Нас интересуют три колонки (подряд перечислены имя колонки в оригинальном посте, в русской Виста, в русской XP и в Process Explorer):
2 - это количество памяти, зарезервированной для процесса (поэтому это число может быть невероятно большим). 1 - это количество физической памяти отданной процессу, а 3 - это часть 1, не занятая DLL-ми.
Примечание переводчика: видимо, Ларри перепутал 2 с 4 (а может быть это я неверно перевёл его слова). Именно колонка 4 показывает общую виртуальную память процесса (т.е. занятое адресное пространство процесса: выделенную + зарезервированную память). Колонка 2 показывает именно выделенную память - это та часть 4, для которой была действительно выделена какая-то память (не важно, где она находится - в RAM или в файле подкачки). Впрочем, в этих колонках немудрено запутаться (вы только посмотрите на разнобой названий для 2! А ведь я ещё не приводил названий колонок в английском Task Manager-е). Кстати, колонка 3 показывает ту часть колонки 2, которая находится в оперативной памяти. Колонка 1 показывает всю оперативную память, занимаемую процессом - но при этом часть этой же памяти разделяется несколькими процессами (ах, как же любят начинающие программисты искать утечки ресурсов по этому значению! А всё потому, что эта колонка единственная видимая по-умолчанию в Диспетчере Задач). Для желающий поглубже разобраться во всей этой мешанине я рекомендую серию Марка Руссиновича: часть 1, часть 2.
На моей машине я взял два запущенных апплета, у них оказалось:
FlashUtil9d.exe занимает 4.5 Мб по колонке 1, 1.3 Мб по колонке 2 и 760 Кб по колонке 3.
FwcMgmt.exe (файрвольный клиент ISA) занимает 4 Мб по колонке 1, 1.6 Мб по колонке 2 и 300 Кб по колонке 3.
Эти 700 + 300 Кб - это та настоящая, физическая память, которая активно используется процессом (иначе она оказалась бы выгруженной на диск). Это и есть ненужная нагрузка на память, возникающая из-за запуска апплета. При нескольких запущенных апплетах это число начинает БЫСТРО расти. На современных мощных машинах это не проблема, но для машин с меньшим объёмом памяти это может быть критично.
Примечание переводчика: у меня сейчас на машине крутится один мусорный процесс, который добавляет 3.5 Мб (по колонке 3).
В моём предыдущем посте я разделил все апплеты по 4-м категориям (обновлялки, обработчики области уведомлений, вспмогательные процессы и службы). В дополнение к общим проблемам, указанным выше, каждая категория имеет индивидуальные проблемы.
Обновлялки часто работают всё время, несмотря на то, что они делают свою работу только раз в день (или даже раз в месяц). Это означает, что они всё время тратят ресурсы зря. А самое худшее, что, например, на моей домашней машине у меня находится обновлялка, которая требует элевации с помощью манифеста (что означает, что у меня всплывает диалог о повышении прав каждый раз, когда она запускается).
Обработчики области уведомлений также работают всё время, что ещё хуже - они засоряют область уведомлений бесполезными иконками. Чем больше иконок в области уведомления - тем менее полезной она становится. Вообще-то именно это стало причиной для появления "большой четвёрки" в Vista (*) - люди часто жаловались на то, что иконки от программ сторонних производителей мешают находить нужные иконки. В дополнение к этому, обработчики уведомлению любят показывать всякие балуны, отвлекая пользователя. А также, поскольку все они запускаются при старте системы, то они замедляют загрузку.
Вспомогательные процессы не имеют каких-либо индивидуальных проблем - они просто потребляют ресурсы при работе.
Службы одновременно и хороши и плохи. Каждая служба Windows имеет тип запуска, определяющий, что система должна делать с ней при старте. Это свойство имеет три значимых для служб значения: AutoStart, DemandStart и Disabled. Когда служба помечена как AutoStart, она запускается автоматически при каждом запуске системы. Кроме того, поскольку службы работают в высоко-привилегированных учётных записях, их разработчикам нужно быть очень внимательными, чтобы не привнести в систему дыр безопасности. До Vista, высоко-привилегированные службы были не прочь показать пользовательский интерфейс на рабочем столе пользователя - эта практика настолько опасна, что категория связанных с нею угроз получила своё собственное название: "shatter attacks". В Vista были сделаны изменения для предотвращения классических shatter-атак для всех последующих версий ОС, так что, к счастью, эта угроза осталась в прошлом.
Завтра: как вы можете минимизировать ущерб от апплетов?
Примечания переводчика:
(*) "Большая четвёрка" (звук, сеть, батарея ноутбука и часы) в Vista вынесена на отдельную область справа от обычного системного трея, поэтому её иконки всегда чётко отделимы от остальных.
А на это есть простой ответ. И я дал его в самом первом посте этой серии: "это мой компьютер, козёл". Простой ответ заключается в том, что апплеты тратят ваши ресурсы вместо того, чтобы эти ресурсы использовались вами.
Как абсолютный минимум, каждый процесс апплета занимает процесс (да ты что, кто-бы мог подумать! - да, Ларри, это было весьма глупое заявление). Но при этом нужно не забывать, что каждый процесс в Windows тратит значительное количество системных ресурсов - вы можете видеть это в Диспетчере Задач Vista.
Нас интересуют три колонки (подряд перечислены имя колонки в оригинальном посте, в русской Виста, в русской XP и в Process Explorer):
1. Оригинал: "Working Set".
Vista: "Память - рабочий набор" (отображается как просто "Память")
XP: "Память - использование" (отображается как просто "Память")
ProcExpl: "Working Set"
2. Оригинал: "Commit Size"
Vista: "Память - выделенная память"
XP: "Виртуальная память"
ProcExpl: "Private Bytes"
3. Оригинал: "Memory"
Vista: "Память - частный рабочий набор"
XP: нет
ProcExpl: "WS Private"
4. Оригинал: нет
Vista: нет
XP: нет
ProcExpl: "Virtual Size"
2 - это количество памяти, зарезервированной для процесса (поэтому это число может быть невероятно большим). 1 - это количество физической памяти отданной процессу, а 3 - это часть 1, не занятая DLL-ми.
Примечание переводчика: видимо, Ларри перепутал 2 с 4 (а может быть это я неверно перевёл его слова). Именно колонка 4 показывает общую виртуальную память процесса (т.е. занятое адресное пространство процесса: выделенную + зарезервированную память). Колонка 2 показывает именно выделенную память - это та часть 4, для которой была действительно выделена какая-то память (не важно, где она находится - в RAM или в файле подкачки). Впрочем, в этих колонках немудрено запутаться (вы только посмотрите на разнобой названий для 2! А ведь я ещё не приводил названий колонок в английском Task Manager-е). Кстати, колонка 3 показывает ту часть колонки 2, которая находится в оперативной памяти. Колонка 1 показывает всю оперативную память, занимаемую процессом - но при этом часть этой же памяти разделяется несколькими процессами (ах, как же любят начинающие программисты искать утечки ресурсов по этому значению! А всё потому, что эта колонка единственная видимая по-умолчанию в Диспетчере Задач). Для желающий поглубже разобраться во всей этой мешанине я рекомендую серию Марка Руссиновича: часть 1, часть 2.
На моей машине я взял два запущенных апплета, у них оказалось:
FlashUtil9d.exe занимает 4.5 Мб по колонке 1, 1.3 Мб по колонке 2 и 760 Кб по колонке 3.
FwcMgmt.exe (файрвольный клиент ISA) занимает 4 Мб по колонке 1, 1.6 Мб по колонке 2 и 300 Кб по колонке 3.
Эти 700 + 300 Кб - это та настоящая, физическая память, которая активно используется процессом (иначе она оказалась бы выгруженной на диск). Это и есть ненужная нагрузка на память, возникающая из-за запуска апплета. При нескольких запущенных апплетах это число начинает БЫСТРО расти. На современных мощных машинах это не проблема, но для машин с меньшим объёмом памяти это может быть критично.
Примечание переводчика: у меня сейчас на машине крутится один мусорный процесс, который добавляет 3.5 Мб (по колонке 3).
В моём предыдущем посте я разделил все апплеты по 4-м категориям (обновлялки, обработчики области уведомлений, вспмогательные процессы и службы). В дополнение к общим проблемам, указанным выше, каждая категория имеет индивидуальные проблемы.
Обновлялки часто работают всё время, несмотря на то, что они делают свою работу только раз в день (или даже раз в месяц). Это означает, что они всё время тратят ресурсы зря. А самое худшее, что, например, на моей домашней машине у меня находится обновлялка, которая требует элевации с помощью манифеста (что означает, что у меня всплывает диалог о повышении прав каждый раз, когда она запускается).
Обработчики области уведомлений также работают всё время, что ещё хуже - они засоряют область уведомлений бесполезными иконками. Чем больше иконок в области уведомления - тем менее полезной она становится. Вообще-то именно это стало причиной для появления "большой четвёрки" в Vista (*) - люди часто жаловались на то, что иконки от программ сторонних производителей мешают находить нужные иконки. В дополнение к этому, обработчики уведомлению любят показывать всякие балуны, отвлекая пользователя. А также, поскольку все они запускаются при старте системы, то они замедляют загрузку.
Вспомогательные процессы не имеют каких-либо индивидуальных проблем - они просто потребляют ресурсы при работе.
Службы одновременно и хороши и плохи. Каждая служба Windows имеет тип запуска, определяющий, что система должна делать с ней при старте. Это свойство имеет три значимых для служб значения: AutoStart, DemandStart и Disabled. Когда служба помечена как AutoStart, она запускается автоматически при каждом запуске системы. Кроме того, поскольку службы работают в высоко-привилегированных учётных записях, их разработчикам нужно быть очень внимательными, чтобы не привнести в систему дыр безопасности. До Vista, высоко-привилегированные службы были не прочь показать пользовательский интерфейс на рабочем столе пользователя - эта практика настолько опасна, что категория связанных с нею угроз получила своё собственное название: "shatter attacks". В Vista были сделаны изменения для предотвращения классических shatter-атак для всех последующих версий ОС, так что, к счастью, эта угроза осталась в прошлом.
Завтра: как вы можете минимизировать ущерб от апплетов?
Примечания переводчика:
(*) "Большая четвёрка" (звук, сеть, батарея ноутбука и часы) в Vista вынесена на отдельную область справа от обычного системного трея, поэтому её иконки всегда чётко отделимы от остальных.
Почему люди пишут апплеты?
Это перевод Why do people write applets? Автор: Ларри Остерман.
Поскольку я потратил так много времени на жалобы на апплеты, я должен также посмотреть на них и показать, что же они делают (в конце концов, первым шагом на пути к повержению своего врага является его понимание).
Поскольку я потратил так много времени на жалобы на апплеты, я должен также посмотреть на них и показать, что же они делают (в конце концов, первым шагом на пути к повержению своего врага является его понимание).
суббота, 14 февраля 2009 г.
ЭТО МОЙ КОМПЬЮТЕР, КОЗЁЛ, А НЕ ТВОЙ!
Это перевод IT'S MY COMPUTER, DAGNABBIT, NOT YOURS! Автор: Ларри Остерман.
Я давно уже хотел написать этот пост, но то меня всё время что-то отвлекало, то не было времени.
Много людей (я слишком ленив, чтобы искать ссылки на них) комментировали такое явление как "bloatware" (также известное как "craplets" или "shovelware").
Я не буду говорить именно об этом, поскольку всё, что можно было сказать, уже сказано другими.
Вместо этого я хочу поговорить об апплетах вообще.
Я давно уже хотел написать этот пост, но то меня всё время что-то отвлекало, то не было времени.
Много людей (я слишком ленив, чтобы искать ссылки на них) комментировали такое явление как "bloatware" (также известное как "craplets" или "shovelware").
Я не буду говорить именно об этом, поскольку всё, что можно было сказать, уже сказано другими.
Вместо этого я хочу поговорить об апплетах вообще.
среда, 11 февраля 2009 г.
Это только временно
Это перевод It's only temporary. Автор: Ларри Остерман.
У NT есть множество классных возможностей, которые далеко не очевидны, если только вы не читаете документацию ДЕЙСТВИТЕЛЬНО внимательно.
Одна из моих любимых - то, что я называю “временные” временные файлы.
У NT есть множество классных возможностей, которые далеко не очевидны, если только вы не читаете документацию ДЕЙСТВИТЕЛЬНО внимательно.
Одна из моих любимых - то, что я называю “временные” временные файлы.
Ошибочные предположения
Это перевод Erroneous assumptions. Автор: Ларри Остерман.
Замечал ли кто-нибудь из вас, что во всей документации Win32 для каждой функции есть что-то такое:
Возвращаемые значения
Если функция выполняется успешно - возвращаемое значение будет NO_ERROR.
Если функция выполняется неудачно - возвращаемое значение будет одним из следующих кодов ошибок:
Я не могу даже представить, сколько раз люди жаловались на эту последнюю строку в таблице. Почему, чёрт побери, в Microsoft не могут документировать ошибки, возвращаемые этой функцией? Они там совсем тупые или ленивые, что-ли?
Замечал ли кто-нибудь из вас, что во всей документации Win32 для каждой функции есть что-то такое:
Возвращаемые значения
Если функция выполняется успешно - возвращаемое значение будет NO_ERROR.
Если функция выполняется неудачно - возвращаемое значение будет одним из следующих кодов ошибок:
| Значение | Смысл | |
ERROR_INVALID_PARAMETER | Что-то об ошибке ERROR_INVALID_PARAMETER | |
Прочие | Код системной ошибки, описанный в WinError.h. |
Я не могу даже представить, сколько раз люди жаловались на эту последнюю строку в таблице. Почему, чёрт побери, в Microsoft не могут документировать ошибки, возвращаемые этой функцией? Они там совсем тупые или ленивые, что-ли?
Подписаться на:
Сообщения (Atom)