Кстати, поскольку апдейты в винде теперь почти принудительные, а содержание их внезапно перестали документировать, резко возрастает вероятность, что апдейт могут поставить “лично одному человеку”. Например, ФСБКГБ решило за вами последить, направляет запрос в Майкрософт и те вам удалённо ставят следилку.
Категория: Компьютеры
25 Aug 2015 10:57
В России заблокирована Википедия.
UPD: Разблокирована.
Наверное, воду пробуют. Чтобы потом “ну так это уже давно”, “не в первый раз блокируют же”.
24 Aug 2015 19:14
Skype export
Сделал простой скрипт skype-export, который экспортирует все контакты скайпа и все логи переговоров с ними в текстовом формате, каждый контакт в свой файл. Так их можно архивировать на случай, если Скайп вдруг начнёт удалять старые логи или слетит при переустановке.
Сделал ещё такую штуку: когда Скайп стоит на нескольких компьютерах, он плохо синхронизирует сообщения, обычно на одном компьютере одни, на другом другие, хотя он и должен это делать. Вместе со skype-export есть skype-merge: выбираете общее место в каком-нибудь дропбоксе, копируете туда базу скайпа с одного из компьютеров, а дальше время от времени делаете в неё skype-merge с каждого, она будет их все собирать. Скайп поверх неё запустить нельзя, но с неё можно сделать skype-export, и так получить все свои переговоры везде.
Может, кому пригодится.
19 Aug 2015 01:12
Mercurial local per-repo .hgignore
What do you do if you need to ignore some local files, but would prefer not to commit that rule to everyone in .hgignore?
(E.g. you’ve created a folder in the repo for your own needs)
There’s a global .hgignore which you can configure from %PROFILE%\hgrc, but using it to list all exceptions from everywhere is ugly.
Turns out you can add per-repository .hgignore overrides this way too! Edit repo’s hgrc:
[ui]
ignore = .hg/.hgignore-local
It wouldn’t be committed as it’s inside .hg, and it would be parsed in addition to repo’s normal .hgignore.
17 Aug 2015 10:50
Секретно не выключалась!
Один из секретов быстрой загрузки Windows 10 в том, что иногда она и не выключалась! Этот сюрприз можно обнаружить в эвентлоге. Говоришь ей “Выключить компьютер”, винда закрывает программы, завершает пользовательский сеанс и… уходит в глубокий спящий режим, причём полусекретный: не мигает лампочкой на корпусе. Когда в следующий раз включаешь компьютер, она просто просыпается, а чтобы обмануть глупых человеков, показывает обычную заставку.
Поэтому может выйти, что думаешь, что после установки программы уже пять раз перезагружался, а на самом деле ещё ни разу.
Как же винда не боится, что неосведомлённый пользователь выдернет кабель питания? А ей не страшно: тогда она просто загрузится с нуля. Когда она засыпает, она к этому готова. На самом деле это довольно умное решение, но неожиданное.
16 Aug 2015 17:32
Component-Based Servicing (CBS)
Пока OneGet собирается стать package manager для винды, в винде уже некоторое время есть работающий менеджер пакетов. Называется он CBS (Component-Based Servicing). Он работает так, как положено нормальному менеджеру: помнит, какой файл кто перезаписал, и может удалить пакет А, если некоторые его файлы перезаписаны пакетом Б. Даже лучше, он хранит все версии файла с помощью WinSxS (Side-by-side assemblies). Он поддерживает обновление всех установленных пакетов через Windows Update (это та самая галочка “Получать обновления для других продуктов Майкрософт”).
Он содержит хоть и не исчерпывающую компонентизацию Windows, но гораздо большую, чем видно в системе на первый взгляд. Более подробной была только компонентизация XP Embedded в билдере. Вершину этого айсберга можно увидеть в “Установке и удалении программ”, “установка компонентов Windows”. Представленный там список – это так называемые Features. В CBS каждый пакет может содержать одну или несколько отключаемых опций, как компоненты установки в MSI. А число пакетов гораздо больше, большинство из них не содержат никаких Features.
Но как обычно, кто-то в Майкрософт сделал полезное дело, а другой приказал всё спрятать и запретить. Большая часть пакетов скрыта, а сам CBS запрятан так глубоко в недра системы, что о нём почти никто не слышал. Прежде, чем им пользоваться, нужно посрывать некоторые предохранители. Считайте это проверкой, как в Гарри Поттере: некоторые заклинания можно использовать только тем волшебникам, которые сумели до них додуматься.
Пакеты перечислены в
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\
Чтобы нормально с ними работать, нужно взять ownership всего раздела Component Based Services с детьми + дать на него с детьми право записи Администраторам.
Большая часть системных пакетов скрыта, у них Visibility=2. Чтобы пакеты были видны в dism.exe, нужно поставить 1.
У любого пакета может быть подключ Owner, где перечислены родительские пакеты. В таком случае самостоятельно его удалить нельзя. Большая часть системных пакетов входит в состав родительских “гранд-пакетов” Windows Home, Windows Pro и Windows Enterprise. Чтобы их можно было удалять, нужно их оттуда исключить и сделать самостоятельными пакетами. Массово это делает утилита install_wim_tweak (видимость она тоже включает):
install_wim_tweak /o
Для управления пакетами есть утилита dism.exe:
dism /Online /Get-Packages
Показывает все установленные пакеты, у которых в параметре Visibility стоит 1.
dism /Online /Get-Features
Показывает все отключаемые компоненты (те, что видно в “Удаление компонентов Windows”). Компоненты группируются по пакетам, но у большинства пакетов компонентов нет, а видимые компоненты на самом деле лежат в паре виртуальных пакетов. В общем, простым взведением флагов компонентизировать остальные пакеты нельзя.
dism /Online /Get-Features /Packagename=[имя]
Можно убедиться, что у большинства пакетов выключаемых компонентов нет, и их можно только удалять.
dism /Online /Remove-Package /Packagename=[имя]
Удаляет пакет из системы навсегда. Чтобы восстановить его, /Add-Package придётся скормить установочный .cab-файл, которого у вас нет, так что думайте. Существует слабый шанс выдрать этот файл из установочного диска винды, но обычно там всё уже в распакованном виде. Скорее всего, для восстановления удалённых пакетов придётся делать repair-install системы.
Обновления по удалённым пакетам приходить не будут.
Почему /Online – потому, что dism может редактировать оффлайн-образы системы в папке. Также dism заодно умеет просматривать установки MSI с помощью /Get-Apps и устанавливать-удалять пакеты Appx (/Get-AppxPackage), чем все пользуются для удаления установленных в винду стильных модных калькуляторов.
Часто удалить достаточно только ведущий пакет, а всевозможные языковые его версии и поддерживающие пакеты удалятся автоматически.
Как понять, какие пакеты что значат? Это сложно, у большинства пакетов названия неговорящие, а часто и не такие, как у конечного продукта. Пакеты также описаны в:
C:\Windows\servicing\Packages
На каждый там лежит XML-файл с описанием пакета, компонентов и обновлений, иногда есть описание (description), хотя редко. По ряду пакетов есть информация в MSDN, хотя она больше касается unattended installation и того, какие параметры пакета можно настроить. Кроме этого остаётся гуглить, часто название технологии что-нибудь подсказывает.
Также во время обслуживания пакетов подключается ключ HKLM\COMPONENTS из C:\Windows\system32\config\COMPONENTS, который содержит много непонятной информации. Как с его помощью сопоставить файлы (assemblies) пакетам я пока не выяснил.
Логи к CBS ведутся в C:\Windows\Logs\CBS, это волшебное место и при диагностике ошибок Windows Update.
Пакеты, которые можно с удовольствием удалить:
Ненужные фичи:
Microsoft-Windows-OneDrive-Setup-Package – окончательно добивает OneDrive, который дедка бил-бил, не разбил.
Microsoft-Windows-OfflineFiles-Package – кто-нибудь этим пользуется?
Microsoft-Windows-Shell-HomeGroup-Package
Microsoft-Windows-Shell-HomeGroup-Package-printscan
Microsoft-Windows-EnterpriseClientSync-Host-Package – это WorkFolders.
Microsoft-Windows-WorkplaceJoin-Package – ещё одна разновидность “синхронизации папок с работой”. Briefcase, OfflineFiles, WorkFolders, WorkplaceJoin, кто больше?
Microsoft-Windows-PeerDist-Client-Package – BranchCache, если у вас сервера BranchCache-документов нет, то не нужен.
Ненужные свистелки и бренчалки:
Microsoft-Windows-Cortana-Package – но осторожно: возможно, удалится и поиск вообще
Microsoft-OneCore-Networking-XboxLive-Package – некоторые другие пакеты по Xbox, возможно, не стоит удалять – какие-то игры могут на них рассчитывать
Microsoft-OneCore-Networking-XboxLive-WOW64-Package
Ненужные технологии:
Microsoft-Hyper-V-* – Пакетов 30 на эту тему. Если адреналин задул в паруса души, можно поудалять.
Microsoft-Windows-IIS-WebServer-Package – впрочем, отключается и из Features.
Microsoft-Windows-IIS-WebServer-AddOn-Package
Microsoft-Windows-IIS-WebServer-AddOn-2-Package
Майкрософт следит за тобой:
Microsoft-WindowsFeedback-Package
Microsoft-Windows-Prerelease-Client-Package [он же Microsoft-Windows-DiagTrack-Package]
CBS просто замечательны в том, что разбивают Винду на пакеты. Чего же в них недостаёт?
1. Зависимостей между пакетами. Сейчас можно удалить пакет, который нужен другому пакету. В компонентизаторе Windows XP Embedded зависимости были, хотя зачастую пакеты и тянули за собой всё подряд потому, что их зависимости были плохо компонентизированы.
2. Установки из онлайн-репозиториев. Здесь преуспевает OneGet, а CBS умеет устанавливать только cab-файлы.
3. Регистрации нескольких репозиториев. Не все хотят обновляться только через Windows Update, какие-то программы хотели бы выкладывать обновления в собственных репозиториях.
4. Подробной информации о содержимом пакета. Куча пакетов непонятно зачем нужна.
Бонус!
Пока я писал эту заметку, я написал свою собственную утилиту для управления пакетами! Называется CBSEnum:
Она представляет их в виде дерева (хотя вообще в реестре они лежат кучей), позволяет удалять пачками, показывает какую-то справку, какую удалось добыть из Windows\servicing. Также может скрывать/восстанавливать пакеты от DISM.
10 Aug 2015 01:20
OneGet
Одна из бед Windows – это что в ней нет собственного package manager. Но Виндоус решила переплюнуть Линукс, и теперь есть package manager manager!
Это штука, которая поддерживает множество типов пакетов. Например, в комплекте есть плагин MSI, возвращающий список всех установленных на компьютере MSI-пакетов (добрая половина инсталляторов). Есть плагин chocolatey – тоже, оказывается, развитый репозиторий, который ещё и поддерживает “автоматически обновляемые пакеты” (т.е. сам сервер выпускает новую версию, когда она выходит на стороннем ресурсе). Пишут о 2800 программах (не считая версий)!
Всё это богатство доступно из командной строки:
Install-Package Firefox
Install-Package Thunderbird
Но не работает, поскольку в версии, попавшей в Windows 10, провайдер chocolatey недоступен, и все способы его добавить не дают возможности установить ПО (хотя поискать по спискам можно). Придётся ждать, когда его починят.
У авторов большие планы, хотят добавить поддержку всех крупных систем распространения модулей (например, питоновский pip или ruby gems).
Это штука с одной стороны очень интересная и полезная, с другой – надо подумать, решает ли она все проблемы? Что chocolatey, что oneget по большому счёту не лезут внутрь инсталляторов. chocolatey вообще часто скачивает готовый инсталлятор и формирует пакет “запустить msi с ключом тихой установки”. Они решают задачу пакетной установки программ.
Но другая цель менеджеров пакетов – это борьба с бардаком. Пользователь имеет право знать, какие файлы на его компьютере кто и зачем установил. Бесхозного мусора не должно быть. К сожалению, во всех современных системах программы сыплют всем подряд куда попало. Бросают свои модули в системные папки, пишут логи в папку Windows, создают временные директории в корнях дисков, складывают в папках данных свои исполняемые файлы, засыпают папку пользователя всевозможными “Моими проектами Visual Studio” и “Моими фотографиями со стиральной машины”. Андроид создавался с нуля, но в нём такой же дикий запад.
Настоящая задача менеджера пакетов – это разобрать ураган бумаги на отдельные книжки. Каждая программа должна работать отдельно от всего остального. Система не должна представлять собой клубок вермишели, части которой вплетаются в другие части и во всё окружающее. Этим ни chocolatey, ни one-get даже не пытаются заняться.
Автор OneGet пишет, объясняя такое решение: “Для Windows сделано что-то в духе двух миллионов программ, сложно ждать, что их все начнут перепаковывать”. Согласен, но иначе никак. Это главный смысл менеджера пакетов. Без него менеджер не менеджер, а пусть комфортная, очень удобная, но программа для автоматизации установки, вот и всё.
Скоро я напишу о настоящем менеджере пакетов, который тихой сапой есть в винде уже давно, но стараниями Майкрософт своей роли не выполняет и почти не известен.
02 Aug 2015 11:14
Windows 10 – допиливание напильником
Отключить IIS
Панель управления -> Удаление программ -> Включение и отключение компонентов Windows.
Почти ничего из списка не нужно. Важны оба .NET-фреймворка (без вложенных галочек), IE 11, Powershell (целиком), компоненты для работы с мультимедиа, поддержка SMB 1.0/CIFS, служба активации и службы печати (не все). Остальное по желанию, причём если что-то непонятно, как правило это вам не надо.
Открывать по умолчанию “Мой компьютер”, а не “Панель быстрого доступа”
Вид -> Параметры -> Открывать Проводник для: “Этот компьютер”.
Убрать библиотеки из панели навигации
Они и так убраны, но на всякий случай: Вид -> Параметры -> Вид -> Область навигации -> Показать библиотеки.
Или правой клавишей по панели навигации: “Показать библиотеки”.
Отключить OneDrive и убрать из панели навигации
Правой клавишей по иконке около часов – в настройках отключаем запуск с системой. Выходим.
gpedit.msc -> Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> OneDrive. “Запретить использование OneDrive для хранения файлов”: “Включено”.
Перезагрузитесь. Если недостаточно, см. “как вообще убирать вещи из панели навигации”.
Тж. см. как удалить OneDrive навсегда.
Убрать HomeGroup из панели навигации
Отключить службы HomeGroup Provider и HomeGroup Client.
Если этого мало, переключить указанные ключи реестра:
How to Add or Remove Homegroup from Navigation Pane
How to disable HomeGroup feature
Как вообще убирать вещи из панели навигации
How to disable icons from Navigation Panel: ищете в реестре “IsPinnedToNamespaceTree”, смотрите, в каком это разделе. Найдя нужный раздел (HomeGroup, OneDrive и т.д.), IsPinned меняете на 0. Рядом в подразделе ShellFolder параметр Attributes, переключите 20-й бит: 1 = скрыть, 0 = показать.
Повторите эти же действия для всех подходящих результатов. Такие разделы могут быть в: HKEY_CLASSES_ROOT\CLSID, HKEY_CURRENT_USER\Software\Classes\CLSID\, а на 64-битной системе ещё в HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ и HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\.
Убрать папки в “Моём компьютере”
How to Remove the Folders from My Computer. В реестре ключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\, поудалять лишнее.
Оверлей-иконки junctions/tortoishg/btsync и т.п. не видны
Это из-за того, что винда исторически поддерживает максимум 11 оверлей-иконок. OneDrive влез и вставил свои вперёд других. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers, удаляете всё, что касается One Drive (нужно стать владельцем этого ключа и его детей, и дать себе права на удаление).
Удалить ряд приложений по умолчанию (в т.ч. OneNote, 3D whatever)
Remove default Apps from Windows: открываете PowerShell под админом, Get-AppxPackage *OneNote* | Remove-AppxPackage.
Переименовать “Этот компьютер”
Включите иконку “Компьютера” на рабочем столе и переименуйте её. Это подействует в том числе и на название в адресной строке Проводника. Но не на тайл в Пуске. Чтобы переименовать тайл в Пуске, см. вопрос про тайлы.
Переименовать тайлы в Пуске, изменить им иконки
По большинству тайлов можно щёлкнуть правой клавишей и “Открыть расположение файла”. Обычно это подпапка “Главного меню”. Переименуйте соотв. ярлык и назначьте ему нужную иконку.
По “Этому компьютеру” так щёлкнуть нельзя, но иконка всё равно существует, лежит в AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools (папка “Служебные”).
Изменить пункты в Пуске
Параметры -> Персонализация -> Пуск -> “Выберите, какие папки будут отображаться”.
Секретное удобное меню в Пуске
Маленький сюрприз: щёлкните правой клавишей по “Пуску”. Видите, сколько всего полезного? Второй маленький сюрприз: AppData\Local\Microsoft\Windows\WinX – здесь в трёх группах лежат пункты этого меню, можно добавить свои.
Отключить перезагрузку без предупреждения
Пуск -> Параметры -> Обновления -> Дополнительно -> “Уведомлять о планировании перезагрузки”.
Отключить экран блокировки
Он красивый, но бесполезный и создаёт лишний шаг при логине:
gpedit.msc -> Конфигурация компьютера -> Административные шаблоны -> Панель управления -> Персонализация -> “Запрет отображения экрана блокировки”: “Включен”.
Lock Screen – Enable or Disable
Включить ввод Ctrl-Alt-Del
cmd -> control userpasswords2 -> Дополнительно -> “Требовать нажатия Ctrl-Alt-Delete”
Ещё пачка полезных советов.
И ещё пачка.
Как отключить Майкрософт следит за вами.
29 Jul 2015 23:45
Обновление до Windows 10
Похоже, на обновлении до Windows 10 Майкрософт получит урок, который гласит “планируй, но дай упрямым сделать по-своему”. Они хотели раздавать обновление на компьютеры волнами, чтобы уменьшить нагрузку на сервера. Каждый компьютер обновится, когда придёт его время…
Разумеется, интернет ждать не захотел. В результате форумы бурлят людьми, которые:
1. Пытаются всеми правдами и неправдами заставить обновление запуститься сразу же.
2. При этом ковыряют кочергами в нутре системы, разбивая там тонкие лампы и куроча микросхемы.
3. Обновление как не ставилось, так и не ставится, а у некоторых уже и не поставится благодаря мудро удалённым файлам и не доведённым до конца сглючившим установкам, которые были запущены с переведёнными в будущее часами.
4. Люди бесятся, что Майкрософт сделала такое тупое обновление.
5. И мало того, каждый раз заново перезапускают скачивание, увеличивая нагрузку на сервера.
И волки голодные, и овец сожрали!
Надеюсь, посмотрев на это, они вернут в Windows 10 возможность отказаться от обновлений.
03 Jul 2015 15:49
Solved: Delphi XE3 64-bit debugger fails to run
Symptoms:
Delphi XE3 sometimes fails to run 64-bit applications under a debugger. Code would compile, but the part where Delphi switches to debug layout never happens, Delphi just pops a message saying "Cannot run the debugger".
32-bit debugging continues to work normally, and so does "Run without debugging".
The funny part is that this happens irregularly. Sometimes the first attempt would succeed, and then the debugger would run all the time in all instances of Delphi. But if it fails the first time then it would always fail even if you restart Delphi.
I also noticed that the earlier I launch Delphi + debugger, the higher is the chance it would run (and then continue working). It seemed like there was something I was doing or the computer was doing sometime after boot that broke the debugger if I hadn’t launched it yet.
Solution:
Stop the "Internet connection sharing" service and restart Delphi.
What might have contributed:
– Uninstalling older versions of Delphi on the same PC.
– Disabling Windows Firewall
– Disabling Windows Defender
Diagnostics process:
Looking at the successful and failed debugger launches with Process Monitor, in both cases Delphi runs a remote debugger. But on the successful run it’s dbkw64_17_0.exe (64 bit) while failed runs spawn rmtdbg170.exe (32 bit). Both are Delphi debuggers, but I suspected that the second one is only supposed to be used for 32 bit debugging.
Further investigation showed that in both cases dbkw64_17_0.exe launches initially, but in the second case it terminates shortly afterwards. Delphi then tries to connect to it through TCP, unable to do so, and restarts it automatically. But the code that does the restart probably wasn’t updated to 64 bit and launches 32-bit rmtdbg170.exe instead.
Anyway, the problem lies in the initial instance of dbkw64_17_0.exe terminating. Comparing Process Monitor logs, both successful and failed runs load the libraries and then work with winsock. Stack in the final calls indicates ws2_32.dll‘s socket() is running – the debugger is probably trying to open it’s command socket for listening – after which failed instance abruptly terminates (Thread Exit, Process Exit). I figured socket() probably returns with an error.
Using rohitab’s Api Monitor I tried to find out the error code, but this didn’t work out. Api Monitor successfully traced all the calls until roughly WSAStartup(), but no further – the last bunch of calls just before the termination always got lost, perhaps the injected driver wasn’t being able to send it back to the main app in time before the application terminated.
Then I opened dbkw64_17_0.exe for debugging in Visual Studio. I set a breakpoint to {,,ws2_32.dll}socket, caught the execution there and studied what happens step by step. Turns out, socket() was successful. It was followed by setsockopt call, also successful (to know which functions we were stepping into, I used VS’s standard ability to load Windows DLL symbols from Microsoft servers). Then dbkw64_17_0.exe called bind() which failed.
My initial guess was that someone else occupied the port it needed. Checking bind() parameters at MSDN, I looked into RDX, RCX, R8, R9 registers which host parameters in x64 calls, namely the memory referenced by RCX, which kept the requested family and port number. It turned out to be 0xC0F3 but it was unoccupied.
I then traced the call to bind() and from the internal call to WSPBind() got the error code: 0x1D27, that is 10013 (WSAEACCES: Permission denied. An attempt was made to access a socket in a way forbidden by its access permissions).
This code has no single specific reason for it. From the internet it looks like it appears when some driver or network-related service misbehaves. I tried stopping network related services one by one, until finally bind() succeeded. The infringing service was "Internet connection sharing (ICS)". As long as I stop this service, the debugger launches normally, and so long as ICS is running, the debugger would not start.
The reason why sometimes the debugger would run and then run always, is probably that ICS hadn’t yet been started or did not yet harm the network stack at the time. If the debugger run at that point, it would bind the socket, and for whatever reason binding at that port would then continue working later. But if the debugger was initially launched after the harm has been done, it wouldn’t be able to bind to the port neither once nor at all.