Ранее я писала, что по какой-то причине вызов встроенной функции DateAdd() в VB3 прекрасно работал в Windows 3.11, но выдавал ошибку «File not found» в 32-разрядных виндах.
Неожиданно в Пойнте мне посоветовали помониторить процесс:
#orvhfn/#3
По-началу я скептически отнеслась к этой идее, поскольку Win16 приложения в 32-битных виндах работают в виртуальной машине и даже своего процесса не имеют. Мало ли, как оно там внутрях работает. Но, подумав, всё же решила попробовать, тем более, что ранее меня всё равно посещала такая идея.
Взяла FileMon (ProcMon более жёстко по отношению к ресурсам системы действует, и у меня комп как-то даже вешался от него), отфильтровала NTVDM.EXE, и посмотрела, что происходит при запуске тестовой программы. С первого раза ничего такого почему-то не заметила, а вот со второго увидела, что какой-то MSAFINX.DLL активно разыскивается в PATH, но не обнаруживается. Глянула – действительно, в системном каталоге такого файла нет, зато он есть в системном каталоге Windows 3.11. В описании – «Finance And Miscellaneous Functions for Microsoft Visual Basic». В экспортах – в том числе CIDATEADD.
Скопировала файл прямо в папку к программе, и всё неожиданно заработало OO
Решила выяснить, что это за файл такой. Поискала в каталоге с VB3 упоминания этого файла, и нашла их не только в PACKING.LST (полный список всех файлов дистрибутива с пояснениями и разбивкой на оригинальные дискеты, где их можно найти), но и в VB.HLP. Поискала в самой справке VB3, ну и в числе прочего нашла ту самую функцию DateAdd(), а в её описании, в самом конце – пояснение:

Distribution Note
When you create and distribute applications that use this function in your code, you should install the file MSAFINX.DLL in the customer's Microsoft Windows \SYSTEM directory. The Visual Basic Setup Kit provides tools to help you write setup programs that install your applications.

Полагаю, что дело было так. В прочих виндах я VB3 таскаю прямо каталогом без какой-либо установки, разве что VBRUN*.DLL закидываю в системный каталог. Поэтому нужного файла у меня не оказалось. А вот в Windows 3.11 я прямо всё устанавливала с образов дискет, чтобы у меня группа в Диспетчере программ появилась и всё такое прочее. Ну и файл тоже установился. А столь важную пометку я никогда не читала потому, что я и так знаю, как работает функция, и в VB6 она не требует никаких дополнительных библиотек. Вот и получилось то, что получилось =_=

С парсингом данных счётчиков производительности и вычислением значений из этих данных, вроде как разобралась. А всё из-за вот этого фрагмента из MSDN:

Windows NT: To obtain the time elapsed since the computer was started, look up the System Up Time counter in the performance data in the registry key HKEY_PERFORMANCE_DATA. The value returned is an 8 byte value.

Оказалось, что WMI иногда сходит с ума и выдаёт странные значения, ну вот я и заинтересовалась...

Разбираюсь со счётчиками производительности Windows. При чём самым хардкорным методом, без дотнет обёрток, без DPH.DLL, а прямо через реестр с парсингом двоичных данных. И это пипец, надо сказать ^^'
Пробовала спрашивать нейросети, но те либо откровенную дичь несут, либо всё к тем же обёрткам отсылают. Один запрос вообще выдал мне некий скелет, куда нейросеть предложила самостоятельно дописать код, который меня и интересовал.
Поэтому пришлось читать и страдать. Страдать в основном потому, что там нет шортката, быстрого кода, который можно написать для решения конкретной задачи и не разбираться со всем остальным. Разбираться таки придётся ^^'

В заголовочнике winperf.h обнаружились константы:
• PERF_DETAIL_NOVICE
• PERF_DETAIL_ADVANCED
• PERF_DETAIL_EXPERT
• PERF_DETAIL_WIZARD

Ещё с нулевых у меня был код на VC++, который форматировал Double в удобочитаемый вид. Сначала он делает так:

sprintf(TXT, "%lf", dblByaka);

На выходе получается что-то в духе «123.456789», а потом TXT пизается в GetNumberFormat(), который уже форматирует этот текст в то, что задано в региональных настройках (или что укажешь в специальной структуре).
Недавно вдруг обнаружилось, что в Windows 2000 и ниже этот код возвращает пустую строку при очень маленьких значениях dblByaka. Начала разбираться и выяснила, что sprintf() выдаёт мне «0,000000123» вместо «0.000000123». Тоесть именно в этом случае он ставит запятую вместо точки, как это происходит во всех остальных случаях. А вот в Windows XP и выше такого не наблюдается. Мистика.

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 так, чтобы хранить в ней какие-то свои данные, не связанные с файловой системой? Типа как маскировка данных в файловых потоках, только ещё круче, что прямо код надо писать, чтобы вытащить эти данные.
// Возможно, этот пост содержит часть ответа на вопрос из предыдущего.