Re: In memory Stream

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2024-02-18 21:56, Lawrence D'Oliveiro wrote:
> On Sun, 18 Feb 2024 11:06:16 +0100, Dmitry A. Kazakov wrote:
> 
>> On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:
>>> On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:
>>>
>>>> My usage is a bit special. The writing process writes a bunch of data in
>>>> a memory buffer then requests this buffer to be transferred to another
>>>> process by way of WM_COPYDATA.
>>>
>>> I thought Windows had pipes.
>>
>> Yes it has, but very rarely used though much better designed than UNIX
>> pipes.
> 
> So why don’t programmers use it?

There is no need in that. At least initially UNIX had a distinct 
philosophy. Its essence was that if a mouse had three buttons, there 
must have been three processes, one for each button. Any so minuscule 
task was split into even lesser subtasks connected through pipes. I 
remember a C compiler that had 5 passes and took forever to compile 
hello-world. I wonder if anybody still actively uses that messy style of 
piping awk, grep, sed so typical for early UNIX users.

>> In general Windows has much richer and better API regarding interprocess
>> communication than Linux.
> 
> So why is it that Windows programs tend to avoid running multiple processes?

Because there is no need in multiple processes most of the time. Windows 
has a different philosophy and services which preclude the process orgy 
so characteristic to UNIX. For example, Windows has and collects many 
resources when a process dies. So you do not need a process monitoring 
file locks, because there is no any. Instead you would deploy a global 
mutex collected automatically. I do not say that Windows has few 
processes. It is bloated beyond any reason.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de