Windows 10 – отличная операционная система. Особенно если установить на SSD, чтобы не слышать постоянного треска. И диспетчер задач с системным монитором не запускать. И ещё стрелочку с крутилкой заменить на обычную стрелочку, дабы каждые десять секунд не видеть, как что-то запускается. А если ещё и на монитор не смотреть, а только с мобилы читать нытьё о том, что Microsoft прекращает поддержку лучшей винды ever – вообще закачаешься!

На днях хотела посмотреть настройки сети на Windows 11 и прикрутить статичный айпишник на время. Короче, я выматерилась, пока хоть что-то нашла в этом модном-стильном-молодёжном интерфейсе, на который так отчаянно дрочат зумеры. Посмотреть текущие настройки – в одном разделе, изменить настройки – в другом разделе. В угоду мобильным дебилам всё открывается в одном окне, и, если нужно свериться с другим разделом, нужно бросать всё, что ты сейчас делаешь и переходить в этот самый другой раздел. Навигация сделана охуенно, если у текущего раздела слишком длинное название, то предыдущие прячутся в менюшку, которую отдельно надо раскрывать. Шрифты, блять, мыльные просто пиздец. Когда случайно тыкаешь в какой-нибудь пункт, который открывает старую панель управления, от чёткости картинки просто охуеваешь. Ощущение, что монитор протёрли от многовековой пыли. Когда уже авторов этого непотребства отпиздят черенками от лопат, выкинут на мороз и сделают как было, только ещё лучше?

Захожу на машину с учётки доменного администратора, открываю папку. Проводник: «Давайте повысим привилегии!» Захожу на шару с той же учётки и захожу в ту же папку. И никаких повышений не требуется. Не, я понимаю, но всё же забавно.

В «новом интерфейсе» (на самом деле – в новой панели управления) Windows 10, на который так дрочат эстеты и зумеры в Твиттере, отсутствует управление с клавиатуры в принципе. Я надеюсь, что Трампарарамп в конце концов найдёт всех причастных к этому говнищу, к Метро, к новому меню Пуск и отправит на тот самый остров с крокодилами.

Где-то попалось, что Microsoft придумала новый алгоритм файлового сжатия и реализовала его через reparse points. Типа, вместо файла – оно самое, а сами сжатые данные – где-то ещё. И всё прозрачно работает через драйвер. Собственно, либо автор описания ебанулся, либо ебанулась Microsoft и забыла, что в NTFS предусмотрено использование разных алгоритмов сжатия, просто до сих пор алгоритм был всего один.

Просмотрщик сертификатов в Windows – единственный вменяемый из всех подобных. Ни в броузерах, ни в других операционных системах не смогли сделать вывод сведений о сертификате таким, чтобы от мешанины букв и цифр не разбегались глаза.

Non-ASCII Paths and Portability - Some features may not be fully portablized if this app is used from a non-ASCII path and then moved to another location (settings, extensions, etc).

https://portableapps.com/ap...rnet/r3dfox-portable
Опять UTF-8 в ANSI API?

Попутно выяснила занятное. У функции DeviceIOControl(), которая позволяет давать команды устройствам и получать от них всякие данные (как раз через неё пишутся и читаются данные reparse point), есть такие параметры: входной буфер с размером, выходной буфер с размером, сколько было записано в выходной буфер, ну и ссылка на OVERLAPPED для асинхронной операции. Буферы опциональны в зависимости от устройства и команды, параметр, возвращающий количество записанного, – тоже, ну и OVERLAPPED. Ну, у меня при записи в reparse point операция синхронная и используется только входной буфер, поэтому в функцию передаю только входной буфер и его размер, а всё остальное – NULL. Ну и программа в результате вылетает. Оказалось, что, если параметр, принимающий OVERLAPPED, установлен в NULL, то параметр, принимающий количество записанного в выходной буфер, должен ссылаться на актуальную переменную, даже если выходной буфер – тоже NULL. Оказывается, Microsoft не только не добавила проверку этого параметра, но и использовала его значение где-то внутрях функции, о чём указала в документации. В общем, не делайте так =_=

Короче, написала я прототип программы, которая данные хранит в reparse point. И оно работает: появляется файл длиной ноль байт, который, поскольку система не знает, что это такое, можно только удалить. Написать код, который вытащит эти данные, разумеется, – задача тривиальная, тоесть для маскировки подходит мало, но тут именно что нужно писать код или искать очень специальную утилиту, ибо никакими блокнотами такие файлы не открываются.

А я поняла, почему размеры не совпадают. При чём, как оказалось, не только в WSL симлинках, но и в других симлинках (собственно, симлинках и junctions). Началось с того, что я нашла баг в билиотеке, где передавался неправильный размер буфера, и сломалось всё. Код показывал, что в заголовке данных размер буфера с путями такой, а на деле – другой, поменьше. Оказалось, что это поле в заголовке показывает кое-что другое. Там есть структура REPARSE_DATA_BUFFER, которая универсальная для всех майкрософтовских reparse points. У всех у них первые восемь байт имеют одинаковый смысл, а дальше уже могут быть как дополнительные данные, так и дополнительные поля, которые эти данные описывают. Полей может быть разное количество. Так вот, поле, которое указывает размер данных, указывает этот размер после общего заголовка, тоесть вместе со всеми дополнительными полями. А я считала без учёта дополнительных заголовков, ну и получалось, что фактически данных меньше, чем в заголовке. При чём в описании этих заголовков именно это и было написано, но я читала невнимательно =_=

Добавила в свою библиотеку парсинг симлинков WSL. Оказалось, что Cygwin создаёт их как-то странно: в заголовке данных симлинка есть поле, которое указывает размер части, которая идёт после заголовка и содержит путь к объекту, на который указывает симлинк (в UTF-8, кстати). И вот это значение почему-то всегда на четыре больше, чем там есть по факту. Почему – БП. Надо попытаться ещё с самим WSL поэкспериментировать. Кроме того, сами данные там в очень свободной форме. Если у обычного симлинка есть флаг, относительный там путь или абсолютный, то тут может быть всё, что угодно, и оно даже может не совпадать с тем, что передано команде ln. Передала «0000» – получила «0000». Передала «/cygdrive/x/0000» – получила «/mnt/x/0000». Передала «X:\0000» – «X:\0000».

Я это всё к чему? У нас есть ещё Cygwin, у которого есть своя ln. И вот как раз она создаёт натуральные reparse points, которые видятся как reparse point. DIR показывает их как «JUNCTION», FAR3 – как «LX_SYM», Проводник (в Windows 7 и ниже) вообще показывает это как файл, а Link Shell Extension не воспринимает как симлинк. И никто не умеет с этим работать. А на деле у данной штуки «тэг» – IO_REPARSE_TAG_LX_SYMLINK, тоесть симлинк, который поддерживается WSL. Возможно, в Десятке в Проводнике он выглядит лучше, но я не видела. Надо экспериментировать.

В линупсе, при создании симлинков на NTFS разделах, создаются нормальные на первый взгляд симлинки. Но после перезагрузки они превращаются в тыкву в виде файла с атрибутом «Системный», с заголовком «IntxLNK» и каким-то данными после Chr(1). Оказалось, что это какое-то легаси, которое должно работать и в винде, но не через нормальные reparse points, а через какое-то дополнительное ПО, обеспечивающее совместимость с POSIX или типа того (кажется, речь идёт не про подсистему). Короче, в живую я это ПО не видела, так что не в курсе. Что интересно, MINGW32 тоже создаёт такие файлы, но при этом правильно парсит их, ls показывает их как симлинки, ну и входящие в комплект программы тоже работают с ними, как с симлинками. Просто интересное наблюдение.

Задача жакафрески, на размышление – тридцать секунд. Есть два компа с Windows 2000, других операционных систем на них нет и не было. Обе стоят на разделе, отформатированном в NTFS. На одном компе версия NTFS – 3.0, тоесть та, что появилась с Windows 2000. На другом – 3.1, тоесть от Windows XP. Вопрос: как так получилось?

А вот интересно... Можно ли сделать кастомную reparse point так, чтобы хранить в ней какие-то свои данные, не связанные с файловой системой? Типа как маскировка данных в файловых потоках, только ещё круче, что прямо код надо писать, чтобы вытащить эти данные.
// Возможно, этот пост содержит часть ответа на вопрос из предыдущего.

Написала код, который изучает симлинк (на самом деле – reparse point) и выдаёт то, на что симлинк ссылается. Проверила – работает. Почти приступила к применению, но тут заметила, что в некоторых случаях код работает неправильно, выдаёт странные результаты. Начала изучать двоичные данные, которые парсит программа, и поняла, что что-то с ними не так: одни поля налезают на другие, хотя в других случаях всё с полями нормально. Начала копаться в MSDN. Оказалось, что документация про всему этому есть, но какая-то туманная, везде недосказанность, функций всего ничего, объясняются только общие концепции. Продолжила копать и повторно открыла для себя раздел «Open Specifications», в котором предельно чётко описаны все структуры, которые в этих самых reparse points используются. И оказалось, что в MSDN была описана одна структура, а в реальности используются другие структуры, по одной на каждый тип симлинков. А та, что описана в MSDN – вообще для сторонних реализаций. В итоге код придётся переписывать и снова всё тестировать. Но я всё равно не понимаю, чего Microsoft так тряслись над этими reparse points так, словно это пентагоновский секрет?

Почему структура GUID не соответствует текстовому виду этого самого GUID?

Обновилась Windows 11. Поотваливались подключения по RDP. Супер. В RDP клиенте по многочисленным просьбам дизайнеров переделали кнопочки, поэтому панелька с кнопками теперь болтается ниже, стала больше и обмазана ШГ, даже значки на кнопках умудрились размазать. Ещё в диалоге свойств RPD соединения криворукие зумеры впилили новый фрейм с галочкой, который не влез по высоте, а посему в окне появился вертикальный скроллбар! Охуенчик! Ещё в меню «Пуск» переделали менюшку (меню в меню, блять), которая появляется при щелчке на имени пользователя. Теперь там логотип Microsoft, который конфузит, и тебе поначалу кажется, что пользователь как-то просочился не с локальной учёткой. Более того, криворукие зумеры решили, что отображаемое имя пользователя – это всегда что-то вроде «BG» (не путать с «BJ»), а посему длинное имя уходит за границы менюшки, обрубаясь краем оной. Зато дизайнеры в экстазе, наконец Microsoft избавляется от старого интерфейса™.

Заметила, что логи CHKDSK, которые в «System Volume Information» лежат, зачем-то в конце содержат кусок из нулей. Озадачилась. Потом вдруг заметила размер файлов и поняла, что нулями оно выравнивает этот размер до килобайтной границы. Зачем – БП. Возможно, что, когда программа запускается из нативного режима при загрузке системы, драйверы ещё не все загружены, и работает что-то вроде упрощённого драйвера NTFS, который не умеет работать с невыровненными файлами. А при запуске программы в обычном режиме, выравнивание случается для совместимости. Но это просто рандомное предположение, возможно, у Рэймонда Чена есть про это.

Оказалось, что старые версии Windows испытывают некоторые затруднения в парсинге строк и эмодзиками. Ну или это я что-то не так делаю, либо хочу не того. Короче, мне надо было взять строку в UTF-8 и заэкранировать ей в HTML кодах. Всякие CharNextW() давали мне не то, что нужно, а то и вообще ничего не давали. Поэтому пришлось открыть доки и написать собственный парсер UTF-8 строки =_= И он даже заработал.