Всем привет,
спешу поделиться полезной информацией о том, что оказывается может вызывать необъяснимое замедление в работе Windows (XP/2003/?).
Популярным языком, контроллер IDE ATA/ATAPI может самостоятельно и очень незаметно переключиться из высокопроизводительного режима типа Ultra DMA Mode 5 в более медленный режим - такой как PIO Transfer Mode. Как я понял, произойти это может в случае превышения некоего порогового числа ошибок чтения, и чем дольше вы используете Windows, тем выше вероятность, что это случится и с вашей системой.

Косвенные признаки:
1) Windows работает очень медленно - все что связано с диском требует в 10 раз больше времени, чем обычно. Запуск и завершение програм может занимать по несколько минут.
2) При проигрывании музыки хорошо заметны частые заедания, даже при использовании хорошего аудиопроигрывателя.
3) Process Explorer показывает необычно высокую CPU-активность псевдо-процесса Hardware Interrupts (у меня было 15-20%).

Как убедиться:
В диспетчере устройств заглянуть на вкладку дополнительных свойств Primary IDE Channel (в разделе IDE ATA/ATAPI Controllers).
Значение Current Transfer Mode равное PIO Mode означает, что проблемы с производительностью действительно вызваны неправильными настройками контроллера.

Как исправить:
Удалить неправильно настроенный IDE канал из системы и позволить Windows его автоматически переустановить (после пары перезагрузок).

Источники информации:
https://forum.sysinternals.com/forum_posts.asp?TID=965
https://winhlp.com/node/10
https://www.microsoft.com/whdc/device/storage/IDE-DMA.mspx

Полезная утилита:
https://www.microsoft.com/whdc/DevTools/tools/RATT.mspx

// Vitaliy

Если бы это был сбой в распространенном приложении - таком как Microsoft Office - еще один отчет вероятно мог бы помочь в поиске и исправлении ошибки в программе. А в моем случае - ошибка содержится в моей собственной программе и увидеть, а тем более исправить ее никто кроме меня не может.

Как быть? А вот как - добавление следующих ключей в реестр отключает эту архи-полезнейшую функцию. Подробнее можно прочитать здесь: https://support.microsoft.com/kb/841477, https://support.microsoft.com/kb/310116, и совсем подробно здесь - https://download.microsoft.com/download/5/9/2/592d2308-a6a2-48ad-ae8f-72f888b9d361/CER_Implementation_Plan.pdf

Пример содержимого файла dw_disable.reg:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Policies\Microsoft\PCHealth\ErrorReporting\DW]
"DWReportee"=dword:00000001
"DWNeverUpload"=dword:00000001
"DWNoFileCollection"=dword:00000001

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\PCHealth\ErrorReporting\DW]
"DWReportee"=dword:00000001
"DWNeverUpload"=dword:00000001
"DWNoFileCollection"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\PCHealth\ErrorReporting\DW]
"DWReportee"=dword:00000001
"DWNeverUpload"=dword:00000001
"DWNoFileCollection"=dword:00000001

[HKEY_LOCAL_MACHINE\Software\Microsoft\PCHealth\ErrorReporting\DW]
"DWReportee"=dword:00000001
"DWNeverUpload"=dword:00000001
"DWNoFileCollection"=dword:00000001

Оказывается все очень просто - выпущенный уже более двух лет назад патч (#896358) заблокировал показ содержимого CHM-файлов, загруженных из Интернета. Лечится довольно просто - щелкаем правой кнопкой на иконке файла, выбираем Properties, и в окне свойств щелкаем по кнопке Unblock.

Подробнее описано в статье: https://support.microsoft.com/kb/902225/

Подробнее (по-английски) можно прочитать на сайте команды разработчиков - https://blogs.technet.com/wsus/archive/2007/04/28/update-on.aspx.
Если я правильно разобрался в описании, обновленная версия будет установлена на машины пользователей уже в следующий "вторник обновлений" (https://en.wikipedia.org/wiki/Patch_Tuesday).

Вопрос:
С кем контактировать в Майкрософт, чтобы предложить свою идею/совет?

Ответ:

1. Пожалуйста, прочитайте и убедитесь, что правильно поняли, раздел "UNSOLICITED IDEA SUBMISSION POLICY" на странице https://www.microsoft.com/info/cpyright.mspx#EVE.
2. В Майкрософт достаточно много сотрудников и продуктовых груп. Уточните, к какому продукту/услуге относится ваше предложение и постарайтесь найти их продуктовую страницу или блог. Там, скорее всего, будут указаны координаты для контактов.
3. Большинство людей в Редмонде говорит по-английски, возможно имеет начать с Вашего местного/регионального офиса (например, для стран СНГ это https://www.microsoft.com/rus/feedback/default.mspx).

Для того, чтобы каждый раз не копировать все документы в один вручную, можно воспользоваться продвинутой функцией Ворда - специальными полями. Итак, пусть в наш текущий документ мы хотим вставить документ (главу из книги), путь к которому на диске c:\documents\mydoc1.doc.

Выбираем меню Insert, в нем опцию Field, в списке FieldNames выбираем IncludeText, а в поле Filename указываем c:\documents\mydoc1.doc и нажимаем OK.

Если все сделано правильно, в месте, на которое указывал ваш курсор, появится вставленный документ. При этом вставленный документ будет вести себя как и все остальные специальные поля - его можно будет обновить щелчком правой кнопки мышки и выбрав опцию Update Field (или клавишу F9).

Для того, чтобы увидеть скрытую информацию, связанную со специальными полями, нажмите Alt-F9. Для нашего примера должно получиться:
{ INCLUDETEXT  "c:\\documents\\mydoc1.doc"  \* MERGEFORMAT }
В этом режиме легко создать нужное число копий этого специального поля и вписать в них правильный путь для каждого документа. При этом не забудьте про удвоенные слэши. Можно также использовать относительные пути к документу. Если наши документы находится в одной папке, достаточно написать mydoc1.doc вместо c:\\documents\\mydoc1.doc. Для того, чтобы вернуться в обычное представление, снова нажмите Alt-F9. Для того, чтобы обновить все вложенные документы (главы книги), выделите весь документ (Ctrl-A) и нажмите F9.

Если вы используете Microsoft Word 2007, опция Field будет находится в меню Insert\Quick Parts.

Попытка 1:
ren *.* *.*.ext

Результат:
filename => filename..ext
filename.aaa => filename.aaa.ext
filename.aaa.aaa => filename.aaa.aaa.ext

Как видно из примера, файлы не имевшие раширения, получили лишнюю точку.

Попытка 2:
ren * *.ext

Результат:
filename => filename.ext
filename.aaa => filename.ext (ошибка - файл уже существует)
filename.aaa.aaa => filename.aaa.ext

Снова проблема - для файлов с расширением, новое расширение не добавляется, а заменяется.

Попытка 3:
ren *? *.*.ext

Результат:
см. попытку 1

Попытка 4:
ren *? *.ext

Результат:
см. попытку 2

Попытка 5:
ren *? *?.ext

Результат:
filename => filename.ext
filename.aaa => filename.ааа.ext
filename.aaa.aaa => filename.aaa.ааа.ext

Ура! Работает!
Контрольный выстрел:
.aaa => .aaa.eхt

Аналогичная ситуация будет наблюдаться и для команд dir, del, copy, move и т.д. В чем причина столь причудливого поведения утилит командной строки? Утверждается, что корни проблемы уходят в прошлое чуть ли не на 25 лет назад во времена DOSа и его прородителя QDOSа, а кажущаяся текущая непредсказуемость толкования символов * и ? связанна с необходимостью обеспечивать обратную совместимость с некими древними приложениями командной строки.

Кстати, в проблеме с переименованиями существует еще и потенциальная возможность коллизии при добавлении разрешения (просто замените в нашем примере eхt на aaa) - так что если в вашем приложении нужна железная гарантия успешного переименования - прийдется писать код для выбора правильной последовательности переименований самостоятельно. (Думаю, будет достаточно просто упорядочить файлы по убыванию длины).

Эта особенность работы браузера вызвана следованием достаточно старому стандарту для HTTP-клиентов. То что казалось разумным 10 лет назад сегодня уже не всегда актуально.

Исправить это недоразумение можно вручную изменив соответствующую опцию в реестре.
Например, следующие параметры увеличивают максимальное число соединений до 16:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:0000010

Файл для модификации реестра можно найти на сайте https://www.enhanceie.com/ie/tweaks.asp. Прямая ссылка - https://www.enhanceie.com/dl/fixHTTPMax.reg.

Имя ClickOnce приложения - это параметр, который вы передаете утилитам mage.exe и mageui.exe при генерации манифеста. Это имя отображается в окне установки и скачивания приложения, в стартовом меню, а также в окне добавления/удаления программ. Поскольку все это происходит одновременно, то, пожалуй, имеет смысл включить в имя программы в дополнение к номеру версии также и название вашей компании. Например, Microsoft Word 2007. Таким образом программу будет легче найти в меню удаления. :).

Итак, неофициальные рекомендации:

1. Формат [Имя компании] [Полное название приложения] [номер версии]
2. Предпочтительно использование английских символов. Использование русских символов теоретически возможно (благодаря использованию XML), но в случае использования автоматической системы сборки приложения создает массу трудности при использовании утилит командной строки и генераторов инсталляций.
3. Длина имени ограничена 260 символами. Разумный предел находится в районе 40-50 - иначе во многих случаях название перестанет помещаться на одну сточку.
4. Даже из множества ASCII символов на самом деле можно использовать лишь ограниченный набор символов. Запрещены к использованию любые символы, не пригодные для использования в качестве имен файлов (" < > | : * ? \ / (Char)0 - (Char) 31), а также символы # и &.

Пробелы? Пробелы можно :)

Эти рассуждения наводят на мысль о необходимости распараллеливания показа заставки и процесса подготовки приложения к работе. И тут начинаются проблемы.

Подход №1. Создаем экран-заставку и в том же потоке исполнения занимаемся нашими вычислениями, загрузкой файлов, вызовами веб-сервисов и т.п. По окончании инициализации закрываем окно и возващаемся в приложения, откуда уже создаем основное окно приложения.

Пример: https://www.codeproject.com/csharp/applicationcontextsplash.asp

Проблема: Если инициализация занимает много времени, окно заставки перестает перерисовываться, переключение между программами проецирует на наше окно куски других окон. Ну вы видели такое.

Подход №2. Создаем два потока - главный и вспомогательный. Вспомогательный поток отображает заставку. Главный производит инициализацию. По окончании инициализации в главном потоке завершаем вспомогательный поток. В главном потоке создаем основное окно приложения.

Пример: https://www.codeproject.com/useritems/usesplashscreen.asp

Проблема: Основное окно оказывается "глубоко" на заднем фоне. Это связано с особенностью оконного менеджера Windows - для него окна созданные в разных потоках приложения не имеют (почти) ничего общего - поэтому их z-ордер оказывается сильно отличным.

Подход №2а. Повторяем описанное в подходе 2, но дополнительно при создании основного окна вызываем функцию this.Activate(); (или SetForegroundWindow() в неуправляемом коде). Этот подход предложен, например, здесь: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=115850. Кстати, интересные попытки обойти логику работы функции SetForegroundWindow() встречаются здесь https://www.rsdn.ru/article/qna/ui/wndsetfg.xml.

Пример: https://www.codeproject.com/csharp/apploadingarticle.asp (здесь следует читать также и комментарии, где как раз и предлагается вызывать this.Activate();)

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

Подход №3. Создаем основной и вспомогательный поток приложения. В основном потоке создаем окно экрана-заставки. Во вспомогательном производим всю необходимую инициализацию. После этого закрываем заставку и, используя подготовленные данные, без задержек открываем главное окно.

Пример: На вскидку ничего не нашел, поэтому оставляется читателю в качестве упражнения.

Проблема: Для реализации такого подхода от нас потребуется отделить инициализационные код в отдельную функцию. А потом передать результаты в другой поток. Это не так весело, как, например, запихнуть весь код в событие OnLoad. Тем не менее это самый красивый с точки зрения пользователей, а также эстетствующих менеджеров проекта :), подход.

Где-то по середине между 1 и 3 подходом находится подход с периодическим просмотром очереди сообщений в перемешку с инициализацией. Что-то вроде этого реализовано, кажется, здесь https://www.codeproject.com/useritems/CustomSplashScreen.asp. Этот подход разумеется не нов, минусы у него достаточно очевидны.

Факультативно, можно почитать рассказ Джастина Роджерса, разработчика из команды IE, о том, как работает ApplicationContext (эдакий wrapper для исполнения приложения) https://weblogs.asp.net/justin_rogers/archive/2004/04/11/111162.aspx.

Да, кстати, ложный путь, указанный в одной из статей на сайте codeproject, стоил мне пары часов анализа исходных текстов CLR в поисках того самого места, где происходит описанное "безобразие" (так и не нашел ;) ):

Solving the z-order problem
The problem with the z-order was caused by running two message loops within the same AppDomain. As soon as the AppDomain recieves the message loop exited message it deactivates the Application sending it to the back of the z-order. This is not normaly a problem as this exited message would indicate the application is closing, but not in this case. Fortunatly, this implementation of a splash screen avoids this problem by never starting a message loop for the splash screen, but rather pumping the messages manually.