eigene .dll in Python

[reinerdoll]

das hab ich auch probiert ... geht nicht.
wie kann ich rauskriegen, was da ggf. als namespace davor muß ?

[__deets__]

Versuchen sie mit einem ner andren Sprache aus dem MS Universum zu benutzen bzw. irgend ein Reflektion Tool/Browser verwenden?

[reinerdoll]

Die Sache ist so : ich möchte bei uns Python einführen, weil in unserer Sparte der Trend massiv in diese Richtung geht.
In VB oder C# hab ich alles im Griff, no Problem. Nun teste ich halt aus, wie das alles mit Python läuft.

Kernapplikation : aus nem Windows-Rechner entweder direkt (TCP/IP) oder über OPCuA auf alle möglichen Prozesskomponenten zugreifen.

Ich habe eine Bibliothek (Easy-OPC von OPCLabs), die ich aus ActivePython (wohl als COM-Kompoente ?) nutzen kann.
Auch die Windows-Domäane kann ich aus Python administrieren (WSH und ADSI sind nutzbar).

Andere Kompoenten (z.b. eine Bibliothek für einen RFID-Controller, die als .exe vorliegt) krig ich nicht zum laufen. Auch meine selber geschriebene VB-dll, die meinen Anwendern die Komplexität der direkten OPC-Zugriffe erleichtern soll, krieg ich nicht zum laufen, obwohl ich nach einem oben genannten Weblink eine .dll als COM-Komponente fehlerfrei erzeugen kann.

Peinliche Ursache : Ich kenn mich mit COM und .net nicht genug aus. Würde IronPython die Sache erleichtern ? Da lese ich von .net-Kompatibilität.
Aber schon der "import win32com.client" läuft darunter nicht. Ich rate mal : weil das COM ist, und nicht .net.

Kann jemand in 3 Sätzen den Unterschied erklären ?

[BlackJack]

@reinerdoll: Ich denke nicht das Du so mit Python glücklich wirst und finde die Motivation auch fragwürdig. Eine Sprache sollte man nicht nehmen weil sie gerade Mode ist, sondern weil man damit gut klar kommt und die anstehenden Probleme leicht lösen kann. Ich habe das Gefühl Du programmierst gegen eine bestehende Infrastruktur an, in die sich Python nicht so leicht integrieren lässt. Das ist entweder sehr windowslastig oder .NET-Welt. Wenn das mit anderen Sprachen leichter geht, sehe ich keinen Vorteil darin Python mit Gewalt da hinein zu prügeln.

In IronPython funktionieren keine externen Module die (mindestens teilweise) in C und gegen die API von CPython geschrieben wurden.

Dafür hast Du in IronPython die .NET-Standardbibliothek und ich vermute mal ganz stark das da auch was für COM-Clients dabei ist.

Aber wie gesagt, ich finde die Motivation das tun zu wollen komisch. Und sehe nicht wie das zu Python-Code führt der auch wirklich ”pythonisch” ist. Wenn Du stattdessen am Ende Windows-COM-Bibliotheken verwendest um Dateien anzulegen, Klassen aus der .NET-Standardbibliothek, und VB oder C# als Python ”verkleidest”, sehe ich da Null Gewinn, aber die zusätzliche Komplexität bei der Anbindung um das alles zum Laufen zu bekommen.

[Sirius3]

@reinerdoll: verschiedene Sprachen können die selben Dinge unterschiedlich ausdrücken. Dir gefällt dir COM-Schnittstelle von OPC nicht, und deshalb schreibst Du eine VB-Schnittstelle, die besser an VisualBasic angepasst ist. Genauso mußt Du vorgehen, wenn Du eine Schnittstelle für Python anbieten willst. Nimm die COM-Schnittstelle von OPC direkt in Python und schreibe für Deine Anwender eine schönere, so wie ein Python-Anwender es gewohnt wäre. Der Umweg über VB passt hier nicht rein und führt auch nicht zu einer guten Python-Schnittstelle, sondern nur zu Visualbasic-Code in Python-Syntax.

[reinerdoll]

Die obigen Meinungen find ich sehr interessant. Danke.

Die Motivation ist genauer so : Mir wird öfter mitgeteilt, daß VB für die Industrietechnik ein sterbender Ast sei. Auch in vielen produktnahen Softwarepaketen, in der Programmierunterstützung bei neuen (multitaskingfähigen)SPS-en, im Skripring von MES-Systemen usw. usw., ist Python die dominierende Spache.

Also tummle ich mich mal, und will austesten, wie groß für uns hier der Aufwand für diese Migration wäre. Meine Anwender sind zu 99% keine Softwareleute, trotzdem müssen sie in kleinem Umfang programmieren oder wenigstens Programme verstehen und modifizieren können.

Wenn ich darf (ich weiß, ist off-topic) erlaube ich mir eine Verständnisfrage :

COM (war ?) die Schnittstellendefintion in Windows für die Interprozesskommunikation seit WindowsNT (modularer Kernel). Wenn man selber in Windows prpgrammieren wollte, und dazu Systemserver oder ähnliches (z.b. Hardwarezugriffe) gebraucht ha, mußte man halt diesen Standard erfüllen. (1. Frage : ist das so korrekt ?).

Ich dachte, .net sei einfach der Nachfolger, nachdem COM (und vor allem DCOM) aus Securitygründen rausgeflogen ist. (2. Frage : stimmt das ?)

[__deets__]

Stimmt beides nicht. COM existierte auch schon unter Windows 95 und hat mit dem Kernel erstmal nichts zu tun. Es entstand AFAIK aus den VBX Komponenten, die es schon unter Win3 gab.

Es hat auch nichts mit Systemservern (mir ist nicht ganz klar was das sein soll) oder vor allem Hardwarezugriffen zu tun. Und es ist auch nicht rausgeflogen, im Gegenteil: mit Windows RT hat MS es sogar wieder bevorzugt gegenüber .NET. Weil es resourcenschonender ist als .NET auf ARM Prozessoren.

Hardwarenahe und Systemprogrammierung ist AFAIK auch bis heute in Windows eine reine C-Angelegenheit.

COM ist zuerstmal ein Standard zur Definition von Objekt orientierten Schnittstellen. Ob mit oder ohne IPC. Außerhalb des MS Universums hat es aber wenig Unterstützung gefunden. Das einzig mir bekannte Projekt welches es auch nutzt ist VST3, ein Standard für Audio Plugins.

Inwiefern das nun deine Produktentscheidung beeinflusst kann ich nicht sagen.

[reinerdoll]

schluck. jetzt zitiere ich mal sinngemäß aus meinen gut 30 jahre alten betriebssystem-vorlesungsskripten :

win nt war modular aufgebaut. oben user, unten kernelmode (protected mode-ringe vom intel-prozl). zugriff auf unten ist user-software nicht möglich, also muß bei hw-zugriff ein systemserver im kernel um hilfe gebeten werden. die schnittstelle zu den (objektorientiert geschriebenen) systemservern
(manchmal auch -services) ist die com-definition. verteilt auf tcp/ip wird draus dcom.

-------------

trotzdem eine frage, deren antwort mich vielleicht beim spielen mit ironpython ein stück weiter bringt :

Code: Alles auswählen

import sys
import clr
from System import Type, Activator

test = Activator.CreateInstance(Type.GetTypeFromProgID('Scripting.FileSystemObject'))
test.createtextfile('g:\\bloed3.txt')

client = Activator.CreateInstance(Type.GetTypeFromProgID('OpcLabs.EasyOpc.UA.EasyUAClient'))
ready = client.ReadValue('opc.tcp://62.245.200.166:7','ns=2;s=zulieferer.sps.Status')
print("ready =" ,ready)

Der Zugriff auf den WSH funktioniert. Das Einbinden der OPC-Library läuft offenbar fehlerfrei.
Aber : "ReadValue" wird nicht als Methode erkannt, sondern Fehlermeldung : "dieses Attribut gibts nicht"

In ActivePython geht das aber. Es kann doch kein fehlendes Modul sein, wenn das Einbinden ja läuft ... ???

[Sirius3]

@__deets__: Windows-NT ist älter als Windows 95.
@reinerdoll: da COM und Windows-NT erst 1993 eingeführt worden ist, kann es noch nicht in 30 Jahre alten Vorlesungsskripten stehen, zumal das was da steht falsch ist.

COM ist eine objektorientierte Schnittstelle zur Interprocesskommunikation, und Nachfolger von OLE. DCOM erweitert diese Schnittstelle noch um Inter-Computer-Kommunikation. VBX, ActiveX und der ganze Kram sind im wesentlichen DLLs, die im selben Prozess wie das Hauptprogramm läuft, hat also nichts mit COM zu tun. COM ist eine sprachunabhängige Schnittstelle, DCOM wird mit der üblichen Windows-Userrechte-Verwaltung verwaltet, also ist genauso sicher wie Windows an sich sicher ist.

Windows-NT ist und war nie rein objektorientiert. Um mit dem Kernel zu kommunizieren kommt daher auch kein COM zum Einsatz.

.NET ist wiederum einfach nur eine Virtuelle Maschine, in direkter Konkurrenz zu Java. Und natürlich bringt das wieder seine eigene Variante von objektorientierter Interprozesskommunikation mit.

Während also die nativen Möglichkeiten von .NET (oder Java oder ähnlichem), relativ leicht von anderen .NET-Programmen nutzen lassen, gibt es Probleme, wenn man verschiedene Systeme mischen will.

COM ist sprachunabhängig und damit von allem, was unter Windows läuft, nutzbar. Weil jede Sprache eine andere Interpretation von Objektorientierung hat, ist eine allgemeine objektorientierte Schnittstelle an sich immer nur ein halber Kompromiss.

[__deets__]

COM ist eine objektorientierte Schnittstelle zur Interprocesskommunikation, und Nachfolger von OLE. DCOM erweitert diese Schnittstelle noch um Inter-Computer-Kommunikation. VBX, ActiveX und der ganze Kram sind im wesentlichen DLLs, die im selben Prozess wie das Hauptprogramm läuft, hat also nichts mit COM zu tun.

Stimmt so nicht. COM *kann* IPC-basiert sein (bis hin zu DCOM), muss und ist es aber nicht notwendigerweise. Oft werden COM Bibliotheken NICHT als Client/Server eingebunden, sondern ebenfalls im gleichen Prozessraum. Und AFAIK ist es durchaus so gewesen, dass VBX das sich quasi versehentlich zu einem eigenen Markt für Komponenten gemausert hat, Vorbild für die Entwicklung von COM war. Und stellt darum auch die technische Grundlage der von dir angesprochenen ActiveX Implementierung dar. Hat also sehr wohl etwas mit COM zu tun.

Genannt wird das immer Client Server. Finde ich missverständlich, aber ist halt deren Lingo.

Und laut https://de.m.wikipedia.org/wiki/Component_Object_Model ist es sogar schon unter Windows 3 eingeführt worden.

@reinerdoll dein eigentliches Problem ist für mich schwierig zu überblicken. Denn neben der rein technischen Umsetzung (die sich früher oder später ergibt) ist eine solche Migration ein komplexes Thema. Ob es besser ist, einen Schnitt zu machen, oder zu versuchen eine integrierte Welt aufzubauen ist eine der ganz großen Fragen für deren jeweilige Beantwortung und Folgen man positiv und negativ Beispiele in großer Menge findet.

Mein Gefühl sagt mir das der Versuch, VB und Python zu mischen in die Hose geht. BlackJack hat schon verargumentiert warum: VB Schnittstellen in Python fühlen sich ggf. unnatürlich an. Besser wäre es, deine Hilfsbibliothek mit einer in Python geschriebenen zu ersetzen. Und die COM-Ebene da zu belassen, wo sie schon jetzt für dich funktioniert.

[reinerdoll]

ok, ich lerne viel hier, wenn auch auf die harte tour

laßt mich noch eine aussage zur prüfung vorlegen :

wenn ich mit ner methode aus dem wsh (z.b. "opentextfile" oder so) auf das sysgtem zugreife, nutze ich dieselben mechanismen (=methoden) wie die grafische oberfläche (maus usw.). ich arbeite also mit einem teil des betriebssystems (benutze einen systemdienst, auch systemserver).

richtig oder falsch ?

[reinerdoll]

@_deeds_ :

"Besser wäre es, deine Hilfsbibliothek mit einer in Python geschriebenen zu ersetzen. Und die COM-Ebene da zu belassen, wo sie schon jetzt für dich funktioniert."

sehe ich eigentlich genauso, aber habe 2 schwierigkeiten :

a) wie schreibe ich in einer interpretersprache eine lib ? (in vb erzeugt mir der compiler sehr komfortable direkt die dll.)
b) die verdammte library des rfid-herstellers (eine .exe) krieg ich in python nicht zum laufen

[__deets__]

Ultimativ benutzt du natürlich immer System-Aufrufe. Dienste oder Server sind aber etwas das du jetzt schon mehrfach eingebracht hast, was ich so nicht stehen lassen würde. Darunter verstehe ich einen expliziten laufenden Prozess. Das ist aber für ganz vieles, und insbesondere dein Beispiel, NICHT so. Filezugriffe brauchen keinen Dienst.

Der Indexer, der die file-basierte Suche ermöglicht (Cortana in Win10) ist ein Dienst. Da kann es sein, dass man eine IPC-Schnittstelle wie COM benutzen muss. Das müsste man konkret ermitteln.

[__deets__]

a) wie schreibe ich in einer interpretersprache eine lib ? (in vb erzeugt mir der compiler sehr komfortable direkt die dll.)
b) die verdammte library des rfid-herstellers (eine .exe) krieg ich in python nicht zum laufen

a) gar nicht. Das ist nicht vorgesehen in Python, und wozu soll es gut sein? Das würde nur Sinn machen, wenn du Python als Zwischenschicht für etwas nutzen willst, das wieder nicht Python ist. Womit dieselben Probleme auftauchen wie mit VB als Zwischenschicht. Was du natürlich tun kannst ist ein Python Modul/Paket zu erstellen, mit dem du oft genutzte Funktionen wiederverwendet. In Python.

b) das kann ich so nicht beurteilen. Ich dachte diverse hats du ans laufen bekommen?

[reinerdoll]

"Filezugriffe brauchen keinen Dienst."

afaik (hab ich erst googlen müssen ist aus der user-mode schicht kein hw-zugriff möglich. ich brauche immer einen systemserver, der dann die festplatte oder wo die datei immer ist, zugreift. war das konzept bei nt, um das system sicherer / stabiler zu machen. damals wurde viel geschimpft, weil das mit ner schwachen hw natürlich sehr auf die performance geht, was die gamer sehr schlecht finden.

[__deets__]

Das ist halt falsch. Es IST kein Server. Man kann natürlich mit einem sehr großen Spachtel alles was das Betriebssystem anbietet als Service an die Tafel schmieren - das ist aber sehr grob und nicht korrekt.

Du rufst C-Funktionen der Win32-API auf. Manche davon tun simple Dinge, andere komplexere für die sie ggf. länger brauchen und diverse Unterschritte machen, die mit anderen Prozessen synchronisiert werden. Und ein paar greifen schlussendlich wieder auf "echte" Server zurück, wie den Window-Server.

Der Zugriff auf Hardware ist orthogonal dazu. Auch unter dem AMIGA oder alten Macs ist das verpönt. Weil es bedeutet das sich Anwendungen gegenseitig zerschießen können. Heutzutage wird das durch den Kernel verhindert. Und man muss Treiber schreiben. Aber das ist immer noch "normaler" C-Code und hat mit Servern wenig zu tun.

[reinerdoll]

ich hab den quellcode der .exe gefunden, deren einbindung in python mir nicht gelingt.
es ist eine c# - datei, so gehts da los :

Code: Alles auswählen

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Net.Sockets;
using System.Runtime.InteropServices;

namespace DTE104_Driver
{

das hab ich dann compiliert als .exe vorliegen. in vb kommt es in die references, und schon kann ich damit arbeiten. in python (weder in iron- noch in active- keinerfolg...

[__deets__]

Daraus kann ich nichts ableiten. Sieht aus wie generischer C# Code. Das der in VB zur Vefügung steht mag sein, das wäre dann aber nur mit IronPython zugreifbar. Oder er implementiert ein COM-Interface, das kann man da aber nicht sehen.

Und das ist der RFID-Code vom Hersteller?

[reinerdoll]

"server"
ok, es geht wohl nur um begriffsdefinition. in meiner literatur liegen zwischen usermode und kernelmode die systemservices.
weil diese mit einem request angesprochen werden, und dann den gewünschten dienst ausführen, nennt sie mancher autor eben server.
alles was ich ansprechen kann und mir dann einen dienst erweist, ist in der basisdefinition von client/server halt ein server (responder).

mein grundproblem lag wohl eher darin, daß ich dachte, gelesen zu haben, daß die schnittstellendefinition dieser sysgtemservices früher com und dann seit win2000 oder so .net ist.


------------

in der treibersoftware vom hersteller ist dieser code drin, und das .exe file. wie wäre das in ironpython ansprechbar ... ich find einfach nix im web.

[__deets__]

Nach der Definition ist auch ein simpler Funktionsaufruf ein Server. Kann man so machen. Ist in meinen Augen dann bis zur Bedeutungslosigkeit beliebig.

Wie dem auch sei. Ich habe immer noch nicht verstanden, was da was ist. Der Code IST Teil der Exe, oder d Code benutz etwas, das die EXE zur Verfügung stellt?

Wenn letzteres, wie installiert man das? Gibt es in der registry Einträge, die auf eben diese EXE zeugen? Mit ClassIDs etc?