[Interest] QProcess unbuffered

[Scott Bloom]

Yeah, Im being dense.. its from the existing startupinfo.. I read that paragraph a dozen times and missed it each time

-----Original Message-----
From: Interest <interest-bounces at qt-project.org> On Behalf Of Scott Bloom
Sent: Tuesday, March 7, 2023 5:28 PM
To: Björn Schäpers <qt-maillist at hazardy.de>; interest at qt-project.org
Subject: Re: [Interest] QProcess unbuffered

Maybe Im being dense (its been a long day)

But where is pipe defined ?

       std::memcpy(&handles.Handles[1], &pipe.Write, 4);
       std::memcpy(&handles.Handles[2], &pipe.Write, 4);

-- Scott
-----Original Message-----
From: Björn Schäpers <qt-maillist at hazardy.de> 
Sent: Tuesday, March 7, 2023 12:58 PM
To: Scott Bloom <scott at towel42.com>; interest at qt-project.org
Subject: Re: [Interest] QProcess unbuffered

So here is what I have:

struct __attribute__((packed)) HackedHandlePasser {
          using HANDLE32 = std::int32_t;

          DWORD    NumberOfHandles = 3; // 4 Byte
          BYTE     FlagsPerHandle[3];   // 3 * 1 Byte
          HANDLE32 Handles[3];          // 3 * 4 Byte
       };

       static_assert(sizeof(HackedHandlePasser) == 19);
       HackedHandlePasser handles;

       #ifndef FOPEN
#define FOPEN 0x01
       #endif
       #ifndef FDEV
#define FDEV 0x40
       #endif

       handles.FlagsPerHandle[0] = 0;
       std::memset(&handles.FlagsPerHandle[1], FOPEN | FDEV, 2);

       const HANDLE invalid = INVALID_HANDLE_VALUE;
       std::memcpy(&handles.Handles[0], &invalid, 4);
       std::memcpy(&handles.Handles[1], &pipe.Write, 4);
       std::memcpy(&handles.Handles[2], &pipe.Write, 4);

       startInf.cbReserved2 = sizeof(HackedHandlePasser);
       startInf.lpReserved2 = reinterpret_cast<LPBYTE>(&handles);

Some explanations:
* I have the HANDLE32 because I start a 32 bit application from within a 64 bit, as far as I understood the structure needs the right HANDLE size, thus for a 64 bit application it should be std:int64_t, but since I don't need that I never tested it.
* In cbReserved2 there is the size of the data in lpReserved2.
* The data in lpReserved2 starts with 2 bytes which indicate how many handles are passed to the spawned process (they may be INVALID_HANDLE_VALUE). Followed by one byte per handle with the opened flags - and here comes the trick: If it has the flag FDEV the ms runtime printf assumes it writes to a console and thus flushes. And then followed by the handles.
* My use case needs only stdout (and I also open stderr, in my case to the same handle), these are the handles number 1 and 2. Number 0 would be stdin.

So when using it with QProcess I think one should copy the handles from the STARTUPINFOW structure into this struct, then I think the normal QIODevice interface should keep working. If one should clear the STARTF_USESTDHANDLES flag I also don't know. I stopped my experiments when I achieved success for my "simple" use case.

Let me know what works for you.

And last but not least some sources:
https://stackoverflow.com/questions/40965496/windows-how-to-stop-buffering-of-redirected-stdout-using-createprocess
which apparently now also has a C/C++ answer, when I needed it there was only the python code.
http://www.catch22.net/tuts/undocumented-createprocess does use the fields for some other stuff, but explains a bit of background.
https://github.com/cansou/msvcrt/blob/master/src/isatty.c One if the involved files to handle the input.

Kind Regards,
Björn.
_______________________________________________
Interest mailing list
Interest at qt-project.org
https://lists.qt-project.org/listinfo/interest