Как получить guid windows

Как получить guid windows

Добрый день! Уважаемые читатели и подписчики IT блога Pyatilistnik.org. В данной статье я приведу один из методов извлечения цифрового идентификатора приложения из реестра Windows. Правильное название: статистически уникальный 128-битный идентификатор . Если Вы знаете ,то можете открыть любой компонент Windows, shell. где — shell — интерпретатор команд Windows. и произвести удаление приложения. Но обо всем по порядку.

Что такое GUID?

GUID — это аббревиатура, которая обозначает глобальный уникальный идентификатор , их также называют UUID или универсальные уникальные идентификаторы — между ними нет реальной разницы. Технически это 128-битные уникальные ссылочные номера, используемые в вычислениях, которые вряд ли будут повторяться при генерировании, несмотря на отсутствие центральных полномочий GUID для обеспечения уникальности.

GUID (глобальный уникальный идентификатор) — это термин, используемый Microsoft для числа, которое ее программа генерирует, чтобы создать уникальную идентичность для объекта, такого как документ Word. Идентификаторы GUID широко используются в продуктах Microsoft для идентификации интерфейсов, наборов реплик, записей и других объектов. Разные виды объектов имеют разные виды GUID — например, база данных Microsoft Access использует 16-байтовое поле для создания уникального идентификатора для репликации.

Типы GUID

Существует 5 версий идентификаторов GUID, определенных в RFC 4122 , каждая с разными свойствами. Чтобы определить версию GUID, просто посмотрите на цифру версии, например, GUID версии 4 имеют формат xxxxxxxx-xxxx- 4 xxx- N xxx-xxxxxxxxxxxx, где N — это одно 5 значений 4, 8,9, A или B.

  • Версия 1: дата-время и MAC-адрес — Эта версия генерируется с использованием текущего времени и MAC-адреса клиента. Это означает, что если у вас есть GUID версии 1, вы можете выяснить, когда он был создан, проверив значение метки времени.
  • Версия 2: DCE Security — Эта версия специально не определена в RFC 4122, поэтому не должна генерироваться совместимыми генераторами. Он аналогичен GUID версии 1, за исключением того, что первые 4 байта метки времени заменяются пользовательским UID или GID POSIX, а старший байт последовательности часов заменяется доменом UID / GID POSIX.
  • Версия 3: MD5 хэш и пространство имен — Этот GUID генерируется путем взятия пространства имен (например, полного доменного имени) и заданного имени, преобразования в байты, объединения и хеширования. После указания специальных битов, таких как версия и вариант, полученные байты затем преобразуются в его шестнадцатеричную форму. Особое свойство этой версии заключается в том, что идентификаторы GUID, сгенерированные из одного и того же имени в одном и том же пространстве имен, будут идентичны, даже если они генерируются в разное время.
  • Версия 4: случайная — Этот тип GUID создается с использованием случайных чисел — из 128 битов в GUID 6 зарезервированы для специального использования (версия + вариантные биты), что дает нам 122 бита, которые могут быть заполнены случайным образом. Спецификация не определяет, как должны генерироваться случайные числа, они могут быть любыми, от псевдослучайных до криптографически безопасных, поэтому эти GUID, как и все другие GUID, следует использовать только для идентификации, а не для безопасности.
  • Версия 5: SHA-1 хэш и пространство имен — Эта версия идентична версии 3 за исключением того, что SHA-1 используется на этапе хеширования вместо MD5.

Разделы реестра, где нужно искать:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Uninstall
  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ Microsoft\Windows\CurrentVersion\Uninstall

Как узнать GUID приложения

Пример вызова компонента Windows диспетчер устройств:
shell. <74246bfc-4c96-11d0-abef-0020af6b0b7a>,для запуска необходимо вызвать диалоговое окно «Выполнить» используя клавиши Win + R, прописать данный код и нажать«OK» Все значения хранятся в разделе реестра HKEY_CLASSES_ROOTCLSID. Зайдя в CLSID поиск, лучше всего производить методом перебора значений для правильного определения в значении должен присутствовать подраздел ShellFolder. Для поиска нужного необходимо иметь время и терпение. Итак, всё по порядку.

Как узнать из реестра GUID приложения в Windows -01

Раздел реестра HKEY_CLASSES_ROOTCLSID

Клавишами Win + R открываем диалоговое окно «Выполнить» вводим команду regedit — открыть редактор реестра. Для поиска заходим в раздел реестра HKEY_CLASSES_ROOTCLSID

Пример: нам нужен «Панели управления — Control Panel», методом перебора значений находим нужный, смотрим наличие подраздела ShellFolder.

Как узнать из реестра GUID приложения в Windows -02

Для того, чтобы извлечь и проверить правой клавишей мыши нажимаем на значение, в открывшемся меню выбираем пункт «Экспортировать», и сохраняем с расширением .reg

Как узнать из реестра GUID приложения в Windows -03

Созданный файл реестра лучше всего открыть программой Notepad ++ познакомиться с которой можно в категории сайта «Офис».Если Вам понравился текстовой редактор Notepad ++ и Вы его установили, то правой клавишей мыши нажимаем на созданный файл реестра. В открывшемся меню выбираем «открыть с помощью Notepad ++ таким образом можно ознакомиться со структурой и синтаксисом файла реестра.

Как узнать из реестра GUID приложения в Windows -04

Выделяем значение, с помощью клавиш Ctrl + C копируем, вызываем диалоговое окно «Выполнить» и с помощью клавиш Ctrl + V вставляем, перед фигурными скобками прописываем Shell. и нажимаем«OK».

Как узнать из реестра GUID приложения в Windows -05

Как узнать GUID через PowerShell

Для того, чтобы вы могли быстро извлечь информацию, о GUID ,я могу вам предложить небольшой скрипт:

Еще один вариант воспользоваться вот такой конструкцией:

Тут мы еще вывели пути расположения MSI пакетов для удаления приложения и его ремонту.

Как узнать GUID через CMD

Откройте cmd от имени администратора и выполните команду, которая создаст на диске C:\ файл с отчетом

Источник

Как узнать и изменить UUID/GUID компьютера?

Каждый компьютер в сети должен иметь уникальный идентификатор UUID или GUID (в терминологии Microsoft). Он позволяет на базе этого ID аутентифицировать и активировать (при необходимости активации лицензий) компьютер.

Чтобы узнать GUID Windows компьютера, выполните команду Powershell на локальном компьютере:

get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

get-wmiobject Win32_ComputerSystemProduct -computername PC_NAME | Select-Object -ExpandProperty UUID

Это же значение содержится в реестре в ветке HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid.

Однако, если речь идет о виртуальных машинах, Vmware технически позволяет создать (или клонировать) машины, сохраняя идентичный UUID, что конечно плохо. UUID основан на пути к конфигурационному файлу VM и он генерируется, когда вы первый раз включаете машину или ресетите (сбрасываете до изначального состояния) её. Эта информация записывается в SMBIOS файл конфигурации виртуальной машины — *.vmx. Файл текстовый, его можно редактировать в текстовом редакторе.

Нужная вам строка будет выглядеть примерно так: uuid.bios = «00 11 22 33 44 55 66 77-88 99 aa bb cc dd ee ff»

Соответственно, вы можете поменять значение на уникальное. Все действия необходимо производить на выключенной виртуальной машине.

Альтернативно, вы можете изменить UUID группы виртуальных машин, если они расположены на ESXi, через PowerCLI, используя скрипт на Powershell.

Источник

Определение и экспорт новых идентификаторов GUID

Вы определяете новый идентификатор GUID для элемента, который экспортируется драйвером в другие системные компоненты, драйверы или приложения. Например, вы определяете новый идентификатор GUID для пользовательского события PnP на одном из его устройств. Чтобы определить и экспортировать новый идентификатор GUID, необходимо выполнить следующие действия.

Выберите символическое имя для GUID.

Выберите имя, представляющее назначение идентификатора GUID. Например, операционная система использует такие имена, как GUID_BUS_TYPE_PCI и PARPORT_WMI_ALLOCATE_FREE_COUNTS_GUID.

Создайте значение для идентификатора GUID, используя Uuidgen.exe или Guidgen.exe. при установке Microsoft Windows SDK автоматически устанавливается Uuidgen.exe. Guidgen.exe доступен на странице загрузки генератора GUID Microsoft Exchange Server .

Эти служебные программы формируют уникальную форматированную строку, представляющую 128-разрядное значение. Параметр «-s» в Uuidgen.exe выводит GUID, отформатированный как структура C.

Определите идентификатор GUID в соответствующем файле заголовка.

Используйте макрос DEFINE_GUID (определенный в гуиддеф. h), чтобы связать символьное имя GUID со своим значением (см. Пример 1).

Пример 1. Определение идентификаторов GUID в файле заголовка GUID-Only

Если идентификатор GUID определен в файле заголовка, содержащем инструкции, отличные от определений GUID, необходимо выполнить дополнительный шаг, чтобы убедиться, что экземпляр GUID создан в драйверах, включающих файл заголовка. Оператор DEFINE_GUID должен находиться вне инструкций #ifdef , препятствующих множественному включению. В противном случае, если файл заголовка включен в предкомпилированный заголовок, идентификатор GUID не будет создан в драйверах, использующих файл заголовка. Пример определения GUID в файле смешанного заголовка см. в примере 2.

Пример 2. Определение идентификаторов GUID в файле смешанного заголовка

Размещение определения GUID вне инструкций, предотвращающих множественное включение, не приводит к созданию нескольких экземпляров GUID в драйвере, поскольку DEFINE_GUID определяет GUID как переменную EXTERN_C. Несколько объявлений переменной типа EXTERN допускаются, пока типы совпадают.

При создании идентификатора GUID для нового класса установки устройства или класса интерфейса устройстваприменяются следующие правила.

Не используйте один GUID для одновременного задания класса установки устройства и класса интерфейса устройства.

При создании символьного имени для сопоставления с GUID используйте следующее соглашение:

Для классов установки устройств используйте формат GUID_DEVCLASS_xxx.

Для классов интерфейсов устройств используйте формат GUID_DEVINTERFACE_xxx.

Источник

Сказка про Guid.NewGuid()

C#. Guid.NewGuid() . Linux. Windows. Randomness or Uniqueness. RNG and PRNG. Performance. Benchmarking.

Цель нашей сегодняшней сказки — развлечься как следует. Детективная история в поисках потерянного перфоманса с красивым финалом и эффектным результатом непосредственно связана с набором слов из предыдущего абзаца.

Художественное отступление, шутка на текущую тему. Читать совершенно не обязательно.

— О, Tux, давно не виделись! — Con, широко улыбаясь, выглядывал из распахнутого окна.

— Здравствуй, Con! Вот, вернулся ненадолго. Как дела, как жизнь?

— Да всё также. За жильё приходится платить всё больше и больше. Пугают всё время, что что-нибудь отключат или запретят. Но пока хорошо, красиво, удобно, привычно. Да и от старых вещей избавляться не хочется, мороки много с этим. Расскажи лучше, как твой переезд, каково там?

— Знаешь, Con, я толком понять не успел. Жильё бесплатное. Но обустраивать самому приходится. В целом, всё также. И одновременно всё не так… точно могу сказать, что переезжать было не просто. Тосковал по старому дому, привыкал к новому климату. От некоторых старых вещей пришлось избавляться, потому что нельзя с ними переезжать. Ещё, точно могу сказать, что жить там тяжелее. Как будто на само существование нужно тратить больше сил, больше внутренних ресурсов.

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

— А недавно я заметил вообще интересную вещь! Я стал очень много времени проводить в придумывании уникальных имен всяким своим штукам. Не знаю почему. Раньше раз, и выдумывалось быстро. А сейчас, как только пытаюсь дать уникальный идентификатор чему-нибудь, так сразу зависаю надолго.

— Во дела.. а чего ты именно туда-то поехал, а, Tux?

— Да просто. Пингвинов хотел посмотреть, очень их люблю.

Каждый раз, когда мы хотим выдумать уникальный идентификатор для какой-нибудь сущности, чтобы она уж точно не была ни на что не похожей, первым в голову приходит Guid. Или, если назвать его имя полностью, Globally Unique Identifier.

Guid — это конкретная реализация стандарта UUID (Universally Unique Identifier).

Guid — это «случайные» 128 бит. Или, 2^128 вариантов (на самом деле чуточку меньше, там есть зарезервированные биты). Это ОЧЕНЬ много. Вероятность сгенерировать два одинаковых Guid’а невероятно мала. Настолько мала, что все условились считать их уникальными.

Guid — это не про security, это про uniqueness. То есть его не стоит использовать для криптографических целей или даже для генерации паролей. Хотя, нам повезло и на Windows (и даже на Linux) по факту прямо сейчас нам дают 122 бит энтропии. И вроде даже обещают не ломать это в будущем (в том же XML документе).

Guid — весьма интересная штука. И продолжать накидывать про неё фактов можно очень долго.

Дело было вечером, делать было нечего

Как-то раз ковырялись в трейсах приложений в поисках ответа на вопрос «почему один и тот же код на Линуксе потребляет в полтора раза больше CPU, чем на Винде». Помимо прочего, в глаза бросалась большая разница во времени, проведённом приложением внутри функции Guid.NewGuid() . На Линуксе оно занимало аж 5.4% от всего времени работы приложения. А на Винде сильно меньше. Вот скриншот PerfView, на котором видно функцию генерации гуида:

Первые две строчки на скриншоте выше — это бессмысленные ожидающие потоки. Они практически ничего не потребляют у приложения, но занимают много времени, отчего всплыли в топ. Если их скрыть, то выйдет, что генерация гуидов занимает аж 8.6% от времени работы приложения (На Windows эта функция потребляла намного меньше):

Почему употребляется термин время, а не CPU?

Средства анализа .NET приложений показывают несколько разную картину в зависимости от ОС, на которой было запущено само приложение. Так, большинство CPU работы, проведённой внутри ОС Linux, неотличимы от всяческих ожиданий при изучении приложения с помощью PerfView. Например, Thread.Sleep() будет неотличим от CPU-bound функции в .nettrace артефактах.

Такие трейсы, снятые на Linux, померили нам время, проведённое всеми тредами приложения в этих стеках. Вне зависимости от того, работал ли CPU внутри этого стека. И в данный момент они попадают в категорию «UNMANAGED_CODE_TIME». В «CPU_TIME» находится только наш managed C# код.

На данный момент, на мой взгляд, на Windows дела со снятием и анализом трейсов обстоят несколько лучше.

Изучаем Guid.NewGuid()

Не то чтобы медленный Guid.NewGuid() был основной причиной нашей проблемы. Было очевидно, что разница в нескольких процентах от всего приложения — это не то, что мы ищем, расследуя разницу в полтора раза. Но всё-таки было интересно, что такого особенного в генерации гуида и откуда такая разница в зависимости от ОС.

Чтобы это выяснить, мы соорудили предельно простой бенчмарк одной функции: Guid.NewGuid() . Запустили на Windows и на Linux (Centos 7) на виртуалках одинаковой конфигурации.

Запускать в каком-нибудь WSL было бы неправильно. Это всё-таки эмулятор (на самом деле далеко нет, но такому бенчмарку доверять всё равно было бы нельзя). А процессоры машин разработчиков это не процессоры на проде.

Результат подтвердил то, что мы видели в трейсах:

Извините, скриншоты потерялись, остались лишь текстовые представления

Но легко повторить такой эксперимент самостоятельно. Дам лишь небольшой хинт. Если вы захотите считерить и собрать проект с бенчмарком у себя на рабочей машине, чтобы затем перенести лишь исполняемые файлы для запуска на другой виртуалке, разочарую вас. Нужно именно собрать проект на целевой машине и запускать бенчмарк из папки с проектом. Этому есть причины. BenchmarkDotNet умный, но хитрый. И хитрый, но умный 😉

Разница просто колоссальная. Создание Guid’а на Линуксе в 16 раз медленнее, чем на Винде! Давайте разбираться, почему так.

Разбираемся

Хочется заглянуть внутрь реализации и посмотреть, что же там такого интересного. Раз производительность зависит от ОС, доверять декомпиляции метода Guid.NewGuid() на своей рабочей машине неправильно. Отправляемся на гитхаб, где можно найти исходники. Находим там два файла с кусочками partial class’ов: Guid.Unix.cs и Guid.Windows.cs.

Кстати, сразу видим интересный комментарий, что генерация Guid’а на Linux’е намеренно пользуется криптографически стойким генератором случайных чисел. Как и в Windows. Но генерация гуида это всё ещё не рекомендуемый способ придумывать «действительно» криптостойкие ключи. Как минимум потому, что в нём есть один предсказуемый бит версии, а утечка хотя бы одного бита информации может быть фатальной.

Linux

Если раскапывать цепочку системных вызовов в случае Linux ветки, можно докопаться до вот такого кода на C. Если кратко, то мы читаем случайные байты из /dev/urandom . Несмотря на то, что в man /dev/urandom говорится, что его не стоит использовать в криптографических целях, это не так. Исключения составляют, кажется, первые мгновения жизни Linux системы, когда генератор шумов ещё не набрал нужный уровень «случайности» (я не умею это доказывать и не имею ссылки на авторитетный источник).

Информация актуальна на момент написания статьи.

Если покопаться в истории коммитов, то там было множество различных вариантов реализации. Например, какое-то время случайные числа брались из /dev/random . Это генератор «действительно» случайных чисел из шумов процессора (RNG), однопоточный и блокирующий вызовы до тех пор, пока не накопится достаточно «случайности».

Также в истории коммитов можно найти, как добавлялись реализации для Apple, или как чинят билды под ARM. Всё-таки, как удобно иметь платформу, которая прячет от тебя весь этот кошмар в различиях операционных систем и даже архитектур.

Windows

Если кратко говорить про Windows, то тут мы пользуемся функцией CoCreateGuid , которая просто перевызывает RPC функцию UuidCreate . А она, в свою очередь, перевызывает генератор случайных чисел CryptGenRandom (или RtlGenRandom в каких-то очень старых версиях). Дальше и подробнее что-то рассказать сложно, потому что, кажется, те исходники, что я нашел в интернете, получены не самым честным путём.

Дак что в итоге?

Судя по ответам на гитхабе, цепочка вызовов на Windows просто быстрее, чем рассмотренное нами выше чтение из /dev/urandom на Linux, поскольку несет в себе меньше оверхеда на всякие системные штуки. Печально.

Как можно обойти эту нелепую ситуацию?

Давайте вернемся в самое начало, к трейсу. На самом деле, если поизучать его более пристально, то видно, что 100% всех гуидов в нашем приложении мы генерируем для телеметрии:

Vostok.Tracing — библиотека, имя которой говорит за себя. Она создаёт трейсы, а метод BeginSpan создаёт спаны. Аналогичные тем, что можно увидеть, например, в opentelementry. Vostok.Hercules.Client — библиотека, вспомогательная к сбору этой телеметрии.

В телеметрии нам уж точно не нужна криптостойкость. Нам просто хочется, чтобы гуиды редко совпадали. И кажется, что можно попробовать взять быстрый и простой псевдослучайный генератор случайных чисел (PRNG) и с помощью него создавать гуиды. В C# уже есть Random , генератор псевдослучайных чисел. Давайте его и попробуем.

Что такое гуид? 16 байт. Random предназначен для того, чтобы генерировать int, то есть 4 байта. Давайте вызовем Random.Next() 4 раза и соберем из них Guid. Даже не будем выставлять нужные битики, как того требует RFC, кому они нужны. И ещё, да, мы потеряем целых 4 бита на знаковых битах int’а, поскольку Random генерирует только положительные числа. Из 128 бит осталось 124 псевдослучайных. Этого уж точно хватит на нашу телеметрию.

Вспомним про многопоточность, ведь гуиды для телеметрии могут создаваться параллельно во всех потоках, а Random не потокобезопасный. Чтобы очень быстро и просто защититься от гонок, навесим на наш инстанс класса Random атрибут ThreadStatic . Крайне не рекоммендую слепо использовать этот атрибут в каждом месте. Он далеко не универсален и со своими недостатками. Просто здесь он пришелся очень кстати.

Реализация и снова бенчмарки

Снова запускаем наш бенчмарк, смотрим, что получилось:

Отлично! Теперь мы умеем генерировать «Guid» на Linux почти так же быстро, как на Windows! Смущает разве что следующее. Используя метод Guid.NewGuid() на Windows, мы обращаемся в winapi, используем криптостойкий генератор случайных чисел, и вообще делаем interop за пределы .NET’а. А наш метод — чистый managed код. И работает с такой же позорной скоростью.

Нетрудно догадаться, на что потратилось много времени. Чтобы сгенерировать 16 байт нам нужно 4 раза вызвать Next() . А значит 4 раза обратиться к ThreadStatic полю. И доступ к ThreadStatic полю, очевидно, дорогой. Воспользуемся некоторыми знаниями устройства тредпула и работы потоков, чтобы обойти это.

Мы делаем 4 обращения к полю random в цикле. Это целиком и полностью синхронный код. Значит между итерациями цикла не может быть context switch’ей (на уровне .NET’а). А значит ThreadID всегда будет одинаковый. А значит мы все 4 раза будем доставать за дорого один и тот же инстанс класса Random . Дак давайте достанем его один раз.

Снова запускаем наш бенчмарк. Для сравнения запустим и старую и новую версию нашего собственного генератора Guid’ов.

Чудесно. Мы умеем генерировать не-криптостойкий «Guid» за 31 строчку кода. Который на Windows быстрее встроенного Guid.NewGuid() в

2 раза. А на Linux быстрее встроенного Guid.NewGuid() в

А можно ещё лучше?

Предложенная выше реализация справедлива для Netstandard2.0. Всё-таки, поддерживать старые проекты под .NET FW нужно, не все из них обновлены до современных версий .NET. Но, к счастью, мы можем писать код так, чтобы под свежей версией .NET использовался другой код. А в .NET 6 как раз появилось несколько полезных вещей.

Воспользуемся сразу двумя фичами .NET 6. Во-первых, появился специализированный Random.Shared . Больше не нужно извращаться с атрибутом [ThreadStatic] . Теперь код нашего ThreadSafeRandom можно написать так (или, при желании, вообще от него избавиться):

Перед тем, как перейти ко второй фиче, сделаем небольшой исторический экскурс. Поначалу, генерация гуидов на Linux была в

100 раз медленнее, чем на Windows. Потому что из генератора случайных чисел читали по одному байту. Потом стали читать пачками, тем самым свели к текущему положению дел. Эта история должна была нас кое чему научить.

В .NET 6 есть способы генерировать куда больше случайных байт за один вызов, чем 4. А именно, появился NextInt64() . А в паре с ним появился и NextBytes(Span buffer) . Незамедлительно ими воспользуемся. Приведу пример только с NextBytes :

Давайте проверим, стало ли лучше? Снова запустим бенчмарк.

Я не стал приводить весь код бенчмарка, чтобы не нагромождать статью однотипным кодом. Поэтому просто дам краткую расшифровку:

GuidNewGuid — генерация вызовом метода Guid.NewGuid() .

GenerateInt32 — генерация вызовом метода random.Next() 4 раза.

GenerateInt64 — генерация вызовом метода random.NextInt64() 2 раза.

GenerateBytes — генерация вызовом метода random.NextBytes(Span buffer) .

Чудесно. Мы умеем генерировать не-криптостойкий «Guid», который на Windows быстрее встроенного Guid.NewGuid() в

5 раз. А на Linux быстрее встроенного Guid.NewGuid() в

Извлечём практическую пользу

Не пропадать же добру.

Этот генератор Guid’ов уже давно крутится в куче сервисов. С помощью него мы генериуем идентификаторы спанов, трейсов, и прочих эвентов телеметрии. Код можно найти на гитхабе: GuidGenerator и одно из использований, генерация трейсов и спанов. И вся данная телеметрия успешно отправляется и обрабатывается в Hercules’е — системе сбора, хранения и обработки логов, метрик, распределённых трассировок и аннотаций.

Но тут не всё рассказано!

Как обычно, мы прошли мимо большого количества всяких интересностей:

А можем ли мы генерировать псевдослучайные числа ещё быстрее? Что на счет максимально быстрой реализации на SIMD? Конечно можем. Всех интересующихся направляю на SIMDxorshift. Здесь не буду утомлять кодом на C и SIMD-инструкциями.

А есть что-нибудь ещё в .NET’е, что неожиданно и кардинально меняет свою производительность при переходе с Windows на Linux? Конечно есть. И много чего. Да хотя бы работа со строками и кодировками чего только стоит. Но об этом, может быть, в другой раз.

Что за заклинания с [MethodImpl(MethodImplOptions.AggressiveInlining)] и (int*) ? Достойно отдельной статьи. Двух разных.

Как снимать и как анализировать трейсы .NET приложений? Тоже достойно отдельной статьи.

Почему на виртуалках одинаковой конфигурации наш полностью managed-код с использованием Random все равно имеет разную скорость исполнения на Linux и Windows? Сложно сказать. Разница небольшая и, возможно, виртуалки просто крутились на разных гипервизорах с разной производительностью железа.

Если углубляться в каждый нюанс, статья получится бесконечной. Но вы всегда можете предложить какую-нибудь конкретную тему для следующей статьи в комментариях или в личке.

Источник

READ  Как поменять назначение боковых клавиш на мышке windows 10