XProfan

« Dieser Beitrag wurde als Lösung gekennzeichnet. »

- Seite 15 -

Jens-Arne
Reumschüssel

Es gibt eine neue Version, die anders mit dem internen Messagehandling umgeht. Bitte probier die mal aus. Vielleicht ist das Problem damit behoben.

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

24.09.2022 ▲

- Seite 23 -

Walter

Danke!

vor 13 Tagen ▲

- Seite 24 -

Jens-Arne
Reumschüssel

Ich habe mir jetzt den Funktionsaufruf der DLL nochmal genauer angesehen. In der readme-Datei steht:

?_Hash(Datei$ | bereich#,Algorithmus$[[,start&],size&])

Die Funktion "testit" wird nicht beschrieben, sie ist aber die einzige Funktion, die die DLL exportiert. Vermutlich ist der letzte Parameter "start&", denn sonst würde "0" keinen Sinn machen. In diesem Fall wäre eine Typumwandlung von chr$(0) in einen String-Pointer auf einen String mit einem Null-Byte tödlich, weil da irgendein riesiger Integerwert rauskommen würde (eben die Adresse auf den String). Eine Integer-Zahl wie "0" scheint daher die einzig sinnvolle Variante zu sein. Warum es mit DEF trotzdem funktioniert, ist mir ein Rätsel.

Vielleicht ist es genau andersherum: bei DEF wird nicht in einen String-Pointer umgewandelt, bei external schon. Wie auch immer, da sollte ein numerischer Wert stehen, kein String.

Gruß, Jens-Arne

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

vor 13 Tagen ▲

Walter

OK!
Habe 0 reingeschrieben - und es läuft!
Diese DLL habe ich auf der Erzeuger-Homepage www.paehl.de/ auch nicht mehr gefunden.
Da sie aber gut funktioniert, setze ich sie weiterhin ein.
Danke!

vor 12 Tagen ▲

Kompilieren Markieren Separieren

Jens-Arne
Reumschüssel

Probier mal dieses kleine Programm aus:


{$NoExternal2CallConversion}
{$NoDef2ExternalConversion}
{$SetFbDllName Test_fbprocs}

DEF fbTestProc2(1) !"Test_fbprocs.dll","FBTESTPROC@4"

fbPROC fbTestProc(byval i as integer) as integer Export
  return i
ENDPROC

cls
print "Direktaufruf: "+@str$(fbTestProc(chr$(0)))
print "via External: "+@str$(@external("Test_fbprocs.dll","FBTESTPROC@4",chr$(0)))
print "via Call: "+@str$(@call(@GetFbProcAddr("fbTestProc"),chr$(0)))
print "via DEF: "+@str$(@fbTestProc2(chr$(0)))
waitinput
end

Daran wird klar, dass alle Funktionsaufruf-Methoden immer korrekt nach interner Typumwandlung die Adresse eines Strings übergeben, der chr$(0) enthält, nur DEF nicht. DEF übergibt unkorrekt 0.

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

vor 11 Tagen ▲

Walter

Glaub Dir das voll!

Ausprobieren geht aber nicht, da sich das Ding im Präcompiler auf nimmer Wiedersehen verabschiedet.

Brauche ich dazu die Test_fbprocs.dll?

bild_2023-05-25_175200090.png	25 kB

Hochgeladen:	vor 9 Tagen

Ladeanzahl:
		Herunterladen

vor 9 Tagen ▲

Jens-Arne
Reumschüssel

Also das ist merkwürdig. Ich kann das problemlos starten, auch mit "<Tilde><Tilde>temp<Tilde><Tilde>.prf" als Dateiname. Daher wieder die zugegebenermaßen etwas hilflose Frage: Hast Du die neuste Version von JRPC3 benutzt? Sonst wüsste ich nicht, woran das liegen könnte. Und die Datei Test_fbprocs.dll wird ja gerade erst durch das Programm erzeugt, die musst Du also nicht vorher haben.

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

vor 8 Tagen ▲

Walter

Sooooo ... geschafft.

Problem war wahrscheinlich, dass ich die Source nicht gespeichert hatte (?).
Jedenfalls ist es nach dem Speichern nun gelaufen - und ich sehe das Ergebnis!

Jetzt muss ich mich noch mit freebasic beschäftigen, um auch eigene DLLs erzeugen zu können!

Doch gleich die nächste Frage

: Warum wird beim call-Aufruf ein anderes i zurückgegeben als beim Direktaufruf und beim external?
Sollte doch der Wert derselben Adresse sein?

bild_2023-05-27_174524520.png	4 kB

Hochgeladen:	vor 7 Tagen

Ladeanzahl:
		Herunterladen

Kompilieren Markieren Separieren

Jens-Arne
Reumschüssel

Nein, das ist der Trick dabei: Bei jeder Übergabe von chr$(0) wird von XProfan intern ein neuer String erzeugt und dessen Adresse übergeben. Direkt nach Rückkehr der DLL-Funktion wird der String mit Sicherheit sofort wieder freigegeben. Daher hat jeder Aufruf eine andere, zufällige String-Adresse.

Das ist sogar bei XProfan-Strings selbst der Fall. Jedes Mal, wenn Du einem String einen neuen Inhalt zuweist (selbst wenn es derselbe ist wie vorher), steht der String danach an einer ganz anderen Speicheradresse. Intern wird ja immer genau so viel Speicher angefordert, wie für die Länge des Strings erforderlich ist. Und da diese Länge variabel ist, wird das bei jeder Zuweisung neu vorgenommen. Deshalb ist das Arbeiten mit übergebenen Strings in fb-/pbPROCs so kompliziert, weil die Speicheradresse von Strings variabel ist, im Gegensatz zur Speicheradresse von z.B. Integer-Variablen.

Beispiel:

declare s$
cls
s$="123"
print @addr(s$)
s$="123"
print @addr(s$)
waitinput
end

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

Jens-Arne
Reumschüssel

Version 9.17a verfügbar:

{$WrapDlls} eingeführt. Damit werden die von fb-/pbPROCs erzeugten DLLs direkt in die XProfan-Exe-Datei integriert, sodass sie nicht mehr mitgeliefert werden müssen. Siehe Hilfe-Datei zu Kompilerdirektiven --> {$WrapDlls}.

Beste Grüße, Jens-Arne

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

Walter

Ok, danke für die Erklärung!

funkheld

Geht das bitte auch für Purebasic?

Danke.
gruss

XProfan 11

vor 4 Tagen ▲

Jens-Arne
Reumschüssel

Hallo funkheld,

ja. Man kann sogar FreeBasic und PureBasic nebeneinander benutzen, wenn man möchte. Dann werden mit {$WrapDlls} beide DLLs in das Profan-Programm eingebaut.

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de

vor 4 Tagen ▲