python - dll access (ctypes or swig)

Discussion in 'Python' started by Daniel Watrous, Apr 17, 2007.

  1. Hello,

    I am interested in using python to script access to some hardware for
    which there are existing drivers in the form of DLLs. The DLLs each
    have four exported functions and a host of COM Properties and COM
    Methods. The four exported functions are as follows:
    DllCanUnloadNow
    DllGetClassObject
    DllRegisterServer
    DllUnregisterServer

    The COM methods and properties all begin with I, followed by a unique name.

    I am able to load the DLL using ctypes and it can access the exported
    functions, but I'm not sure how to access the COM methods and
    properties. I have read that ctypes once had support for COM but that
    it has since been separated into its own project. I couldn't find any
    information about how these work together.

    All help is appreciated. THANKS in advance...

    Daniel
     
    Daniel Watrous, Apr 17, 2007
    #1
    1. Advertisements

  2. Daniel Watrous

    Larry Bates Guest

    I recently learned that you can ship COM as either an .EXE or a .DLL (nobody
    has yet let me know why). You don't have a traditional .DLL that you would
    use ctypes to call methods in, you have a COM .DLL. COM methods need to be
    access with Win32com

    obj=win32com.client.Dispatch("typelib name").

    You need to find out the COM dispatch typelib name and make sure the DLL is
    registered (regsvr32 your.dll).

    -Larry
     
    Larry Bates, Apr 17, 2007
    #2
    1. Advertisements

  3. Daniel Watrous

    Larry Bates Guest

    I recently learned that you can ship COM as either an .EXE or a .DLL (nobody
    has yet let me know why). You don't have a traditional .DLL that you would
    use ctypes to call methods in, you have a COM .DLL. COM methods need to be
    access with Win32com

    obj=win32com.client.Dispatch("typelib name").

    You need to find out the COM dispatch typelib name and make sure the DLL is
    registered (regsvr32 your.dll).

    -Larry
     
    Larry Bates, Apr 17, 2007
    #3
  4. The "why" is pretty obvious -- you may want to be able to instantiate a
    COM object either in-process, or in its own separate process, depending
    on that object's nature. For example, a complete application that when
    running exposes COM objects to let other processes drive/script it will
    be an EXE file since it can also run independently.

    In general I'm no big fan of MS's design, but COM, despite its
    imperfections, was in fact seriously good (Don Box's "Essential COM", an
    excellent book, went just into enough depth to let a developer really
    appreciate that, IMHO). I'm using the past tense because MS has been
    trying to kill COM for a while now (but I notice that "Essential COM",
    while 10 years-old, is _still_ in stock at Amazon -- so, I guess that so
    far MS's attempts haven't _quite_ succeeded yet:).


    Alex
     
    Alex Martelli, Apr 18, 2007
    #4
  5. Is this--adroit use of Win32com with special-purpose DLLs--written
    up anywhere? Doing this with unusual hardware that turns up in the
    real world is ENTIRELY more satisfying than trying to wrangle the
    Visual C bindings that vendors usually push, but, apart from Mark
    and Andy's book, now over seven years old, I know of no appropri-
    ately ambitious tutorial in the subject.

    Daniel, do you have what you need to make progress? Have you seen
    <URL: http://www.oreilly.com/catalog/pythonwin32/ >?
     
    Cameron Laird, Apr 18, 2007
    #5
  6. Daniel Watrous

    Larry Bates Guest

    I guess I was the only one it wasn't "obvious" to <grin>. I've always
    written my COM servers as .EXE files even though they cannot be run
    independently. What I find is "odd" is that I can create a .DLL or an
    ..EXE of my COM server and after I register it, my application doesn't
    appear to know the difference. The difference seems to be hidden from
    the actual application and doesn't affect it (at least that I can
    determine).

    I also think COM works quite well and I've found it much easier to use
    than C-style DLLs that many vendors ship as their API. Most of what
    I've learned came from Mark/Andy's Python Programming on Win32 and
    trial-and-error so my knowledge is quite limited.

    Thanks for the info.

    Larry
     
    Larry Bates, Apr 18, 2007
    #6
  7. thank you for the responses and the links. I will give these ideas a
    try this week and post again if I have more questions. Thanks again
    for being so helpful!

    Daniel
     
    Daniel Watrous, Apr 18, 2007
    #7
  8. Yes, except for performance (a DLL affords within-process communication
    without the overhead of IPC, so it can be much faster when appropriate)
    and some technical issues such as threading (if COM client and server
    are in separate processes, their threading models are independent from
    each other; if they are in the same process, they'd better have
    compatible threading approaches -- a thread-unsafe DLL server can make a
    single-threaded client happy but would cause problems and crashes if a
    freely-threaded client tried using it).


    Alex
     
    Alex Martelli, Apr 18, 2007
    #8
  9. I think that the latter problem (incompatible threading models in the same
    process) are solved by COM apartments - aren't they?

    Thomas
     
    Thomas Heller, Apr 18, 2007
    #9
  10. "apartment" is one threading model, but it still means that your
    application and your in-process server must be compatible with it
    (again, we're discussing the fact that out-of-process servers, at a
    performance price, can do away with these minor limitations).


    Alex
     
    Alex Martelli, Apr 19, 2007
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.