eigene .dll in Python

[__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.

[reinerdoll]

@ deets : ja, aber nichts gefunden.
die externe library für den opc-zugriff finde ich in der registry,
aber die .exe für den rfid-controller ist mit der suchfunktion in der registry nicht aufzuspüren.

imho ist das opc-dings also vermutlich eine com-komponente, die rfid-treiberdatei aber nicht.


@sirius : das mit der fleißarbeit ist so ne sache, der c#-quellcode hat über 2500 zeilen.

du schreibst, als .net-dll sollte sie nutzbar sein. mit syntaxvarianten aus dem web hab ich das bisher nicht hingekriegt.

[BlackJack]

@reinerdoll: Wenn das aus dem C#-Compiler rauskommt, dann ist es keine native EXE, sondern eine .NET-EXE. Wenn man den Code darin auch von anderen .NET-Programmen aus nutzen kann, dann wird so eine .NET-EXE wohl auch wie eine .NET-DLL nutzbar sein. Ist ja letztlich auch das selbe drin: .NET-Bytecode, nur das bei der EXE noch ein nativer ”Stub” davor steht der die .NET-Laufzeitumgebung startet um den Bytecode in der EXE auszuführen, damit man die EXE so starten kann als wäre es eine normale/traditionelle EXE.

Wenn es die Möglichkeit gibt, dass Du irgendetwas hast/brauchst was es nur für .NET gibt, jetzt oder in der Zukunft, dann müsstest Du jetzt erst einmal abklären ob und wie man das von CPython aus benutzen kann, ansonsten bist Du dadurch auf IronPython festgelegt. Es gibt für CPython so etwas wie JPython für .NET: Python for .NET.

Noch mal zur Motivation: VB ist auf einem absteigenden Ast? Dann nimm doch C#. Ich glaube ich hatte es schon mal geschrieben: VB ist seit VB.NET doch eh nur eine andere Syntax für C# damit man die ganzen alten VB6-Programmierer zu .NET rüberholen konnte. Ich denke nicht das Microsoft VB.NET in absehbarer Zeit einstampfen wird, also ist das auch nach wie vor noch eine ”sichere” Sache.

[reinerdoll]

Ich hoffe ich nerve nicht. ich hab jetzt hier schon ne menge über com und .net und so gelernt, deshalb noch eine frage :

ich habe folgende .net standard-dll (in vb geschrieben) :

Code: Alles auswählen

Public Class Class1
    Public a As Integer
    Public Sub doppel()
        a = a * 2
    End Sub
End Class

die ich so versuche in python zu nutzen (kein com-objekt erzeugt !) :

Code: Alles auswählen

from ctypes import *
objekt = cdll.LoadLibrary("C:\\experimente\\doppeltest1\\doppeltest1\\bin\\Debug\\netstandard1.4\\doppeltest1.dll")
objekt.a = 2
objekt.doppel()
print(objekt.a)

(ich weiß, fast das gleiche hatte ich schon mal)
jetzt aber die frage nach einem detail : wenn ich den methodenaufruf objekt.doppel() rausnehme, klappt das, ich kann mit dem attribut doppel.a arbeiten. der methodenaufruf aber klappt nicht. wieso das attribut, aber nicht die methode ??

[Sirius3]

@reinerdoll: mit ctypes kann man keine Klassen importieren. Man kann nur einfache Funktionen aufrufen. Dass das mit .net-DLLs überhaupt geht, hatte ich bisher nicht gewußt, aber hier wurde ich fündig. Dass Du dem Objekt `objekt` Attribute hinzufügen kannst, liegt daran, dass Python dynamisch ist, hat aber nichts mit dem Attribut `a` Deiner VB-Klasse zu tun.

[reinerdoll]

kann ich in vb ne function "doppel" schreiben, die ich dann mit ctypes.CDLL aufrufen kann ?

[__deets__]

Das wuerde mich wundern. Eben weil das C-FFI (foreign function interface, also Aufrufkonvention wie man C-Funktionen anspricht) NICHT ausreichend ist fuer objektorienterte Programmierung, hat MS COM erfunden. Das VB da ploetzlich von Abweicht waere ueberraschend. Wenn es das taete, ginge es auch nur fuer sehr eingeschraenkte Faelle.

Du kannst unter Windows das Programm DUMPBIN.EXE verwenden, um dir anzuschauen, was eine DLL alles enthaelt.

http://embeddedguruji.blogspot.de/2015/ ... orial.html

Da kannst du ja sehen, ob dein "doppel" vorkommt. Ich wuerde da aber nicht die Luft anhalten.

[Sirius3]

In der von mir verlinkten StackOverflow-Antwort wird eine statische C#-Funktion exportiert, weiß nicht, ob das mit VB auch geht, das ist ja in der Hinsicht sehr eingeschränkt. Klassen und Klassemethoden kann man, wie schon geschrieben, auf diese Weise nicht benutzen.

[reinerdoll]

auch auf die gefahr hin, daß einer schimpft weil das so off-topic ist : die grundlagen sind mir wichtig.

also nochmal nach ausführlicher recherche zu COM und .net :

COM war mit win3.1 der microsoft-standard für interprozesskommunikation im system. objektorientiert.
DCOM war dann die basis für ole und so, also vereinfacht gesagt COM auf tcp/ip ausgedehnt.
es war damals schon möglich, COM-objekte selber zu schreiben.
u.a. wegen security-problemen, aber auch weil einfach zu viele schräge ports nötig waren, hat sich COM nicht als allgemienstandard durchgesetzt. viele industrieableger ( opc da, profinet cba) sind deswegen in schwierigkeiten gekommen.

.net war dann die antwort, neben der reinen interprozesskommunikation (auf soap umgestellt) kommt damit dann auch eine große plattform für softwareentwicklung, vor allem eine riesen klassenbibliothek für systemnahe programmierung. dazu sprachen, deren compiler (oder interpreter) keinen klassichen objectcode erzeugen, sondern auf laufzeitumgebungen (clr) zielen.

-> richtig oder bodenloser quatsch ??

[__deets__]

Nicht Quatsch, aber auch nicht ganz richtig. DCOM hat mit OLE AFAIK nix zu tun, dafür reicht COM. Und das .NET nun so speziell eine Antwort auf DCOM war - das bezweifele ich auch. Klar, es sollte in vielen Beziehungen ein Neuanfang sein. Aber ich glaube da haben andere Aspekte überwogen. Und was das mit Profinet zu tun hat erschließt sich mir nicht so, aber da bin ich auch weit weg von.

[reinerdoll]

wenn in word ein serienbrief geschrieben wird (wurde, mit com) und die adressen aus nem sql-server kommen, dann brauchts dcom, um über tcpip zugreifen zu können.

profinet cba basiert im kommunikationskern auf dcom, genau wie opc da.
man liest, daß die beiden wegen der abkündigung von dcom tot sind.
die reaktion in opc war dann die spezifikation von opc ua, basierend auf soap(xml) oder binary tcpip.

im wesentlichen gehts mir auch darum, keinen blödsinn zu reden, wenns um .net und com geht :

com als ipc und dann auch als standard für win-programmierung, objektorientiert mit wmi, adsi und so als klassenbibliotheken.

.net als neuer standard für ipc, auf soap basierend, und dazu ne mächtige plattform für programmierung. mit laufzeitsystemen und fetten klassenbibliotheken und eigenen sprachen.