PureBoard

Der fehler muss wo anders liegen. Bei PB sind die String immer Null terminiert...

Ja, eben.

Vielleicht sollte der Ersteller der DLL mal ein paar vernünftige Fehlermeldungen ausgeben, oder alternativ eine Debug-Variante anbieten.

Hallo zusammen...

Ich bin der Autor dieser ominösen DLL. Zu meiner Verteidigung: Das Projekt ist erst ein paar Tage alt und bestimmt noch nicht Bugfree.

Spaß beiseite. Der Hintergrund und Areiz zu diesem Projekt ist, dass IPS, also die Server Applikation eine recht komplizierte SOAP Schnittstelle zur Vefügung stellt. Die Bedienung dieser Schnittstelle ist für viele Hobby Programmierer einfach ne Nummer zu groß und auch für "Eingefleischte" eher lästig. Die Idee vor ein paar Tagen war nun für möglichst viele Leute einen möglichst einfachen Wrapper zur Verfügung zu stellen. Darum liegen im Paket auch mehrere Demos in verschiedenen Sprachen. An einer c++ demo und einer c# Demo will ich mich als nächstes versuchen.

So, genug geschwafelt. Ein PAnsiChar (delphi) entspricht einem Pointer auf einen Nullterminierten String, einem LPCSTR, wie er in der Windowswelt auch genannt wird. Nach Helmuts, meinen und auch euren Bemühungen sehe ich das Problem mittlerweile aber nicht mehr an dem Parameter. Es muss irgend etwas anderes sein.

Bei einem c++ Konsolen-Beispiel bin ich über den MT-Compilerschalter gestolpert ohne den es nicht geht. Das SDK, dass ich wrappe, benötigt zwingend Multithreading. Dies scheint mir eine Hürde zu sein. Vielleicht kann dazu ein PureBasic-Spezi mal was sagen. Und verwendet PureBasic stdcall als Aufrufkonvention? Kann man ihm das explizit sagen, dass es das tun soll? Darüber konnte ich auch nichts in Erfahrung bringen.

Ich habe mir mal die PureBasic Demo angeschaut. Auch wenn ich schon vieles gemacht habe, muss ich gestehen, dass mir der Begriff "PureBasic" noch nicht untergekommen ist... Eine mit PureBasic erstellte EXE lässt sich irgendwie nicht als Host für meinen Debugger verwenden. Ich öffne meinen Quellcode, stelle meine PB-EXE als host ein, setze eine Haltemarke und klicke "run". Es blinkt einmal kurz und die exe beendet sich ohne an der Haltemarke angehalten zu sein. Witziger weise muss der code aber ausgeführt worden sein, den die Funktion WriteString gibt korrekterweise den Errorcode 102 (not connected) zurück. Die Exe ist auch sehr klein. Fehlen debuginformationen in der Exe? Kann man dem PB-Compiler sagen, dass sie benötigt werden?

Gruß,

Toni

In der Demoversion von PB kann man den Debugger nicht deaktivieren. Du hast also immer eine langsamere und groessere Executable. Die Debuginformationen in der Exe sind groesstenteils nur mit dem Debugger von Purebasic brauchbar.

Das es an der Kompileroption MT liegt, glaube ich nicht. Damit sagt man dem Kompiler ja nur welche Runtime er linken soll.
Ich hab oben ja schon geschrieben, das ich es mit C, C++ und PB versucht habe. Und selbst der C++ Code aus eurem Forum, wo steht das er funktioniert, konnte keine Verbindung herstellen.
Erstelle doch mal eine, wie von HeX0R bereits vorgeschlagen, Version die ein paar Infos in die Konsole schreibt.

der c++ code, den ich im IP-Symcon Forum gepostet hatte funktioniert schon. Liegt halt an den richtigen compilerswitches. Und da muss ich gestehen, bin ich nicht der Held (verwöhnt von teuren IDEs) . Hab den codeschnipsel dort mal durch ein Borland-Builder Projektfile erstetzt. dann funktioniert der selbe code 1a.

Ich weiss nicht genau was der MT switch unter PB tut. Aber die DLL macht zwei Threads auf und ohne MT Switch gehts unterm RAD Studio (C++) nicht. Ich werd Montag abendmal schauen ob ich ein brauchbares C++ Demo auf die Beine bekomm. PB teste ich dann auch direkt noch mal. Aber Basic und C sind nicht meine Lieblinge

Toni

@Tonic1024,

danke das Du dich hier gemeldet hast.

Purebasic ist vielleicht auch eine gute Methode um auf Industrie-Standard-DLL und auf CDecl-DLL zu prüfen.
Bis jetzt hatte ich noch keine Probleme mit DLL`s gehabt. Kann sein das bei Deiner DLL in AttachProcess oder AttachThread etwas falsch läuft und somit in unterschiedlichen Instancen läuft.

Nur eine Vermutung wegen den MT-switch


Alles Gute noch für Dein Projekt. Eine einfache SOAP-Schnittstelle können bestimmt einige sehr gut gebrauchen.

FF

Ich muss gestehen, dass ich mich noch nie großartig um Aufrufkonventionen und Compilerswitches gekümmert habe. Da ich Berufs-Progger bin bin ich mit meien Werkzeugen gewohnt, das es "einfach geht"

Da nicht geplant ist das Projekt auf Linux oder Mac zu portieren hielt ich es für eine gute Idee WinAPI Standard, mit der ich etwas mehr Erfahrungen habe, als Grundlage, bzw Vorbild, zu verwenden. Und da wird eben stdcall verwendet. Damit hab ich Erfahrung und "was der Bauer..."

Ich wundere mich ein wenig, dass ich bisher bei meinen demos überhaupt keine Schwierigkeiten hatte. Sogar in Excell (VBA) bekomm ich nen Connect hin. Nur Exoten, tschuldigung wenn ich das so formuliere, wie PB und Wald-und-Wiesen C- Compiler zicken. Für mich klingt es als wenn mit der DLL schon alles (zumindest grundlegend) in Ordnung ist aber irgend eine Kleinigkeit eingestellt werden muss.

Ich muss aber auch sagen, dass ich kein Spezialist auf dem Gebiet der Low-Level-Programmierung bin, so dass ich diesen Part, wenn ichs nich zeitnah in den Griff bekomme, gerne an Spezialisten und Freaks (und das ist in meinem Sprachschatz kein abwertender Begriff) abgebe.

Gruß,

Toni

Es ist eigentlich egal ob stdcall oder cdecl, PB bietet beides an. PB eignet sich eigentlich recht gut fuer solche Sachen, da sich das Programm wie jedes andere verhaelt. Bei deiner DLL schaffe ich es lediglich unter .NET (VB und C++) eine Verbindung herzustellen. Jeder andere "Wald und Wiesen" Compiler, wie gcc (MinGW), VC++ (Express-ob nun mit MT oder nicht), pellesc usw, schaffen das nicht. Irgendetwas fehlt da.
Vielleicht kannst du ja doch mal eine Debugversion deiner DLL erstellen, da reicht es auch erstmal wenn du nur die Connect Funktion einbaust.

PB ruft die Funktion im uebrigens richtig auf, da das Programm nach dem Verlassen abschmieren wuerde, weil der Stack nicht mehr stimmt. Auch wird der IP String wohl richtig uebergeben, zumindest sah es bei Olly so aus.

Hallo,
@Helmut ist ja ein richtiger Scherzkeks :

Es soll kein Ckient oder Server mit Purebasic-Befehlen aufgebaut werden, sondern ich möchte mit Hilfe einer DLL und Purebasic auf ein Server zugreifen.

Man will dir helfen und du bietest uns Minimalwerkzeuge an. Weißt du eigentlich, wie nervig es ist, den "umgestrickten" Webserver nach jeden Versuch zu starten. Den Link hättest du uns liefern müssen und er war auch nur indirekt für Dich bestimmt.
Wir, die helfen wollen, haben ja nur als Test einen Webserver oder erwartetst du, das wir erstmal deine elktronische Schaltung kaufen, damit "Helmut" sein Problem gelöst hat?

Ich will nicht abschweifen, es ging auch nur darum, welche "nützlichen Infos" der im Link angegebene Webserver ausgibt, das -uns- irgendwie weiterhilft. Könnte ja sein?

Zwischenzeitlich hat sich ja @Tonic1024,

Ich bin der Autor dieser ominösen DLL

gemeldet.

Ich gebe @mk-soft recht:

Der fehler muss wo anders liegen

@edel schreib:

Das es an der Kompileroption MT liegt, glaube ich nicht

@Tonic1024 informiert uns:

Bei einem c++ Konsolen-Beispiel bin ich über den MT-Compilerschalter gestolpert ohne den es nicht geht. Das SDK, dass ich wrappe, benötigt zwingend Multithreading. Dies scheint mir eine Hürde zu sein.

Genau hier ist der Hase im Pfeffer begraben.
@Tonic1024 linkt CRT-Bibliothek und MFC-Bibliotheken zusammen und ohne diesen besagten Switch bekommt er höchstwahrscheinlich eine Fehlermeldung, die auch folgenden Textinhalt haben kann:

"(??2@YAPAXI@Z) already
defined in LIBCMTD.lib(new.obj)

Benutze ich nun diesen "ominösen MT-Compilerschalter", gibt es keine Fehlermeldung mehr.
Aber was bewirkt dieser Schalter?
Er linkt anstatt die MSVCRT.lib, die standardmäßig verwendet wird, die LIBCMTD.lib
Ruft man jetzt Funktionen in beiden Lib´s auf, werden beide Lib´s selbstverständlich mit eingebunden.
Nun haben wir ein Problem. Die Lib´s dürfen nur in einer bestimmten Reihenfolge hinzu gelinkt werden.
Erst die MSVCRT.lib, dann die Restlichen, dann funktioniert es auch ohne diesen "ominösen MT-Compilerschalter".
Jetzt muß man nur aufpassen, das man nicht diese Einstellung benutzt: _STATIC_CPPLIB .
Dann hat man wieder den gleichen Effekt: er linkt die LIBCMTD.lib und nicht die MSVCRT.lib

Ich hoffe, mit diesen Hinweisen kann @Tonic1024 eine funktionierende Multithread-Standard-DLL hier posten, mit der wir hier weiter testen können.

dysti hat geschrieben:Hallo,
@Helmut ist ja ein richtiger Scherzkeks :

Es soll kein Client oder Server mit Purebasic-Befehlen aufgebaut werden, sondern ich möchte mit Hilfe einer DLL und Purebasic auf ein Server zugreifen.

Man will dir helfen und du bietest uns Minimalwerkzeuge an. Weißt du eigentlich, wie nervig es ist, den "umgestrickten" Webserver nach jeden Versuch zu starten. Den Link hättest du uns liefern müssen und er war auch nur indirekt für Dich bestimmt.
Wir, die helfen wollen, haben ja nur als Test einen Webserver oder erwartetst du, das wir erstmal deine elktronische Schaltung kaufen, damit "Helmut" sein Problem gelöst hat?

Ich will nicht abschweifen, es ging auch nur darum, welche "nützlichen Infos" der im Link angegebene Webserver ausgibt, das -uns- irgendwie weiterhilft. Könnte ja sein?

Ist meine Aussage, mit der Verwendung, falsch gewesen?

Ich hätte erst den "schaltbaren" Servercode aus dem Jahre 2006, den du gelinkt hast, auf die aktuelle Version bringen sollen, obwohl ich Den nicht brauche, weil das Beispiel aus der PB-Hilfe mit eingeschalteten Debug auch geht?

Ist irgentwo die Rede von elektronischen Schaltungen und kann man meine kaufen?

Sei mir nicht böse und ich bin dir dankbar, dass du hilfst, aber diese Aussagen ist nur eine Erklärungsnot für dein anfängliches "nicht verstehen".

Was ich auch noch nachvollziehen kann, dafür entschuldige ich mich.

Aber was schriebst du noch.... ich schweife ab.......

Gruß ... und.....Danke für deine Tips, die hoffentlich Toni helfen.
Helmut

Edit: Bemerkung gelöscht.