Thank you very much for the update. I have already changed my code to use a shared file(s). Neverthless, after reading your comments - I can see exactly where my original design was wrong. I get it now. Thank you very much - this will be invaluable in other areas where I need to alter pipe processing connections.

After some deliberation - I have decided to replace the whole mechanism with a shared file instead. It is a little ironic to say the least that I cannot get the pipe method to work for me - when my own application is called 'Pipelines'. Thank you for your help. Regards. James

I wish I could get big bucks! I cannot get an IT job for love nor money!

Thank you for looking into this for me. I am still at a loss as to why the process is not working. All the process' are synchronous - the mechanism I posted is one small part of a very big set of multi-threaded interlocked processes - however it is pretty much stand-alone - all it does is simulate the re-directed std handles of another process. For the first time in years - I am stuck! James.

As far as I understand - this is the server-side of the code - I cannot believe that it is so complicated to connect two process together .. with my application ..

Yes

Hiya. The following code is bit of a mess - cos - I dont know how to submit stuff in a web friendly way - sorry about that - but if you can spot where I am going wrong in-terms of process control - especially in this server stuff - great - below - note - the peek before the read is for good reson! UINT ReadWorker( LPVOID a_pParam ) { // Get the pipeline and stage number for this worker. CCallpipe *p = ( CCallpipe * )a_pParam; #ifdef _PIPE_DIAG_MESSAGE_ CString szPrefix; szPrefix.Format( "CCallpipe::ReadWorker(%d,%d)", p->Pipeline(), p->Stage() ); CApplMessage cons( true, true, ( LPCTSTR )szPrefix ); cons.Write( "Starting ReadWorker" ); #endif // _PIPE_DIAG_MESSAGE_ CHAR szReadBuffer[ _IO_BUFFSIZE_ ]; DWORD dwBytesWritten = 0; DWORD dwRecCount = 0; // Create the lock name. p->m_szLock.Format( "CALLPIPE-%.5d", p->m_dwProcId ); // Connect to the IN stage input stream pipeline. ConnectNamedPipe( p->m_hInputWrite, NULL ); // Ok, now lets read and process our input stream. for( ;; ) { // Read a record from the primary input stream. if( !p->m_pManager->PeekRecord( *p->m_pProcess, 0, &p->m_szInRecord ) ) { #ifdef _PIPE_DIAG_MESSAGE_ cons.Write( "Read of stream: %d, failed", 0 ); #endif // _PIPE_DIAG_MESSAGE_ break; } #ifdef _PIPE_DIAG_MESSAGE_ cons.Write( "I have read the following: >%s<", ( LPCTSTR )p->m_szInRecord ); #endif // _PIPE_DIAG_MESSAGE_ const char *pszRecord = ( LPCTSTR )p->m_szInRecord; do { // Copy the input record to the buffer we will pass the WriteFile(). int nIndex; for( nIndex = 0; nIndex < ( _IO_BUFFSIZE_ - 2 ) && *pszRecord; ++nIndex ) { szReadBuffer[ nIndex ] = *pszRecord; ++pszRecord; } szReadBuffer[ nIndex ] = 0; // If its the end of the record, tag on the newline character. if( !*pszRecord ) { szReadBuffer[ nIndex ] = _NEWLINE_; ++nIndex; szReadBuffer[ nIndex ] = 0; } #ifdef _PIPE_DIAG_MESSAGE_ cons.Write( "Writing: %s", szReadBuffer ); #endif // _PIPE_DIAG_MESSAGE_ if( !WriteFile( p->m_hInputWrite, szReadBuffer, ( DWORD )nIndex, &dwBytesWritten, NULL ) ) { if( GetLastError() == ERROR_NO_DATA ) { #ifdef _PIPE_DIAG_MESSAGE_ cons.Write( "The pipe is now closed!" ); #endif // _PIPE_DIAG_MESSAGE_ break; } else { DWORD dwRetCode = GetLastError(); CString szMessage;

There is never more than one client connected at any one time .. they serviced one at a time.

OK that sounds interesting - can you spell it out for me! Sorry to come across a bit thick

Re-design of a process launched with re-directed STD streams. Process A creates two named pipes. One to write to the input of launched process B and one to read from process B. Standard stuff. Process B launches process C and D and E etc.. In that order and each one runs synchronously. So, only one sub-process is active at any one time. Process' C,D,E in turn connect to process A through the CreateFile() function - again standard stuff. Now, the first pass runs just fine - process C reads and writes records from/to A and then ends. Then process D starts - but there is nothing in the pipe. Process A puts stuff in the pipe - it is active all the time - (until process B terminates), then it deals with process E and so on .. I know that this a bit vague interms of detial - but I have tried every combination of CreateNamedPipe/ConnectNamedPipe/DisconnectNamedPipe on the server side and PeekNamePipe/ReadFile etc on the server side - with pipe busy and pipe closed returncodes. If anyone has an example or knows of where I can get some idea of how to design a server side mechanism that lets multiple synchronous clients connect in-turn then you would be my friend. I guess that I am missing something very simple - I hope.

Hi Hans. I have been writing an application for a few years now .. www.tenfiftytwo.co.uk/pipelines It's basically a multi-stream pipelines (textual manipulation) app that will allow you to chain together pipelines to transform text/data. I am developing a TRACE option that allows interactive user input to inspect i/o records and in order to do this each called process must share the same console. So, console prompts must be just that - no redirection back to the calling process. They need to be console only. Only the called process output should be captured by re-directed streams. Best regards. James. PS. Cannot believe that I did not think of CreateFile() .. thanks again.

Hans. Thanks a lot for the CreateFile() suggestion. It works perfectly .. I am delighted. You should create a short post about CONS only output. There is lots out there about re-direction etc .. but nothing that I could find about faithful rendering of console only output. Again .. cheers. Best regards. James.

Thanks Hans .. I am going to try that! Cheers.

Hi Hans. Thank you for the suggestion but all of the variations of printf, cout etc .. all write to an (re-directable) output stream. I need to write the console only.

Process A launches process B with re-directed out, and err. Process B must write to the console only - no re-direction (as the output will obviously be routed back to Process A). I have tried a number of ways; including _cputs() etc. But I need a method where the output is rendered faithfully - where extended ASCII chars are written correctly. None of the 'console only' output functions seem to support this. Any suggestions? Third party libraries I might look at? Thanks in advance.

A job would be nice!

I am from the old school - so I am quite happy with pointers. If you ever had to work with any kind of assembly language where you regularly used instructions like (390 assembler - LA) then using pointers; especially in a language like C/C++ seems very natural. After all most computing really just involves loading/accessing stuff/data in one location - doing something to it and then putting it in another location. Pointers rock. Additionally - once you understand the concept and are comfortable using them - you can develop programs/applications on a platform where you might not have the sophisticated library support you might otherwise currently rely on. Know the basics!

Hi. I have an MSI package which works with 2000, XP and Vista Home Premium; after installation, in each case the ShellNew process works perfectly (a right click on the desktop and explorer offers the creation of a new file based on a template which is fully qualified; and life is good). However, under Ultimate the popup menu does not contain the option. I have tried adding the template (removing the qualified path from the Reg ShellNew entry) to the system ShellNew directory, but whatever I do; it simply will not work. Has something changed under Ultimate or is there an additional setting that I need to consider. Any help or comment would be much appreciated. My best regards, in hopeful and optimistic anticipation. James.

modified on Wednesday, February 4, 2009 5:10 PM

This is re-post, as I really could do with some help.. Hi. I have a simple console app which I use to CreateProcess() other console apps with re-directed output streams so that I can get hold of their output with PeekNamedPipe(). I have just noticed, by accident (which does not say much for my intensive testing) that in the output from the DOS tree command, the nice ASCII angle and bar characters are encoded incorrectly (I think with the default windows encoding). My App is built using MBCS which I understand is OK for ASCII, what do I need to do to get an output identical to the command-line invocation of TREE. Any thoughts are much appreciated. James.