From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cygwin-talk-return-3747-listarch-cygwin-talk=sources.redhat.com@cygwin.com>
Received: (qmail 10722 invoked by alias); 7 Jun 2007 17:39:17 -0000
Received: (qmail 10632 invoked by uid 22791); 7 Jun 2007 17:39:16 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.artimi.com (HELO mail.artimi.com) (194.72.81.2)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Jun 2007 17:39:14 +0000
Received: from rainbow ([192.168.8.46]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); 	 Thu, 7 Jun 2007 18:37:49 +0100
From: "Dave Korn" <dave.korn@artimi.com>
To: "'n2794'" <cygwin-talk@cygwin.com>
References:  <000c01c7a927$b7256b50$2e08a8c0@CAM.ARTIMI.COM> <f49f3n$rmd$2@sea.gmane.org>
Subject: RE: FW: Certain files in the system32 directory are not listed
Date: Thu, 07 Jun 2007 17:39:00 -0000
Message-ID: <000e01c7a92a$91a18230$2e08a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <f49f3n$rmd$2@sea.gmane.org>
Mailing-List: contact cygwin-talk-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin-talk.cygwin.com>
List-Subscribe: <mailto:cygwin-talk-subscribe@cygwin.com>
List-Post: <mailto:cygwin-talk@cygwin.com>
List-Help: <mailto:cygwin-talk-help@cygwin.com>, <http://cygwin.com/lists.html#faqs>
Sender: cygwin-talk-owner@cygwin.com
Reply-To: The Cygwin-Talk Maiming List <cygwin-talk@cygwin.com>
X-SW-Source: 2007-q2/txt/msg00170.txt.bz2

On 07 June 2007 18:26, Matthew Woehlke wrote:

> Dave Korn wrote:
>> "  On 64-bit systems, Windows system files for 64-bit applications are
>> stored in the $WINDIR/System32 directory. To avoid confusion, the system
>> files for 32-bit applications are stored in the $WINDIR/SysWOW64
>> directory.  " 
> 
> ...what did you expect from the platform that brought us the
> ever-so-helpful sizeof(void*) != sizeof(long)?

  Actually there's nothing really wrong with that.  The C language spec makes
no such guarantee.  That's why we have things like [u]intptr_t, intmax_t and
ptrdiff_t.  Any code that assumes a relationship between the size of a pointer
and the size of a long int is just bogus.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....