X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4AD7C5E7.7020909@gmail.com>
Date: Fri, 16 Oct 2009 02:01:27 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: fork failure?
References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> <4AD73B83 DOT 9060505 AT gmail DOT com> <4AD74586 DOT 8070803 AT cwilson DOT fastmail DOT fm> <4AD752C8 DOT 2040908 AT gmail DOT com> <4AD7B135 DOT 6020401 AT cwilson DOT fastmail DOT fm> <4AD7C26A DOT 70505 AT gmail DOT com>
In-Reply-To: <4AD7C26A.70505@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Dave Korn wrote:

>   I'd investigate phdl.  

>   Now is it just my imagination, or does Vista really insert an extra ULONG
> bitfield at offset 4 in the struct resulting in all subsequent members being
> offset by 4 relative to other versions of Windows?  This needs verifying
> against the official MS headers.

  Nope, just looks like an artifact of the way that HTML documentation was
generated; the supposed "ULONG :1" bitfields are actually just the bits of the
BitField UCHAR, and not actually ULONG at all:

http://forum.sysinternals.com/forum_posts.asp?TID=14624

> From WinDbg, in Vista SP1:
> 0:000> dt ntdll!_PEB
>    +0x000 InheritedAddressSpace : UChar
>    +0x001 ReadImageFileExecOptions : UChar
>    +0x002 BeingDebugged    : UChar
>    +0x003 BitField         : UChar
>    +0x003 ImageUsesLargePages : Pos 0, 1 Bit
>    +0x003 IsProtectedProcess : Pos 1, 1 Bit
>    +0x003 IsLegacyProcess  : Pos 2, 1 Bit
>    +0x003 IsImageDynamicallyRelocated : Pos 3, 1 Bit
>    +0x003 SkipPatchingUser32Forwarders : Pos 4, 1 Bit
>    +0x003 SpareBits        : Pos 5, 3 Bits
>    +0x004 Mutant           : Ptr32 Void
>    +0x008 ImageBaseAddress : Ptr32 Void
>    +0x00c Ldr              : Ptr32 _PEB_LDR_DATA
>    +0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS

  Ah well, sorry about the red herring.

  (Mind you, it does also say

> // The PEB and TEB structures are subject to changes between Windows
> // releases, thus the fields offsets may change as well as the Reserved
> // fields.  The Reserved fields are reserved for use only by the Windows
> // operating systems.  Do not assume a maximum size for the structures.

but that doesn't seem to be a possibility here in particular right at the
start of the struct.)

    cheers,
      DaveK

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple