Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
Т.е. порт может быть реальным или виртуальным — без разницы.

Если вопрос задан нечётко, то обрисую ситуацию:
Есть программа, которая берёт данные с порта. Есть железка, которая посылает данные в порт. Но формат этих данных надо преобразовавать, т.е. я пишу конвертилку. У портов, в общем случае, могут быть разные настройки (скорость и т.д.).
Сейчас просто кинули кабель СОМ1-СОМ2, но получается, что для отладки мне надо 4 порта, да и на этапе продажи какое-то некрасивое решение получится.

P.S. Если ошиблась форумом — отмодерируйте пожалуйста.

Здравствуйте, Red Cap, Вы писали:

RC>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
Скрепка во 2-3ю дырку Правда система двум программам СОМ-порт не даст

Здравствуйте, Programador, Вы писали:

P>Здравствуйте, Red Cap, Вы писали:

RC>>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
P>Скрепка во 2-3ю дырку Правда система двум программам СОМ-порт не даст

если бы дала, я бы так и сделала

Здравствуйте, Red Cap, Вы писали:

RC>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
RC>Т.е. порт может быть реальным или виртуальным — без разницы.

Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.

Здравствуйте, wallaby, Вы писали:

W>Здравствуйте, Red Cap, Вы писали:

RC>>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
RC>>Т.е. порт может быть реальным или виртуальным — без разницы.

W>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.
Это как? Хотя бы схематично расскажите.

Здравствуйте, Red Cap, Вы писали:

W>>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.
RC>Это как? Хотя бы схематично расскажите.

Ну например, для открытия порта приложения будут вызывать экспортируемую этой dll функцию OpenPort, которая при первом обращении будет вызывать CreateFile для физического открытия порта, а при последующих вызовах просто инкрементировать глобальный счётчик. Аналогично, ClosePort будет этот счётчик декрементировать и при обнулении вызывать CloseHandle. Ну и так далее.

Здравствуйте, wallaby, Вы писали:

W>Здравствуйте, Red Cap, Вы писали:

W>>>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.
RC>>Это как? Хотя бы схематично расскажите.

W>Ну например, для открытия порта приложения будут вызывать экспортируемую этой dll функцию OpenPort, которая при первом обращении будет вызывать CreateFile для физического открытия порта, а при последующих вызовах просто инкрементировать глобальный счётчик. Аналогично, ClosePort будет этот счётчик декрементировать и при обнулении вызывать CloseHandle. Ну и так далее.

Т.е. драйвер виртуального СОМ-порта, где вся обработка будет в драйвере? Или нет? Если так, то слишком сложно и трудоёмко
Приложение, читающее СОм-порт чужое, его менять нельзя

Здравствуйте, Red Cap, Вы писали:

RC>Т.е. драйвер виртуального СОМ-порта

Было недавно. Null-modem emulator