eigene .dll in Python

[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?

[reinerdoll]

sorry, bin halt nur laie.
der quellcode ist als visual-studio projekt vorliegend. enorm komplex in c# geschrieben.
dazu das schließlich compilierte .exe -file.

in vb kann ich nun das .exe in den resources im solution explorer einbinden, kann die lib mit imports erreichen, kann das objekt erstellen, und kann die methoden die da drin sind in vb nutzen.

wieso ich eine .exe einbinde wie eine .dll hab ich nicht verstanden, aber so gehts (ist ein beispielprojekt dabei..).

-> aber wie gehts in python ?? (am liebsten in active python, weil da der ganze rest den ich haben will auch funktioniert)

[Sirius3]

@reinerdoll: Dein Gebrauch von bestimmten Begriffen weicht stark von dem üblichen ab, so dass es schwierig ist, Dir zu folgen.

Um darin etwas Ordnung zu bringen:
1. es gibt native DLLs, die in einer Programmiersprache geschrieben sind, die direkt auf Maschinensprache compiliert werden und Funktionen anbieten. Praktisch alle Kernel-Funktionen sind über solche DLLs aufrufbar.
2. es gibt COM-Componenten, die zentral bei der Installation registriert werden und beim Aufruf entweder einen eigenen Prozess starten oder in den aktuellen Prozess importiert werden. Sie ähneln dann nativen DLLs, nur dass das Laden und Ansprechen nicht direkt über Funktionen stattfindet, sondern noch die COM-Schnittstelle dazwischen liegt.
3. es gibt .NET-DLLs, die aber außer der Endung nichts mit DLLs gemein haben. Das sind Module, die Klassen und Interfaces für andere .NET-Programme zur Verfügung stellen.
4. Python kennt auch Module, das sind aber ganz normale Python-Dateien, die man in andere Python-Programme einbinden kann. Da im Gegensatz zu .NET Compilierung und Ausführung bei Python ein Schritt ist, gibt es keine compilierten Module.

[reinerdoll]

wenn ich jetzt ne .exe in resources in vstudio angebe, ohne irgendwas zu installieren, kann es so gesehen keine com-komponente sein, weil die ja wie du schriebst registriert sein müßte.

könnte also eine "native dll" sein, also die .exe als ausführbarer maschinencode : ... wie rankommen in python ?

oder ein ".net - modul" : kann das auch .exe -format haben ? ironpython müßte es dann nutzen können, wenn ich die doku richtig gelesen habe ?


(der sprachunterschied rührt daher, daß ihr softwareprofis seid, und ich nur interessierter laie ohne praxiserfahrung !)

[__deets__]

Deine Schlussfolgerung ist nicht richtig. COM Komponenten können auch als EXE vorliegen. Hast du mal gemacht worum ich dich gebeten habe - in deine Registry geschaut?

[Sirius3]

@reinerdoll: wie Du schon geschrieben hast, ist Dein RFID-Leser in C# geschrieben, somit .NET-DLL mit aus welchen Gründen auch immer der Endung .exe. Damit müßtest Du sie in Ironpython benutzen können. Ansonsten scheint Dein RFID-Leser über TCP/IP angesprochen zu werden. Da Du scheinbar das Protokoll schon als C#-Programm vorliegen hast, ist die Übertragung nach Python nur Fleißarbeit aber kein Hexenwerk.