По идее если реализовать систему для ХП то можно воспользоваться ихней системой обратной совместимости на ХП она по крайней мере нормально работает.
Если говорить про Win98/95 можно будет части этого проекта включить для портретирования HX DOS Extender, который умеет в работу консольных приложений Вин95 в среде Дос и некоторые зачатки работы графических одно оконных приложений.
Эмулятор ядра OS Windows
Я думаю это нужно переписать на FASM поскольку есть конфликт лицензии GNU GPL и MASM. Также думаю нужно в вести некоторое разделение поскольку ориентироваться в файле на 36к строк крайне весело, также и с нумерованными метками.
Глобальная цель данного проекта сделать так, чтобы ОС Колибри и эмулятор стали необходимой и востребованной вещью для подавляющего большинства пользователей ПК и ноутов. Пользователи в основном "сидят" на ОС от Win XP до Win11.
По моему, после доработки эмулятора под Win XP, доработать его для совместимости под Win98/95 не составит большого труда для заинтересованного ассемблерщика.
По моему, после доработки эмулятора под Win XP, доработать его для совместимости под Win98/95 не составит большого труда для заинтересованного ассемблерщика.
Amazing!
Проект судя по всему сдох...
НЕ сдох.
Проект в работе. Будет сдыхать - напишу сам.
Уже много чего добавилось - идет отладка. А так, в конце года планирую написать что и как с проектом.
Проект в работе. Будет сдыхать - напишу сам.
Уже много чего добавилось - идет отладка. А так, в конце года планирую написать что и как с проектом.
недавно взглянул на исходники, Пожалуйста не используйте системные функции 18.11, 64 и 37.2 , они могут быть удалены в скором будущем. 18.11 планируется к удалению в течении года так как устарела, в качестве альтернативы существует 70 и 80 функции.
Спасибо за инфу.
Применение Функций 64 и 37.2 у себя в текущей реализации не нашел.
По поводу 18.11. У него удобная "фича" - указание типа устройства и числа разделов распознанных на жестком диске.
В качестве альтернативы намекаете на функцию 70.5? Тогда непонятно как там определить последовательный список типов устройств - это нужно чтобы сопоставить имена томов Винды с типами устройств и с их разделами.
У Винды идет селекция имен томов по типам контроллера и расположении устройств на контроллере. То есть сначала идут дисководы, потом ЖД, потом CD.
Далее для ЖД сначала берутся данные от всех первичных контроллеров (Primary Master) и (Secondary Master) и о числе их разделов.
Потом берутся данные от всех вторичных контроллеров (Primary Slave) и (Secondary Slave) и о числе их разделов.
Потом составляется глобальный последовательный список Виндовых имен томов по алфавиту для всех устройств и разделов по ранжиру.
Если я забью на это сопоставление, то при извлечении из реестра Винды патчей, с готовыми именами томов, будут проблемы при открытии файлов.
Применение Функций 64 и 37.2 у себя в текущей реализации не нашел.
По поводу 18.11. У него удобная "фича" - указание типа устройства и числа разделов распознанных на жестком диске.
В качестве альтернативы намекаете на функцию 70.5? Тогда непонятно как там определить последовательный список типов устройств - это нужно чтобы сопоставить имена томов Винды с типами устройств и с их разделами.
У Винды идет селекция имен томов по типам контроллера и расположении устройств на контроллере. То есть сначала идут дисководы, потом ЖД, потом CD.
Далее для ЖД сначала берутся данные от всех первичных контроллеров (Primary Master) и (Secondary Master) и о числе их разделов.
Потом берутся данные от всех вторичных контроллеров (Primary Slave) и (Secondary Slave) и о числе их разделов.
Потом составляется глобальный последовательный список Виндовых имен томов по алфавиту для всех устройств и разделов по ранжиру.
Если я забью на это сопоставление, то при извлечении из реестра Винды патчей, с готовыми именами томов, будут проблемы при открытии файлов.
насколько я понял, нужно сопоставить полное название раздела в колибри с тем, что в винде. При чтении корневой директории мы получаем список дисков в котором тип устройства можно определить по имени без учёта цифр:
- fd - дискеты
- bd - диски видимые через биос
- hd - ide диски
- cd - ide atapi дисководы
- sd - sata диски
- usbhd - юсб флешки/внешние диски
- sdhci - SD карточки через SDHCI контролер
При получении информации о разделе(например /sd0/4) через 70.5 можно как-то получить имя раздела, скорее всего через установку нужного флага.
- fd - дискеты
- bd - диски видимые через биос
- hd - ide диски
- cd - ide atapi дисководы
- sd - sata диски
- usbhd - юсб флешки/внешние диски
- sdhci - SD карточки через SDHCI контролер
При получении информации о разделе(например /sd0/4) через 70.5 можно как-то получить имя раздела, скорее всего через установку нужного флага.
Тут у меня пока такая проблема. Запускаю виндовый lsass.exe в первом процессе и потом services.exe во втором процессе.
Оба процесса для инициализации загружают один и тот же файл реестра.
Так вот, когда второй процесс загружает файл реестра, то в первом процессе происходит сбой из-за нарушения доступа к памяти.
У меня реализовано открытие файла так - в результате вызова функции 68,27 получаю адрес в памяти и сохраняю его в хэндле и далее работаем, используя этот адрес в памяти.
Выходит так, что полученный адрес файла от функции 68,27 является "временным от системы", который может стать недействительным в любой момент времени?
И чтобы не было проблем с этим файлом, я должен дополнительно перекопировать файл в локальную память процесса?
А если требуется межпроцессорный доступ к файлу, то должен дополнительно перекопировать файл в именованную область памяти?
Поправьте меня, если у меня неверные выводы.
Оба процесса для инициализации загружают один и тот же файл реестра.
Так вот, когда второй процесс загружает файл реестра, то в первом процессе происходит сбой из-за нарушения доступа к памяти.
У меня реализовано открытие файла так - в результате вызова функции 68,27 получаю адрес в памяти и сохраняю его в хэндле и далее работаем, используя этот адрес в памяти.
Выходит так, что полученный адрес файла от функции 68,27 является "временным от системы", который может стать недействительным в любой момент времени?
И чтобы не было проблем с этим файлом, я должен дополнительно перекопировать файл в локальную память процесса?
А если требуется межпроцессорный доступ к файлу, то должен дополнительно перекопировать файл в именованную область памяти?
Поправьте меня, если у меня неверные выводы.
68,27 выделяет память в куче процесса через 68,12 и читает через 70,0. Естественно, другой процесс доступа к ней не имеет, и нужна именованная область.
Если файл не сжат через Kpack, то лучше непосредственно использовать функцию 70,0.
Если файл не сжат через Kpack, то лучше непосредственно использовать функцию 70,0.
Кстати. Я нашёл в интернете сервак, где ты, если интересно, можешь посмотреть исходники Windows XP SP1 и Windows Server 2003 (чисто в качестве вдохновления. Copy-Paste запрещён ). Надо в личку ссылку дать?
Скинь, может быть пригодится. Я иногда пользуюсь базами Wine и ReactOS, если нужно подсмотреть структуры и константы недокументированных функций Nt... Zw..
Скинул. Лучше смотреть исходники оригинала, чем поделок вроде Wine и ReactOS (осторожно! В исходниках у винды можно в коментариях к коду встретить слово f*ck!!! )
Who is online
Users browsing this forum: No registered users and 1 guest