From ntifs.h:
NTSYSCALLAPI
NTSTATUS
NTAPI
NtOpenProcess (
__out PHANDLE ProcessHandle,
__in ACCESS_MASK DesiredAccess,
__in POBJECT_ATTRIBUTES ObjectAttributes,
__in_opt PCLIENT_ID ClientId
);
My point: this is the OS function to open a process; Win32 is NOT the
OS, and if the Win32 developers decided to hard code their handle sizes
to 32 bits, that’s their issue. Then again, I’d have to check the
Platform SDK to see if this is different for 64 bit clients.
My point: don’t assume that just because something is done in a
particular way in Win32 that it bears any resemblance to what is going
on in Windows. Or perhaps it would be better to say “any similarity
between Win32 and Windows is purely coincidental…”
The bit-borrowing technique is one that was once (NT 3.1) very common -
it was used in the file system code for example. They would exploit the
knowledge that pool memory is allocated on 8-byte boundaries. It sounds
like they used a comparable trick in Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey Lane
Sent: Tuesday, July 19, 2005 2:27 PM
To: ntfsd redirect
Subject: RE: [ntfsd] 64-bit issues/handles
Well…
The WIN32 function OpenProcess() takes a process ID as it’s 3rd
argument.
It’s specified as a DWORD or ‘unsigned long’.
The kernel callback routine provides two 32/64 PVOID handles as process
ids.
Up until today, my filter code would send the two process ids up to user
space as ULONGs where they would eventually be passed into
OpenProcess().
This gives us 32/64 bits on the kernel end and 32 bits on the use end…
I understand opaque. I don’t really care what the value means. I just
want
to know what the rules are so I can deal with stuffing 32/64 bits into a
32-bit only hole.
Mickey.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Tuesday, July 19, 2005 2:11 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] 64-bit issues/handles
It’s a HANDLE. It’s opaque for a reason. The only use other than
passing
it into the OS is testing for equality to see if two instances match.
Any
other use is asking for trouble.
Why do you think you need to cast it to any other type?
If you insist on doing something this bug-inviting, at least cast it to
a
ULONG_PTR, which is *supposed* to be the size of a pointer on all
platforms.
Again, why do you think you need to do this?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Mickey Lane”
net>
To
Sent by: “Windows File Systems Devs
Interest
bounce-214402-739 List”
xxxxx@lists.osr.com
cc
No Phone Info
Available
Subject
[ntfsd] 64-bit issues/handles
07/19/2005 11:49
AM
Please respond to
“Windows File
Systems Devs
Interest List”
com>
I’ve got a mini-filter which calls PsSetCreateProcessNotifyRoutine() to
set
up a callback to monitor process start/stop.
The callback header is:
VOID
(*PCREATE_PROCESS_NOTIFY_ROUTINE) (
IN HANDLE ParentId,
IN HANDLE ProcessId,
IN BOOLEAN Create
);
Key issue here is the ‘handle’ to specify process id values. Handles are
pointers. Process ids are, as far as I know, integers in the range 0
(idle),
4, 8, A, etc. to ???. (Perhaps they’re added to the base address of a
table
to generate real pointers…)
When porting the mini-filter to AMD64, the handle variable changes size.
My
interface code casts this information to a ULONG which doesn’t change.
The
compiler gripes about this.
I’m not at all sure I want to use a 64-bit interface for something that
as
far as I know never gets much bigger than 4,000 or so.
Question: Is there a paper somewhere that will tell me more than I ever
wanted to know about process ids? What’s the largest process id that
will
ever exist? Will it fit in 32 bits? Will there be 32-bit plus ids on
64-bit
systems?
Regards,
Mickey.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@earthlink.net To
unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com