strings including nulls

[Fred Buffington]

I posted this on the Windows BBS but no answer has been posted. Maybe someone here has an idea.

I support (in addition to PB programs, and some QB programs) a few clients running another OS. In appearance it is like PBcc or DOS but is probably closer to unix that DOS in running.

Anyway, I can call in with a modem and connect to the remote OS with my windows XP using AMEcomm
terminal emulation software. I attach a remote printer to the remote OS which is my local printer defined
as DJ6540 and winprint>text. I send pcl to the printer here over the modem and it works fine.

This includes PCL raster graphics wherein lies the problem.

One of the users at the client's office is also using AMEcomm with the same settings, and although using an HP Laserjet 5L everything else seems to be the same other than it's a direct connection through a serial port rather than a modem.

The PCL works fine except for raster graphics.

What happens is that the raster graphic strings sent to the client's printer have the null characters taken out or trimmed. I verified this by sending the data to a file.

She is also running Windows XP to run the terminal emulation software.

The chr$(0) are not trimmed when it comes to my printer (and this is critical because the strings have to be a fixed length for the raster graphics to work properly).

I am frustrated as to why, with the same settings, it it trimming on one computer and not the other.
I have tried sending directly to the printer, bypassing the device driver and everything else i can think of to make it work.

I finally made it so that on her computer, chr$(0) is replace with chr$(1). This made it work (after a fashion). It does result in some 'shading' that i wish was not there but if it must be, it will be acceptable.

Any ideas ?

[Charles Pegge]

This is not my area of expertise, Fred but I would hazard a guess that your client's computer is using a different transfer protocol to yours. If FTP is involved then files of data cand be downloaded either in text format or binary format. The client determines which format is to be used. Only the binary format will deliver an exact copy of the file on the server without shedding or inserting bytes.  Does that give you a clue?

[Fred Buffington]

I do have clients using this remote OS and ftp or DHP (or whatever it's called -- as a client on the network), but this isn't one of them. The OS (THEOS), in this case, is a multiuser OS that does have
that capability but this is not enabled (and will not be enabled) on this particular system. It's just like having dumb terminals connected.

[Fred Buffington]

I figured out the problem, I think.

When I call in on the modem, the handshake is CTS/RTS

The user at the office is having to use xon/xoff handshake because we only have Send, Receive, and ground hooked up. The help (for windows_ says that xon/xoff cannot handle binary data since a control code may have to  be sent. (or something to that effect). So, I will either have to hook up the CTS or DTR line or just do it the way i am doing it unless i can figure out a way around it.

[Fred Buffington]

I figured out a way around it. I attached the com port with no handshake. The windows computer is fast enough to handle 38400 baud rate so I havent had any problems with displays so far and the raster graphics are now printing ok.

[Donald Darden]

It used to be recommended that for binary data, you select odd parity.  The reason was that a zero byte (null character) had no 1's bits, and setting for odd parity would cause the parity bit to be forced to 1.  For some reason (and this has never been explained to my satisfaction), the default mode for PC communications was to use even parity, which brings the problem back of having no bits to sync on in asyncronous communications when sending a null byte.  With a modem involved, you have added start and stop bits as defined for the modem interface.  So the problem is pretty much confined to the serial interface.

If using your approach seems to work, then it isn't necessary to change anything.  On the other hand. if the PC and the printer can be configured for odd parity, then you could try and deal with it that way. 

[Fred Buffington]

Thanks Donald, I'll keep that in mind. I do have the ability to use parity on the remote OS so i may try it
if I have a problem.