Named pipes in LabWindows/CVI

[dean.s]

Although LabWindows/CVI supports the windows SDK, it looks like I can't do what I want due to LabWindows/CVI C run-time limitations. Maybe someone has some suggestions.

I am trying to open a pipe (windows xp) so that I have a FILE* to the write end of the pipe. I don't really care if the pipe is named or anonymous. Creating the pipe is no problem. 

2 appraoches to getting a FILE*:

1) Use fopen(), e.g., fopen("\\\\.\\pipe\\SamplePipe","wb"). This identical call works under MS VC++, but under CV, I get:

NON-FATAL RUN-TIME ERROR:   ...  Library function error (return value == 0 [0x0]). (EIO) General I/O failure

2) Convert a pipe handles toFILE*. Under MS VC++ I can call

  fd = _open_osfhandle (writeHandle, 0);  /* Windows C run-time lib, io.h */
  FILE = _fdopen (fd, "w");               /* Windows C run-time lib, stdio.h */

but don't seem to have access to these functions in the LabWindows/CVI C run-time.

Thanks.

[dummy_decoy]

this has already been discussed on this forum. this is not a limitation of CVI C runtime, but is rather a limitation of the ANSI standard definition of the C runtime (which has never been thought to be extensible...)

this is due to the definition of a stream which is, according to the C language standard, implementation defined. thus a handle which has NOT been opened using the C runtime cannot be easily converted to a FILE *. note that the _fdopen() function you are using in VC++ starts with '_' which means it is not a standard C function: it is rather a microsoft specific function.

also note that, eventhough CVI does "support" the Windows SDK, it does not mean it absolutely has to be compatible with every single type defined in this SDK. also, you may achieve your goal by using Windows SDK calls exclusively: this is not a big deal and would make your code definitely compiler independant, plus Windows SDK file i/o functions are far more powerful than their C counterparts.

but yes, you are right, having a function to perform this job would be really nice...

[dean.s]

OK, fair enough for approach 2.

But what about approach 1? Why does CVI fail opening a named pipe? That seems like a run-time limitation to me.

The reason I was going after a FILE* is to hook into a bunch of existing CVI code that does stdio on a FILE*. I probably wouldn't be trying this if I was starting from scratch.

Thanks.

[menchar]

I agree with _decoy, we've used named pipes extensively in CVI applications, and we use the SDK functions, we don't mix with language functions.  I could see using language functions but if you're doing Win32 pipes you're not portable anyway so why not just use the SDK calls.  There can be a lot of frustrating overhead to learning some of the Win32 SDK calls, but you generally are able to get the nuanced behavior you might need.

Menchar

[dean.s]

So the "why" is that I have a pile of legacy code that uses the C stdio library & requires a FILE* as input.

It seems to me the C run-time should just be a simple a layer on top of the OS & that fopen() should work on any valid OS file name. I can do a

echo test > \\.\pipe\myPipe

from the command line, so why does

fopen("\\\\.\\pipe\\myPipe", "w")

get the (EIO) General I/O failure   ???

So CVI does what it does -- it's not worth agruing over whether or not this is reasonable. If there aren't any other suggestions, I'll probably set the FILE* to stdout & handle the redirection outside of the program.