ASM Inline code x64

[venice2]

Zitat:

Ich vermute vom SOP.exe (Release Win32).

Ja.
Obwohl es zwei uMain gibt.
Aber jede für sich im eigenen Root incl. der erzeugten DCU.

Zitat:

Da der inline Assembler-Quelltext nicht unter 64-Bit kompiliert, schlägt dir der erste Fehler entgegen.

Hier darf aber kein Fehler auftreten denn SOP.exe muß mit dcc32 kompiliert werden.
Da ist die IDE bzw. der Compiler anscheinend zu dumm zu erkennen das es hier um 32Bit bzw.. eine Kombination von 32/64Bit geht.

In VS(Visual Studio) kann ich mehrere Konfigurationen festlegen x86/x64 usw.. dort wird jeweils der korrekte Compiler beim Kompilieren ausgeführt.
Nur mal so nebenbei.

Zitat:

Wenn du das SOP.exe-Projekt so umbaust, dass es theoretisch unter 64-Bit kompilieren würde, dann könnte es funktionieren.

Meine Vermutung ist ganz einfach das die Reihenfolge wie die Projekte kompiliert werden nicht stimmt bei aktivierter Abhängigkeit.
Erst muß diese und dann das aufgerufenen Projekt kompiliert werden. Das scheint aber nicht so zu sein.
Wenn ich doch weiß das mein Hauptprogramm ohne die Abhängigkeit nicht funktioniert dann muß logischer weise erst diese erstellt werden damit
das Hauptprogramm überhaupt funktioniert. Aber bitte mit dem richtigen Compiler.

Es ist doch nicht der Sinn des Programmierers Fehler beim erstellen von Konfigurationen für die Kompilierung der IDE\Compiler für Delphi auszubügeln
wenn hier solche Sachen auftreten das weder eine Abhängigkeit noch das erstellen einer Projektgroup verschiedener Builds (Konfigurationen) auftreten\nicht funktionieren.

Wie ich schon sagte..
Ich kann jedes Projekt eigenständig erstellen und es Kompiliert Fehlerfrei.
Aber nicht auf den oder die aufgezeigten von der IDE bereitgestellten Möglichkeiten.
Warum stellt man diese zur Verfügung wenn sie nicht funktionieren?

Ich hatte ja schon gefragt wie ich es umbauen könnte.
Leider kam diesbezüglich noch kein Vorschlag siehe..

Delphi-Quellcode:

procedure ClearPendingExceptions;
asm
  FNCLEX
end;

Scheint ja als eigene Procedure nicht zu funktionieren.
Nur warum funktioniert dann meine Rgb2Gray Funktion wenn "asm inline" angeblich unter 64Bit nicht funktioniert.
Sehr unverständlich das ganze.

Zitat:

ganz einfacher Test:

Danke! Obwohl ich jetzt nicht erkenne was du damit jetzt aussagen willst.
Das es falsch bzw. richtig ausgeführt wird in deinem Test?

Aus meiner Sicht läuft hier definitiv etwas ganz gehörig schief!

[himitsu]

Nja, vermutlich sind die Abhängigkeiten eher für sowas wie Packages gedacht, welche ja naturbedingt im selben System vorliegen.

[venice2]

Zitat von himitsu:

Nja, vermutlich sind die Abhängigkeiten eher für sowas wie Packages gedacht, welche ja naturbedingt im selben System vorliegen.

Möglich nur dann sollte man das dem Developer mitteilen so das er es gar nicht erst versucht. Traurig das ganze.
Nur wenn ich mit DLL's arbeite werden diese ja auch als Abhängigkeit addiert.

Fazit daraus..
Abhängigkeit scheint nicht gleich Abhängigkeit zu sein.
Es steht hier nicht das Abhängigkeit ausschließlich für Bibliotheken vorgesehen sind.

[himitsu]

siehe mein kleines Beispiel


Gut ist erstmal, dass die Settings der DPROJ verwendet werden, aber halt die aus der falschen Plattform.
Nur dass die Platform-Config ja hier nicht vorhanden ist und somit wird zumindes deren Vorfahre genutzt.


Aber noch schlimmer, es wird "teilweise" auch die falsche Config (Build) verwendet.
Und selbst wenn ich Erzeugen (Build), wird nur kompiliert (compile) und dann doch die falsche Config genutzt (vorher kompilierte DCU).

[venice2]

Zitat von himitsu:

siehe mein kleines Beispiel


Gut ist erstmal, dass die Settings der DPROJ verwendet werden, aber halt die aus der falschen Plattform.
Nur dass die Platform-Config ja hier nicht vorhanden ist und somit wird zumindes deren Vorfahre genutzt.


Aber noch schlimmer, es wird "teilweise" auch die falsche Config (Build) verwendet.
Und selbst wenn ich Erzeugen (Build), wird nur kompiliert (compile) und dann doch die falsche Config genutzt (vorher kompilierte DCU).

Ja aber das ist doch ein Problem von Delphi nicht eins vom Entwickler.

[jaenicke]

Das ist schon korrekt so. Und normalerweise ist es auch das, was man möchte. In deinem Fall leider nicht.

Ich habe eine Projektgruppe mit einer Exe und diversen DLLs. Diese kompiliere ich mal für 64-Bit und mal für 32-Bit. Deshalb sind die DLLs als Abhängigkeiten der Exe definiert. Auf die Weise kann ich einfach die Zielplattform der Exe auf 32-Bit oder 64-Bit stellen und die DLLs werden dazu passend erstellt.
Ansonsten müsste ich ja die Zielplattform jeder einzelnen DLL korrekt einstellen...

Der Anwendungsfall, dass man eine Abhängigkeit mit einer anderen Bittigkeit hat, dürfte recht selten sein...

Trotzdem wäre es eine Möglichkeit, dass erkannt wird, wenn ein Projekt gar nicht für 64-Bit konfiguriert ist, sprich diese Zielplattform nicht hat. Damit könnte auch dieser Konstellation begegnet werden. Ich befürchte allerdings, dass das zu selten benötigt wird, so dass es nicht umgesetzt werden wird.

Die einzige Möglichkeit das herauszufinden ist einen entsprechenden Featurerequest zu erstellen. Ein Bug ist es nicht.

Was du machen kannst:
Rufe msbuild in einem Pre- oder Post-Build Ereignis deiner 64-Bit Exe manuell auf, um die 32-Bit Exe zu erstellen.

[venice2]

Zitat:

Ich habe eine Projektgruppe mit einer Exe und diversen DLLs. Diese kompiliere ich mal für 64-Bit und mal für 32-Bit.

Ist nicht meine ausgangs Situation daher.. sorry fehl am Platz dies als vergleich heranzuziehen.

Zitat:

Ein Bug ist es nicht.

Bin ich anderer Meinung.

Wenn eine Funktion innerhalb der IDE zur Verfügung gestellt wird und diese nicht funktioniert ist es ein Bug.
Ich erhalte nicht umsonst Fehlermeldungen auf Grund meiner Konstellation.

Wenn ich eine Projektgruppe neu erstelle und das nicht Funktioniert btw. auf falsche *.DCU's hin kompiliert wird dann ist das ein Bug.
Kann man drehen und wenden wie man will.

Zitat:

Der Anwendungsfall, dass man eine Abhängigkeit mit einer anderen Bittigkeit hat, dürfte recht selten sein...

Trotzdem ändert es nichts daran das es funktionieren muß.
Tut es das nicht ist es ein Bug.

Zitat:

Das ist schon korrekt so.

Nein ist es nicht.

Kann man aber geteilter Meinung drüber sein.
Es ist nicht das was man eigentlich logischerweise erwartet.

Zitat:

Rufe msbuild in einem Pre- oder Post-Build Ereignis deiner 64-Bit Exe manuell auf, um die 32-Bit Exe zu erstellen.

Es geht nicht um eine lösungssuche oder eine andere Möglichkeit
sondern darum aufzuzeigen das beide Varianten nicht korrekt funktionieren.

Man schaue sich mein Video an.
Mehr ist da nicht zu sagen.

Wenn man versucht das irgendwie zu Entschuldigen, gut kann ich mit Leben
ändert aber nichts an der Tatsache das hier einiges im argen, nicht vollständig\funktionstüchtig ist.