Как избавиться от неуправляемого кода в VW 3.1d и ENVY

Question

У меня есть старое изображение VW3/ENVY с посылкой, загруженной как неуправляемый код (точно такая ситуация Mastering ENVY/DEVELOPER предупреждает). К сожалению, эта проблема возникла давно, и уже слишком поздно просто «вернуться» к изображению без загрузки посылки.

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

В теории должно быть возможно удалить посылку и перезагрузить код с карты конфигурации. На практике все обычные способы (с использованием ParcelBrowser или прямой вызов UnmanagedCode >> remove) завершаются с ошибкой. Я даже попытался вручную удалить оскорбительные селектора из словаря метода, но прошёл мимо определенной точки (с вызовом #primBecome :) все изображение полностью зависает (я даже не могу попасть в отладчик). Я начал взламывать экземпляры классов и методов, надеясь, что я обманул ENVY, подумав, что эти конкретные методы являются нормальным версированным кодом, но без успеха.

Есть ли какие-нибудь маленькие гуру-гуру, которые до сих пор помнят достаточно VW 3, чтобы предоставить мне любые указатели?

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

Во-первых, я должен был исправить указатели файлов для umnanaged кода (в противном случае все, что пыталось прикоснуться к методам, создало бы исключение). Похоже, что ENVY расширяет Parcel, так что теоретически все целые указатели файлов меняются на файл ENVY void при загрузке, но в моем случае я должен был сделать это вручную (Parcel предоставляет перечисление для всех определяемых им селекторов). Другой способ - настроить код filePointer, но это невозможно сделать автоматически на каждом изображении, где это необходимо.

Затем посылка может быть отброшена, что исключает информацию о посылке, но сохраняет код. У официального механизма «Отменить» должен быть действительный файл изменений (зависть которого не используется, поэтому его необходимо установить вручную и затем сбрасывать) и источника посылки (что, к счастью, было у нас).

Чтобы иметь возможность вносить любые изменения в методы (вручную или через загрузку приложения или класса из ENVY), им необходимо избавиться от неуправляемого статуса. Это можно сделать с помощью ручной настройки TheClass>>applicationAssocs (я также избавился от всех ссылок на классы в UnmanagedCode sich как временные метки и удалил ссылку на отброшенный пакет). На самом деле у меня была информация о том, как добраться до этого момента от моего босса, но я не смог понять инструкции, пока сам не понял.

Это позволило мне загрузить и перезагрузить все Приложения, содержащие классы. В теории. На практике изображение все равно зависало всякий раз, когда я пытался загрузить более новую версию приложения (содержащую ранее код в пакете).

Оказался, что аварии не были абсолютно ничего общего с кодом будучи неуправляемый, но с тем, что посылка в вопросе модифицированной InputState>>process:, где это вызвало исключение из-за отсутствующим и/или неинициализированный переменный класс (метод InputState>>initialize не вызывался до тех пор, пока не появился новый метод process:).Мне пришлось изменить класс Notifier, чтобы сбросить все исключения в файл, чтобы узнать, что происходит. Добавление переменной класса в источник класса (вместо добавления его через отражение), приостановка потока обработки ввода через toBeLoadedCode и повторное начало его в методе loaded и создание новой версии приложения, решение которой разрешено даже этой проблемой.

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

Answer 1

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

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

Извините, у меня нет лучших ответов.