Да, ключевая фраза "до переустановки Windows".
Значит железо у вас нормальное - ищите подходящие драйвера.
Если проблемы с поиском или не знаете какое оборудование у вас установлено, то делайте следующим образом: в диспетчере устройств откройте свойства вашего устройства, перейдите на закладку "Сведения" выберите в списке "ИД оборудования" и ищите по идентификатору оборудования: перепешите весь идентификатор включая SUBSYS_.....
REV и прочее в поиск, как правило, включать не надо.
Вариант по проще - возьмите любой драйверпак и натравите его на свои железки. Например этот: https://sdi-tool.org/
Перечитал документацию по fgets - в примере правильное использование, fgets учитывает, что в количество прочитанных символов входит еще и завершающий 0.
Все функции, работающие со строками, добавляют символ 0 в конце строки. Этим они отличаются от функций, которые работают с массивами байт, типа memcpy.
Но тут еще один момент - судя по описанию fgets, она читает не более заданного количества символов, т.е. в нашем случае 80, и дописывает следом за последним прочитанным символом 0. Т.е. если пользователь ввел 80 символов fgets запишет в 81 байт 0. Типичное переполнение буфера.
И это не вызовет никакой ошибки т.к. буфер в стеке. Даже если буфер будет в динамической памяти, то вполне вероятно, что ошибки не будет. Скорее всего конкретно в этом примере это не приведет ни к каким последствиям, но в более сложной программе вполне может быть порча данных, которые лежат в стеке следом за буфером.
По уму в fgets надо передавать 79 или делать буфер в 81 символ.
Да, будет висеть и ждать когда нажмешь "вход". За одно и пароль можно поставить. Тут уж одно из двух или нормальный терминальный режим или автоматический вход.
Кстати, есть еще вариант - shadow RDS: https://habrahabr.ru/post/147273/
В этом случае можно получить доступ к рабочему столу одновременно с пользователем консоли, т.е. и удаленный и локальный пользователи будут видеть один и тот же раб.стол. Но для этого требуется подключаться к конечному компьютеру из терминальной сессии. Т.е. в общем случае сначала с удаленной рабочей станции заходишь по RDP на промежуточный терминальный сервер, а с него уже даешь команду shadow и подключаешься к удаленной рабочей станции. Кроме того у этого режима есть еще нюансы - микрософт начиния с Windows Vista и заканчивая Windows 8 (и соответствующих серверных ОС) убрала shadow из RDP. В Windows 8.1 вернули обратно.
Хром получает только HTTP ответ (внешний слой инкапсуляции пакета уже обработан ОС), но т.к. на момент получения ответа соединение уже установлено, то хром знает и адрес и порт сервера, и свои то же знает, конечно.
В ОС есть таблица соответствия номера порта и процесса открывшего этот порт. Но на самом деле ОС не отправляет данные процессу из таблицы, а процесс сам читает свой сокет (читай "данные пришедшие на свой порт"). Это сделано так, потому что, например, возможна ситуация, когда TCP соединение устанавливает один процесс, а прием/передачу данных по этому соединению осуществляет другой.
В винде посмотреть таблицу можно:
netstat -ab
Правда PIDы не отображаются, но имя процесса есть, на самом деле, конечно, в таблице лежат PIDы, а уже из них netstat получает имена процессов.
В никсах есть аналогичная команда:
sockstat - во FreeBSD
В линуксе то же она должна быть, но точно не скажу, т.к. с линуксом мало имею дела.
Тут я не сильно в теме, но, возможно, надо перезагрузить веб сервер или вообще сервер. Может быть php или веб сервер кэшируют ДНС запросы и просто отдают вам ответ из кэша.
HTTP работает поверх TCP, TCP поддерживает виртуальное соединение (сессию). Сессии в TCP адресуются с помощью адреса и порта отправителя и адреса и порта получателя. Таким образом обоим сторонам сессии известен и адрес и порт "собеседника". Все данные для адресации должны быть известны еще до установки соединения. Для доказательства того что PID не передается можно просто посмотреть формат IP+TCP заголовка.
Ответ на HTTP запрос приходит в рамках одной сессии. Т.е. проблем со знанием порта chroma у сервера нет.
Вообще довольно странная точка зрения у вашего преподавателя, учитывая, что tcp/ip - это универсальный способ передачи данных по сети, не привязанный к конкретной реализации в конкретной операционной системе. Например, в одной ОС PID может быть целым без знаковым 32 битным числом, а в другой - знаковым 16 битным, а в третьей - вообще идентифицироваться именем исполняемого файла - никаких жестких стандартов по этому поводу нет. А в каких-нибудь встроенных контроллерах вообще нет ОС и нет процессов в общем понимании, но они при этом вполне могут посылать информацию по сети.
С Z я пожалуй не прав. Пересеклось с Citrix XenApp. Там локальные клиентские диски по другому планируются. И освободив букву диска С на терминальном сервере, клиентский С: будет планироваться в терминальной сессии то же на С:. И это довольно удобно для пользователей - они видят один и тот же диск как на локальном компе так и в терминальной сессии.
Когда выводите на печать, то разбираться надо уже с принтером, а не с консолью. print так же как и type ничего не предполагает о кодировке файла - тупо посылает файл в принтер.
Если принтер достаточно продвинутый, то как правило там можно установить кодировку текста по умолчанию, если нет, то надо смотреть какой управляющий язык поддерживает принтер, искать команду смены кодировки текста и вставлять ее в начало файла.
Либо искать другой инструмент для печати.