- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
; * WARNING WARNING WARNING WARNING WARNING WARNING WARNING *
; Please do not try to use external procedures
; unless you are familiar with assembly language.
;
; IMPORTANT: Externals must be written in assembly language.
;
; The following example translates a string to upper case.
;
; Place the following code in a file: "STU.ASM"
;
CODE SEGMENT
ASSUME CS:CODE
STU PROC NEAR
PUSH BP ; SAVE ENVIRONMENT
MOV BP,SP ; MANUAL PAGE 189
LES DI,[BP+4] ; GET PARAMETER
MOV CL,ES:[DI]
INC CL
L1: DEC CL
JZ L2
INC DI
CMP ES:BYTE PTR[DI],'a'
JB L1
CMP ES:BYTE PTR[DI],'z'
JA L1
SUB ES:BYTE PTR[DI],20H
JMP SHORT L1
L2: MOV SP,BP ; RESTORE ENVIRONMENT
POP BP ; MANUAL PAGE 190
RET 4
STU ENDP
CODE ENDS
END
; Now exit to PC-DOS and type:
;
; ASM STU
; LINK STU
; EXE2BIN STU.EXE STU.COM
;
; IGNORE MINOR ERRORS FROM ASM AND LINK
To use, write the following program:
type
AnyString = string[255];
var
S: AnyString;
I: integer;
procedure STU(var S: AnyString); external 'STU.COM';
begin
readln(S);
STU(S);
writeln(S);
end.
Turbo Pascal 3.0. Внешние процедуры/функции линковались не из OBJ-файла, а из COM-файлов. Один файл — одна функция, никакого обмена символами.
Follow us!
Со мною не видать тебе удачи.
Навеки моё дело — зло и месть,
Для демона не может быть иначе!
https://youtu.be/eqt2xLTatc8
В более новых Турбо Паскалях поддерживалась линковка OBJ-файлов и директива asm для вставок на Ассемблере. В 3.0 таких вкусностей не было, потому и придумали такой костыль.
Начало модуля GRAPH.BIN — 28 джампов, каждый из которых занимает по три байта (отсюда и шаг, равный трём, в индексах). Самое смешное, что этот самый GRAPH.BIN дожил до Борман Паскаля 7.0 (декомпиляция GRAPH.TPU от BP 7.0 показывает, что в него целым куском включён тот самый GRAPH.BIN (вероятно, с модификациями), а остальные функции — обёртки над вызовами допотопного кода).
Настоящие COM-файлы DOS всегда грузит так, что в точке старта IP=100H (256 в десятичной системе).
EXE-файлы могут грузиться по любому смещению от начала сегмента, но в них есть таблица перемещаемых символов, с помощью которой ОС патчит исполняемый образ при загрузке.
А виртуальные адреса уже относятся к программам защищённого режима (в том числе и Windows), к которым данный пример не относится. И да, бывают приложения Windows как с фиксированным виртуальным адресом (без таблицы перемещаемых символов), так и с произвольным виртуальным адресом (с таблицей перемещаемых символов).
>произвольным виртуальным адресом (с таблицей перемещаемых символов).
Это как?
> Turbo Pascal 3.0.
Действительно, трудно догадаться, для какой системы он был.
Пересмотрел код ещё раз. По коду видно только, что он для 16-битной системы с сегментами, больше никаких особенностей. Теоретически такой же код можно было скомпилировать и для Windows 3.x, и для 16-битной OS/2 (если бы существовал подходящий компилятор).
Ну тут даже и не важно, что он для ДОС. Важно то, что внешний двоичный образ (STU.COM) вклеивается в произвольное место программы, следовательно, адрес первой команды процедуры STU может быть случайным.
В OBJ-файлах есть табличка перемещаемых данных, чтобы фиксить адреса при линковке. В COM-файле такой таблички нет.
**********
>>произвольным виртуальным адресом (с таблицей перемещаемых символов).
> Это как?
Ты не про виртуализацию, а про RVA, который присутствует в виндовых PE-файлах, в линуксовых ELF-файлах и в OBJ-файлах? Ну так если модуль загрузился по адресу, не совпадающему с RVA, то его надо фиксить, а для этого нужна таблица перемещаемых символов (релокейшнов/фиксапов).
Что же касается виндовых экзешников, то их было два типа. Начиная с Windows 98 стали активно форсить экзешники, у которых при старте VA=RVA и табличка фиксапов отсутствует. Это позволяло сэкономить несколько килобайт (уже смешно) в экзе-файле и несколько наносекунд при старте программы. Для этого каждый экзешник помещался в своё адресное пространство.
Но такое поведение не было обязательным. Как я уже написал, раньше собирали экзешники, способные запускаться при VA≠RVA. В частности у Win32s (32-битный API для Windows 3.x) не было поддержки виртуальных пространств, поэтому экзешники приходилось раздвигать по разным адресам.
С появлением ASLR в Висте снова вспомнили про VA≠RVA и экзешники с табличкой фиксапов вернулись.
64К should be enough for everything.
Нет, он про OpenSolaris. У него регистры 16ти битные SP и BP. Угадай операционку по разрядности.
Даже Windows 95/98/Me зачем-то использовали несколько вызовов DOS API, хотя теоретически они не были нужны...
С дисками была проблема из-за отсутствия кэширования, но это решалось костылями типа smartdrive.
Кстати, с дисками через контроллер пользовательские программы не общались (за исключением специфических типа undelete/unerase, scandisk, defrag, diskedit, которым прямой доступ к дискам необходим). Кулхацкеры писали для себя драйвера, которые заменяли собой тормозные драйвера ДОСа или БИОСа, но в пользовательские программы это не совали.
Только представь себе, что для прямого обращения к диску через контроллер тебе придётся распарсить файловую систему, причём сделать это точно так же, как это делает ДОС, включая все виртуальные и сетевые диски, директории, для которых сделан JOIN или SUBST и прочую питушню.
Вот в Интернет не умел... Приходилось библиотеки для TCP/IP линковать с программой.
В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM.
и DOS (новел нетварь же!) а в Win95 он чуть ли не сразу ставился потому что ппрактически все сети были на нем.
Вот в 98 уже нет.
А примерно во времена Win2K МС ризнал главенство Интернета и начал вместо левого говна стараться всезде юзать TCP, IP, DNS, LDAP итд.
P.S. Если что, окно для текстового режима было в $B800:$0000. Там всё было просто.
Эээээ...
Некоторым, конечно, удавалось через ДОС, но для этого нужно было загрузить драйвер ANSI.SYS, чтобы он обрабатывал эскейп-последовательности, с помощью которых можно было раскрашивать экран и двигать курсор. Но дальше бибиэсок это не пошло́.
Все популярные программы типа Нортона рисовали UI через БИОС или срали в видеопамять.
В итоге АБСОЛЮТНО ВСЕ
эмуляторы терминала (линуксовые, маковые итд) работают через эскеп последовтальности (из termcap / terminfo), а винда нет.
В итоге ncureses например работает везде, а на винде надо всё по другому делать.
Ну не сидары-ли?
Из-за этого кстати все прыщеговно не умеет в юникод на виндовой консоли. Ну не прыщеговно ли?
Все идут не в ногу, и только MS в ногу.
Уникод нормальный в консоли есть, но с болью потому что пиндовый "65001" на самом деле не UTF-8.
А так да, «графический» режим Нортон Коммандера на самом деле был текстовым, только вместо стандартных символов псевдографики в знакогенератор были загружены красивости.
ТурбоВижен
Ну тогда ты прав. Я просто неверно понял, извини.
Мой комментарий был ответом на комментарий Василия, где он писал, как «старый хакер» рекомендовал выводить на экран через средства БИОС, а не ДОСа.
Через BIOS работать проще и везде работает, но медленнее.
Ну а самый простой (и самый тормознутый) сопосб это DOS.
Ты так не пугай, а то люди и правда поверят, что никогда нельзя... А ты только про случаи, когда релоков нет.
Олсо, на x86_64 можно юзать RIP-relative адресацию и наслаждаться жизнью без релоков.
Виноват. Забыл, что на сайт заходят дети, которые могут неправильно понять...
> x86_64 можно юзать RIP-relative адресацию
На x86_64 можно использовать относительную адресацию не только для джампов, но и для обращения к памяти?