>>599089
Ясно, ты пока не понимаешь, как всё устроено.

COM-порт позволяет пользовательской программе или системному модулю получать и принимать байтики (опустим семибитные и прочие ещё более древние варианты). Всё. В простейшем варианте у него нет ни проверки корректности приёма и передачи, ни их подтверждения, ни понимания, что творится на другом конце, и есть ли там вообще какое-то устройство, ни согласования режима скорости. Ты просто посылаешь байтик за байтиком и предполагаешь, что должно произойти, либо принимаешь их и веришь, что они правильные, всё остальное надо реализовывать дополнительно. Что значат эти байтики, как они должны быть сгруппированы, оборудованию абсолютно всё равно.

Модем изначально такое же пассивное устройство, преобразующее колебания между двумя уровнями сигнала в простое или сложное гудение, которое можно передавать по телефонной сети. Компьютер точно так же не знает, что провода идут к модему, а на другом конце вызова тоже модем, и к нему так же подключен компьютер, он просто посылает и принимает байтики. Потом модемы набрали чипов, стали умными и начали в байтиках искать последовательности (AT-команды), на которые самим надо было реагировать вместо отправки дальше.

В восьмидесятые годы и до середины девяностых в разговорах о глобальных сетях (не обязательно Internet) для персональных компьютеров (не обязательно IBM-совместимых) подразумевался терминальный доступ, унаследованный от многопользовательских систем прежних десятилетий. Клиент, выполняющийся локально, получал байтики от подключенной напрямую или удалённо через коммуникационный порт (и, возможно, модем) системы и выводил их на экран, а нажатия клавиш передавал туда. Следовательно, всю работу делала программа на сервере, а клиент мог выполняться даже на микрокомпьютерах с минимумом памяти, поскольку его задача была в копировании буковок на экран. Человек звонил на BBS и получал менюшки, сообщения и новости, звонил на сервер провайдера и после ввода логина и пароля мог посмотреть почту в ящике или новые сообщения на досках Usenet, на которые подписался, звонил на сервер какого-нибудь биржевого сервиса и выводил нужные данные об акциях.

Изначально буковки просто выводились построчно и убегали за верхнюю границу экрана, чтобы пропасть навсегда. Если к локальной системе был подключен принтер, то для сохранения нужного вывода (текста письма, записи из базы данных, результата расчёта) можно было нажать какой-то аналог «Print Screen» и получить копию моноширинного текстового экрана на моноширинном текстовом принтере. К моменту появления персональных компьютеров уже существовали стандартные последовательности для управления положением курсора на экране, то есть терминальные протоколы в простых и сложных вариантах от разных производителей. Потом появились ориентированные на новые применения протоколы передачи файлов со сжатием и проверкой корректности вроде x-, y-, z-modem, когда более умные терминальные программы понимали, что после определённой последовательности надо перестать выводить данные на экран, а договориться с той стороной о длине и прочем и сохранять получаемое в файл. В FidoNet свои протоколы были для автоматического получения и отправки пачки сообщений и отключения. В сетях вроде COMPUSERVE использовались свои клиентские программы, которые сами рисовали пользователю сложные интерфейсы с кучей функций (почта, новости, форумы), а с серверов получали только изменённые данные (саму почту, сами тексты новостей и так далее).

COM-порт виртуалки тривиально заворачивается хоть на ввод и вывод приложения или терминальной консоли, хоть в сетевое соединение куда-то далеко через telnet или netcat. Но это терминальный доступ сам по себе.

В DOS, WIndows 3 и 9x сетевые компоненты вообще не ставились по умолчанию (если на компьютере не было модема или сетевой карты). Не было не только реальных, но и виртуальных сетевых интерфейсов, включая 127.0.0.1 (в случае протокола IP). Не было даже библиотек, к которым приложения могли бы обратиться для работы с сетью. Процессы, не использующие сетевые функции, просто не знали, существуют они или нет (да и до сих пор так работают). Вот если надо было, то ставился драйвер сетевой карты, знающий, как пакетики обернуть в кадры нужного формата, и заставляющий железку генерировать битовые последовательности для отправки и в колебаниях на входе выделять корректные предназначенные локальной системе данные, а также сетевые протоколы по выбору: IPX (файловые сервера Netware появились раньше и были функциональнее, а игры, поддерживающие локальную сеть, выбирали его из-за простоты и популярности), TCP/IP, NetBIOS и SMB («Общий доступ к файлам и принтерам»), а также приложения, которые могли их использовать. Чем раньше было дело, тем большая часть перечисленного поставлялась фирмами, отвечающими за сеть, а не Microsoft, и тем сильнее была привязка к конкретному оборудованию.

Следовательно, ты либо добавляешь виртуальную сетевую карту, которая хорошо поддерживалась в старых системах, ставишь драйверы и соответствующий софт, и пользуешься IP-сетью так же, как и в более новых системах, либо используешь виртуальный COM-порт в госте как нуль-модем (прямое подключение компьютеров друг к другу) или выделенную линию (на которой оборудование настроено, постоянно работает и не требует команд), а на стороне хоста заводишь его на приложение PPP- или SLIP-сервера (в зависимости от того, какие протоколы поддерживает установленный набор программ), которое будет думать, что принимает вызов. Древние мануалы по модемной связи и настройке сервера на UNIX-подобных системах до сих пор можно найти в интернете.