Проект прогрессирует
Педполагается ли и рабочий стол КолибриОС поддержать?
P.S. Cubeline у меня отображается медленно, в сравнении с KlbrnWin, а Invaders почему то не стартует.
У игры 2048 сообщение о атрибутах write памяти. Lode Runer стартует не в полном своём окне,
но это пока всё мелочи.
Эмуляция KolibriOS API
Чтобы проверить, в чём дело, собрал версию с DEBUG_OUTPUT с помощью make(debug).bat.Kopa wrote:Cubeline у меня отображается медленно, в сравнении с KlbrnWin,
После запуска в консоли можно обнаружить
Code: Select all
EIP = $000001F2; EAX = $0000001A; EBX = $00000009; ECX = $0190017C
EDX = $00000014; ESI = $00000000; EDI = $00000000; EBP = $0412FE68
ESP = $0412FE30; EFLAGS = $00010202
!UNDEFINED!
Code: Select all
{26.9} Function GetTickCount: Dword; StdCall; External 'KolibriOS';
Как оказалась, современная версия требует libimg, а более старая не требует, она запускаетсяKopa wrote:Invaders почему то не стартует
Скорее всего, используется SetWindowPos, это сейчас тоже не поддерживается.Kopa wrote:Lode Runer стартует не в полном своём окне
Вопрос,
Почему отдано предпочтение dll варианту кода программы? (в ReactOS, возможно, какие то проблемы связаны с ним при проверке работоспособности программ)
P.S. Какие шансы запустить эмулятор на не XP Windows.
Ещё, управление в игре Tetris несколько инерционно.
Почему отдано предпочтение dll варианту кода программы? (в ReactOS, возможно, какие то проблемы связаны с ним при проверке работоспособности программ)
P.S. Какие шансы запустить эмулятор на не XP Windows.
Ещё, управление в игре Tetris несколько инерционно.
На Windows 7 x64 не работает, ReadFile error
Технологии меняют мир, а я - меняю технологии.
Ответ вообще-то выше уже есть.Kopa wrote:Почему отдано предпочтение dll варианту кода программы?
В первом сообщении http://board.kolibrios.org/viewtopic.ph ... 679#p70011
И в этом http://board.kolibrios.org/viewtopic.ph ... 679#p70077
Смысл копировать одно и тоже? Ну ладно:
Да, как видно, память чуть выше уже занята, и её использовать сейчас не получится
вот если бы можно было вставить в самое начало большой кусок ненужных данных или кода, которые можно было бы потом затереть...
компилятор позволяет собрать приложение с ImageBase = 64 K:
тогда можно сделать сам эмулятор как библиотеку и запустить её из приложения с ImageBase = 64K(сам этот загрузчик можно искусственно раздуть до нужных размеров, чтобы потом после запуска самого эмулятора можно было благополучно затереть), загрузить kex, проверить сколько реально нужно, ненужное освободить.
Сделал DLL-версию.
"Загрузчик", резервирующий 64 мегабайта памяти(константа MEM_SIZE в исходнике), загружается по адресу 64K.
С помощью VirtualProtect устанавливаются атрибуты PAGE_EXECUTE_READWRITE. После чего управление передаётся в Main, которая находится в DLL.
В дальнейшем "загрузчик" можно затереть кодом или данными загруженного KolibriOS приложения.
Kopa wrote:Какие шансы запустить эмулятор на не XP Windows.
Опять же, выше уже говорилось об этом.pavelyakov wrote:На Windows 7 x64 не работает
И в первом сообщении
и в этом http://board.kolibrios.org/viewtopic.ph ... =15#p70089Обнаружил ограничения этого:
Цитата:
NULL page mitigations for Windows 8 (both x86 and x64), and even backported the mitigation to Vista+
Но всё зависит от конечной цели.Насколько я смог нагуглить, это появилось в одном из обновлений безопасности на семёрке.
То есть, теоретически, на каких-то семёрках оно может работать.
Возможно на висте работает.
Мой вариант не использует SetLDTEntries, и, по идее(если я ничего больше не упустил ) должен на x64 тоже запуститься.
Хорошо бы проверить XP 64 bit, Vista 32 bit и 64 bit.
Я так полагаю, эмулятор только ради эмулятора — это немного странная цель.
Если же цель — использование для разработки программ, то на период тестирования\отладки своей программы можно её скомпилировать не с "org 0", а, скажем с 'org 64K' и грузить эмулятором по этому адресу.
Сделал в связи с этим экспериментальную версию, позволяющую указать куда грузить: опция -base.
Также добавлено GetTickCount, Cubeline теперь должен работать правильно.
[/i][/b][/color]
Но надо понимать, что делаешь, и на что это влияет.
Например, берём FREE3D04, указываем вместо org 0x0 другое значение(доступное для загрузки) org 65536.
Компилируем и грузим в эмуляторе, указав в командной строке
Проблемы могут быть при использовании абсолютных значений адресов.KEm -base 65536 FREE3D04
Code: Select all
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
Code: Select all
dd APP_MEM;0x100000 ; memory for app
dd APP_MEM;0x100000 ; esp
Code: Select all
dd I_END + нужное значение
dd I_END + нужное значение
Такой способ должен работать и в Win8 тоже.
Но мне всё равно остаётся интересно XP 64 bit, Vista 32 bit и 64 bit.
Да, проверил работает0CodErr wrote:Такой способ должен работать и в Win8 тоже..
указал в 3dsheart заголовке при сборке такие значения
Code: Select all
org 65536
dd I_END+ 100000
dd I_END+ 100000
Code: Select all
kem -base 65536 3dsheart
Там + 100000 не обязательно, главное, чтобы это было относительное значение, но некоторые пишут абсолютное mem dd 100500Kopa wrote: dd I_END+ 100000
Да, было при изменении размеров, но это не связано со способом запуска -base 65536. В предыдущих версиях эмулятора так же.Kopa wrote:P.S. При перемещении демо-сердца заметил, что текстовая информация исчезла.
Там вызывается неподдерживаемая SysFn70, происходит работа с файлом 2048.dat.Kopa wrote:У игры 2048 сообщение о атрибутах write памяти.
org 65536
kem -base 65536 3dsheart
Вот так работает в Windows 7 x64
Вот если бы еще решить вопрос со смещением, то цены бы не было))
kem -base 65536 3dsheart
Вот так работает в Windows 7 x64
Вот если бы еще решить вопрос со смещением, то цены бы не было))
Технологии меняют мир, а я - меняю технологии.
И таким способом можно использовать софт из KolibriOS в разных Windows + какой то "функционал" из возможностей самой Windows. В таком варианте может оказаться полезным загрузка несколько "утилит' по разным адресам.pavelyakov wrote:Вот если бы еще решить вопрос со смещением, то цены бы не было))
Отлаживать можно под какими нибудь Windows отладчиками.
Почти ОС внутри ОС. Антивирусам прибавится работы.
P.S. Только добавить поддержку значимых API из KolibriOS. Может добавится и улучшится софт для КолибриОС.
А CPUID или PCIDEV заработают?
0CodErr,
Если адрес загрузки теперь можно указать в параметрах эмулятора, то может быть, вместо нуля надо написать адрес исполняемого файла?
Если адрес загрузки теперь можно указать в параметрах эмулятора, то может быть, вместо нуля надо написать адрес исполняемого файла?
Code: Select all
Function GetThreadInfo(Slot: Dword; Buffer: PThreadInfo): Dword;
...
MemAddress := 0;
akron1, трудно сказать, как правильно.
В настоящей KolibriOS всегда грузится в 0.
Но даже если указать реальный адрес загрузки, то он всё равно мало что даст приложениям(насколько знаю, ни одно приложение не использует это значение, разве только tinfo, но лишь для вывода его на экран, не более).
Хотя формально, наверное, ты всё-таки прав
С PCIDEV ситуация сложнее.
Есть некоторое различие при субпиксельном(fontSmoothing: Byte = 2; ) сглаживании: Верхняя(KolibriOS) и нижняя(эмулятор) строки действительно отличаются.
Несмотря на то, что основной цвет передаётся верный(перед передачей происходит преобразование rgb2bgr), цвет сглаживания рассчитывается внутри самой функции dtext в соответствии с правилами KolibriOS.
Думаю, надо сделать rgb2bgr где-то внутри dtext.
Вообще, иногда бывает и при обычном сглаживании небольшие проблемы, например, цвет сглаживания становится темнее, чем нужно.
Где-то на форуме встречались сообщения про похожую проблему в самой KolibriOS.
Вроде бы у меня все необходимые регистры сохраняются, пробовал даже флаги сохранять.
Если только хитрым образом пишется\читается ещё в какой-нибудь [esp + ...] ?
Не исключено, что проявляется баг в самом алгоритме отрисовки текста(но я ничего не утверждаю).
Есть намного поменьше проект DrawText.
Только использование одной функции вывода текста средствами WinAPI.
Я им пользовался на период отладки функци
В настоящей KolibriOS всегда грузится в 0.
Но даже если указать реальный адрес загрузки, то он всё равно мало что даст приложениям(насколько знаю, ни одно приложение не использует это значение, разве только tinfo, но лишь для вывода его на экран, не более).
Хотя формально, наверное, ты всё-таки прав
Да, один из плюсов, кстати.Kopa wrote:Отлаживать можно под какими нибудь Windows отладчиками.
CPUID — должен, там ведь используется инструкция процессора cpuid. Хотя и не только.Kopa wrote:А CPUID или PCIDEV заработают?
С PCIDEV ситуация сложнее.
Есть некоторое различие при субпиксельном(fontSmoothing: Byte = 2; ) сглаживании: Верхняя(KolibriOS) и нижняя(эмулятор) строки действительно отличаются.
Несмотря на то, что основной цвет передаётся верный(перед передачей происходит преобразование rgb2bgr), цвет сглаживания рассчитывается внутри самой функции dtext в соответствии с правилами KolibriOS.
Думаю, надо сделать rgb2bgr где-то внутри dtext.
Вообще, иногда бывает и при обычном сглаживании небольшие проблемы, например, цвет сглаживания становится темнее, чем нужно.
Где-то на форуме встречались сообщения про похожую проблему в самой KolibriOS.
Вроде бы у меня все необходимые регистры сохраняются, пробовал даже флаги сохранять.
Если только хитрым образом пишется\читается ещё в какой-нибудь [esp + ...] ?
Не исключено, что проявляется баг в самом алгоритме отрисовки текста(но я ничего не утверждаю).
Есть намного поменьше проект DrawText.
Только использование одной функции вывода текста средствами WinAPI.
Я им пользовался на период отладки функци