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

[R.Wieser]

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

[Paul]

One of the requirements, was to send an EOT character

https://en.wikipedia.org/wiki/End-of-Transmission_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

[R.Wieser]

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

[R.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

[Paul]

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

[R.Wieser]

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

[R.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

[Herbert Kleebauer]

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).

[R.Wieser]

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

[Herbert Kleebauer]

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.

[R.Wieser]

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

[Herbert Kleebauer]

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.

[Paul]

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

[R.Wieser]

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

[R.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

[R.Wieser]

Just an update.

This morning I was doing some more testing, and found out something : when
just using "copy" a files (terminating) ctrl-Z is not send. For that the
"/b" switch needs to be included. ("type" does send it though).

While that works for COMMAND.COM (on DOS and XP) (the "copy com1 file"
command terminates - without including the ctrl-Z in the file) XPs CMD still
does not want to play ball. It stubbornly keeps stuck in both the "copy"
and the "type" commands (and need to be task-managered outof it).

@Herbert

Using, as you suggested, a small DEBUG program on XP echoing received COM
bytes to stdout until a terminating character (ctrl-Z) is received works.

A caveat though: using CMD exiting such a COM style program on XP resets,
for some reason, the datawidth to 5. That ofcourse means that shrinking
the program by excluding the comports initialisation (allowing it to use
whatever speed its currently set to isn't possible - unless the "mode com1"
command is available and used in between.

Talking about (subtile) changes throwing a wrench in something that shoud
have been simple ... :-)

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Fri, 21 May 2021 at 13:56:43, R.Wieser <add...@not.available> wrote
(my responses usually follow points raised):

>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. :-\

[]
You've already mentioned the /b switch. Have you played with /a?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Mike Jackson |\ _,,,---,,_
and Squeak /,`.-'`' -. ;-;;,_ Shame there's no snooze button
[1998] |,4- ) )-,_..;\ ( `'- on a cat who wants breakfast
zzz '---''(_/--' `-'\_)

[R.Wieser]

John

> Have you played with /a?

Nope. To be honest, I was trying to get the whole file to the other side,
and as "/b" did the job ...

But I did just now. Hmm. Under XP it does not seem to make a difference
if I use it on a single file or not. Ether way the ctrl-Z EOF, if there, is
removed.

Regards,
Rudy Wieser

[R.Wieser]

John,

>> Have you played with /a?

...
> But I did just now. Hmm. Under XP it does not seem to make a difference
> if I use it on a single file or not. Ether way the ctrl-Z EOF, if there,
> is removed.

It took me a while to realize that it could maybe be usefull on the
receiving end (if "/a" strips the ctrl-Z on sending it might also detect it
while receiving and end the copy process). Alas, a test just now showed it
made no difference (the copy process still gets stuck).

Regards,
Rudy Wieser