AxServe python client that provides interfaces of COM or OCX components through a gRPC server.
Project description
Introduction
AxServe is a server program and client interface that provides functionalities of COM or OCX components through a gRPC server.
Motivation
There are many ways to integrate COM or OCX components, such as creating native apps or using other libraries or frameworks. But they all have their own strengths and weaknesses.
Options that I had considered so far were:
Library | Module | Based On | Maintainer | Language |
---|---|---|---|---|
Win32 | Microsoft | C/C++ | ||
MFC | Microsoft | C++ | ||
Qt5 | ActiveQt | Win32 | Qt Group | C++ |
Qt6 | ActiveQt | Win32 | Qt Group | C++ |
pywin32 | win32com.client | Win32 | Mark Hammond | Python |
pywin32 | pywin.mfc.activex | MFC | Mark Hammond | Python |
PyQt5 | PyQt5.QAxContainer | Qt5 | Riverbank Computing | Python |
PyQt6 | PyQt6.QAxContainer | Qt6 | Riverbank Computing | Python |
PySide2 | PySide2.QtAxContainer | Qt5 | Qt Group | Python |
PySide6 | PySide6.QtAxContainer | Qt6 | Qt Group | Python |
And Pros & Cons of each of these options that I had experienced while using some of them were as follows:
- Requires build step
- (-) C/C++ Language options require build step
- (+) Python Language options do not require built step
- Complexity in dependency resolution and installation
- (-) Python Language options may have no proper python version that supports all requirements like target architecture (x86/x64) and version support (3.x)
- (-) And Python Language options may require multiple python installations with some IPC (Inter-Process Communication) technique as workaround
- (+) C/C++ Language options only require single installation for each target architecture once built
- (-) But C/C++ Language options may have hard time in managing it's dependencies compared to python when it comes to installation and building
- Size of dependencies
- (+) Microsoft Maintainer options require no further dependencies
- (-) Other libraries and frameworks based options may require large amount of dependencies which might complicate things
- Ease of use, amount of learning materials and references, quality of documentation
- (+) Qt based Python bindings options are easy to use, have lots of materials and references
- (+) Qt based options have good documentation and sufficient references
- (-) Other options may have less materials, might be harder to use
- (+) Python Language options are generally considered as easy compared to C++
- Possibility of being deprecated or obsolete
- (-) Qt5 Based options will become deprecated/obsolete over time in favor of Qt6
- (+) Qt6 based options are latest version in Qt
- 32bit architecture support
- Applicability of acquired knowledge across domains
- (+) Qt based options can leverage learned skills to create other applications for platforms other than windows
- (-) Other options may be too platform specific
- License
- (-) PyQt Based options require GPLv3 license, unless commercial license is used
- (+) Qt Group Maintainer options (QtX and PySideX) require LGPLv3 license
- (+) Pywin32 based options generally considered as PSF-2.0 (issue)
- (+) Microsoft Maintainer options have less license implications
My personal goal was to use 32bit COM/OCX feature in python. So based on the analysis and my goal, my final decision was:
- Not to bring the COM/OCX part of dependency to the python side
- But make the dependency loose by supporting the functionality using an IPC technique with some libraries like gRPC
- Learn Qt6 and use that for development
- Build Qt6 for 32bit architecture support on my own
- Build single server executable and use that in python
- More specifically, run the server executable using
subprocess
and connect to that usinggrpcio
And this project is the outcome of those choices.
Usage
Server
GUI
- Run the executable by double clicking.
- Type the required information.
- CLSID required to instantiate an Active-X or COM object.
- Address URI for gRPC server to bind.
- Press start button to start server.
Console
If built with console support, give required options to run the server as cli argument:
.\axserve-x86-console-debug.exe --clsid="{A1574A0D-6BFA-4BD7-9020-DED88711818D}" --address="localhost:8080" --no-gui
That --no-gui
option makes the application run without GUI components. This can be useful for cases like embedding this executable in other things. FYI, technically it's not a pure non-gui application but just tries to hide or not to show the windows created internally.
The GUI version also accepts the same cli arguments. But note that it cannot print any messages since there is no console attached. FYI, the GUI version uses message boxes for that instead when needed (like printing errors).
Client
Just started working on a Python client.
Check the following codes for more information, until relevant documentations are added:
- Example usage of it example_client.py
- Example usages from tests:
- Normal synchronous API: test_iexplorer.py
- Asynchronous API under
asyncio
framework: test_iexplorer_async.py
- Python client implementation stub.py
- Proto file for gRPC service definition active.proto
Building
Install Tools for Building Project
Install MSVC BuildTools
vs_buildtools.exe
--add "Microsoft.VisualStudio.Workload.VCTools"
--add "Microsoft.VisualStudio.Component.VC.Tools.x86.x64"
--add "Microsoft.VisualStudio.Component.VC.CMake.Project"
--add "Microsoft.VisualStudio.Component.VC.ATL"
--add "Microsoft.VisualStudio.Component.VC.ATLMFC"
--includeRecommended
--passive
--norestart
Install Chocolatey
https://chocolatey.org/install
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
Install GIt
choco install git.install
Install NASM
choco install nasm
Install Python
choco install python311
Install CMake
choco install cmake
Install Ninja
choco install ninja
Build Project using CMake
List Configure Presets
cmake --list-presets
Configure
cmake --preset x86-win32-debug .
Build
cmake --build .\build\x86-win32-debug --parallel
Build Project using Hatch and publish
Build Project for Python client package
hatch build
Publish to PyPI
hatch publish
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file axserve-0.1.5.tar.gz
.
File metadata
- Download URL: axserve-0.1.5.tar.gz
- Upload date:
- Size: 95.6 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: python-httpx/0.25.2
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | e26e621b2e1dba85f624181723ba4e159da82227cddb38d5852902c1a4a5e2c2 |
|
MD5 | 63d1598c67fe553ad5859e1e391e1fa0 |
|
BLAKE2b-256 | 453d5830993834b0ffff977ee03c5d42c2cdb4af7f93c06dcce3997e5d9a479a |
File details
Details for the file axserve-0.1.5-py3-none-any.whl
.
File metadata
- Download URL: axserve-0.1.5-py3-none-any.whl
- Upload date:
- Size: 44.2 MB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: python-httpx/0.25.2
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 2327bc4a4c586d39a81c383c520fd80a2ef76d2f012cfa16a5bec01024be95ab |
|
MD5 | d390c96faabd161e82cf360d9efa8026 |
|
BLAKE2b-256 | ed43fc83f4e98d9f4ddcb4f7627392409a969165c0e4a635e24cdb01399cefba |