Package: axserve
IntroductionAxServe is a server program and client interface that provides functionalities of COM or OCX components through a gRPC server.MotivationThere 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:LibraryModuleBased OnMaintainerLanguageWin32MicrosoftC/C++MFCMicrosoftC++Qt5ActiveQtWin32Qt GroupC++Qt6ActiveQtWin32Qt GroupC++pywin32win32com.clientWin32Mark HammondPythonpywin32pywin.mfc.activexMFCMark HammondPythonPyQt5PyQt5.QAxContainerQt5Riverbank ComputingPythonPyQt6PyQt6.QAxContainerQt6Riverbank ComputingPythonPySide2PySide2.QtAxContainerQt5Qt GroupPythonPySide6PySide6.QtAxContainerQt6Qt GroupPythonAnd 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 stepComplexity 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 buildingSize of dependencies(+) Microsoft Maintainer options require no further dependencies(-) Other libraries and frameworks based options may require large amount of dependencies which might complicate thingsEase 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 Qt32bit architecture support(+) Qt5 Based options support 32bit architecture on windows naturally with prebuilt binaries (link)(-) Qt6 Based options do not provide prebuilt binaries for 32bit architecture on windows (link)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 specificLicense(-) 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 implicationsMy 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 sideBut make the dependency loose by supporting the functionality using an IPC technique with some libraries like gRPCLearn Qt6 and use that for developmentBuild Qt6 for 32bit architecture support on my ownBuild single server executable and use that in pythonMore specifically, run the server executable usingsubprocessand connect to that usinggrpcioAnd this project is the outcome of those choices.UsageServerGUIRun 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.ConsoleIf 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-guiThat--no-guioption 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).ClientJust started working on a Python client.Check the following codes for more information, until relevant documentations are added:Python client implementationstub.pyExample usage of itexample_client.pyProto file for gRPC service definitionactive.protoBuildingInstall Tools for Building ProjectInstall MSVC BuildToolshttps://learn.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio?view=vs-2022vs_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
    --norestartInstall Chocolateyhttps://chocolatey.org/installSet-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 GIthttps://git-scm.com/choco install git.installInstall NASMhttps://www.nasm.us/choco install nasmInstall Pythonhttps://www.python.org/choco install python311Install CMakehttps://cmake.org/choco install cmakeInstall Ninjahttps://ninja-build.org/choco install ninjaBuild ProjectList Configure Presetscmake --list-presetsConfigurecmake --preset x86-win32-debug .Buildcmake --build .\build\x86-win32-debug --parallel