На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! Перед отправкой сообщения внимательно прочтите правила раздела!!!
1. Запрещается обсуждать написание вирусов, троянов и других вредоносных программ!
2. Помните, что у нас есть FAQ раздела Assembler и Полезные ссылки. Не поленитесь, загляните в эти разделы перед созданием темы. Возможно, так уже имеется решение вашего вопроса.

3. Настоятельно рекомендуем обратить особое внимание на правила форума, которые нарушаются чаще всего:
  3.1. Заголовок темы должен кратко отражать её суть. Темы с заголовками типа "Срочно помогите!" или "Ассемблер" будут отправляться в Корзину для мусора.
  3.2. Исходники программ обязательно выделяйте тегами [code]...[/code] (одиночные инструкции можно не выделять).

Не забывайте также про главные Правила форума!

Так что добро пожаловать и приятного вам общения!!! ;)
 
Модераторы: Jin X, Qraizer
Страницы: (4) « Первая ... 2 3 [4]  все  ( Перейти к последнему сообщению )  
> Переход в нереальный режим, загрузчик
    Ноги, видимо, отсюда растут:
    user posted image
    Прикреплённый файлПрикреплённый файл2017_10_17_17_30_56.png (46,85 Кбайт, скачиваний: 143)
    vpmultishiftqb vscatterpf0dps vfmsubadd132pd vgatherpf1dps vpclmulhqlqdq vcmptrue_ussd vaeskeygenassist
      Похоже вы правы. Только я это читал уже в переводе, и там не упоминалось о сегменте SS.
      Я никогда не трогаю лимит сегмента SS. Но, 32-бит (в DS, ES) иногда глючат.

      Добавлено
      Похоже разобрался. Я использую программу для просмотра файловой системы NTFS - NDOS.EXE. Исходная программа периодически переводит в режим 64К.
      Я исправил это, нашел дескриптор, отвечающий за это и перенастроил его на 4-Гиг. Но, т.к. я пользуюсь MASM 6.11 (оказывается он тоже переводит в режим 64К)
      возникают кратковременные моменты, когда процессор находится в режиме RM-64K.
        Прошло довольно много времени, как я эхперементировал с режимом UNRAL. Работает отлично. Сделал несколько нужных программ.
        Решил замахнутся UNRAL(ом) на WINDOWS. В итоге большой облом. Даже если создать RAM диск с помощью UNRAL в среде DOS и
        потом загрузить WINDOWS-98, то или WINDOWS-98 не грузится, или RAM диск исчезает. Выходом из этого положения остались
        функции HIMEM.SYS (или XMRG.SYS). В итоге решил, компромисное решение будет в использование режима UNRAL в среде DOS для
        создания программы (драйвера), а при переходе в WINDOWS-98, использовать функции HIMEM.SYS.
          Цитата andr00 @
          UNRAL(ом) на WINDOWS

          Windows работает в полноценном pm32. Зачем там нужна эмуляция 16-битного режима с забаганными сегментными регистрами я даже представить не могу.
          Сообщение отредактировано: shm -
          Цитата TheMachine @
          т.е. в общем случае вы правы конечно, а мне надо спать больше а пить меньше
            Интересно, а можно ли использовать режим UNRAL в DOSBOX(е)?
              andr00, попробуй, потом расскажешь :)
              vpmultishiftqb vscatterpf0dps vfmsubadd132pd vgatherpf1dps vpclmulhqlqdq vcmptrue_ussd vaeskeygenassist
                Ставлю 8 из 10, что не получится. Ибо условия запуска "DOS"-режима в над-ОС всё же пишутся=защищаются в этой самой над-ОС, которая не позволит (не должна позволить) изнутри "поломать" её для таких экспериментов.
                  Попробовал, получилось. Но в пределах 16 мб, котоые выделяет DosBox.

                  Добавлено
                  Попробовал, получилось. Но в пределах 16 мб, котоые выделяет DosBox. Параметр memsize расширяет до 64 мб
                    Я как-то смотрел его сырцы. Сложилось впечатление, что он пределы сегментов вообще не проверяет. По крайней мере не нашёл кода, но нашёл коммент типа "TODO: check limit"
                    Одни с годами умнеют, другие становятся старше.
                    1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                    0 пользователей:


                    Рейтинг@Mail.ru
                    [ Script Execution time: 0,0983 ]   [ 15 queries used ]   [ Generated: 19.06.18, 20:25 GMT ]