RE: LabVIEW SSH Tools

[Rolf K. <rol...@ci...>]

RE: LabVIEW SSH ToolsDees, Ian  wrote:=20
  Well, the main issues would be ease of calling from LabVIEW, or=20
  ease of wrapping in a DLL.  There are several gotchas with=20
  unnamed pipes on Windows; it's at least possible that the POSIX=20
  layer, while not a perfect emulator, uses more sensible blocking=20
  semantics.=20

Mmm, this were also my concerns at first. But I thought I would =
investigate into it as the work would proceed. I have to admit that I =
was wondering about the blocking semantics of the Unix read() function =
in general and on pipes in special. Seeing the example Jim had created I =
had to assume that read() definitely would not block on unsuccesful =
reads at all but just return with whatever data was present. Windows =
ReadFile will indeed not work the same as in non overlapped mode it will =
just block until the data it wants arrives or the pipe gets an error =
such as being closed on the other side. Using overlapped mode should be =
able to avoid that but is not very simple. I would however like =
confirmation that read() indeed does not block on pipe reads.=20

  I like your approach with named pipes.  This may indeed work better;=20
  one thing to watch out for, though, is that IIRC named pipes are=20
  only available for NT/2000/XP and not for 95/98/Me (don't know=20
  about CE/PocketPC). =20

Well there is little to do about that. The msvcrt functions won't =
implement named pipes on non NT systems if the underlaying system does =
not support them.  Also the problem remains that named pipes under =
Windows have a different name syntax than on Unix, as they are =
implemented as special NT sub-namespace unlike unix which maps them into =
the normal file system name space.

But any help and suggestion on this is very much appreciated.

Rolf Kalbermatter