eigene .dll in Python

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

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
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

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
User
Beiträge: 72
Registriert: Samstag 15. Juli 2017, 18:47

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__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

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
User
Beiträge: 72
Registriert: Samstag 15. Juli 2017, 18:47

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.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Dein erster Satz stimmt nicht. Die Verbindung zu einem SQL-Server geschieht zwar ueblicherweise ueber IP, aber mit DCOM hat das noch lange nix zu tun. Theoretisch kann man natuerlich eine Datenbank per DCOM anbinden. Fuer alles ausser MsSQL ist das aber 100%ig nicht so. Und selbst da ist es denke ich auch nicht so, denn ODBC hat mit DCOM auch erstmal nichts zu tun.

Insofern bleibe ich dabei: OLE hat mit DCOM per se nix zu tun. Da DOCM transparent sein soll zu COM kann man sich vielleicht irgendwas ausdenken, bei dem man seine Komponente per DCOM hochfaehrt/anspricht. Aber das ist bestimmt nicht ueblich. Jedenfalls fuer OLE. Fuer andere Dienste wie MS Workflow Services (oder wie die heissen) mag das alles anders sein.

.NET als neuer Standard fuer IPC ist mir auch wieder etwas seeeehr stark auf einen kleinen Teilaspekt abgestellt. Eher wird andersrum ein Schuh draus: .NET ist eine neue Laufzeitumgebung mit diversen Sprachen, und fuer IPC hat man auch da auf was neues gesetzt.

Uebrigens IMMER einen Blick wert ist zu dem Thema SOAP das hier: http://harmful.cat-v.org/software/xml/soap/simple

Wir sind hier aber auch schon ziemlich bei den Korinthen :) Im groben stimmt das schon alles.
reinerdoll
User
Beiträge: 72
Registriert: Samstag 15. Juli 2017, 18:47

danke !
Antworten