From dev-return-9041-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sat Jan 25 05:09:45 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 37281 invoked by uid 500); 25 Jan 2003 05:09:44 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 37115 invoked from network); 25 Jan 2003 05:09:43 -0000 Reply-To: fitz@red-bean.com From: "B. W. Fitzpatrick" To: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= Cc: dev@apr.apache.org Subject: Re: cvs commit: apr/include apr_file_io.h In-reply-to: Your message of "Sat, 25 Jan 2003 00:25:56 +0100." <3E31CB84.8040302@xbc.nu> Emacs: because extension languages should come with the editor built in. Date: Fri, 24 Jan 2003 23:10:53 -0600 Sender: fitz@red-bean.com Message-Id: <20030125051053.46BEE1083E@pantheon.red-bean.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N brane@xbc.nu writes: > fitz@apache.org wrote: > > > + * @remark The only reason that the apr_file_open_std* functions exist > > + * is that you may not always have a stderr/out/in on Windows. > > > Huh? I thought the reason these functions exist is that otherwise you'd > have no portable way of getting a standard i/o handle that was an > apr_os_file_t. Which is a HANDLE on Windows, not an int, and > stdin/out/err aren't 0, 1 and 2, unlike Unix. I'm just following up with what Ryan wrote to the svn dev list. Feel free to elaborate in the header if you wish. :) > > This > > + * is generally a problem with newer versions of Windows and services. > > + * > > + * The other problem is that the C library functions generally work > > + * differently on Windows and Unix. So, by using apr_file_open_std* > > + * functions, you can get a handle to an APR struct that works with > > + * the APR functions which are supposed to work identically on all > > + * platforms. > > > > > Yes, and the third "problem" is that APR on Windows doesn't use C file > functions, nor POSIX ones, it uses Win32 functions -- thank the gods -- > and that's why apr_os_file_t exists. Gotcha. -Fitz