Как сделать com файл
"Ха" 23 раза!
Тогда уже проще взять полученный Проект1.exe и переименовать в Проект1.com (этот пункт делает именно это. )
to Александррррррр
не парьтесь. COM файл умел генерить TurboPascal 3.0 (если мне память не изменяет). С тех пор генерация COM файлов в TurboPascal была недоступна!
Delphi — это ВООБЩЕ из другой оперы (это exeшники Win32 — компилятор Delphi DOS программы не генерит и полученные программы без Windows работать не могут. О каком уже COM файле может вообще идти речь. )
Александррррррр, Да и зачем Вам это нужно?!
Если нужно реально получить COM файл — пишите на Assembler (причём используйте правильную модель памяти, иначе и он откажется линковать COM файл.)
Как вариант — можете скачать TP 3.0. И сгенерировать файл в нём. Только я думаю, что Вам это НЕ НУЖНО!
Как собрать досовский COM-файл компилятором GCC
В минувшие выходные я участвовал в Ludum Dare #31. Но даже до объявления тем конференции из-за своего недавнего увлечения я хотел сделать олдскульную игру под DOS. Целевой платформой выбрана DOSBox. Это самый практичный способ запуска DOS-приложений несмотря на то, что все современные процессоры x86 полностью обратно совместимы со старыми, вплоть до 16-битного 8086.
Я успешно создал и показал на конференции игру DOS Defender. Программа работает в реальном режиме 32-битного 80386. Все ресурсы встроены в исполняемый COM-файл, никаких внешних зависимостей, так что игра целиком упакована в бинарник 10 килобайт.
Для игры понадобится джойстик или геймпад. Я включил поддержку мыши в релиз для Ludum Dare ради презентации, но потом удалил её, потому что она не очень хорошо работала.
Наиболее технически интересная часть заключается в том, что для создания игры не понадобились никакие инструменты разработки DOS! Я использовал только обычный компилятор Linux C (gcc). В реальности даже нельзя собрать DOS Defender под DOS. Я рассматриваю DOS только как встроенную платформу, что и есть единственная форма, в которой DOS всё ещё существует сегодня. Вместе с DOSBox и DOSEMU это довольно удобный набор инструментов.
Если вас интересует только практическая часть разработки, перейдите к разделу «Обманываем GCC», где мы напишем DOS COM программу “Hello, World” с GCC Linux.
Поиск правильных инструментов
Когда я начал этот проект, то не думал о GCC. В реальности я пошёл по этому пути, когда обнаружил пакет bcc (Bruce’s C Compiler) для Debian, который собирает 16-битные бинарники для 8086. Его держат для компиляции загрузчиков x86 и прочего, но bcc также можно использовать для компиляции DOS COM файлов. Это меня заинтересовало.
Для справки: 16-битный микропроцессор Intel 8086 вышел в 1978 году. У него не было никаких причудливых функций современных процессоров: ни защиты памяти, ни инструкций с плавающей запятой и только 1 МБ адресуемой RAM. Все современные десктопы и ноутбуки x86 всё ещё могут притвориться этим 16-битным процессором 8086 сорокалетней давности, с такой же ограниченной адресацией и всё такое. Это нехилая обратная совместимость. Такая функция называется реальным режимом. Это режим, в котором загружаются все компьютеры x86. Современные ОС сразу переключаются в защищённый режим с виртуальной адресацией и безопасной многозадачностью. DOS так не поступал.
К сожалению, bcc — не компилятор ANSI C. Он поддерживает подмножество K&R C, а также встроенный ассемблерный код x86. В отличие от других компиляторов 8086 C, у него нет понятия «дальних» или «длинных» указателей, поэтому для доступа к другим сегментам памяти (VGA, тактовые импульсы и т. д.) необходим встроенный ассемблерный код. Примечание: остатки этих «длинных указателей» 8086 до сих сохранились в Win32 API: LPSTR , LPWORD , LPDWORD и др. Тот встроенный ассемблер даже близко не сравнится со встроенным ассемблером GCC. На ассемблере нужно вручную загружать переменные из стека, а поскольку bcc поддерживает два разных соглашения о вызовах, то переменные в коде следует жёстко закодировать в соответствии с одним или другим соглашением.
Учитывая такие ограничения, я решил искать альтернативы.
DJGPP
DJGPP — порт GCC под DOS. Реально очень впечатляющий проект, который переносит под DOS почти весь POSIX. Многие портированные под DOS программы сделаны на DJGPP. Но он создаёт только 32-битные программы для защищённого режима. Если в защищённом режиме нужно работать с аппаратным обеспечением (например, VGA), то программа делает запросы к сервису интерфейса защищённого режима DOS (DPMI). Если бы я взял DJGPP, то не смог бы ограничиться единственным автономным бинарником, потому что пришлось бы поиметь и сервер DPMI. Производительность тоже страдает от запросов к DPMI.
Получить необходимые инструментальные средства для DJGPP сложно, мягко говоря. К счастью, я нашел полезный проект build-djgpp, который всё запускает, по крайней мере, на Linux.
Либо там серьёзная ошибка, либо официальные бинарники DJGPP опять заразились вирусом, но при при запуске моих программ в DOSBox постоянно возникала ошибка “Not COFF: check for viruses”. Для дополнительной проверки, что вирусы не на моей собственной машине, я настроил среду для DJGPP на своём Raspberry Pi, который действует как чистая комната. Это устройство на базе ARM невозможно заразить вирусом x86. И всё равно возникала та же проблема, и все двоичные хэши совпадали между машинами, так что это не моя вина.
Так что учитывая это и проблему DPMI, я начал искать дальше.
Обманываем GCC
На чём я в итоге остановился — так это на хитром трюке по «обману» GCC для сборки DOS COM-файлов реального режима. Трюк работает до 80386 (что обычно и нужно). Процессор 80386 выпущен в 1985 году и стал первым 32-битным x86 микропроцессором. GCC по-прежнему придерживается этого набора инструкций, даже в среде x86-64. К сожалению, GCC никак не может производить 16-битный код, так что от изначальной цели сделать игру для 8086 пришлось отказаться. Впрочем, это не имеет значения, потому что целевая платформа DOSBox по сути является эмулятором 80386.
В теории трюк должен работать и в компиляторе MinGW, но там есть давняя ошибка, которая мешает ему работать правильно (“cannot perform PE operations on non PE output file”). Впрочем, её можно обойти, и я делал это сам: следует удалить директиву OUTPUT_FORMAT и добавить дополнительный шаг objcopy ( objcopy -O binary ).
Hello World в DOS
Для демонстрации создадим досовскую COM-программу “Hello, World” с помощью GCC на Linux.
В этом способе есть главное и значительное препятствие: стандартной библиотеки не будет. Это как писать операционную систему с нуля, за исключением нескольких служб, которые обеспечивает DOS. Это значит, нет printf() и тому подобного. Вместо этого мы попросим DOS вывести строку в консоль. Создать запрос к DOS требует запуска прерывания, что означает встроенный ассемблерный код!
В DOS девять прерываний: 0x20, 0x21, 0x22, 0x23, 0x24, 0х25, 0x26, 0x27, 0x2F. Самое главное, которое нас интересует, это 0x21, функция 0x09 (вывести строку). Между DOS и BIOS есть тысячи функций, названных по такому шаблону. Я не собираюсь пытаться объяснить ассемблер x86, но вкратце номер функции забивается в регистр ah — и прерывание 0x21 срабатывает. Функция 0x09 также принимает аргумент — указатель на строку для печати, который передается в регистрах dx и ds .
Вот функция print() встроенного ассемблера GCC. Строки, передаваемые этой функции, должны заканчиваться символом $. Почему? Потому что DOS.
Код объявлен volatile , поскольку у него побочный эффект (печать строки). Для GCC ассемблерный код непрозрачен, и оптимизатор полагается на ограничения выхода/входа/клоббера (последние три строки). Для таких DOS-программ любой встроенный ассемблер будет с побочными эффектами. Это потому что он пишется не для оптимизации, а для доступа к аппаратным ресурсам и DOS — вещей, недоступных простому C.
Нужно также позаботиться о вызывающем операторе, потому что GCC не знает, что память, на которую указывает string , когда-либо читалась. Вероятно, массив, который поддерживает строку, тоже придётся объявить volatile . Всё это предвещает неизбежное: любые действия в такой среде превращаются в бесконечную борьбу с оптимизатором. Не все из этих битв можно выиграть.
Теперь к основной функции. Её название по идее не важно, но я избегаю называть её main() , потому что у MinGW есть забавные идеи, как обрабатывать конкретно такие символы, даже если его просят не делать этого.
COM-файлы ограничены размером 65279 байт. Это связано с тем, что сегмент памяти x86 составляет 64 КБ, а DOS просто загружает COM-файлы в адрес 0x0100 сегмента и выполняет. Заголовков нет, только чистый бинарник. Поскольку программа COM в принципе не может иметь значительный размер, то не должно происходить и никакой реальной компоновки (freestanding), вся вещь компилируется как одна единица трансляции. Это будет один вызов GCC с кучей параметров.
Параметры компилятора
Вот основные параметры компилятора.
-std=gnu99 -Os -nostdlib -m32 -march=i386 -ffreestanding
Поскольку стандартные библиотеки не используются, то единственное различие между gnu99 и c99 заключается в отключенных триграфах (как и должно быть), и встроенный ассемблер можно записать как asm вместо __asm__ . Это не бином Ньютона. Проект будет настолько тесно связан с GCC, что я всё равно не озабочен расширениями GCC.
Параметр -Os насколько возможно уменьшает результат компиляции. Так и программа будет работать быстрее. Это важно с прицелом на DOSBox, потому что эмулятор по умолчанию работает медленно как машина 80-х. Я хочу вписаться в это ограничение. Если оптимизатор вызывает проблемы, то временно поставим -O0 , чтобы определить, тут ваша ошибка или оптимизатора.
Как видите, оптимизатор не понимает, что программа будет работать в реальном режиме с соответствующими ограничениями адресации. Он выполняет всевозможные невалидные оптимизации, которые ломают ваши совершенно валидные программы. Это не баг GCC, ведь мы сами тут делаем сумасшедшие вещи. Мне пришлось несколько раз переделывать код, чтобы помешать оптимизатору сломать программу. Например, пришлось избегать возврата сложных структур из функций, потому что они иногда заполнялись мусором. Настоящая опасность в том, что будущая версия GCC станет ещё умнее и будет ломать ещё больше кода. Здесь ваш друг volatile .
Следующий параметр -nostdlib , поскольку мы не сможем залинковаться ни с какими валидными библиотеками, даже статически.
Параметры -m32-march=i386 командуют компилятору выдавать код 80386. Если бы я писал загрузчик для современного компьютера, то прицел на 80686 тоже был бы нормальный, но DOSBox — это 80386.
Аргумент -ffreestanding требует, чтобы GCC не выдавал код, который обращается к функциям хелпера встроенной стандартной библиотеки. Иногда он вместо реально рабочего кода выдаёт код для вызова встроенной функции, особенно с математическими операторами. У меня это была одна из основных проблем с bcc, где такое поведение невозможно отключить. Такой параметр чаще всего используется при написании загрузчиков и ядер ОС. А теперь и досовских COM-файлов.
Параметры компоновщика
Параметр -Wl используется для передачи аргументов компоновщику ( ld ). Нам это нужно, поскольку мы всё делаем за один вызов GCC.
—nmagic отключает выравнивание страниц разделов. Во-первых, нам оно не требуется. Во-вторых, оно впустую отнимает драгоценное пространство. В моих тестах это не кажется необходимой мерой, но я на всякий случай оставляю эту опцию.
Параметр —script указывает, что мы хотим использовать особый скрипт компоновщика. Это позволяет точно разместить разделы ( text , data , bss , rodata ) нашей программы. Вот скрипт com.ld .
OUTPUT_FORMAT(binary) говорит не помещать это в файл ELF (или PE и т. д.). Компоновщик должен просто сбросить чистый код. COM-файл — это просто чистый код, то есть мы даём команду компоновщику создать файл COM!
Я говорил, что COM-файлы загружаются в адрес 0x0100 . Четвёртая строка смещает туда бинарник. Первый байт COM-файла по-прежнему остаётся первым байтом кода, но будет запускаться с этого смещения в памяти.
Далее следуют все разделы: text (программа), data (статичные данные), bss (данные с нулевой инициализацией), rodata (строки). Наконец, я отмечаю конец двоичного файла символом _heap . Это пригодится позже при написании sbrk() , когда мы закончим с “Hello, World”. Я указал выровнять _heap по 4 байтам.
Запуск программы
Компоновщик обычно знает нашу точку входа ( main ) и настраивает её для нас. Но поскольку мы запросили «двоичную» выдачу, то придётся разбираться самим. Если первой запустится функция print() , то выполнение программы начнётся с неё, что неправильно. Программе нужен небольшой заголовок для начала работы.
В скрипте компоновщика для таких вещей есть опция STARTUP , но мы для простоты внедрим её прямо в программу. Обычно подобные штуки называются crt0.o или Boot.o , на случай, если вы где-то на них наткнётесь. Наш код обязан начинаться с этого встроенного ассемблера, перед любыми включениями и тому подобным. DOS сделает за нас бóльшую часть установки, нам просто нужно перейти к точке входа.
.code16gcc сообщает ассемблеру, что мы собираемся работать в реальном режиме, так что он сделает правильную настройку. Несмотря на название, это не выдаст 16-битный код! Сначала вызывается функция dosmain , которую мы написали ранее. Затем он сообщает DOS с помощью функции 0x4C («закончить с кодом возврата»), что мы закончили, передавая код выхода в 1-байтовый регистр al (уже установленный функцией dosmain ). Этот встроенный ассемблер автоматически volatile , потому что не имеет входов и выходов.
Всё вместе
Вот вся программа на C.
Не буду повторять com.ld . Вот вызов GCC.
И его тестирование в DOSBox:
Тут если вы хотите красивой графики, то вопрос всего лишь в вызове прерывания и записи в память VGA. Если хотите звука, используйте прерывание PC Speaker. Я ещё не разобрался, как вызвать Sound Blaster. Именно с этого момента вырос DOS Defender.
Выделение памяти
Чтобы покрыть ещё одну тему, помните тот _heap ? Можем использовать его для реализации sbrk() и динамического выделения памяти в основном разделе программы. Это реальный режим и нет виртуальной памяти, поэтому можем писать в любую память, к которой мы можем обратиться в любой момент. Некоторые участки зарезервированы (например, нижняя и верхняя память) для оборудования. Так что реальной нужды в использовании sbrk() нет, но интересно попробовать.
Как обычно на x86, ваша программа и разделы находятся в нижней памяти (0x0100 в данном случае), а стек — в верхней (в нашем случае в районе 0xffff). В Unix-подобных системах память, возвращаемая malloc() , поступает из двух мест: sbrk() и mmap() . Что делает sbrk() , так это выделяет память чуть выше сегментов программы/данных, приращивая её «вверх» навстречу стеку. Каждый вызов sbrk() будет увеличивать это пространство (или оставлять его точно таким же). Данная память будет управляться malloc() и подобными.
Вот как можно реализовать sbrk() в программе COM. Обратите внимание, что нужно определить собственный size_t , потому что у нас нет стандартной библиотеки.
Он просто устанавливает указатель на _heap и увеличивает его по мере необходимости. Немного более умный sbrk() также будет осторожен с выравниванием.
В процессе создания DOS Defender произошла интересная вещь. Я (неправильно) посчитал, что память от моего sbrk() обнулилась. Так было после первой игры. Однако DOS не обнуляет эту память между программами. Когда я снова запустил игру, она продолжилась точно там, где остановилась, потому что те же структуры данных с тем же содержимым были загружены на свои места. Довольно прикольное совпадение! Это часть того, что делает забавной эту встроенную платформу.
Программы в com-файлах
1. Для выполнения лабораторной работы вы должны войти в каталог группы из панели NORTON. Каждый студент должен иметь в каталоге группы свой личный каталог. Все программы должны создаваться и записываться в личном каталоге студента.
2. Для получения COM-файлов необходимо написание программы в текстовом редакторе в несколько другой форме. Сегмент стека в COM-файле не определяется, COM-программа генерирует стек автоматически, а все данные определяются не в сегменте данных, а в сегменте кодов.
3. После написания программы в текстовом редакторе с помощью программы tasm.exe необходимо получить OBJ-файл. Далее с помощью программы tlink.exe получают требуемый COM-файл.
4. В COM-программе сегмент стека и сегмент данных не определены. Поэтому в COM-программах резервируется 256-байтовый блок памяти (100Н). Так как адресация начинается со смещения 100Н от начала PSP (префикс программного сегмента), то в программе после директивы ASSUME должна быть команда ORG 100H.
5. Объем COM-файла ограничен 64 Кбайт.
6. Файл в COM-формате меньше, чем соответствующий EXE-файл.
ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ:
Войти в каталог TASM и удалить все созданные вами файлы в предыдущих работах за исключением файла exasm2.asm. Для этого необходимо выделить файлы для удаления клавишей Ins и нажать F8, после чего появится приглашение для подтверждения операции удаления. После нажатия Enter будут удалены все помеченные вами файлы.
1. Создание exe-файла.
1.1. Для программы exasm2.asm получить OBJ-файл. Для этого в командной строке DOS ввести команду:
tasm exasm2.asm
1.2. Для программы exasm2.asm получить LST-файл. Для этого в командной строке DOS ввести команду с опцией l (генерация листинга):
tasm exasm2.asm /l
Просмотреть полученный листинг с помощью текстового редактора LEXICON и записать листинг в отчет.
1.3. Для программы exasm2.asm получить перекрестные ссылки в файле LST. Для этого необходимо ввести команду DOS с опцией с (генерация перекрестных ссылок):
tasm exasm2.asm /l/c
Просмотреть полученный листинг с помощью текстового редактора LEXICON и записать перекрестные ссылки в листинг.
1.4. Для программы exasm2.asm получить листинг без таблицы имен. Для этого необходимо ввести команду DOS c опцией n (подавление таблицы имен):
tasm exasm2.asm /l/n
Просмотреть полученный листинг с помощью текстового редактора LEXICON.
1.5. Для OBJ-файла получить EXE-файл. Для этого в командной строке DOS ввести команду:
tlink exasm2.obj
Выполните ввод команды DOS (Enter). В вашем каталоге появится необходимый EXE-файл, а также MAP-файл. Просмотрите MAP-файл, нажав клавишу F3 и запишите текст файла в отчет.
2. Получение com-файла.
2.1. Для получения COM-файла необходимо создать в текстовом редакторе NORTON программу в другом формате. Для этого нажмите комбинацию клавиш Shift F4 и введите имя программы xcom1.asm. Далее запишите текст программы в следующей форме:
TITLE XCOM1 (COM) для пересылки и сложения
CODESG SEGMENT PARA ‘Code’
ORG 100H ;Начало в конце PSP
BEGIN: JMP MAIN ;Обход через данные
FLDA DW 250 ;Определение данных
MOV AX,FLDA ;Переслать 0250 в АХ
ADD AX,FLDB ;Прибавить 0125 к АХ
MOV FLDC,AX ;Записать сумму в FLDC
RET ;Вернуться в DOS
Оператор ASSUME указывает ассемблеру на необходимость установить относительные адреса с начала сегмента кодов. Регистр CS также содержит этот адрес, являющийся к тому же адресом префикса программного сегмента (PSP). Директива ORG служит для резервирования 100Н байт от начального адреса под PSP.
ORG 100H устанавливает относительный адрес для начала выполнения программы. Программный загрузчик устанавливает этот адрес в командном указателе.
Если опущен ORG 100H, то на данные в префиксе программного сегмента будут установлены неправильные ссылки с непредсказуемым результатом при выполнении.
Команда JMP служит для обхода данных, определенных в программе. Запишите программу на диск и выйдите из редактора нажав комбинацию клавиш Shift F10.
2.2. Создайте OBJ-файл и LST-файл для программы xcom1.asm аналогично пункту 1.3. Просмотрите LST-файл с помощью текстового редактора LEXICON и запишите листинг в отчет.
2.3. Создайте COM-файл и MAP-файл. Для этого в командной строке DOS введите команду аналогично пункту 1.5. с опцией t (создание COM-файла):
tlink xcom1.obj /t
Без опции t управляющая программа tlink создаст EXE-файл.
Попытка выполнить EXE-модуль программы, написанной для COM-формата, успеха не имеет.
Нажав клавишу F3 просмотрите MAP-файл и его текст запишите в отчет.
СОДЕРЖАНИЕ ОТЧЕТА:
1. Листинги программ.
2. Тексты MAP-файлов.
КОНТРОЛЬНЫЕ ВОПРОСЫ:
1. Каков максимальный размер COM-файла?
2. Какие сегменты можно определить в программе, которая будет преобразована в COM-файл?
MS-DOS и TASM 2.0. Часть 3. Первая программа.
Наша первая программа на ассемблере будет в формате *.COM — как мы уже знаем, исполняемые файлы указанного формата очень крохотные (tiny) по размеру и состоят из одного сегмента, в котором размещаются код, данные и стек.
Ещё мы знаем, что в указанном формате пишутся резидентные программы, драйверы и вирусы.
Резидентная (TSR-программа, от англ. Terminate and Stay Resident) — это программа, которая после запуска передает управление операционной системе, но сама не завершается, а остаётся в оперативной памяти, реагируя на определённые действия пользователя. Например, при нажатии сочетания горячих клавиш делает снимок экрана.
Код в статьях отображается в удобочитаемой форме: каждая строка имеет свой номер, строки и код подсвечиваются. Чтобы скопировать «чистый исходник», наведите курсор мыши на текст, дождитесь всплывающего меню и нажмите в меню кнопочку «копировать» (изображение двух листочков бумаги с текстом). Чистый код не содержит нумерации строк!
Наша первая программа выведет на экран монитора (консоль) надпись «Hello, World!». Итак, как говорил Юрий Алексеевич, поехали!
Создаём исполняемый файл PRG.COM.
Для достижения нашей цели делаем следующее.
- Скачиваем с нашего сайта архив (DOS-1.rar) с предустановленными DOSBox и программами. Запускаем DOSBox. Стартует эмулятор MS-DOS и Norton Commander пятой версии.
- В папке D:\TASM.2_0\TASM\ находим текстовый файл PRG.ASM. Это обычный текстовый файл, который можно создать
с помощью любого текстового редактора, с расширением ASM вместо TXT. - В файл вносим код:
- В папке D:\TASM.2_0\TASM\ находим «батник» ASM-COM.BAT со следующим текстом:
Первая строка — запуск транслятора с названием нашего файла с кодом, расположенного в одной директории с транслятором.
Вторая строка — запуск компилятора с параметрами /t /x и название объектного файла — prg.obj, получившегося в результате выполнения первой команды.
Чтобы посмотреть список всех возможных параметров с пояснениями для файлов tasm.exe и tlink.exe необходимо запустить эти программы без параметров. Если вы сделаете это, не выходя из оболочки NC, то, чтобы просмотреть чистое окно DOS нажмите Ctrl+O, чтобы вернуться в NC, нажмите сочетание клавиш повторно.
- После запуска ASM-COM.BAT в этой же директории появится файл prg.com. Запустив его мы увидим сообщение «Hello World!» в окне MS-DOS (при необходимости просмотра, снова применяем Ctrl+O).
Батник ASM-EXE.BAT предназначен для создания исполняемого файла формате *.EXE (предусматривает раздельную сегментацию для кода, данных и стека — наиболее распространённый формат исполняемых файлов DOS).
Батник COMPLEX.BAT предназначен для создания исполняемых файлов из двух файлов кода (названия обязательно должны быть prg.asm, prg1.asm).
Наша первая программа на ассемблере прекрасно работает!
TASMED (Tasm Editor) — среда разработки приложений DOS на ассемблере.
Выше мы рассмотрели стандартный подход к программированию на TASM в системе MS-DOS. Указанным алгоритмом создания программ можно пользоваться и далее.
Для более удобной работы с кодом целесообразно применять какую-либо среду разработки. Среда разработки — это громко сказано для времён MS-DOS, правильнее сказать — специфический редактор.
Можете попробывать TASMED в папке D:\UTILS\TASMED\. Программа уже настроена и готова к использованию.
Первая программа на ассемблере в среде разработки TASMED.
- подсветка ассемблерного синтаксиса;
- возможность сохранения проектов под любым именем и в любой директории;
- работа как с TASM, так и MASM.
- только английский язык интерфейса, но английский программист должен знать лучше русского;
- слишком много настроек для текстового редактора.
Хотя, в принципе, настройки — не проблема. Основное, что необходимо настроить — это соответствующие пути:
Options->External->Assembler
Options->External->Linker
В общем, разобраться не сложно.
Практические советы: группирование проектов, русский язык в MS-DOS.
Для удобства группирования создаваемых программ можно создать отдельную папку (мы создали папку PROJECTS) в которой создавать папки названий проектов, куда копировать соответствующие файлы. Пока у нас — это PRG.ASM, PRG.OBJ, PRG.EXE. Однако, в зависимости от параметров и наших программ их может быть больше (PRG.MAP, PRG.SYM и др.).
В нашем случае, все программы, рассматриваемые в курсе обучения будут группироваться в директории D:\WORK в соответствующих папках. Например, наша первая программа в папке D:\WORK\PRGCOM\ (файлы prg.asm и prg.com). Папку D:\TASM.2_0\PROJECTS\ оставляем пустой для ваших проектов и экспериментов.
Для того, чтобы в исходниках, которые вы будете просматривать в системе MS-DOS с использованием текстовых редакторов DOS и различных сред разработок нормально отображалась кириллица (например в комментариях к строкам кода) необходимо проделать следующие действия.
- Запустить драйвер русской раскладки клавиатуры. В нашей запущенной MS-DOS системе на базе DOSBox это файл C:\KEYRUS\keyrus.com. Впрочем, при запуске MS-DOS согласно нашим настройкам DOSBox, он запустится автоматически. При этом будет обеспечено не только отображение русского текста в текстовых редакторах, но и русскоязычная раскладка клавиатуры. Переключение раскладки Eng->Rus и наоборот — горячая клавиша «правый CTRL».
- Текст исходников необходимо писать в текстовых редакторах или средах разработки DOS.
- Если исходники пишутся в Windows редакторах, должна быть обеспечена русскоязычная кодировка текста — ASCII для DOS (CP866 или OEM866).
Конечно вопрос снимается сам собой, если комментарии писать на английском.