[Soren Andersen <soren_andersen@sp...>]

I cannot know if anyone is still interested in this topic, but it's
friday and I feel a holiday coming on and feel in the mood to expound
out of compassion for others (nothing to with Easter necessarily, I am
not a Xian but trying to be a Buddhist...). So here goes again...

On Fri, 22 Mar 2002 11:34:50 -0600 (CST), "M Joshua Ryan"
<josh@...> said:
> On Fri, 22 Mar 2002, Soren Andersen wrote:
>
> > On Fri, 22 Mar 2002 09:33:15 -0600 (CST), "M Joshua Ryan"
> > <josh@...> said:
> >
> > > then you probably need to look at CreatePipe, DuplicateHandle,
> > > and CreateProcess in win32. for cygwin, you can stick with
> > > pipe(2).
> >
> > Thanks, Joshua, but there's still some kind of breakdown in
> > comprehension here. I think it might stem from lack of familiarity
> > with UNI*-style tool pipelining, in shell scripts, on your end? In
> > what i am doing here, the *SHELL* is going to be creating a pipe
> > (sometimes, according to user decree, NOT programmer choice!!) and
> > supplying all the context for what's going on here. This is a
> > cross-platform stand-alone console application, not a Win32-only
> > complex something-or-other. The real crux of my initial query lies
> > in that porting applications to Windows from standard UNI* -style
> > code is complexified because you cannot treat stdin and stdout on
> > Win32 like any other filehandle, as in the UNI* credo "everything
> > is a file".

> as i understand it, normal windows batchfiles cannot create pipes.
> it's part of their inheritance from DOS. i don't think there's a
> terrible lack of understanding on my part.

Put none too diplomatically, but honestly (and with kind intention): there actually *is* clearly now a really fundamental misbelief on your part and depending on what (kind of programming) you get involved with it will surely bite you someday in the future, sooner or later.

Put in psuedocode-ish terse style:
-------------------------------------------------------
   DOS  !=  Win32  [ != UNIX-ported-to-Windows]
-------------------------------------------------------
Put at somewhat greater verbosity:

MinGW is really three things from a programming-strategy POV, you could say. First off the run-time basis for the C library calls is MSVCRT.DLL, Microsoft's implementation of a "standard" ANSI C library which is none too standard and conforming, but is what we have to work with.

Secondly as users will note when they download MinGW, a sizeable bundle of files gets installed which consists of what's called "win32api." This is libraries (lib*.a in our case but for users of MSVC they'd be *.lib) and their accompanying header files. Things like "libkernel32.a" and "libgdi.a". This is the Win32 API: what Microsoft gives the world to let programs interact with their many OS's (Let's see, there's 'Win32s' running under 16-bit Win3.x; and "Win9x/Millenium", and "WinNT3.x-WinNT4/Win2K/WinXP. These are all DIFFERENT  and specifically [in specific instances] INCOMPATIBLE operating system platforms). "Win32" attempts -- but none too well or cleanly (read David Korn) -- to implement a "uniform" interface to these several different flavors of 'doze and in typical M$ fashion, 'the devil is in the details.'

Thirdly there is a 'port' of "libiberty.a" which is a Gnu project library that adds many useful functions (implemented in C) considered standard and desirable on a modern feature-rich *NIX-like OS (LINUX, *BSD's) but often missing on many other flavors of OS.

Other people might see things from a different perspective or think of something important to add or subtract, but as a start on clarifying this, this is how it is 'according to Soren'.

These three things are really separate, especially the 2cd item from the first or the third ones. The Win32API is completely separate from and different from a standard or 'extended-standard' C library.

The one thing MinGW is NOT is a _DOS_ development platform. That already exists and has existed for a   *l  o  n  g*   time now, and it's called "DJGPP". It could be said to be ancestrally related to MinGW and everyone using any GNU software ported to Windows today owes a big debt of gratitude to D.J. Delorie for his pioneering work on DJGPP. But it's a completely separate thing, because, (yep, let's repeat it once again people):
---------------------
  DOS  !=  Win32
---------------------

> unix shells create pipes between programs using the pipe(2) system
> call to setup the proper connections between filehandles before
> calling fork(2). since DOS didn't have a fork() (because it didn't
> have multiple processes), the command shell implemented "piping" by
> redirecting the output of the first program to a temporary file,
> running it to completion, and then redirecting the input of the
> second program to the temporary file.

Yes, this is quite true. Also largely only of historical, trivial interest because most people do not run DOS anymore. Win32 != DOS. Unfortunately even the folks at Microsoft have apparently long been in the habit of themselves sometimes referring to a "DOS box" running "under Windows" and therefore have compounded the apparently widespread confusion concerning this. Since I don't work and never have worked for M$ this is in no way my responsibility.

To answer your first statement above specifically: Windows 32-bit uses Real Pipes. Even more specifically WinNT and decendants use Real Pipes and Real 'alot else' -- NT in console mode is *almost* a *NIX OS (and yes there is even a way [expensively] to implement a thing that's almost as good as a true *NIX `fork' on Win32). Even more to the point (increasing verbosity yet more but getting back to the thrust of my original questions about your meaning): when discussing Windows _shell_ scripting one *must* specify *which shell* one is referring to. NT's CMD.exe is a completely different and far more competent creature than Win9x's command.com (which running under Windows9x in a so-called "DOS box" may or may not be subject to all or some of the DOS limitations you've referred to: it's a matter for more research than I am able to do at this time and I am going to limit my statements here to what I can authoritatively speak on).

In ANY event the correct way to refer to the kind of program the o.p. was talking about (that was me) is **Win32 Console Mode**. Any competent book on Windows (esp. on NT or decendants) will refer to this. I'm going to suggest a suitably concise new coinage for the Internet and now nickname "Win32 Console Mode" as "win32c-m". "win32c-m" has its own API and everything (and that API looks really nothing like DOS and nothing like standard *NIX I/O and really nothing like anything else that's ever been).

I heartily recommend to readers of this List that they find a book: _Programming Win32 Under the API_ by Pat Villani [CMP, 2001, ISBN 1-57820-067-9] which among other things will dispel the pervasive badness of the 'little bit of knowledge' that a lot of people seem to display about Windows and Win32. It even includes a version (albeit outdated of course) of MinGW on CD-ROM! Of course this book covers both win3gui and win32c-m. And I don't know the author and have no fiduciary interest in the book.

Finally I'd like to remind readers, especially some of the recent contributors to this thread, that one ought to go back and read a thread from the beginning. Mostly the original context and point of this thread (I was the o.p.) was lost almost immediately after the second generation of reply had been posted. Leading me to suspect that most of those who replied are young and inexperienced at List-mode discussion.

    Thanks for reading,
       Soren Andersen



-- 
The makefiles which eventually result from using 'automake' 1.5x are monstrosities. Sheer hellish madness. Several dozen targets, named obscene things like "am_remake_your_mother"; utterly counter-intuitive, buried in 4 or 5 levels of indirection, swamped in a thousand lines of baffling, migraine-inducing auto-generated superfluity. [These] Makefiles  ought to be taken out and bled to death slowly, shot, burned, staked through the heart, generally Buffy-ated to the maximum possible extent.
    -- Soren Andersen (me) in
<http://groups.google.com/groups?selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226>;