Kopa писал(а):
Почему отдано предпочтение dll варианту кода программы?
Ответ вообще-то выше уже есть.
В первом сообщении
viewtopic.php?f=37&t=3679#p70011И в этом
viewtopic.php?f=37&t=3679#p70077Смысл копировать одно и тоже? Ну ладно:
Цитата:
Да, как видно, память чуть выше уже занята, и её использовать сейчас не получится
Цитата:
вот если бы можно было вставить в самое начало большой кусок ненужных данных или кода, которые можно было бы потом затереть...
Цитата:
компилятор позволяет собрать приложение с ImageBase = 64 K:
Цитата:
тогда можно сделать сам эмулятор как библиотеку и запустить её из приложения с ImageBase = 64K(сам этот загрузчик можно искусственно раздуть до нужных размеров, чтобы потом после запуска самого эмулятора можно было благополучно затереть), загрузить kex, проверить сколько реально нужно, ненужное освободить.
Цитата:
Сделал DLL-версию.
"Загрузчик", резервирующий 64 мегабайта памяти(константа MEM_SIZE в исходнике), загружается по адресу 64K.
С помощью VirtualProtect устанавливаются атрибуты PAGE_EXECUTE_READWRITE. После чего управление передаётся в Main, которая находится в DLL.
В дальнейшем "загрузчик" можно затереть кодом или данными загруженного KolibriOS приложения.
Kopa писал(а):
Какие шансы запустить эмулятор на не XP Windows.
pavelyakov писал(а):
На Windows 7 x64 не работает
Опять же, выше уже говорилось об этом.
И в первом сообщении
Цитата:
Обнаружил ограничения этого:
Цитата:
NULL page mitigations for Windows 8 (both x86 and x64), and even backported the mitigation to Vista+
и в этом
viewtopic.php?f=37&t=3679&start=15#p70089 Цитата:
Насколько я смог нагуглить, это появилось в одном из обновлений безопасности на семёрке.
То есть, теоретически, на каких-то семёрках оно может работать.
Возможно на висте работает.
Мой вариант не использует SetLDTEntries, и, по идее(если я ничего больше не упустил

) должен на x64 тоже запуститься.
Хорошо бы проверить XP 64 bit, Vista 32 bit и 64 bit.
Но всё зависит от конечной цели.
Я так полагаю, эмулятор только ради эмулятора — это немного странная цель.
Если же цель — использование для разработки программ, то на период тестирования\отладки своей программы можно её скомпилировать не с "
org 0", а, скажем с '
org 64K' и грузить эмулятором по этому адресу.
Сделал в связи с этим экспериментальную версию, позволяющую указать куда грузить: опция
-base.
Также добавлено
GetTickCount,
Cubeline теперь должен работать правильно.
Вложение:
KEm.7z [44.39 КБ]
7 скачиваний
Но надо понимать, что делаешь, и на что это влияет.
Например, берём
FREE3D04, указываем вместо
org 0x0 другое значение(доступное для загрузки)
org 65536.
Компилируем и грузим в эмуляторе, указав в командной строке
Цитата:
KEm -base 65536 FREE3D04
Проблемы могут быть при использовании абсолютных значений адресов.
Код:
org 0x0
db 'MENUET01' ; 8 byte id
dd 0x01 ; header version
dd START ; start of code
dd I_END ; size of image
dd APP_MEM;0x100000 ; memory for app
dd APP_MEM;0x100000 ; esp
dd 0x0 , 0x0 ; I_Param , I_Icon
Вместо вот этого
Код:
dd APP_MEM;0x100000 ; memory for app
dd APP_MEM;0x100000 ; esp
желательно делать(в
3dsheart примерно так и сделано)
Код:
dd I_END + нужное значение
dd I_END + нужное значение
Почему сейчас и так работает без этого? Потому что при загрузке резервируется целых 64 мегабайта памяти, сама
KolibriOS, разумеется, так не делает, но этого вполне хватит, чтобы запустить и посмотреть, как оно выглядит.
Такой способ должен работать и в
Win8 тоже.
Но мне всё равно остаётся интересно
XP 64 bit, Vista 32 bit и 64 bit.
