CallDLL/WinDLL vs Python Wrapper Extension (Win32)
_spam_sux_tdfunk at _spam_sux_nettally.com
Thu Mar 23 23:23:02 CET 2000
I wish to write a Python Module that will talk to the PowerBuilder ORCA
DLL. ORCA is an API for PowerBuilder library modules used by 3rd party
tools to access and manipulate the source modules stored in PB libraries.
The API uses callback functions extensively.
The API ships as a DLL, an object library and a C/C++ header file. The
header file details the interfaces to the functions exported by the DLL.
The intent is that users write C/C++ programs and link them to the ORCA
library to access the DLL's functions, thereby allowing access to the
source code locked in the libraries.
That's the intent, but I want to use Python.
I've just started reading the Embedding/Extending Python docs. I've
downloaded four chapters of SWIG. I think SWIG is probably overkill
since I get the first impression that it's designed to wrap C/C++ source,
not header files alone. I've also looked at some of the docs and
examples that come with Sam Rushing's DynWin module that use calldll,
gencb and windll.
I'm trying to decide the best approach to take.
The API consists of 53 #defines (mostly numeric constants), 2 enums, 7
typedef'd structs, and 24 function calls. Of the 6 required callback,
all take a struct as an argument.
I don't want to expose the end user to the (ugly) API directly, rather I
want to python-ize it. i.e., create a Library class that exposes the
source code as a dictionary or list. Provide an Application class that
wraps a group of libraries and exposes the libraries as a collection
(dictionary or list). Move, copy and compile functions would become
methods of a library rather than distinct function calls. Things like
So, any takers? Does anyone have any feedback on what might be a
Thanks for your help.
-=< tom >=-
Thomas D. Funk | "Software is the lever
Software Engineering Consultant | Archimedes was searching for"
Advanced Systems Design, Tallahassee FL. |
More information about the Python-list