ctypes-users — Discussion forum for ctypes users

Re: [ctypes-users] Using ctypes inside a C application embedding the CPython runtime

[eryk s. <er...@gm...>]

On Thu, Jun 9, 2016 at 4:35 PM, jef...@gm...
<jef...@gm...> wrote:
>
> On Tue, Jun 7, 2016 at 9:36 PM, eryk sun <er...@gm...> wrote:
>>
>> This should have been documented for POSIX systems, which rely on this
>> feature internally for `pythonapi = PyDLL(None)`.
>
> Great to read that! Is there any way I can help to get this documented?
> Should I submit a PR to the documentation or something like that?

Here's the link to create a new issue:

    http://bugs.python.org/issue?@template=item

It's an enhancement for components "ctypes" and "Documentation" for
2.7, 3.5, and 3.6. See the dev guide for how to get started with
submitting patches and writing docs using reStructuredText.

    https://docs.python.org/devguide

Re: [ctypes-users] Pickling ctypes pointer/array

[eryk s. <er...@gm...>]

On Thu, Jun 9, 2016 at 5:49 PM, Carlos Pita <car...@gm...> wrote:
>
> ptr --string_at --> bytes --dump--> pickle
> pickle --load--> bytes --> create_string_buffer --> ptr
>
> (where I'm taking create_string_buffer as a kind of inverse of string_at).

An alternative is array_type.from_buffer_copy, but it isn't more
efficient. If a memoryview were allowed, you could use from_buffer.

> There are at least two obstacles on the way to pickling without copies:
>
> 1. Pickle is unable to serialize memoryviews.
> ...
> Now, what about bytearrays? If the underlying buffer of ctypes objects were
> get/settable as (views to) bytearrays no immutability constraint would be
> violated and we could move between python and c worlds without copying.

bytearray's __reduce_ex__ creates a bytes copy in the args tuple (see
_common_reduce in Objects/bytearrayobject.c):

    >>> bytearray(3).__reduce_ex__(3)
    (<class 'bytearray'>, (b'\x00\x00\x00',), None)

Supporting memoryview would make pickling bytearray more efficient.

[ctypes-users] Pickling ctypes pointer/array

[Carlos P. <car...@gm...>]

Hi all,

this  question was triggered by the suggestion of Eryk in
http://bugs.python.org/issue27274. Currently my way to go in order to
pickle/unpickle the underlying array of a pointer is:

ptr --cast--> array --copy--> bytes --dump--> pickle
pickle --load--> bytes --(from_buffer_)copy --> array --cast--> ptr

Eryk suggested a more concise way of achieving the same:

ptr --string_at --> bytes --dump--> pickle
pickle --load--> bytes --> create_string_buffer --> ptr

(where I'm taking create_string_buffer as a kind of inverse of string_at).

But this still makes a couple of copies. There are at least two obstacles
on the way to pickling without copies:

1. Pickle is unable to serialize memoryviews.
2. It's not desirable to expose a pointer to the underlying memory of a
bytes object, since bytes are supposed to be immutable.

Now, what about bytearrays? If the underlying buffer of ctypes objects were
get/settable as (views to) bytearrays no immutability constraint would be
violated and we could move between python and c worlds without copying.

Is something like that already possible? If not, is there an essential
limitation preventing its implementation?

Thank you in advance
--
Carlos

Re: [ctypes-users] Using ctypes inside a C application embedding the CPython runtime

[<jef...@gm...>]

Hi Eryk,

On Tue, Jun 7, 2016 at 9:36 PM, eryk sun <er...@gm...> wrote:

> On Tue, Jun 7, 2016 at 10:06 PM, jef...@gm...
> <jef...@gm...> wrote:
> >
> > If filename is NULL, then the returned handle is for the main
> >        program.  When given to dlsym(), this handle causes a search for a
> >        symbol in the main program, followed by all shared objects loaded
> at
> >        program startup, and then all shared objects loaded by dlopen()
> with
> >        the flag RTLD_GLOBAL.
> >
> > As documented on dlopen's manpage[1], and this is working right now. What
> > we're worried about is that passing None to the CDLL constructor is not
> > documented anywhere (at least that I could find), so we're not sure if we
> > can rely on this functionality (if so, the documentation should probably
> be
> > updated and I can help with that if needed) or if there's an alternate
> > recommended and documented way of achieving the same result.
>
> This should have been documented for POSIX systems, which rely on this
> feature internally for `pythonapi = PyDLL(None)`.
>

Great to read that! Is there any way I can help to get this documented?
Should I submit a PR to the documentation or something like that?


> Of course, Windows LoadLibrary doesn't accept NULL, so CDLL(None) is
> an error there. It could be special cased as GetModuleHandle(NULL),
> but that's rarely useful in this context since there's no global
> symbol table.
>

Yes, you're right, I was only thinking about the specific context of my
problem (we're using Linux).


Regards,

-- 
Jeffrey Esquivel S.

Re: [ctypes-users] Using ctypes inside a C application embedding the CPython runtime

[eryk s. <er...@gm...>]

On Tue, Jun 7, 2016 at 10:06 PM, jef...@gm...
<jef...@gm...> wrote:
>
> If filename is NULL, then the returned handle is for the main
>        program.  When given to dlsym(), this handle causes a search for a
>        symbol in the main program, followed by all shared objects loaded at
>        program startup, and then all shared objects loaded by dlopen() with
>        the flag RTLD_GLOBAL.
>
> As documented on dlopen's manpage[1], and this is working right now. What
> we're worried about is that passing None to the CDLL constructor is not
> documented anywhere (at least that I could find), so we're not sure if we
> can rely on this functionality (if so, the documentation should probably be
> updated and I can help with that if needed) or if there's an alternate
> recommended and documented way of achieving the same result.

This should have been documented for POSIX systems, which rely on this
feature internally for `pythonapi = PyDLL(None)`.

Of course, Windows LoadLibrary doesn't accept NULL, so CDLL(None) is
an error there. It could be special cased as GetModuleHandle(NULL),
but that's rarely useful in this context since there's no global
symbol table.

[ctypes-users] Using ctypes inside a C application embedding the CPython runtime

[<jef...@gm...>]

Hi,

We have a python server application that will load a shared library (using
ctypes) and make its functions available to a client application on another
host.

Now we're been asked to embedded that application into a larger C
application that also loads the same library (the goal is to let the C
application turn on and off the server as needed). We used the CPython
runtime to embed the python application inside the C application
successfully, using the documentation available here[0].

The problem is that right now we make sure that our python application is
using the same library (in memory) as the C application by passing None as
the name parameter to the CDLL constructor, which means it ultimately calls
dlopen() with Null as it's filename parameter, having the following effect:

If *filename* is NULL, then the returned handle is for the main
       program.  When given to *dlsym*(), this handle causes a search for a
       symbol in the main program, followed by all shared objects loaded at
       program startup, and then all shared objects loaded by *dlopen*() with
       the flag *RTLD_GLOBAL*.

As documented on dlopen's manpage[1], and this is working right now. What
we're worried about is that passing None to the CDLL constructor is not
documented anywhere (at least that I could find), so we're not sure if we
can rely on this functionality (if so, the documentation should probably be
updated and I can help with that if needed) or if there's an alternate
recommended and documented way of achieving the same result.

Thank you very much for your time.


Regards,

[0] https://docs.python.org/3.5/extending/embedding.html
[1] http://man7.org/linux/man-pages/man3/dlopen.3.html

-- 
Jeffrey Esquivel S.

Re: [ctypes-users] Passing self though to callbacks

[eryk s. <er...@gm...>]

On Thu, Mar 3, 2016 at 4:38 AM, Glenn Pierce <gle...@gm...> wrote:
> I can pass the int now. I was retrieving with.value and not .contents
>
> If anyone has a simpler way though please let me know.

Using id(self) as a void* is wrong in general. It's not incrementing
the reference count. But with ctypes you should almost always ignore
the context parameter of C callbacks. Pass None (i.e. NULL) for the
context. Instead use a bound method as the callable. You'll get the
self reference for free, which gives you all the context that you'll
ever need.

Re: [ctypes-users] Passing self though to callbacks

[Glenn P. <gle...@gm...>]

Update.
I can pass the int now. I was retrieving with.value and not .contents

If anyone has a simpler way though please let me know.

On 3 March 2016 at 08:32, Glenn Pierce <gle...@gm...> wrote:
> Hi I am having trouble getting self passed through to callbacks.
> I know ctypes usually takes care of this but in my case it does not
> because the c API I am wrapping requires the function pointers to be
> placed into a structure
> which then is passed to the function that sets up the connection. I
> believe this stops the ctypes self propagation from working.
> Is there a way to get it working in this case  ?
>
>
> An example is below.
>
> The functions I have wrap except a context which is just callback
> data. So I have tried passing id through this
> like
>
> self.handle = self._Create(C.byref(self.callback_structure),
> C.c_void_p(id(self)))
>
> in the callback I cast back like
>
> self = C.cast(context, C.py_object).value
>
>
> This does not seem to work well though. With one object it is find but
> when adding different callback objects of the same style the cast back
> sometimes returns the wrong object.
> Not sure why though. Neither object gets garbage collected so id
> should be valid unique.
>
> I would try to pass a unique int / dict mapping though context but how
> can I pass an int through a void*   ?
>
> If anyone has any suggestions that would be great. Thanks
>
>
>
> if sys.platform == 'win32':
>     CallbackType = C.WINFUNCTYPE
> else:
>     CallbackType = C.CFUNCTYPE
>
> SessionListenerSessionLostFuncType = CallbackType(None, C.c_void_p,
> C.c_int, C.c_int) # context sessionId reason
>
> class SessionListenerCallBacks(C.Structure):
>     _fields_ = [
>                 ("SessionLost", SessionListenerSessionLostFuncType)
>                ]
>
>
> class SessionListener(object):
>
>
>     def __init__(self, callback_data=None):
>
>         super(SessionListener, self).__init__()
>
>         self.callback_structure = SessionListenerCallBacks()
>         self.callback_data = callback_data
>
>         self.callback_structure.SessionLost =
> SessionListenerSessionLostFuncType(SessionListener._OnSessionLostCallBack)
>         self.callback_structure.SessionMemberAdded =
> SessionListenerSessionMemberAddedFuncType(SessionListener._OnSessionMemberAddedCallback)
>
>         # I have remove the wrapper for this for simplicaity
>         # The prototype is # _create(const sessionlistener_callbacks*
> callbacks, const void* context);
>         self.handle = self._Create(C.byref(self.callback_structure),
> C.c_void_p(id(self)))
>
>
>     def __del__(self):
>         if self.handle:
>             return self._Destroy(self.handle)
>
>     @staticmethod
>     def  _OnSessionLostCallBack(context, sessionId, reason):
>         self = C.cast(context, C.py_object).value
>         self.OnSessionLostCallBack(self.callback_data, sessionId, reason)
>
>     def OnSessionLostCallBack(self, context, sessionId, reason):
>         pass

[ctypes-users] Passing self though to callbacks

[Glenn P. <gle...@gm...>]

Hi I am having trouble getting self passed through to callbacks.
I know ctypes usually takes care of this but in my case it does not
because the c API I am wrapping requires the function pointers to be
placed into a structure
which then is passed to the function that sets up the connection. I
believe this stops the ctypes self propagation from working.
Is there a way to get it working in this case  ?


An example is below.

The functions I have wrap except a context which is just callback
data. So I have tried passing id through this
like

self.handle = self._Create(C.byref(self.callback_structure),
C.c_void_p(id(self)))

in the callback I cast back like

self = C.cast(context, C.py_object).value


This does not seem to work well though. With one object it is find but
when adding different callback objects of the same style the cast back
sometimes returns the wrong object.
Not sure why though. Neither object gets garbage collected so id
should be valid unique.

I would try to pass a unique int / dict mapping though context but how
can I pass an int through a void*   ?

If anyone has any suggestions that would be great. Thanks



if sys.platform == 'win32':
    CallbackType = C.WINFUNCTYPE
else:
    CallbackType = C.CFUNCTYPE

SessionListenerSessionLostFuncType = CallbackType(None, C.c_void_p,
C.c_int, C.c_int) # context sessionId reason

class SessionListenerCallBacks(C.Structure):
    _fields_ = [
                ("SessionLost", SessionListenerSessionLostFuncType)
               ]


class SessionListener(object):


    def __init__(self, callback_data=None):

        super(SessionListener, self).__init__()

        self.callback_structure = SessionListenerCallBacks()
        self.callback_data = callback_data

        self.callback_structure.SessionLost =
SessionListenerSessionLostFuncType(SessionListener._OnSessionLostCallBack)
        self.callback_structure.SessionMemberAdded =
SessionListenerSessionMemberAddedFuncType(SessionListener._OnSessionMemberAddedCallback)

        # I have remove the wrapper for this for simplicaity
        # The prototype is # _create(const sessionlistener_callbacks*
callbacks, const void* context);
        self.handle = self._Create(C.byref(self.callback_structure),
C.c_void_p(id(self)))


    def __del__(self):
        if self.handle:
            return self._Destroy(self.handle)

    @staticmethod
    def  _OnSessionLostCallBack(context, sessionId, reason):
        self = C.cast(context, C.py_object).value
        self.OnSessionLostCallBack(self.callback_data, sessionId, reason)

    def OnSessionLostCallBack(self, context, sessionId, reason):
        pass

Re: [ctypes-users] why sturct size different between C and Python ctypes?

[Stephen G. <ste...@op...>]

The reference I found to inet_diag_req online shows Inet_diag_sockid is 
a structure contained by value NOT by reference, .. I took away the 
POINTER and got a total of 76 bytes ( packing =1)

nlmsghdr     = 16     pack=1
inet_diag_req= 60     pack=1
===================
nlmsg        = 76     pack=1



Check to see if I am correct.

class inet_diag_req(ctypes.Structure):
     _pack_ = ww
     _fields_ = [
         ("idiag_family", ctypes.c_uint8),        # 1  = 1
         ("idiag_src_len", ctypes.c_uint8),       # 1  = 2
         ("idiag_dst_len", ctypes.c_uint8),       # 1  = 3
         ("idiag_ext", ctypes.c_uint8),           # 1  = 4
#        ("id", ctypes.POINTER(Inet_diag_sockid)),# 4  = 8
         ("id", Inet_diag_sockid), #<<<< by value, not reference
         ("idiag_states", ctypes.c_uint32),       # 4  = 12
         ("idiag_dbs", ctypes.c_uint32)           # 4  = 16
     ]                                         # total = 16


Steve



On 22/02/16 18:52, Yang Liu wrote:
> Hi,all
>
> I am using ctypes today and a sturct size is differet in C and Python 
> ctypes code
> here is my code
>
> C:
> #include<linux/netlink.h>
> #include<linux/inet_diag.h>
>
> int main(int argc, char *argv[])
> {
>     struct {
>         struct nlmsghdr      nlh;
>         struct inet_diag_req req;
>      } nlreq;
>     printf("nlreq: %d\n", sizeof(nlreq));
>     return 0;
> }
>
> out:
> nlreq: 76
>
>
> Python:
> class nlmsghdr(ctypes.Structure):
>     _fields_ = [
>         ("len", ctypes.c_uint32),
>         ("type", ctypes.c_uint16),
>         ("flags", ctypes.c_uint16),
>         ("seq", ctypes.c_uint32),
>         ("pid", ctypes.c_uint32)]
>
> class Inet_diag_sockid(ctypes.Structure):
>     _fields_ = [
> ("idiag_sport", ctypes.c_uint16.__ctype_be__),
> ("idiag_dport", ctypes.c_uint16.__ctype_be__),
> ("idiag_src", ctypes.c_uint32.__ctype_be__ * 4),
> ("idiag_dst", ctypes.c_uint32.__ctype_be__ * 4),
> ("idiag_if", ctypes.c_uint32),
> ("idiag_cookie", ctypes.c_uint32 * 2),
>     ]
>
> class inet_diag_req(ctypes.Structure):
>     _fields_ = [
>         ("idiag_family", ctypes.c_uint8),
>         ("idiag_src_len", ctypes.c_uint8),
>         ("idiag_dst_len", ctypes.c_uint8),
>         ("idiag_ext", ctypes.c_uint8),
>         ("id", ctypes.POINTER(Inet_diag_sockid)),
>         ("idiag_states", ctypes.c_uint32),
>         ("idiag_dbs", ctypes.c_uint32)
>     ]
>
> class nlmsg(ctypes.Structure):
>     _fields_ = [
>         ("nlh", nlmsghdr),
>         ("req", Inet_diag_req)
>     ]
>
> print ctypes.sizeof(nlmsg)
>
> out:
> 24
>
>
> why the same struct size is 76 inC and 24 in ctypes ?
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>
>
> _______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users

Re: [ctypes-users] why sturct size different between C and Python ctypes?

[niki <ni...@vi...>]

On 22.02.2016 09:52, Yang Liu wrote:
> Hi,all
>
> I am using ctypes today and a sturct size is differet in C and Python
> ctypes code
> here is my code
>
> C:
> #include<linux/netlink.h>
> #include<linux/inet_diag.h>
>
> int main(int argc, char *argv[])
> {
>      struct {
>          struct nlmsghdr      nlh;
>          struct inet_diag_req req;
>       } nlreq;
>      printf("nlreq: %d\n", sizeof(nlreq));
>      return 0;
> }
>
> out:
> nlreq: 76
>
>
> Python:
> class nlmsghdr(ctypes.Structure):
>      _fields_ = [
>          ("len", ctypes.c_uint32),
>          ("type", ctypes.c_uint16),
>          ("flags", ctypes.c_uint16),
>          ("seq", ctypes.c_uint32),
>          ("pid", ctypes.c_uint32)]
>
> class Inet_diag_sockid(ctypes.Structure):
>      _fields_ = [
>          ("idiag_sport", ctypes.c_uint16.__ctype_be__),
>          ("idiag_dport", ctypes.c_uint16.__ctype_be__),
>          ("idiag_src", ctypes.c_uint32.__ctype_be__ * 4),
>          ("idiag_dst", ctypes.c_uint32.__ctype_be__ * 4),
>          ("idiag_if", ctypes.c_uint32),
>          ("idiag_cookie", ctypes.c_uint32 * 2),
>      ]
>
> class inet_diag_req(ctypes.Structure):
>      _fields_ = [
>          ("idiag_family", ctypes.c_uint8),
>          ("idiag_src_len", ctypes.c_uint8),
>          ("idiag_dst_len", ctypes.c_uint8),
>          ("idiag_ext", ctypes.c_uint8),
>          ("id", ctypes.POINTER(Inet_diag_sockid)),
>          ("idiag_states", ctypes.c_uint32),
>          ("idiag_dbs", ctypes.c_uint32)
>      ]
>
> class nlmsg(ctypes.Structure):
>      _fields_ = [
>          ("nlh", nlmsghdr),
>          ("req", Inet_diag_req)
>      ]
>
> print ctypes.sizeof(nlmsg)
>
> out:
> 24
>
>
> why the same struct size is 76 inC and 24 in ctypes ?

Usually this is due to structure packing. Try with _pack_ values in struct.

HTH
Niki

Re: [ctypes-users] why sturct size different between C and Python ctypes?

[Diez B. R. <de...@we...>]

I find the results very surprising. nlmsghdr is 16 Bytes for me, which leaves ~8.5 Bytes for each of inet_diag_ret fields. And that makes little to no sense to me - even on a 64 bit system (one explanation for differing sizes, btw) there shouldn’t be > 8 bytes per entry.

Can you break down the sizeofs of various substructures in C and Python to home in on this?

Diez

> 
> I am using ctypes today and a sturct size is differet in C and Python ctypes code
> here is my code




> 
> C:
> #include<linux/netlink.h>
> #include<linux/inet_diag.h>
> 
> int main(int argc, char *argv[])
> {
>     struct {
>         struct nlmsghdr      nlh;
>         struct inet_diag_req req;
>      } nlreq;
>     printf("nlreq: %d\n", sizeof(nlreq));
>     return 0;
> }
> 
> out:
> nlreq: 76
> 
> 
> Python:
> class nlmsghdr(ctypes.Structure):
>     _fields_ = [
>         ("len", ctypes.c_uint32),
>         ("type", ctypes.c_uint16),
>         ("flags", ctypes.c_uint16),
>         ("seq", ctypes.c_uint32),
>         ("pid", ctypes.c_uint32)]
> 
> class Inet_diag_sockid(ctypes.Structure):
>     _fields_ = [
>         ("idiag_sport", ctypes.c_uint16.__ctype_be__),
>         ("idiag_dport", ctypes.c_uint16.__ctype_be__),
>         ("idiag_src", ctypes.c_uint32.__ctype_be__ * 4),
>         ("idiag_dst", ctypes.c_uint32.__ctype_be__ * 4),
>         ("idiag_if", ctypes.c_uint32),
>         ("idiag_cookie", ctypes.c_uint32 * 2),
>     ]
> 
> class inet_diag_req(ctypes.Structure):
>     _fields_ = [
>         ("idiag_family", ctypes.c_uint8),
>         ("idiag_src_len", ctypes.c_uint8),
>         ("idiag_dst_len", ctypes.c_uint8),
>         ("idiag_ext", ctypes.c_uint8),
>         ("id", ctypes.POINTER(Inet_diag_sockid)),
>         ("idiag_states", ctypes.c_uint32),
>         ("idiag_dbs", ctypes.c_uint32)
>     ]
> 
> class nlmsg(ctypes.Structure):
>     _fields_ = [
>         ("nlh", nlmsghdr),
>         ("req", Inet_diag_req)
>     ]
> 
> print ctypes.sizeof(nlmsg)
> 
> out:
> 24
> 
> 
> why the same struct size is 76 inC and 24 in ctypes ?
> 
> Thanks
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users

[ctypes-users] why sturct size different between C and Python ctypes?

[Yang L. <liu...@gm...>]

Hi,all

I am using ctypes today and a sturct size is differet in C and Python
ctypes code
here is my code

C:
#include<linux/netlink.h>
#include<linux/inet_diag.h>

int main(int argc, char *argv[])
{
    struct {
        struct nlmsghdr      nlh;
        struct inet_diag_req req;
     } nlreq;
    printf("nlreq: %d\n", sizeof(nlreq));
    return 0;
}

out:
nlreq: 76


Python:
class nlmsghdr(ctypes.Structure):
    _fields_ = [
        ("len", ctypes.c_uint32),
        ("type", ctypes.c_uint16),
        ("flags", ctypes.c_uint16),
        ("seq", ctypes.c_uint32),
        ("pid", ctypes.c_uint32)]

class Inet_diag_sockid(ctypes.Structure):
    _fields_ = [
        ("idiag_sport", ctypes.c_uint16.__ctype_be__),
        ("idiag_dport", ctypes.c_uint16.__ctype_be__),
        ("idiag_src", ctypes.c_uint32.__ctype_be__ * 4),
        ("idiag_dst", ctypes.c_uint32.__ctype_be__ * 4),
        ("idiag_if", ctypes.c_uint32),
        ("idiag_cookie", ctypes.c_uint32 * 2),
    ]

class inet_diag_req(ctypes.Structure):
    _fields_ = [
        ("idiag_family", ctypes.c_uint8),
        ("idiag_src_len", ctypes.c_uint8),
        ("idiag_dst_len", ctypes.c_uint8),
        ("idiag_ext", ctypes.c_uint8),
        ("id", ctypes.POINTER(Inet_diag_sockid)),
        ("idiag_states", ctypes.c_uint32),
        ("idiag_dbs", ctypes.c_uint32)
    ]

class nlmsg(ctypes.Structure):
    _fields_ = [
        ("nlh", nlmsghdr),
        ("req", Inet_diag_req)
    ]

print ctypes.sizeof(nlmsg)

out:
24


why the same struct size is 76 inC and 24 in ctypes ?

Thanks

Re: [ctypes-users] Structure inheritance and tail padding

[eryk s. <er...@gm...>]

On Sat, Feb 6, 2016 at 8:25 AM, Carlos Pita <car...@gm...> wrote:
>
> just from observation I arrived to the unconfirmed conclusion that
> Structure inheritance adds tail padding. For example:
>
> class A(Structure):
>   _fields_ = [('a', c_double), ('b', c_char)]
>
> class B(A):
>   _fields_ = [('c', c_int)]
>

It's a subclass alternative to the following:

class A(Structure):
    _fields_ = (('a', c_double),
                ('b', c_char))

class B(Structure):
    _anonymous_ = '_A',
    _fields_ = (('_A', A),
                ('c',  c_int))

FYI, the padding at the end of "A" provides aligned access in
aggregates (arrays, structs). The size of "A" is 16 bytes, which is a
multiple of its 8-byte alignment. Similarly the size of B has to be
rounded up to 24 bytes, with 4 trailing pad bytes.

    >>> sizeof(B), alignment(B)
    (24, 8)
    >>> B.c
    <Field type=c_int, ofs=16, size=4>

Using a subclass is a good idea when several structures share a common
header. It's more flexible and scalable than cramming everything into
a union.

[ctypes-users] Structure inheritance and tail padding

[Carlos P. <car...@gm...>]

Hi all,

just from observation I arrived to the unconfirmed conclusion that
Structure inheritance adds tail padding. For example:

class A(Structure):
  _fields_ = [('a', c_double), ('b', c_char)]

class B(A):
  _fields_ = [('c', c_int)]

will not show the same layout than:

class C(Structure):
  _fields_ = [('a', c_double), ('b', c_char), ('c', c_int)]

Supposing my conclusion is right, what is the intention of this feature:

i. To support c++ pod subclassing? (most compilers reuse the tail
padding for non-pod subclassing).

ii. To support a more oo view of c struct composition? (btw, it
complements the ms-extensions very well).

Thank you in advance
--
Carlos

Re: [ctypes-users] resize content, not type

[eryk s. <er...@gm...>]

On Mon, Jan 25, 2016 at 8:37 PM, Carlos Pita <car...@gm...> wrote:
>
> Also, regarding this last part: from_address created instances have
> nothing in _objects, while from_buffer ones have a reference there.
> Does this mean that an object created from the buffer of another one
> will keep the buffer alive despite the first one may have been garbage
> collected at some point?

2.x from_buffer stores a reference to the source object in _objects.
In 3.x it's a memoryview that in turn references the source object. In
either case the object that owns the memory is kept alive. There's no
transfer of ownership. It's just CPython reference counting.

You can also use a pointer:

    short_array = (c_short * 4)()
    resize(short_array, 32)

    short_array_ex = POINTER(c_short * 16)(short_array)[0]

    >>> short_array_ex._b_base_
    <__main__.LP_c_short_Array_16 object at 0x7fb07a409710>
    >>> short_array_ex._b_base_._objects
    {'1': <__main__.c_short_Array_4 object at 0x7fb07a4097a0>, '0': {}}

Or a cast for a similar result:

    short_array_ex = cast(short_array, POINTER(c_short * 16))[0]

    >>> short_array_ex._b_base_
    <__main__.LP_c_short_Array_16 object at 0x7fb07a4098c0>
    >>> short_array_ex._b_base_._objects
    {140395942025120: <__main__.c_short_Array_4 object at 0x7fb07a4097a0>}

Only from_buffer verifies the buffer size. Be careful with pointer casts.

Re: [ctypes-users] resize content, not type

[Carlos P. <car...@gm...>]

> Another option is to resize and then create a new array from_address,
> but it won't own the memory so it's a problematic approach.

Also, regarding this last part: from_address created instances have
nothing in _objects, while from_buffer ones have a reference there.
Does this mean that an object created from the buffer of another one
will keep the buffer alive despite the first one may have been garbage
collected at some point?

[ctypes-users] resize content, not type

[Carlos P. <car...@gm...>]

Hi all,

for the resize function the ctypes tutorial states:

> Another way to use variable-sized data types with ctypes is to use the dynamic
> nature of Python, and (re-)define the data type after the required size is already
> known, on a case by case basis.

What does this mean? I tried monkey-patching the __class__ attribute,
also changing the _length_ attribute, but to no avail. This is not
surprising as the relevant length attribute is part of the C-side
object state, which doesn't seem to be exposed to the python API and
won't change just because I changed the type after construction.

Another option is to resize and then create a new array from_address,
but it won't own the memory so it's a problematic approach.

Cheers
--
Carlos

Re: [ctypes-users] Library Import

[eryk s. <er...@gm...>]

On Mon, Dec 21, 2015 at 6:48 AM, Andrew Robert Whalley <ar...@et...> wrote:
>
> I would like to use Python / ctypes to test a C library that contains
> some dependencies. Is it possible to satisfy those dependencies from
> within the Python interpreter, by using ctypes to define callables
> (similar to the callback function mechanism)? Or do any dependencies
> have to be defined in other, loadable, libraries?

You need a shim library that calls the ctypes callbacks.

[ctypes-users] Library Import

[Andrew R. W. <ar...@et...>]

Hi All,

I would like to use Python / ctypes to test a C library that contains 
some dependencies. Is it possible to satisfy those dependencies from 
within the Python interpreter, by using ctypes to define callables 
(similar to the callback function mechanism)? Or do any dependencies 
have to be defined in other, loadable, libraries?

Regards,

Rob Whalley

Re: [ctypes-users] NtQuerySystemInformation

[Cristian B. <cri...@gm...>]

Thank you,

It worked perfectly. I also wanted to get the types and names of the
handles, so i duplicated the handles and i used NtQueryObject to get the
type information and the name information and it worked

On Thu, Oct 29, 2015 at 3:18 PM, eryksun <er...@gm...> wrote:

> On 10/29/15, Cristian Badescu <cri...@gm...> wrote:
> > After calling NtQuerySystemInformation with _stdcall (windll) as Diez
> > suggested, i am getting STATUS_INFO_LENGTH_MISMATCH. After calling
> realloc
> > to get a new size a few time trying to get to the actual buffer size
> > required (for SystemHandleInformation the function does not return the
> > required buffer size) the function fails with an 0xC0000005 (Access
> > Violation) error. This is the code i use:
>
> Use SystemExtendedHandleInformation (64) because it handles PIDs
> greater than 65535. Note that your version of SYSTEM_HANDLE
> incorrectly makes the ProcessId field a c_ulong. Actually it's a
> c_ushort followed by another reserved c_ushort.
>
> Resize the structure to exactly the size returned in the 4th
> parameter. Do this by calling ctypes.resize; don't call C realloc
> directly.
>
> Here's a version that I've tested on Windows 7 and 10 in both 32-bit
> and 64-bit processes in Python 2.7, 3.4, and 3.5. It has improved type
> safety, error handling, and demonstrates using a property to return an
> array for a variable-sized array field.
>
> from ctypes import *
> from ctypes.wintypes import *
> import functools
>
> ntdll = WinDLL('ntdll')
>
> PVOID       = c_void_p
> PULONG      = POINTER(ULONG)
> ULONG_PTR   = WPARAM
> ACCESS_MASK = DWORD
>
> @functools.total_ordering
> class NTSTATUS(c_long):
>     def __eq__(self, other):
>         if hasattr(other, 'value'):
>             other = other.value
>         return self.value == other
>     def __ne__(self, other):
>         if hasattr(other, 'value'):
>             other = other.value
>         return self.value != other
>     def __lt__(self, other):
>         if hasattr(other, 'value'):
>             other = other.value
>         return self.value < other
>     def __bool__(self):
>         return self.value >= 0
>     def __repr__(self):
>         value = c_ulong.from_buffer(self).value
>         return 'NTSTATUS(%08x)' % value
>
> STATUS_INFO_LENGTH_MISMATCH = NTSTATUS(0xC0000004)
>
> def WinErrorFromNtStatus(status):
>     last_error = ntdll.RtlNtStatusToDosError(status)
>     return WinError(last_error)
>
> class SYSTEM_INFORMATION_CLASS(c_ulong):
>     def __repr__(self):
>         return '%s(%s)' % (type(self).__name__, self.value)
>
> SystemExtendedHandleInformation = SYSTEM_INFORMATION_CLASS(64)
>
> class SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX(Structure):
>     _fields_ = (('Object',                PVOID),
>                 ('UniqueProcessId',       HANDLE),
>                 ('HandleValue',           HANDLE),
>                 ('GrantedAccess',         ACCESS_MASK),
>                 ('CreatorBackTraceIndex', USHORT),
>                 ('ObjectTypeIndex',       USHORT),
>                 ('HandleAttributes',      ULONG),
>                 ('Reserved',              ULONG))
>
> class SYSTEM_INFORMATION(Structure):
>     pass
>
> PSYSTEM_INFORMATION = POINTER(SYSTEM_INFORMATION)
>
> class SYSTEM_HANDLE_INFORMATION_EX(SYSTEM_INFORMATION):
>     _fields_ = (('NumberOfHandles', ULONG_PTR),
>                 ('Reserved',        ULONG_PTR),
>                 ('_Handles', SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX * 1))
>     @property
>     def Handles(self):
>         arr_t = (SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX *
>                  self.NumberOfHandles)
>         return POINTER(arr_t)(self._Handles)[0]
>
> ntdll.NtQuerySystemInformation.restype = NTSTATUS
> ntdll.NtQuerySystemInformation.argtypes = (
>     SYSTEM_INFORMATION_CLASS, # SystemInformationClass
>     PSYSTEM_INFORMATION,      # SystemInformation
>     ULONG,                    # SystemInformationLength
>     PULONG)                   # ReturnLength
>
> def list_handles():
>     info = SYSTEM_HANDLE_INFORMATION_EX()
>     length = ULONG()
>     while True:
>         status = ntdll.NtQuerySystemInformation(
>                         SystemExtendedHandleInformation,
>                         byref(info),
>                         sizeof(info),
>                         byref(length))
>         if status != STATUS_INFO_LENGTH_MISMATCH:
>             break
>         resize(info, length.value)
>     if status < 0:
>         raise WinErrorFromNtStatus(status)
>     return info.Handles
>
> if __name__ == '__main__':
>     import os
>     import sys
>     if len(sys.argv) > 1:
>         pid = int(sys.argv[1])
>     else:
>         pid = os.getpid()
>     for h in list_handles():
>         if h.UniqueProcessId != pid:
>             continue
>         t = (h.HandleValue, h.ObjectTypeIndex, h.GrantedAccess)
>         print('%04x : %04x : %08x' % t)
>

Re: [ctypes-users] NtQuerySystemInformation

[eryksun <er...@gm...>]

On 10/29/15, Cristian Badescu <cri...@gm...> wrote:
> After calling NtQuerySystemInformation with _stdcall (windll) as Diez
> suggested, i am getting STATUS_INFO_LENGTH_MISMATCH. After calling realloc
> to get a new size a few time trying to get to the actual buffer size
> required (for SystemHandleInformation the function does not return the
> required buffer size) the function fails with an 0xC0000005 (Access
> Violation) error. This is the code i use:

Use SystemExtendedHandleInformation (64) because it handles PIDs
greater than 65535. Note that your version of SYSTEM_HANDLE
incorrectly makes the ProcessId field a c_ulong. Actually it's a
c_ushort followed by another reserved c_ushort.

Resize the structure to exactly the size returned in the 4th
parameter. Do this by calling ctypes.resize; don't call C realloc
directly.

Here's a version that I've tested on Windows 7 and 10 in both 32-bit
and 64-bit processes in Python 2.7, 3.4, and 3.5. It has improved type
safety, error handling, and demonstrates using a property to return an
array for a variable-sized array field.

from ctypes import *
from ctypes.wintypes import *
import functools

ntdll = WinDLL('ntdll')

PVOID       = c_void_p
PULONG      = POINTER(ULONG)
ULONG_PTR   = WPARAM
ACCESS_MASK = DWORD

@functools.total_ordering
class NTSTATUS(c_long):
    def __eq__(self, other):
        if hasattr(other, 'value'):
            other = other.value
        return self.value == other
    def __ne__(self, other):
        if hasattr(other, 'value'):
            other = other.value
        return self.value != other
    def __lt__(self, other):
        if hasattr(other, 'value'):
            other = other.value
        return self.value < other
    def __bool__(self):
        return self.value >= 0
    def __repr__(self):
        value = c_ulong.from_buffer(self).value
        return 'NTSTATUS(%08x)' % value

STATUS_INFO_LENGTH_MISMATCH = NTSTATUS(0xC0000004)

def WinErrorFromNtStatus(status):
    last_error = ntdll.RtlNtStatusToDosError(status)
    return WinError(last_error)

class SYSTEM_INFORMATION_CLASS(c_ulong):
    def __repr__(self):
        return '%s(%s)' % (type(self).__name__, self.value)

SystemExtendedHandleInformation = SYSTEM_INFORMATION_CLASS(64)

class SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX(Structure):
    _fields_ = (('Object',                PVOID),
                ('UniqueProcessId',       HANDLE),
                ('HandleValue',           HANDLE),
                ('GrantedAccess',         ACCESS_MASK),
                ('CreatorBackTraceIndex', USHORT),
                ('ObjectTypeIndex',       USHORT),
                ('HandleAttributes',      ULONG),
                ('Reserved',              ULONG))

class SYSTEM_INFORMATION(Structure):
    pass

PSYSTEM_INFORMATION = POINTER(SYSTEM_INFORMATION)

class SYSTEM_HANDLE_INFORMATION_EX(SYSTEM_INFORMATION):
    _fields_ = (('NumberOfHandles', ULONG_PTR),
                ('Reserved',        ULONG_PTR),
                ('_Handles', SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX * 1))
    @property
    def Handles(self):
        arr_t = (SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX *
                 self.NumberOfHandles)
        return POINTER(arr_t)(self._Handles)[0]

ntdll.NtQuerySystemInformation.restype = NTSTATUS
ntdll.NtQuerySystemInformation.argtypes = (
    SYSTEM_INFORMATION_CLASS, # SystemInformationClass
    PSYSTEM_INFORMATION,      # SystemInformation
    ULONG,                    # SystemInformationLength
    PULONG)                   # ReturnLength

def list_handles():
    info = SYSTEM_HANDLE_INFORMATION_EX()
    length = ULONG()
    while True:
        status = ntdll.NtQuerySystemInformation(
                        SystemExtendedHandleInformation,
                        byref(info),
                        sizeof(info),
                        byref(length))
        if status != STATUS_INFO_LENGTH_MISMATCH:
            break
        resize(info, length.value)
    if status < 0:
        raise WinErrorFromNtStatus(status)
    return info.Handles

if __name__ == '__main__':
    import os
    import sys
    if len(sys.argv) > 1:
        pid = int(sys.argv[1])
    else:
        pid = os.getpid()
    for h in list_handles():
        if h.UniqueProcessId != pid:
            continue
        t = (h.HandleValue, h.ObjectTypeIndex, h.GrantedAccess)
        print('%04x : %04x : %08x' % t)

Re: [ctypes-users] NtQuerySystemInformation

[Cristian B. <cri...@gm...>]

I finally solved the problem. Here is the code if anyone else needs it:

from ctypes import *
from ctypes.util import *

class SYSTEM_HANDLE(Structure):

_fields_ = [("ProcessId", c_ulong),
("ObjetTypeNumber", c_byte),
("Flags", c_byte),
("Handle", c_ushort),
("Object", c_void_p ),
("GrantedAccess", c_ulong)
]

class SYSTEM_HANDLE_INFORMATION(Structure):

_fields_ = [("HandleCount", c_ulong),
("Handles", POINTER(SYSTEM_HANDLE))
]


handleInfoSize = c_ulong(0x1000)

SystemHandleInformation = 16

handleInfo = create_string_buffer(handleInfoSize.value)

pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))

while windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
pHandleInfo, handleInfoSize, None) == -1073741820:
handleInfoSize.value *= c_ulong(2).value
handleInfo = create_string_buffer(handleInfoSize.value)
pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))

On Thu, Oct 29, 2015 at 12:27 PM, Cristian Badescu <
cri...@gm...> wrote:

> After calling NtQuerySystemInformation with _stdcall (windll) as Diez
> suggested, i am getting STATUS_INFO_LENGTH_MISMATCH. After calling
> realloc to get a new size a few time trying to get to the actual buffer
> size required (for SystemHandleInformation the function does not return the
> required buffer size) the function fails with an 0xC0000005 (Access
> Violation) error. This is the code i use:
>
> from ctypes import *
> from ctypes.util import *
>
> class SYSTEM_HANDLE(Structure):
>
> _fields_ = [("ProcessId", c_ulong),
> ("ObjetTypeNumber", c_byte),
> ("Flags", c_byte),
> ("Handle", c_ushort),
> ("Object", c_void_p ),
> ("GrantedAccess", c_ulong)
> ]
>
> class SYSTEM_HANDLE_INFORMATION(Structure):
>
> _fields_ = [("HandleCount", c_ulong),
> ("Handles", SYSTEM_HANDLE * 1)
> ]
>
>
> handleInfoSize = c_ulong(sizeof(SYSTEM_HANDLE_INFORMATION))
>
> SystemHandleInformation = 16
>
> c_lib=CDLL(find_library("c"))
> malloc=c_lib.malloc
> malloc.restype=c_void_p
> handleInfo = malloc(handleInfoSize.value)
>
> pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))
>
> size = c_ulong(sizeof(SYSTEM_HANDLE_INFORMATION))
>
> print(pHandleInfo.contents)
>
> while windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
> byref(pHandleInfo), handleInfoSize, byref(size)) == -1073741820:
> print("Buffer size to small!")
> handleInfo = c_lib.realloc(handleInfo, handleInfoSize.value +
> c_ulong(sizeof(SYSTEM_HANDLE)).value * c_ulong(100).value)
> handleInfoSize.value += c_ulong(sizeof(SYSTEM_HANDLE)).value *
> c_ulong(100).value
>
> On Wed, Oct 28, 2015 at 3:15 PM, Thor Andreas Tangen <th...@gm...>
> wrote:
>
>> Why not call it as
>>
>> spi = SYSTEM_HANDLE_INFORMATION()
>>
>> retlen = c_ulong()
>>
>> res = windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
>>                                             byref(spi),
>>                                             sizeof(spi),
>>                                             byref(retlen))
>>
>>
>> On Wed, Oct 28, 2015 at 2:03 PM, Diez B. Roggisch <de...@we...> wrote:
>>
>>> Have you tried defining the signature of NtQuerySystemInformation? It
>>> could be that arguments are being truncated.
>>>
>>> Also, is that really a CDLL, not a WINDLL?
>>>
>>> Cheers,
>>>
>>> Diez
>>>
>>> On 28 Oct 2015, at 13:31, Cristian Badescu <cri...@gm...>
>>> wrote:
>>>
>>> Hello,
>>>
>>> I am trying to get handles information by using NtQuerySystemInformation
>>> but my code fails for some reason. I am using the following code to call
>>> NtQuerySystemInformation:
>>>
>>> from ctypes import *
>>> from ctypes.util import *
>>>
>>> class SYSTEM_HANDLE(Structure):
>>>
>>>     _fields_ = [("ProcessId", c_ulong),
>>>                 ("ObjetTypeNumber", c_byte),
>>>                 ("Flags", c_byte),
>>>                 ("Handle", c_ushort),
>>>                 ("Object", c_void_p ),
>>>                 ("GrantedAccess", c_ulong)
>>>                 ]
>>>
>>> class SYSTEM_HANDLE_INFORMATION(Structure):
>>>
>>>     _fields_ = [("HandleCount", c_ulong),
>>>                 ("Handles", SYSTEM_HANDLE * 1)
>>>                 ]
>>>
>>> handleInfoSize = 65536
>>>
>>> SystemHandleInformation = 16
>>>
>>> c_lib=CDLL(find_library("c"))
>>> malloc=c_lib.malloc
>>> malloc.restype=c_void_p
>>> handleInfo = malloc(handleInfoSize)
>>>
>>> pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))
>>>
>>> retVal = cdll.ntdll.NtQuerySystemInformation(SystemHandleInformation, pHandleInfo, handleInfoSize, None)
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> ctypes-users mailing list
>>> cty...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> ctypes-users mailing list
>>> cty...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>>>
>>>
>>
>

Re: [ctypes-users] NtQuerySystemInformation

[Cristian B. <cri...@gm...>]

After calling NtQuerySystemInformation with _stdcall (windll) as Diez
suggested, i am getting STATUS_INFO_LENGTH_MISMATCH. After calling realloc
to get a new size a few time trying to get to the actual buffer size
required (for SystemHandleInformation the function does not return the
required buffer size) the function fails with an 0xC0000005 (Access
Violation) error. This is the code i use:

from ctypes import *
from ctypes.util import *

class SYSTEM_HANDLE(Structure):

_fields_ = [("ProcessId", c_ulong),
("ObjetTypeNumber", c_byte),
("Flags", c_byte),
("Handle", c_ushort),
("Object", c_void_p ),
("GrantedAccess", c_ulong)
]

class SYSTEM_HANDLE_INFORMATION(Structure):

_fields_ = [("HandleCount", c_ulong),
("Handles", SYSTEM_HANDLE * 1)
]


handleInfoSize = c_ulong(sizeof(SYSTEM_HANDLE_INFORMATION))

SystemHandleInformation = 16

c_lib=CDLL(find_library("c"))
malloc=c_lib.malloc
malloc.restype=c_void_p
handleInfo = malloc(handleInfoSize.value)

pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))

size = c_ulong(sizeof(SYSTEM_HANDLE_INFORMATION))

print(pHandleInfo.contents)

while windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
byref(pHandleInfo), handleInfoSize, byref(size)) == -1073741820:
print("Buffer size to small!")
handleInfo = c_lib.realloc(handleInfo, handleInfoSize.value +
c_ulong(sizeof(SYSTEM_HANDLE)).value * c_ulong(100).value)
handleInfoSize.value += c_ulong(sizeof(SYSTEM_HANDLE)).value *
c_ulong(100).value

On Wed, Oct 28, 2015 at 3:15 PM, Thor Andreas Tangen <th...@gm...>
wrote:

> Why not call it as
>
> spi = SYSTEM_HANDLE_INFORMATION()
>
> retlen = c_ulong()
>
> res = windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
>                                             byref(spi),
>                                             sizeof(spi),
>                                             byref(retlen))
>
>
> On Wed, Oct 28, 2015 at 2:03 PM, Diez B. Roggisch <de...@we...> wrote:
>
>> Have you tried defining the signature of NtQuerySystemInformation? It
>> could be that arguments are being truncated.
>>
>> Also, is that really a CDLL, not a WINDLL?
>>
>> Cheers,
>>
>> Diez
>>
>> On 28 Oct 2015, at 13:31, Cristian Badescu <cri...@gm...>
>> wrote:
>>
>> Hello,
>>
>> I am trying to get handles information by using NtQuerySystemInformation
>> but my code fails for some reason. I am using the following code to call
>> NtQuerySystemInformation:
>>
>> from ctypes import *
>> from ctypes.util import *
>>
>> class SYSTEM_HANDLE(Structure):
>>
>>     _fields_ = [("ProcessId", c_ulong),
>>                 ("ObjetTypeNumber", c_byte),
>>                 ("Flags", c_byte),
>>                 ("Handle", c_ushort),
>>                 ("Object", c_void_p ),
>>                 ("GrantedAccess", c_ulong)
>>                 ]
>>
>> class SYSTEM_HANDLE_INFORMATION(Structure):
>>
>>     _fields_ = [("HandleCount", c_ulong),
>>                 ("Handles", SYSTEM_HANDLE * 1)
>>                 ]
>>
>> handleInfoSize = 65536
>>
>> SystemHandleInformation = 16
>>
>> c_lib=CDLL(find_library("c"))
>> malloc=c_lib.malloc
>> malloc.restype=c_void_p
>> handleInfo = malloc(handleInfoSize)
>>
>> pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))
>>
>> retVal = cdll.ntdll.NtQuerySystemInformation(SystemHandleInformation, pHandleInfo, handleInfoSize, None)
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> ctypes-users mailing list
>> cty...@li...
>> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> ctypes-users mailing list
>> cty...@li...
>> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>>
>>
>

Re: [ctypes-users] NtQuerySystemInformation

[Thor A. T. <th...@gm...>]

Why not call it as

spi = SYSTEM_HANDLE_INFORMATION()

retlen = c_ulong()

res = windll.ntdll.NtQuerySystemInformation(SystemHandleInformation,
                                            byref(spi),
                                            sizeof(spi),
                                            byref(retlen))


On Wed, Oct 28, 2015 at 2:03 PM, Diez B. Roggisch <de...@we...> wrote:

> Have you tried defining the signature of NtQuerySystemInformation? It
> could be that arguments are being truncated.
>
> Also, is that really a CDLL, not a WINDLL?
>
> Cheers,
>
> Diez
>
> On 28 Oct 2015, at 13:31, Cristian Badescu <cri...@gm...>
> wrote:
>
> Hello,
>
> I am trying to get handles information by using NtQuerySystemInformation
> but my code fails for some reason. I am using the following code to call
> NtQuerySystemInformation:
>
> from ctypes import *
> from ctypes.util import *
>
> class SYSTEM_HANDLE(Structure):
>
>     _fields_ = [("ProcessId", c_ulong),
>                 ("ObjetTypeNumber", c_byte),
>                 ("Flags", c_byte),
>                 ("Handle", c_ushort),
>                 ("Object", c_void_p ),
>                 ("GrantedAccess", c_ulong)
>                 ]
>
> class SYSTEM_HANDLE_INFORMATION(Structure):
>
>     _fields_ = [("HandleCount", c_ulong),
>                 ("Handles", SYSTEM_HANDLE * 1)
>                 ]
>
> handleInfoSize = 65536
>
> SystemHandleInformation = 16
>
> c_lib=CDLL(find_library("c"))
> malloc=c_lib.malloc
> malloc.restype=c_void_p
> handleInfo = malloc(handleInfoSize)
>
> pHandleInfo = cast(handleInfo, POINTER(SYSTEM_HANDLE_INFORMATION))
>
> retVal = cdll.ntdll.NtQuerySystemInformation(SystemHandleInformation, pHandleInfo, handleInfoSize, None)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> ctypes-users mailing list
> cty...@li...
> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>
>