CreateNamedPipe on Windows 95

Please refer to the following instruction and sample codes:
http://devcentral.iftech.com/learning/tutorials/nt/nt3.asp

Thanks for your attempt, trestan, but this does not answer my question.  Please allow me to clarify my question:

The functions CreateNamedPipe and ConnectNamedPipe are *not* supported by Windows 95.  These functions are necessary to create and connect to a named pipe in a server under Windows NT.   My question is how to simulate the behavior of these functions in Windows 95 only.  CreateFile will open an _existing_ pipe created by NT, but appearantly cannot create a new named pipe.

Kirby, as you indicate you are on a hiding to nothing with named pipes and '95.  Instead, one way through the mess which works on DOS, 95, 98, and NT, is mailslots.  There is a CreateMailslot API a la CreateNamedPipe.  There are various gotchas and caveats when using them, including multiple datagram delivery if there is more than one protocol connecting the nodes, and a hard limit on datagram length.  But the thing works: I have apps here using the technique.  Go to the following (huge) URL for more details:

http://search.microsoft.com/searchbin/mssearch.idq?MSCOM_SRV=http%3A%2F%2Fwww.microsoft.com&SearchKB=none&CiMaxRecordsPerPage=10&CiSort=rank%5Bd%5D&HTMLQueryForm=http%3A%2F%2Fwww.microsoft.com%2Fsearch%2Fdefault.asp%3FSPath%3D%5Cpremium%5Cmsdn%5Clibrary%26SName%3DMSDN%2BOnline%26CiTemplate%3D&IDQFile=%2Fsearchbin%2Fmssearch.idq&CiTemplate=&SearchCountry=@Locale+en-us&DisplayString=mailslot&SearchType=microsoft&SearchString=mailslot+AND+%28+%23PATH+*%5Cpremium%5Cmsdn%5Clibrary*%29&SName=MSDN+Online&SearchArea=%5Cpremium%5Cmsdn%5Clibrary&Finish=Search+Now%21&x=41&y=8

First, what does "on a hiding to nothing" mean?

Did I mention that I also need near-real-time speed?  Mailslots are too slow.

Creating a named pipe should be a matter of creating the pipe object and filling it with the "right stuff".  

Actually, the real answer to your original question is to use TCP/IP sockets. (Mailslots might work too, I have never used them, but you already rejected that answer). Named pipe servers are simply not supported on 95. You have to create the named pipe on an NT machine.

TCP/IP sockets are a mechanism close to named pipes in terms of being able to set up a server which can accept multiple connections from clients over the network.

If you only need fast interprocess communication on a single machine, WM_COPYDATA is your best bet, but you imply you need intermachine communication.

Why don't you create a simple file with shared access on a server which can be accessed by
both machines? It will be held in cache if it is accessed often, so it should not be too slow.

I am using mapped file i/o now, as a sort of temporary solution.  I works okay, and the speed is acceptable, but other application constraints would seem to make the pipe solution look better.  At least, I'd like to try it.  Besides, I don't want to do this the same way our competition does it.  :-0

Windows 95 apps can read named pipes they justs can't make them. so why don't you make your porgram use named pipes if it's running on nt and files if 95?

Sorry,  you didn't answer my question.  You just said that as far as you know, it cannot be done.  That does not mean it's impossible.

You could replace the functionality of the named pipe just by writing to a file.

For each itteration of your process write the values to the file. Overwrite for each itteration.
Seperate the values if you wish with a delimitor like a comma. Flag the end of the written data with some unique char string so to acknowledge that the record has been written.

Ex.
Data is a string. Wrote to file pipe.txt
"Processing byte 32,Stereo,56,325 remaining bytes,abcd"

The abcd is a flag that signifies that the record has been completed.

Now in your visual side, use a timer or thread to poll the file pipe.txt Seperate the values and then display them in your controls. (Probably just a Static). If you use a timer to pump the values to the visual part to screen you will need a flag to signify when the process starts and ends.


Pseudo:

Call function to produce something.

In function set flag to indicate process has started.

In function process where output is expected to be shown visually, write visual element to file. (pipe.txt) If repeated itteration, over-write file.

In display portion of code. Use timer to poll for completed file, (read and search for "abcd")
if "abcd" found then update visual components, else do nothing.

When function process ends turn off timer flag.

If this functionality is to be between two different machines then pipe.txt will need to be a shared access file.

RJ







If you use a timer