type a file to serial port and receive it on another computer

Hello all,

Recently I remembered that it was possible to make a serial connection
between two 'puters and send, from the commandprompt and without using any
(other) programs, a textfile from one to the other. I say "was", as I
can't seem to repeat it between two XPsp3 machines.

Specs:
The machines are connected thru a so-called "null modem" (three-wire) cable
(with the handshake signals wrapped back onto the same conector).

A "mode com1 9600,n,8,1" command has been used (trying to debug the matter)
on both to set up the connection, and "mode com1 /status" returns the same
for both 'puters:

Baud: 9600
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: ON
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON

The problem:
Both "type com1" and "copy com1 bla" on the target 'puter finish
immediatlily (do not wait for incoming data).

The null-modem connection itself seems to be fine, as I've used a simple
RS232 application which shows the data coming in.

Does anyone recognise the problem and can tell me what goes wrong ?

Regards,
Rudy Wieser

R.Wieser wrote:
Hello all,

Recently I remembered that it was possible to make a serial connection
between two 'puters and send, from the commandprompt and without using any
(other) programs, a textfile from one to the other. I say "was", as I
can't seem to repeat it between two XPsp3 machines.

Specs:
The machines are connected thru a so-called "null modem" (three-wire) cable
(with the handshake signals wrapped back onto the same conector).

A "mode com1 9600,n,8,1" command has been used (trying to debug the matter)
on both to set up the connection, and "mode com1 /status" returns the same
for both 'puters:

Baud: 9600
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: ON
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON

The problem:
Both "type com1" and "copy com1 bla" on the target 'puter finish
immediatlily (do not wait for incoming data).

The null-modem connection itself seems to be fine, as I've used a simple
RS232 application which shows the data coming in.

Does anyone recognise the problem and can tell me what goes wrong ?

Regards,
Rudy Wieser

One of the requirements, was to send an EOT character

https://en.wikipedia.org/wiki/End-of...sion_character

so that the connection could close properly.

Now, mine is all cabled up and ready to go. The two machines
already have a serial RS232 interconnect (COM1 == COM3), with a null modem
thingy in the center (connects TX to RX, RX to TX, so
two computers can talk to one another, without shorting a
TX to a TX).

I fired up putty to verify, on the receiving end.
Set baud rate to 57600, enabled RTS/CTS.

On sending end

mode COM1 BAUD=57600 PARITY=n DATA=8 STOP=1 RTS=on
type sample.txt COM1
copy con: COM1
Enter
ctrl-Z
Enter === flushes input at a guess

The problem seems to be mostly on the receiving end.

1) Doesn't seem to have permission to copy COM3 to anything.
2) Does see the ctrl-Z coming across the cable. Closes COPY.

copy COM3 impossible.txt

impossible.txt ends up with "0 files copied" string in it.

The receive end is not at all happy. Could this be
symptoms that "port is busy" ? Probably.

Evidence when receiving in putty, is "it's working to the
best of puttys knowledge". Ownership issues from Command Prompt
seem an issue right now. When putty exist, you'd think COM3
could then be captured by anyone.

So, nope, doesn't work for me at the moment. Situation
"ripe" but "not harvested". All the ingredients seem to be
there, but Clippy has broken it.

HTH,
Paul

Paul,

One of the requirements, was to send an EOT character

Yep, I also tried sending files terminated with it. Alas, no change.

impossible.txt ends up with "0 files copied" string in it.

I found out that in my case it depends: directly after booting it doesn't
return and needs to be killed thru the taskmanager, but after having used my
beforementioned RS232 checking program (even though "mode com1" showing the
same !) it returns directly (either not displaying anything or as you
described, with a zero-length file)

The receive end is not at all happy.

Thats my assumption too.

Could this be symptoms that "port is busy" ? Probably.

As I can run that "RS232 checking program" without a problem (and it
receives the send data), I would say that the port isn't busy or owned by
another program.

So, nope, doesn't work for me at the moment. Situation
"ripe" but "not harvested". All the ingredients seem to be
there, but Clippy has broken it.

:-) /Something/ seems to be "broken" alright. I just wish I knew how to
fix it.

Regards,
Rudy Wieser

A heads-up:

I just tried to use "type com1" on a machine running w98 DOS, and it works
as expected.

I have no clue if its just an XP, or more globally a Windows problem though.

Regards,
Rudy Wieser

R.Wieser wrote:
A heads-up:

I just tried to use "type com1" on a machine running w98 DOS, and it works
as expected.

I have no clue if its just an XP, or more globally a Windows problem though.

Regards,
Rudy Wieser

After doing an additional number of test cases,
my conclusion is, someone has gone to a great deal
of trouble to break it. Everything I tried had
a bad outcome.

At the receiver, this works better:

copy COM3: output.txt

but even so, I can't get copy.exe to exit,
and get to keep a proper output.txt file.

I tried sending

single character 0x03 hex
single character 0x04 hex
ctrl-Z (which gets remapped by the OS)

Paul

Paul,

At the receiver, this works better:

copy COM3: output.txt

I've tried "type com1" as well as "copy com1 con". Neither works, but
depending on what program I ran before it it fails differently (instantly
returning, or not returning at all) - even though "mode com1 /status" shows
no difference between.

The only thing I can still try is to, instead of a z-modem cable, use one
with the signalling lines connected too. That will have to wait until I can
find the cable for it though.

Regards,
Rudy Wieser

Paul,

The only thing I can still try is to, instead of a z-modem cable, use one
with the signalling lines connected too. That will have to wait until I
can find the cable for it though.

I realized I had still had my crossover dongle, and even could find it back
(Jay!). Alas, no change.

I can't get copy.exe to exit,

Same here, regardless of the used cable (z-modem or full-wired). Only
"type com1 datafile" works /somewhat/ on the DOS 'puter - I still have to
press Ctrl-C, which "^C" output than (ofcourse) also gets stored in the
file. Not that that is the only thing, as the output file also starts with
a slew of NUL (0x00) chars.

It looks like that copying a textfile over COM1 is a bitof a tricky
business...

Regards,
Rudy Wieser

On 21.05.2021 11:10, R.Wieser wrote:

It looks like that copying a textfile over COM1 is a bitof a tricky
business...

Why not use a communication program? I don't know
if HyperTerm from Windows XP still works in Win10,
but there are many free replacements.

Or try PowerShell instead of CMD (type and copy
are build-in commands and so part of the shell program).

Herbert,

Why not use a communication program?

:-) The idea is that I would be able to transfer a program to a 'puter
running a basic OS (DOS - old or new) that does not yet have such a
communications program available.

The reason why I started with trying it between two XP machines is because
those two where readily available and I thought it would not make a
difference - boy, was I wrong :-)

Regards,
Rudy Wieser

On 21.05.2021 12:14, R.Wieser wrote:
Herbert,

Why not use a communication program?

:-) The idea is that I would be able to transfer a program to a 'puter
running a basic OS (DOS - old or new) that does not yet have such a
communications program available.

But in real DOS, the "copy com1 file" should work.
Also INTERLINK.EXE/INTERSVR.EXE was part of DOS.

Herbert,

But in real DOS, the "copy com1 file" should work.

You got me there I'm afraid, I used the DOS w98 ran on. And although "copy
com1 file" /looks/ to be working there, it , just as "type com1", does not
know when to stop. Ctrl-C-ing outof it causes the file to be empty. :-\

Also INTERLINK.EXE/INTERSVR.EXE was part of DOS.

Afaik only part of DOS 6.x (thanks for reminding me though, had forgotten
all about it). And ofcourse only if everything was/is installed (all
floppies).

Regards,
Rudy Wieser

On 21.05.2021 13:56, R.Wieser wrote:
Herbert,

But in real DOS, the "copy com1 file" should work.

You got me there I'm afraid, I used the DOS w98 ran on. And although "copy
com1 file" /looks/ to be working there, it , just as "type com1", does not
know when to stop. Ctrl-C-ing outof it causes the file to be empty. :-\

How many characters did you send? Maybe it is written to the file only if
an internal buffer is full. But in DOS you can use .com programs. Just a
few bytes of code is necessary to copy bytes from com1 to stdout (terminate
if a special character is received or after maybe 1k byte is received).
Use debug or directly enter an ascii binary using the keyboard.

Herbert Kleebauer wrote:
On 21.05.2021 13:56, R.Wieser wrote:
Herbert,

But in real DOS, the "copy com1 file" should work.

You got me there I'm afraid, I used the DOS w98 ran on. And although
"copy
com1 file" /looks/ to be working there, it , just as "type com1", does
not
know when to stop. Ctrl-C-ing outof it causes the file to be empty.
:-\

How many characters did you send? Maybe it is written to the file only if
an internal buffer is full. But in DOS you can use .com programs. Just a
few bytes of code is necessary to copy bytes from com1 to stdout (terminate
if a special character is received or after maybe 1k byte is received).
Use debug or directly enter an ascii binary using the keyboard.

I did this at work, between an Apple computer and a PC
that had no NIC card in it. My boss got a PC from the
"warehouse", and I gather this is like "picking plums
from a plum tree", you don't get to specify anything
about the machine. They just take the one on the front
of the pile and ship it. The PC arrived, with no NIC card,
and I couldn't afford to wait for that to be corrected.

And at the time, I had both directions working. I was sending
files Apple to PC and PC to Apple. Complete with the little
ceremony to send some character like ETX, to close the file
on the receiving end. I may have brought in an adapter cable
from home (because Apple to PC wouldn't have been a cable
sitting in the lab at work).

While many would consider what Rudy is doing, to be some
kind of joke, this is a survival skill. If you're in the
jungle and two PCs won't talk to one another, this is
what you do. I saw it on McGyver.

It's possible my config here, would work better if
using COM1 or COM2 (SuperIO), than one of the many USB
serial ports I've got. One machine has a COM1, but the
other one only has COM3, and it's remotely possible
the USB driver for the COM3 is screwing this up.

Paul

Herbert,

How many characters did you send? Maybe it is written to the file only if
an internal buffer is full.

I've send "hello world!" and upto a few hundred bytes. But if what you say
is true than the only way to get around it is to append a tail of chars
thats larger than that buffer. Which would make the whole thing even more
iffy. :-\

Luckily "type com1 file" works, showing all of the text but for the last
char - probably due to the ctrl-C I have to terminate it with.

But in DOS you can use .com programs. Just a few bytes of code is
necessary to copy bytes from com1 to stdout (terminate
if a special character is received or after maybe 1k byte is received).

:-) The whole idea is that I would be able to transfer such an initial
program to the target 'puter - by way of an executable textfile (nice trick
those executable textfiles), not even needing DEBUG.

Use debug or directly enter an ascii binary using the keyboard.

But yes, when push comes to shove entering two, maybe three rows of data
into DEBUG would work - if DEBUG is already available on the target
ofcourse. I would not want to directly enter ALT codes using the keyboard
though. Just one little mistake and its un-editable junk ...

Regards,
Rudy Wieser

Paul,

While many would consider what Rudy is doing, to be some kind of joke,
this is a survival skill. If you're in the
jungle and two PCs won't talk to one another, this is
what you do.

To be honest, it /is/ a bit of a joke - to anyone who uses recent hardware.
Just grab an USB stick, boot from it and copy anything you want from it to
the DOS 16-bit FAT drive.

The thing is that I got some old/odd hardware here (some won't even
recognise an USB stick), and I'm trying to create a bit of a toolbox to work
with them.

You can look at it it as me putting a jigsaw puzzle together. The endproduct
might be considered absolutily worthless to most, but I've spend a number of
enjoyable hours on it (and picking some knowledge up along the way too
:-) ).

Regards,
Rudy Wieser