Runtime: Опрос: родной AOT

Я не мог найти лучшую метку области, чтобы добавить к этой проблеме. Если у вас есть права на запись, пожалуйста, помогите мне научиться, добавив ровно одну метку области .

Похоже на опечатку - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) Может это должно быть "частью"?

Я так рад видеть эту проблему! 😄🚀

Вопрос: для разработчиков UWP, которые работали с цепочкой инструментов .NET Native, должны ли мы ответить на опрос, просто сказав, что мы не использовали CoreRT раньше, или поскольку .NET Native имеет много общего (и некоторый общий код тоже?) с CoreRT, следует мы просто упоминаем об этом в примечаниях, а затем отвечаем на другие вопросы CoreRT только в отношении нашего опыта работы с .NET Native? 🤔

@ Sergio0694, спасибо за вопрос UWP. Я согласен, я думаю, что имеет смысл упомянуть об этом в примечаниях и ответить на использование corert, если вы использовали версию с открытым исходным кодом.

Спасибо за публикацию этого опроса!

Я также был сбит с толку тем, как отвечать на определенные вопросы как разработчик UWP, который использовал только .NET Native. У меня есть несколько мнений о цепочке инструментов UWP .NET Native, но я не нашел места, где их записать. Совершенно нормально, если это выходит за рамки данного обзора, но, возможно, стоит уточнить.

Я также подозреваю, что «поскольку .NET Native используется по умолчанию для выпусков UWP и требуется в Магазине», вероятно, является наиболее распространенной причиной, по которой люди используют AOT, но это не один из предварительно заполненных ответов на вопрос 5.

Спасибо, что включили Avalonia в параметры графического интерфейса :) Мы уже экспериментировали с CoreRT+Avalonia раньше, и в результате получились великолепные нативные приложения с графическим интерфейсом :D, хотя мы не поддерживали совместимость с тех пор, как прошло 2 года...

Часто забываемая часть .net — это разработка игр, многие платформы не позволяют запускать JIT, подумайте о консолях или устройствах IOS.
Для будущего разработки игр очень важно получить родной AOT для .net в качестве первоклассного гражданина экосистемы .net.
Некоторые игровые движки развернули свои собственные AOT (например, Unity делает это с il2cpp), но это абсолютное крушение поезда.
Так что официальное решение было бы более чем кстати. Это может стать событием, которое изменит отрасль.
Не забывайте, что игровая индустрия обгоняет киноиндустрию как по прибыли, так и по обороту.
Консоли — это то место, где делается основная прибыль.

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

...

AOT в основном имеет значение в приложениях с графическим интерфейсом. Вот где нужно сосредоточиться. Я не вижу, чтобы веб-приложение, сервисы и т. д. нуждались в этом.

Я не согласен. Для лучшего UX конечного пользователя AOT со статической компоновкой необходим для игровых движков , бессерверных микросервисов , настольных приложений с графическим интерфейсом , приложений для iOS и Android , клиентских SPA/библиотек на основе WASM и базовых инструментов CLI (~ несколько МБ).

Я хотел, чтобы я мог легко компилировать свой код с помощью AOT, пробуя все вышеперечисленные сценарии на C# в течение последних нескольких лет, и я чувствую, что .NET сильно уступает по сравнению с языками на основе LLVM, такими как Rust.

Причина, по которой текущие варианты публикации выглядят «хорошо», заключается в том, что .NET исторически не подходил для описанных выше сценариев, и люди просто реализуют свои собственные AOT (например, Unity, UWP, Mono) при использовании C#. Частичные решения AOT, такие как поскольку собственный образ (например, ReadyToRun) может «помогать» в сценариях холодного запуска для монолитных серверных приложений или больших настольных клиентских приложений, но размер двоичного файла по-прежнему во много раз превышает размер полной среды выполнения AOT.

.NET уже не «хорошо работает» для бессерверных/контейнерных микросервисов — они могут сильно выиграть от компиляции AOT, уменьшенного размера двоичного файла и минимальных зависимостей .
Текущее решение ReadyToRun + многоуровневая компиляция + IL Linker уже достигло предела размера файла, что раздражает для автономных развертываний, таких как рекомендованное AWS Lambda в своем блоге.

Настоящая проблема заключается в том, что в настоящее время существует слишком много сред выполнения/генераторов кода/инструментальных цепочек/экспериментов со своими особенностями: IL2CPP/Burst (Unity), бэкэнд Mono AOT (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), Серверная часть Mono LLVM, CrossGen/ReadyToRun (.NET Core) и т. д., и просто неприемлемо, что .NET не имеет стандартизированного набора инструментов для компиляции AOT.

Если бы все эти команды объединили свои инженерные усилия над чем-то общим, таким как CoreRT, бэкэнд Mono LLVM или ныне заброшенный dotnet/lilic, то AOT был бы гораздо лучшим опытом для разработчиков .NET.

AOT со статическим связыванием теперь доступен большому количеству разработчиков с CI/CD для масс, и это больше не раздражает незначительное увеличение производительности.

Конечная цель C#: собственный код, собственный пользовательский интерфейс, быстрое и простое взаимодействие, собственный экспорт и API-интерфейсы, ориентированные на производительность (например, System.IO.Pipelines, System.Text.Json).

Я не согласен с утверждением, что веб-приложения от этого не выиграют. AOT очень поможет с бессерверными рабочими нагрузками (также известными как Функции Azure). Не говоря уже о преимуществах времени запуска инструментов CLI.

Я ответил на опрос, но, честно говоря, я не получаю этих постоянных опросов с тех пор, как запустили .NET Core 1.0, без четкого направления, куда идут дела.

.NET Native — это то, чем .NET должен был быть с самого начала, когда проект Ext-VOS только начинался, и есть опыт Singularity и Midori, к которому вы, ребята, наверняка имеете отношение, или даже получить некоторые внутренние серверы с ними.

Даже Java решила наверстать упущенные возможности AOT, команда не спрашивает, с какими рабочими нагрузками мы хотим, чтобы она работала.

Мы почти не используем NGEN, потому что с момента выпуска .NET качество генерации его кода никогда не улучшалось, а рабочий процесс развертывания усложняется по сравнению с другими компилируемыми языками AOT.

Поэтому, если в будущем AOT снова будет исключен из .NET, учтите, что вся конкуренция в управляемых языках теперь сосредоточена на цепочках инструментов AOT, и они также не спрашивают, какие рабочие процессы мы хотели бы использовать для компилятора.

Я хочу, чтобы .NET продолжал процветать и был первым вариантом независимо от сценария, и, если что-нибудь, чтобы взять на себя рабочие процессы, где Microsoft по-прежнему заставляет нас использовать C++ вместе с .NET, с которым у других компилируемых языков AOT нет проблем.

Я ответил на опрос, но, честно говоря, я не получаю этих постоянных опросов с тех пор, как запустили .NET Core 1.0, без четкого направления, куда идут дела.

Я думаю, это здорово, что MS пытается прислушиваться к сообществу, а не просто диктовать, чего мы хотим.

@jkotas Я заметил, что распространяются две разные ссылки на этот опрос, это нормально?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce спросите у коллег-разработчиков, которые ответили на аналогичные опросы о кроссплатформенном графическом интерфейсе пользователя, поддержке инструментов WCF и EF, насколько это помогло.

Так что, хотя и приятно, что они спрашивают нас, было бы лучше, если бы действия действительно происходили. Даже для кроссплатформенного графического интерфейса еще неизвестно, действительно ли появится MAUI или мы получим Blazor в веб-виджетах в качестве решения.

Для меня единственное приемлемое решение AOT — это когда оно генерирует истинное собственное приложение без JIT вообще в режиме выпуска (без псевдонима параллельного решения, готового к запуску) и когда оно работает во всех проектах .NET, над которыми работают разработчики. на. Это, в частности, включает Winforms и WPF. В лучшем случае он также должен работать автономно без каких-либо зависимостей во время выполнения, не раздувая себя с 3 МБ до 80 МБ.

¹ По техническим причинам могут быть случаи, когда AOT не поддерживает API. Выражение «на всех» означает поддержку не всех API, а всех типов проектов, которые поддерживает .NET Core: dll/winforms/wpf/winui/console/maui/… Я имею в виду, что разработчики должны взять на себя свои существующие приложения.

_ Я также писал приложения в Delphi, и меня раздражает то, что я просто компилирую, а затем отправляю свой единственный исполняемый файл Delphi в другое место, и он просто запускается. И просто быстрее. То же самое относится и к приложению C++, когда оно скомпилировано определенным образом. И вы по-прежнему можете отлаживать оба приложения, и оба приложения по-прежнему предоставляют полезную трассировку стека/дамп, когда вы решите включить PDB. Но из соображений безопасности вы также можете решить НЕ включать его, что также будет работать нормально. Меня беспокоит вопрос, почему мы не можем иметь то же самое с C#? Когда я услышал о планах AOT, я ожидал ЭТОГО._

Я всегда вижу много упоминаний о проблемах с отражением, и я считаю, что на самом деле не так уж важно, если ядро ​​​​ASP.net создает большой исполняемый файл.

Большинство мест, где AOT является жестким требованием, — это такие вещи, как инструменты CLI, игры и приложения пользовательского интерфейса, они могут быть разборчивы в том, какие библиотеки включать, и могут обойти некоторые проблемы с отражением. Приоритетом должно быть включение приложений «с чистого листа».

Я всегда вижу много упоминаний о проблемах с отражением, и я считаю, что на самом деле не так уж важно, если ядро ​​​​ASP.net создает большой исполняемый файл.

Я думаю, что с выпуском Blazor WebAssembly размер исполняемого файла, а также скорость выполнения будут иметь большое значение, и AOT может значительно выиграть. Но по какой-то причине это даже не упоминалось конкретно в опросе.

Да, красиво, пожалуйста! Я рассматривал возможность использования Rust или CoreRT, чтобы сохранить безопасность памяти и получить нативную скорость, а также чтобы мой код можно было вызывать нативно. Но было бы замечательно иметь AOT в .NET, так как он невероятно богатый и мощный, а Rust, хотя и фантастический, не так просто перейти на него.

@jkotas Я заметил, что распространяются две разные ссылки на этот опрос, это нормально?

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

Для разработки игр нам это нужно, я приостановил работу над своим игровым движком https://github.com/amerkoleci/alimer_sharp в пользу родного движка, использующего c++, я также поддерживаю привязки для DirectX и vulkan, здесь нужна производительность

Для разработки игр нам это нужно, я приостановил работу над своим игровым движком https://github.com/amerkoleci/alimer_sharp в пользу родного движка, использующего c++, я также поддерживаю привязки для DirectX и vulkan, здесь нужна производительность

Здесь тот же сценарий 😄, только я его не приостанавливал. Мне нравится AOT как за лучшее время запуска, так и (и в моем случае, что более важно) за возможность иметь более оптимизированный код — меня устраивает увеличение времени сборки на 50% для ускорения на 10%, что, очевидно, не так. т действительно отношение JIT

Я согласен с увеличением времени сборки на 50% для ускорения на 10%, что, очевидно, не совсем подходит для JIT.

На самом деле это одна из важных второстепенных причин, по которым я хочу использовать AOT в .NET, а не переключаться на другую экосистему. Я полностью избалован быстрым временем компиляции больших проектов .NET по сравнению с большими проектами C++ или Rust.

Я хочу JIT для быстрой итерации во время разработки, но AOT, когда я отправляю что-то своим клиентам.

Я использовал CoreRT для создания кроссплатформенных (и кроссплатформенных) собственных библиотек.

AOT со статической компоновкой срочно необходим для игровых движков в iOS и консольных платформах, которые отключают jit, а также требуют нескольких режимов компиляции aot:

1. полный аот
2. гибридный aot, который поддерживает режим запуска jit + aot или интерпретатор + aot
   гибридный аот действительно важен для игровой индустрии, он может изменить правила игры

AOT со статической компоновкой срочно необходим для игровых движков в iOS и консольных платформах, которые отключают jit, а также требуют нескольких режимов компиляции aot:

1. полный аот
2. гибридный aot, который поддерживает режим запуска jit + aot или интерпретатор + aot
   гибридный аот действительно важен для игровой индустрии, он может изменить правила игры

как моно на платформе iOS, режим запуска aot+interpreter.

Полный Aot, одиночный exe, независимая среда выполнения и отсечение ненужного кода, это определенно делает меня крейгазмом XD

Я ждал этого вопроса 10 лет. Блин, у меня есть 5 классных проектов, которые пылятся на жестком диске, потому что если я их выпущу, то любой ребенок сможет их перевернуть, добавить небольшие изменения в GUI и продать как свои.

Я разработал Robocraft, Cardlife и Gamecraft с Unity на платформе ПК, и мне никогда не приходилось использовать IL2CPP, если только это не требовалось (читай Xbox one), даже для игровых серверов. Я лично считаю сочетание JIT-компиляции и решения наподобие Burst (которое работает лучше, чем я когда-либо мог сделать, используя явные встроенные функции) как более чем достаточное, когда необходима производительность. Однако я понимаю, что AOT необходим для платформ, которым требуется полностью нативный код, и для тех платформ, для которых ценны аппаратные ресурсы. Я понимаю, как разработчики платформы .net могут испытывать смешанные чувства по поводу AOT, но я не думаю, что это вариант, если мы хотим, чтобы он получил более широкое распространение в разработке игр. Честно говоря, меня немного пугает тот факт, что Unity имеет монополию на такие технологии, как IL2CPP и Burst.

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

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

Я бы сказал, что около 25% кода во время прогона создается динамически, поэтому гибридный подход предпочтительнее; некоторая комбинация компиляции AOT и JIT. Если бы динамические биты нужно было интерпретировать, я думаю, что многие преимущества AOT были бы уменьшены, по крайней мере, в нашем случае использования.

Сборщик мусора — наша проблема номер один, которая мешает нам достичь более высокой масштабируемости (например, когда мы получим около 44 ядер). Наличие у компилятора возможности выполнять более глубокую оптимизацию между сборками, агрессивное встраивание и анализ побега может позволить размещать в стеке более короткоживущие объекты, а не в куче.

В нашей кодовой базе есть много мест, где качество JIT-кода становится узким местом, особенно при распределении регистров и работе со многими структурами. Это вынуждает нас писать код, чтобы манипулировать JIT-компилятором, чтобы он делал правильные вещи (перетягивание каната, которое является хрупким, запутанным и сложным в обслуживании) или переходить к нативному коду (и мы теряем большую часть преимуществ из-за отсутствия встраивания). и накладные расходы от переходов GC/PInvoke).

Иногда небольшие улучшения качества кода могут привести к сумасшедшим победам в ходе модели, которая часами работает на многочисленных ядрах. Для нас JIT стал немного хрупким (даже менее детерминированным) с точки зрения производительности, поскольку наша кодовая база меняется по мере разработки. Мы надеемся, что компилятору AOT потребуется гораздо больше времени для компиляции и генерации кода более высокого качества, что уменьшит некоторые из этих ненужных колебаний производительности и позволит нам сохранить большую часть нашего кода на C#.

В целом, я бы хотел, чтобы больше инвестиций вкладывалось как в технологии JIT, так и в технологии AOT.

копия @AndyAyersMS

AOT со статической привязкой срочно необходим для игровых движков в iOS и консольных платформах, которые отключают jit,

Я полностью согласен здесь. Поскольку нам нужно решение этой проблемы (код C#, работающий на игровых консолях для проекта, отличного от Unity), мы используем цепочку инструментов на основе Mono-AOT. Но он имеет некоторые серьезные ограничения и не работает так хорошо.

Поэтому мы рассматриваем возможность запуска CoreRT на трех игровых консолях (XBox One, PlayStation 4 и Nintendo Switch). Первоначальная проверка концепции показывает, что она действительно работает (все еще с некоторыми ограничениями), но уже со значительным улучшением производительности во время выполнения по сравнению с решением на основе Mono.

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

Для нас JIT стал немного хрупким (даже менее детерминированным) с точки зрения производительности, поскольку наша кодовая база меняется по мере разработки.

@ jpapp05 Я хотел бы узнать больше о вашем приложении и, в частности, о вышеупомянутой проблеме, так как это одна из моих основных проблем. Не стесняйтесь обращаться ко мне в автономном режиме (по электронной почте в профиле), если это поможет.

Привет @AndyAyersMS , это было бы здорово. Я свяжусь с вами в автономном режиме, поскольку я могу говорить немного более свободно, но я буду рад опубликовать любое резюме наших обсуждений на благо других.

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

@movedoa см. API NativeLibrary https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

Моя самая большая проблема заключается в том, что обычно .NET можно легко декомпилировать, за исключением UWP Native, по крайней мере, насколько я тестировал (надеюсь, что был прав). Не в «нормальном» мышлении компании кто-то вложит много IP в проект, который можно легко декомпилировать.
Linux — это хорошо, но все настольные приложения в корпоративном мире предназначены для Windows.

Может быть, чтобы облегчить жизнь, поставьте галочку, которая говорит:
СОБСТВЕННАЯ КОМПИЛЯЦИЯ (РАБОТАЕТ ТОЛЬКО ДЛЯ WINDOWS 10 DESKTOP!)
Чувак, сделай это, и я больше не забочусь об AOT. Если это работает для ASP.NET Core, круто! Если нет, то мне действительно все равно.

Кстати, спасибо за создание вопроса и проведение опроса, вы проделали большую работу, потому что спрашиваете мнение людей, которые используют технологию в своей работе. Я думаю (на самом деле я уверен), что вы все еще скучаете по множеству мнений разработчиков настольных компьютеров, которые обычно не вмешиваются в эти вещи на Github. Не все помнят (или знают), что код .NET можно легко декомпилировать и я уверен, что их начальство сошло бы с ума, если бы узнало : grin:.

Не все помнят (или знают), что код .NET можно легко декомпилировать.

Ш-ш-ш... Тот факт, что Rider делает это за вас автоматически, поразителен, когда я пытаюсь понять, как что-то работает за кулисами в Unity или сторонних пакетах. Однако сейчас это не так важно, поскольку большая часть кода изначально открыта, но вы понимаете, что я имею в виду.

@jcbeppler Вы ошибаетесь, это распространенное непонимание байт-кода и нативного, это просто вопрос наличия правильных инструментов.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays — это просто возможное решение, есть и другие варианты.

@MostHated Да, понял. На самом деле декомпилировать программное обеспечение в .NET настолько просто, что оно похоже на открытый исходный код, и многие компании не хотят, чтобы их программное обеспечение было открытым исходным кодом. "Бесплатных обедов не бывает" 😄

@pjmlp Я знаю разницу между декомпиляцией и дизассемблированием. Я ничего не могу сделать против дизассемблирования моего программного обеспечения, но собственная компиляция может сделать программное обеспечение намного более безопасным, потому что человек не может выполнить очень простую декомпиляцию. Дизассемблированное программное обеспечение определенно будет выглядеть странно, и дизассемблированный код может даже работать некорректно.

@jcbeppler Вы ошибаетесь, это распространенное непонимание байт-кода и нативного, это просто вопрос наличия правильных инструментов.

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

Нативное приложение можно разобрать. Но он не раскрывает полный исходный код C++/Delphi и т. д. (есть некоторые инструменты, которые пытаются перестроить этот исходный код, но результаты ужасны). В лучшем случае вы получаете код на ассемблере и блок-схемы управления. Если вам повезет, и он поставляется с файлом символов, вы также получите имена функций, но в режиме выпуска этот файл символов обычно не включается, опять же из соображений безопасности.

Мы можем погрузиться в детали, говоря о том, что нативный код является реальной защитой. На мой взгляд, это не защита с точки зрения взлома (хотя благодаря полным полным именам методов/переменных и полной генерации исходников на C# проверку лицензии можно убрать без особых знаний) или отладки, а защита от стилеров. Такие инструменты, как dnSpy, могут даже экспортировать приложение .NET в полноценный проект VS ОДНИМ ЩЕЛЧКОМ. Нет такого инструмента, который работал бы так же для нативного кода. Таким образом, для коммерческих приложений было бы огромной победой генерировать собственный код, помимо того факта, что им больше не нужно платить тысячи долларов в год за что-то, что просто переименовывает все методы и переменные в конечном приложении.

Меня интересуют результаты этого опроса. Есть ли планы опубликовать информацию о том, как люди голосовали?

@Symbai Это не защита ни от чего, как скажет вам любой разработчик Android, который пытался использовать NDK как средство защиты своей интеллектуальной собственности. Приложения, которые вы вкратце упомянули, могут делать то же самое одним щелчком мыши, и хотя они обычно предполагают код C или C++ в качестве исходного кода, они достаточно хороши, чтобы украсть ваши алгоритмы.

Я хочу AOT для сценариев, в которых .NET в долгосрочной перспективе будет проигрывать Rust, Go, Swift, C++, Java (GraalVM), настольным, консольным и мобильным/IoT-приложениям, где время запуска действительно важно, существуют высокие ограничения на использование памяти. и потеря скорости из-за JIT при загрузке сборки недопустима, как и в некоторых сценариях ASP.NET, код AOT может быть актуален при масштабировании своих 100 экземпляров модулей K8S.

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

Существует множество языков, которые предлагают обе модели компиляции, позволяя своим пользователям выбирать в зависимости от ситуации, поэтому в основном давайте сохраним JIT и улучшим историю AOT в направлении .NET Native, забыв о робкой попытке NGEN.

@Symbai Это не защита ни от чего, как скажет вам любой разработчик Android, который пытался использовать NDK как средство защиты своей интеллектуальной собственности. Приложения, которые вы вкратце упомянули, могут делать то же самое одним щелчком мыши, и хотя они обычно предполагают код C или C++ в качестве исходного кода, они достаточно хороши, чтобы украсть ваши алгоритмы.

Кража алгоритма, с которым я могу жить, но не с тем, что .NET позволяет сегодня (например, WPF), когда у человека есть ваше полное приложение, красиво и легко готовое к запуску в качестве проекта VS. Я думаю, что UWP с компиляцией Native хорошо справляется со своей задачей, если кто-то захочет его разобрать, ок, удачи! Я всегда буду использовать нативную компиляцию, несмотря ни на что. Мир Android, о котором я не могу говорить, однажды попробовал AOT с Xamarin Forms, и это действительно не сработало, как я ожидал.

Я думаю, что UWP с компиляцией Native хорошо справляется со своей задачей, если кто-то захочет его разобрать, ок, удачи! Я всегда буду использовать нативную компиляцию, несмотря ни на что. Мир Android, о котором я не могу говорить, однажды попробовал AOT с Xamarin Forms, и это действительно не сработало, как я ожидал.

Спойлер — люди, которые пытаются добраться до вашего источника, вероятно, пытаются улучшить/расширить/интегрировать вас, а не ограбить вас. Если они пытаются вас обокрасть, то ваши показатели действительно глупы.

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

Это я говорю как разработчик, не имевший опыта дизассемблирования нативных бинарников, и решивший перепроектировать шифрование и форматы данных на Star Citizen.

Мне, человеку с нулевым опытом, потребовалось две недели, чтобы пройти путь от нуля до программы, которая может не только расшифровывать их зашифрованные файлы данных, но и преобразовывать их проприетарные форматы данных в XML/JSON.

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

иметь программу, которая может не только расшифровывать свои зашифрованные файлы данных

Шифрование — это совсем другое. Декомпиляция ВИДЕОИГРЫ для создания модов — это нечто совершенно другое. Большинство разработчиков игр не возражают, если их фанаты создают моды, это скорее показывает их страсть и любовь к игре. А может быть, "шифрование" вовсе и не было шифрованием, а просто файлы были запакованы для меньшего размера? За то, что не нужно хранить тысячи отдельных файлов на диске. Производительность тоже могла быть причиной... чтение множества маленьких файлов с диска медленнее, чем чтение одного огромного файла. И уже через 2 недели вы смогли распаковать упакованные образы. Вы смогли изменить текст в некоторых файлах данных. Это здорово, но не причина, по которой такие люди, как я, хотят избавиться от JIT.

Проблема, с которой мы сталкиваемся прямо сейчас, заключается в том, что JIT-код может быть полностью декомпилирован для завершения исходного кода, Java имеет ту же проблему, что и любой другой язык JIT. Нативный код можно дизассемблировать (это превратит машинный код в ассемблерный код), нативные приложения можно взломать с достаточными затратами, все это верно, но нативный код нельзя скомпилировать в полный исходный код. Вы когда-нибудь видели такой инструмент, как dnSpy для кода C++? Дельфийский код? у меня нет. Это потому, что невозможно получить имена переменных и методов, они просто больше не существуют при правильной компиляции. Невозможно превратить дизассемблирование в C++ и сгенерировать полностью рабочий проект, который можно скомпилировать. Это должно звучать как что-то не очень важное для вас, но это очень важно для коммерческих приложений. Мы просто хотим избавиться от того факта, что .NET-приложение — это открытая книга, которую может прочитать каждый с абсолютно нулевыми знаниями. Когда мы вкладываем тысячи долларов в исследования, мы не хотим, чтобы все посмотрели на них и скопировали за пару секунд. Мы хотим избавиться от необходимости платить тысячи долларов за обфускатор, единственной целью которого является переименование всех имен переменных и методов, чтобы люди больше не могли открывать приложение и искать «лицензию», чтобы сразу получить к нему доступ. Это не только (но в основном) стоимость обфускатора, но и то, что обфускаторы создают дополнительные проблемы. Я сам сталкивался с этим довольно часто, особенно с частотой выпусков .NET Core. Нам пришлось ждать несколько недель только для патча, который заставит обфускатор работать с последней версией .NET Core.

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

С C++ и Delphi у вас просто нет этой проблемы. Я знаю, что это проблема не для всех. Разработчики с открытым исходным кодом найдут JIT более интересной и полезной. Им трудно объяснить, почему кто-то хочет, чтобы его исходный код был закрытой книгой, когда они считают, что открытые книги просто лучше. Так что в идеале нам не нужно объяснять друг другу наши совершенно разные взгляды, а AOT будет просто переключателем, который вы можете включить в режиме релиза, если хотите. И если вы не хотите, продолжайте с JIT.

Я очень благодарен команде .NET за то, что она позволила нам выбрать «защиту» в качестве причины, по которой мы хотим использовать AOT ❤. Это показывает, что они знают о потребностях некоторых людей. И если опросы выявят, что человек проголосовал за него, у нас, наконец, может появиться шанс, что реализация AOT позаботится об этом так же, как компилятор C++. К вашему сведению: я взял это в кавычки, чтобы избежать дальнейших дискуссий о том, насколько на самом деле защищен AOT, точки зрения на этот вопрос чрезвычайно широки, как мы уже могли заметить.

Безопасность — это не все или ничего. Удаление IL не мешает решительному злоумышленнику отменить приложение. Но это создает препятствия, которые имеют практическое значение. Это глубокоэшелонированная защита. Вот почему продукты обфускации IL могут быть рациональными в использовании.

Мой друг взломал продукты .NET, декомпилировав IL в C# и внеся довольно тривиальные модификации. Он не способен взламывать родные приложения. Это намного сложнее. Ему также пришлось сдаться в присутствии обфускаторов IL, потому что инструмент декомпиляции давал сбой на этих двоичных файлах. Опять же, эти продукты были защищены в практическом смысле. Это сработало.

@Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays хорошо справляется с C и содержит макросы, помогающие в процессе принятия решений.

Имея исходный код C, дети легко могут преобразовать его в C++ или Delphi.

Кроме того, теперь у нас есть ИИ, чтобы помочь тем, кто недостаточно умел.

Нейронная реверс-инжиниринг разделенных двоичных файлов

Hex-Rays хорошо справляется с C и содержит макросы, помогающие в процессе принятия решений.

Вы работаете в Hex-Rays или в компании, которая продает программное обеспечение для обфускации? Кажется, что.

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

BTW: Вы выглядите очень заинтересованным в JIT-компиляции, а также, похоже, у вас большой опыт дизассемблирования программного обеспечения. Мне интересно, почему и где вы должны были это использовать?!

Независимо от того, что вы думаете о простоте декомпиляции IL по сравнению с машинным кодом, это не меняет того факта, что это реальное требование для реального бизнеса. (И мы могли бы спорить о том, насколько действительным или недействительным может быть это требование, пока коровы не вернутся домой.)

По этой причине мой предыдущий работодатель явно запрещал поставки инструментов .NET или JVM извне. Прямо перед тем, как я ушел, одна команда убедила начальство разрешить им выпустить инструмент с усиленной обфускацией, но в остальном мы писали внешние инструменты на C++, чтобы удовлетворить корпоративную политику.

Эта дискуссия сошла с рельсов. Если вы все хотите устроить флейм по поводу того, имеет ли значение AOT для защиты интеллектуальной собственности, пожалуйста, сделайте это где-нибудь в другом месте.

Hex-Rays хорошо справляется с C и содержит макросы, помогающие в процессе принятия решений.

Вы работаете в Hex-Rays или в компании, которая продает программное обеспечение для обфускации? Кажется, что.

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

BTW: Вы выглядите очень заинтересованным в JIT-компиляции, а также, похоже, у вас большой опыт дизассемблирования программного обеспечения. Мне интересно, почему и где вы должны были это использовать?!

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

РЕДАКТИРОВАТЬ: Также останавливаю мои комментарии. Просто хотел ответить на личную атаку.

Cloud Native и WPF должны быть AOT.
Клиент Windows без времени выполнения! нет JIT

Результаты опроса опубликованы - https://github.com/dotnet/runtime/issues/41522. Сейчас мы пытаемся связаться с людьми, предоставившими свои контактные данные, и у нас есть дополнительные дополнительные вопросы.

AOT со статической привязкой срочно необходим для игровых движков в iOS и консольных платформах, которые отключают jit,

Я полностью согласен здесь. Поскольку нам нужно решение этой проблемы (код C#, работающий на игровых консолях для проекта, отличного от Unity), мы используем цепочку инструментов на основе Mono-AOT. Но он имеет некоторые серьезные ограничения и не работает так хорошо.

Поэтому мы рассматриваем возможность запуска CoreRT на трех игровых консолях (XBox One, PlayStation 4 и Nintendo Switch). Первоначальная проверка концепции показывает, что она действительно работает (все еще с некоторыми ограничениями), но уже со значительным улучшением производительности во время выполнения по сравнению с решением на основе Mono.

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

@RalfKornmannEnvision Используете ли вы монопорты Xamarin Xbox One/PS4 Mono с генератором кода LLVM?

@RalfKornmannEnvision Используете ли вы монопорты Xamarin Xbox One/PS4 Mono с генератором кода LLVM?

@lateralusX Поскольку интеграцию выполнил кто-то другой, я не знаю никаких подробностей. Но, насколько я знаю, они использовали монопорты, предусмотренные для XBox One/PS4, и сделали простой порт для коммутатора. себя.

@RalfKornmannEnvision Было бы здорово связаться и обсудить опыт, связанный с этим. LLVM codegen имеет (в зависимости от проекта) очень положительное влияние на производительность сгенерированного кода, поэтому, если он не использовался (нужно включить), обычно можно много выиграть, просто включив его. Вы находитесь на дискорд-сервере DotNetEvolution, если да, то, возможно, мы могли бы обсудить это в автономном режиме?

@lateralusX Я почти уверен, что члены команды, работавшие над этим, включили генератор кода LLVM и пробовали другие вещи. Их последним заявлением перед тем, как перейти к другому проекту, было то, что это лучшее, что они могли сделать.

В рамках моего исследования я создаю тест с основным компонентом, используя Xamarin Android, и запускаю его на устройстве на базе Tegra X1, чтобы увидеть, не потеряли ли мы производительность из-за проблемы с нашим пользовательским портом Switch для Mono. К сожалению, производительность проекта Xamarin не сильно отличалась от того, что мы видели на Switch.

Мне жаль, что я не на этом сервере разногласий, и, честно говоря, я не так много знаю о текущей интеграции MONO. С моей точки зрения, это тупиковый путь для этого проекта. Текущий прототип CoreRT (хотя и имеет еще меньшую официальную поддержку) уже намного превосходит его по производительности и удобству использования.

@RalfKornmannEnvision Хорошо, спасибо за вашу информацию и отзывы, все очень ценно.