А как дёргать лапами LPT через ВинАПИ?, По аналогии с СОМ не получается. Опции

[Dr.Alex]

Port = CreateFile ("LPT1", .... ) успешно открывает порт,
но WriteFile (Port, ....) ничего не выводит.
А еще хотелось бы какие-то функции, чтоб остальные лапы контролировать....

[ReAl]

Стандарт IEEE1284 — не более, чем первоисточник по обмену согласно стандарту IEEE1284.

LPT — это устройство, которое позволяет (может позволять) работать согласно этому стандарту. Но кроме этого может позволять и прямое управление, как это делается при работе непосредственно с регистрами ввода-вывода под DOS или через драйвер доступа к портам под windows. И как это делает драйвер параллельного порта под Windows, в режиме SPP всё идёт тем же ногодрыгом, только в драйвере. Можно было дать канал ioctl для такой работы снаружи.
Для COM-порта в WinAPI есть всё дёрганье на нижнем уровне, для LPT под Windows почему-то этого не сделали, ioctl-операции есть только для статусных сигналов.
И, непонятно почему, даже к стаусным сигналам доступ занимает очень много времени — около десяти микросекунд.

Под Linux ioctl-коды есть на все операции с регистрами LPT и занимают они намного меньше времени. Например, для LPT-платы, прямое обращение к регистру данных или состояния которой занимает 0.7-0.72 мкс, ioctl-операции под Linux укладываются в 1.1-1.2мкс, под Windows, как уже сказано, только регистр состояния и около 10мкс.

[V_G]

Для COM-порта в WinAPI есть всё дёрганье на нижнем уровне, для LPT под Windows почему-то этого не сделали, ioctl-операции есть только для статусных сигналов.

Так верно написали же, что LPT считается портом ТОЛЬКО для управления принтером, а COM - порт универсальный. Для универсализма допустимо и требуется больше функций.
Потому и управление через LPT считается дурным тоном. Если делаете для себя, то допустимо, если для клиентов - то крайне нежелательно. Винды в своем развитии допускают все меньше вольностей подобного рода.

[ReAl]

Так верно написали же, что LPT считается портом ТОЛЬКО для управления принтером,

Iomega ZIP drive. Сканеры.
Да, да, да, «они просто приспособили принтерный порт».

а COM - порт универсальный. Для универсализма допустимо и требуется больше функций.

Какая универсальность? COM-порт — это порт последовательного канала со своим стандартом.
У линий DTR, DSR, RTS, CTS есть вполне оговоренное предназначение. Надо аппаратное квитирование — включите его в DCB при настройке порта. Открывайт порт, указывайте скорость, режим квитирования, ... и всё. Обменивайтесь.
Зачем вытаскивать на уровень API операции установки и опроса состояния этих ног?
Точно такая же «вольность подобного рода».

Потому и управление через LPT считается дурным тоном. Если делаете для себя, то допустимо, если для клиентов - то крайне нежелательно.

Как клиент Iomega я в своё время был очень доволен. Да, они управление через LPT сделали в драйвере (против чего ял ично ничего не имею, см. ниже).
Но они не считали LPT портом прямо аж большими буквам ТОЛЬКО для принтера, за что я им и благодарен. Ну а уж 1284-ый стандарт так и вообще принтер хоть и упоминает, но как историческую основу.

Винды в своем развитии допускают все меньше вольностей подобного рода.

Зачем тогда вытащено прямое управление линими состояния LPT?
Если бы не было ничего — я бы относился с пониманием.
Вот есть порт, вот есть драйвера, вот есть ОС, вот есть приложение. Открывайте устройство (принтер, сканер, ...) и общайтесь через API с устройством. Опрашивайте его готовность через драйвер. И вообще — какой такой WriteFile? PrintPage, PrintDocument, раз это принтер.
А так выходит, что PaperEnd можно вручную опросить через IOCTL, а байт вручную выбросить, записав в регистр данных — нельзя. Где логика?

Ещё раз — я не считаю, что ОС обязана мне предоставить «низкий» уровень работы с каналом связи, будь то принтрный порт или порт RS232. Дала — хорошо, пользуемся. Не дала — разбираемся, как писать свой драйвер.
Я просто вижу странность — для одного порта наверх выведено и нормальное высооуровневое управление типа «включить аппаратное квитирование», и прямой ногодрыг RTS/CTS/DTR/DSR (при том, что при пассивных *Ready по стандрту состояние соответствующих *ToSend-о считется невалидным), а для другого — из нижнего уровня наверх выведена половина.

Да и вообще LPT медленно, но верно вымирает. Нечего на него и ориентироваться.

Это отдельный вопрос :-)
Кроме того, как говорил один мой знакомый на фразу «так это уже N лет не выпускается!» — «я уже в K раз большее время не выпускаюсь».