ASM Inline code x64

[venice2]

Habe gelesen das man unter 64Bit ASM nicht in Inline code verwenden soll.
Wie kann ich dann diesen Block als Procedure auslegen? So das er inline verwendet werden kann?
Wenn möglich sollte es auch unter 32Bit funktionieren.

Delphi-Quellcode:

      FPWord := Get8087CW;
      Set8087CW(MCW_EM);

      if (not VisInfo^.VisPointer^.Render(VisInfo^.VisBuf, StretchWidth,
        StretchHeight, StretchWidth, @VisData)) then
      begin
        // der block
        asm
          FNCLEX
        end;
        // end block
        Set8087CW(FPWord);

        VisInfo^.Rendering := False;
        Exit;
      end;

      // der block
      asm
        FNCLEX
      end;
      // end block
      Set8087CW(FPWord);

Würde das reichen?

Delphi-Quellcode:

procedure ClearPendingExceptions;
asm
  FNCLEX
end;

Aktueller Fehler. 64Bit

Zitat:

[dcc64 Fehler] uMain.pas(513): E1025 Sprach-Feature wird nicht unterstützt: 'ASM'

Aber nur wenn ich die 32Bit exe als Abhängigkeit zuweise.
Zudem treten dann noch andere Probleme auf.

Zitat:

[dcc64 Fehler] uMain.pas(23): E2065 Ungenügende Forward- oder External-Deklaration: 'WinMain'
[dcc64 Fehler] uMain.pas(26): E2065 Ungenügende Forward- oder External-Deklaration: 'WndProc'

Delphi-Quellcode:

function WinMain(hInstance: HINST; hPrevInstance: HINST; lpCmdLine: PChar;
  nCmdShow: integer): integer; stdcall;

function WndProc(WinHandle: HWND; Msg: UINT; wP: WParam; lP: LParam): LRESULT;
  stdcall;

Warum treten dann diese Fehler auf?
Weil 32Bit.exe nicht kompatibel ist zu 64Bit.exe ??
Weshalb vertragen sich die Abhängigkeiten nicht.

Bei aktivierter Abhängigkeit tritt beim Start der Anwendung noch dieser Fehler auf

Zitat:

[dcc64 Fataler Fehler] SOP.dpr(10): F2048 Falsches Unit-Format: '_dcu\uMain.dcu' - Erwartete Version: 35.0, Windows Unicode(x64) Gefundene Version: 35.0, Windows Unicode(x86)

Wie kann es sein das der Compiler nicht erkennt das SOP eine 32Bit Anwendung ist bei aktivierter Abhängigkeit.
Auch ohne die Zuweisung der Abhängigkeit alle Projekte kompilieren tritt der Fehler auf
Da stimmt doch was nicht!

[TurboMagic]

Nein, so geht das glaube ich nicht!
Mit ASM eingeleitete Blöcke dürften in x64 nicht
funktionieren.

Du musst glaube ich sowas machen:

Delphi-Quellcode:

Procedere DoIt; Assembler;
begin
  mov ax, 0; // nur ein Beispiel
end;

[venice2]

Zitat:

Zitat von TurboMagic (Beitrag 1502118)

Nein, so geht das glaube ich nicht!
Du musst glaube ich sowas machen:

Delphi-Quellcode:

Procedere DoIt; Assembler;
begin
  mov ax, 0; // nur ein Beispiel
end;

Ich habe leider keine Ahnung von ASM daher nutz mir eine Vermutung (Beispiel) nichts.. Sorry
Der Aufruf müßte also schon genau funktionieren.

FNCLEX müßte dann also nach Delphi übersetzt werden.
Oder die Procedure entsprechend angepaßt.

Trotzdem Danke!

Zitat:

Mit ASM eingeleitete Blöcke dürften in x64 nicht
funktionieren.

Diese Funktion unter 64Bit macht aber keine Probleme.
Wird anstandslos akzeptiert trotz Abhängigkeit (allerdings in einer DLL 64Bit)

Delphi-Quellcode:

function TSkinEngine.Rgb2Gray(RGBValue: COLORREF): COLORREF; stdcall;
asm
  movzx   edx, al
  imul    edx, 19595  //Red
  movzx   ecx, ah
  imul    ecx, 38470  //Greean
  shr     eax, 16
  imul    eax, 7471   //Blue
  add     eax, ecx
  add     eax, edx
  shr     eax, 16
  mov     ah, al
  shl     eax, 8
  mov     al, ah
end;

Verstehe wer will.

Also Basis Anwendung 64Bit funktioniert.
32Bit Anwendung ASM macht Probleme wenn ich diese als Abhängigkeit der 64Bit Anwendung zuweise.
64Bit DLL mit obiger Funktion geht ohne Probleme.

[himitsu]

"Assembler" als Schlüsselwort dürfte schon ewig keine Auswirkng mehr haben und wird vom Compiler quasi ignoriert.

Assembler wird mit ASM ... END angegeben.


InlineASM gibt es nur im Win32-Compiler (von Borland).

Überall in neuen Compilern war man (CodeGear/Embarcadero/Idera) zu faul sowas zu bauen.


Also dort wo Assember noch geht, da dann nur noch als komplette Funktion (abgesehn von Win32)
und für ARM scheinbar nirgendwo, also ausschließlich x86.
https://docwiki.embarcadero.com/RADS...ation_(Delphi)
https://docwiki.embarcadero.com/RADS...ten_Assemblers



Hast du DCUs im selben Ausgabeverzeichnis, für alle Platformen?

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1502122)

InlineASM gibt es nur im Win32 (von Borland).

Überall in neuen Compilern war man (CodeGear/Embarcadero/Idera) zu faul sowas zu bauen.


Also da wo Assember noch geht, da dann nur noch als komplette Funktion (abgesehn von Win32)
und für ARM scheinbar nirgendwo.
https://docwiki.embarcadero.com/RADS...ation_(Delphi)

Die Frage ist nur was hilft mir das jetzt weiter?

Zitat:

Assembler wird mit ASM ... END angegeben.

Habe ich.. siehe

Delphi-Quellcode:

        // der block
        asm
          FNCLEX
        end;
        // end block

Die Meldung die dann bei 32Bit kommt.

Zitat:

[dcc64 Fehler] uMain.pas(513): E1025 Sprach-Feature wird nicht unterstützt: 'ASM'

Zitat:

Hast du DCUs im selben Ausgabeverzeichnis, für alle Platformen?

Nein.
Diese sind getrennt in jeweiligen Root der Projekte im Ordner "dcu"

Zitat:

Also dort wo Assember noch geht, da dann nur noch als komplette Funktion (abgesehn von Win32)

Delphi-Quellcode:

function TSkinEngine.Rgb2Gray(RGBValue: COLORREF): COLORREF; stdcall;
asm
  movzx edx, al
  imul edx, 19595 //Red
  movzx ecx, ah
  imul ecx, 38470 //Greean
  shr eax, 16
  imul eax, 7471 //Blue
  add eax, ecx
  add eax, edx
  shr eax, 16
  mov ah, al
  shl eax, 8
  mov al, ah
end;

Funktioniert unter 64Bit.. sagte ich schon.

Zitat:

"Assembler" als Schlüsselwort dürfte schon ewig keine Auswirkng mehr haben

Verwende stdcall !

Das Problem sind die Abhängigkeiten.
Addiere ich SOP.exe (32Bit) zu den Abhängigkeiten der 64Bit Anwendung funktioniert das Kompilieren nicht mehr.
Mit den im ersten Beitrag angegebenen Fehlermeldungen.

[TiGü]

Zitat:

Zitat von venice2 (Beitrag 1502116)

Aktueller Fehler. 64Bit

Zitat:

[dcc64 Fehler] uMain.pas(513): E1025 Sprach-Feature wird nicht unterstützt: 'ASM'

Aber nur wenn ich die 32Bit exe als Abhängigkeit zuweise.
Zudem treten dann noch andere Probleme auf.

Ich verstehe diesen Punkt nicht.
Was genau machst du da? Wie weist du "die Abhängigkeit" zu?

[venice2]

Rechte Maustaste auf Projekt dann aus Menu "Abhängigkeiten.." anklicken. 32Bit Anwendung Checkbox aktivieren.

[TiGü]

Zitat:

Zitat von venice2 (Beitrag 1502149)

Rechte Maustaste auf Projekt dann aus Menu "Abhängigkeiten.." anklicken. 32Bit Anwendung Checkbox aktivieren.

Also das hier:
Anhang 54866

Das sind bei dir aber schon zwei verschiedene Projekte, richtig?
Jetzt nicht irgendwie merkwürdig in sich selbst abhängig?!

[venice2]

Zitat:

Das sind bei dir aber schon zwei verschiedene Projekte, richtig?
Jetzt nicht irgendwie merkwürdig in sich selbst abhängig?!

Was ist in sich selbst abhängig?

64Bit ist die Basis 32Bit die Abhängigkeit hatte ich aber schon geschrieben.

Bei dir wäre das Projekt1 die Basis und die andere die Abhängigkeit.
Ohne Projekt 2 würde Projekt 1 nicht korrekt funktionieren.

Wenn ich 64Bit kompiliere dann soll die 32Bit Anwendung ebenfalls kompiliert werden weil 64Bit abhängig von der 32Bit ist.
64Bit würde nicht korrekt funktionieren wenn die 32Bit nicht vorher kompiliert wurde.

Oder anders..
Wenn ich die Projektgruppe kompiliere tritt auch hier der gemeldete Fehler auf!
Kann gerne ein Video aufnehmen um es zu demonstrieren.

[TiGü]

Ja, bitte!

[venice2]

Zitat:

Zitat von TiGü (Beitrag 1502178)

Ja, bitte!

Danke für das Interesse..
Video im Archiv meine Cloud meldet leider Error 504

So wie ich das sehe läuft hier einiges falsch beim Kompilieren.
DCU's sind in unterschiedlichen Ordnern.
Und was soll das mit ASM bei 32Bit!

Ich kann die Anwendungen Fehlerfrei kompilieren aber nicht mit der Abhängigkeit oder über die Projektgroup.
Möchte herausfinden warum das so ist!

[himitsu]

Also doch die DCUs für 32 und 64 Bit im selben Verzeichnis :shock:


Ich denke mal die Abhängigkeiten verwenden den gleichen Compiler, wie er grade kompiliert wird.
Es kommt ja auch als Meldung, dass es der DCC64 ist.

Somit kannst du nur Abhängigkeiten mit dem gleichen Ziel nutzen.

Und warum ist deine 64-Bit-Anwendung von der 32-Bit abhängig?

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1502182)

Also doch die DCUs für 32 und 64 Bit im selben Verzeichnis :shock:

Bitte?

Verzeichnis 1 = ...\MyPhone64_SOP\_src\_dcu
Verzeichnis 2 = ...\MyPhone64_SOP\SOP\_src\_dcu

ist bei dir das selbe? Definitiv nicht!
Kann man das an den hochgeladenen Bildern nicht erkennen?

[himitsu]

Hatte geguckt und keinen Unterschied gesehn :duck:

[add] Ich weiß, dass der selbe Compiler genommen wird, egal ob Abhängigkeit nur eine Config für 32 Bit besitzt.

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1502185)

Hatte geguckt und keinen Unterschied gesehn :duck:

Zitat:

Und warum ist deine 64-Bit-Anwendung von der 32-Bit abhängig?

Weil die 32Bit Anwendung 32Bit DLL's verwaltet bzw. damit arbeitet.

Die 64Bit Anwendung schickt über WM_COPYDATA Befehle an die 32Bit Anwendung so das diese mit den 32Bit DLL's arbeiten kann.
Bekanntlich vertragen sich 64Bit Anwendungen nicht mit 32Bit DLL's.

Damit die 64Bit Anwendung korrekt funktioniert muß vorher die 32Bit kompiliert werden (falls dort etwas geändert wurde)
Und ohne die 32Bit Anwendung funktioniert die 64Bit nicht da hier eine Abhängigkeit zu dieser besteht siehe WM_COPYDATA!

Zitat:

[add] Ich weiß, dass der selbe Compiler genommen wird, egal ob Abhängigkeit nur eine Config für 32 Bit besitzt.

Dann liegt hier das Problem begraben.
Der Compiler sollte schon erkennen können ob innerhalb einer Projektgroup Unterschiedliche Konfigurationen 32/64Bit vorliegen.
Iczh kann diese ja alle einzeln kompilieren warum dann nicht auch in einer gruppe. Also Alle!

[himitsu]

Dann arbeite doch einfach mit BuildGruppen.

oder im BeforeBuild eine Prüfung (if not exist oder so) und abbrechen, wenn nicht da/aktuell.

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1502187)

Dann arbeite doch einfach mit BuildGruppen.

Es gibt viele Möglichkeiten inklusive einzelner Kompilierung aber darum geht es nicht.
Meine frage war nicht welche Möglichkeiten man noch hat sondern warum die von mir aufgezeigten nicht funktionieren.

Es ist unlogisch eine Option.. Alle Projekte zu kompilieren zur Verfügung zu stellen wenn es nicht funktioniert (Siehe Video)

Und warum können Abhängigkeiten nicht in einem Durchgang kompiliert werden letztendlich ist es nichts anderes als..
Kompiliere erst dies und dann das.

Sorge dafür das SOP.exe aktuell ist und kompiliere dann die 64Bit-EXE.

Zitat:

Es geht um die von der IDE bereit gestellten Funktionen (Möglichkeiten)
Abhängigkeiten hinzuzufügen sowie eine komplette Projektgruppe zu erstellen.
Wenn beides nicht funktioniert wie hier gezeigt was soll das ganze dann?

Wenn der Compiler in einer Projektgroup nicht erkennen kann das 32 und 64Bit Verwendung finden was soll dann der Kram.
Das ist ein Fehler des Compiler und oder der IDE.. und wenn dem so ist sollte man das schnellstens beheben.

[TiGü]

Zitat:

Zitat von venice2 (Beitrag 1502179)

Zitat:

Zitat von TiGü (Beitrag 1502178)

Ja, bitte!

Danke für das Interesse..
Video im Archiv meine Cloud meldet leider Error 504

So wie ich das sehe läuft hier einiges falsch beim Kompilieren.
DCU's sind in unterschiedlichen Ordnern.
Und was soll das mit ASM bei 32Bit!

Ich kann die Anwendungen Fehlerfrei kompilieren aber nicht mit der Abhängigkeit oder über die Projektgroup.
Möchte herausfinden warum das so ist!

Ich habe mir das Video angesehen.
Meine Frage dazu ist:
Ist die gezeigte uMain.pas mit den Assembler-Quelltext Bestandteil des MyPhone64.exe Projektes oder von SOP.exe?
Ich vermute vom SOP.exe (Release Win32).

Ich kann das Verhalten nicht ganz erklären, aber wie du auch im Video siehst, wird bei aktivierte Abhängigkeit von MyPhone64.exe zu SOP.exe zuerst der dcc64 aufgerufen, wenn du "Erzeugen" auf MyPhone64.exe aufrufst.
Erst dann wird in Folge der passende dcc32 für SOP.exe aufgerufen.
Da der inline Assembler-Quelltext nicht unter 64-Bit kompiliert, schlägt dir der erste Fehler entgegen.
Alles andere sind nur Folgefehler, weil nicht ordnungsgemäß geparst werden kann.

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

Code:

Checking project dependencies...
Building SOP.dproj (Release, Win64)
brcc32 command line for "SOP.vrc"
  c:\delphi\sydney\bin\cgrc.exe -c65001 SOP.vrc -foSOP.res
dcc64 command line for "SOP.dpr"
  c:\delphi\sydney\bin\dcc64.exe -$D0 -$L- -$Y- --no-config -B -Q -TX.exe -AGenerics.Collections=System.Generics.Collections;
  Generics.Defaults=System.Generics.Defaults;WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE -DRELEASE
  -E.\Win64\Release -Ic:\delphi\sydney\lib\Win64\release\DE;c:\delphi\sydney\lib\Win64\release;"\\NAS\Nutzer_Doku\User\Eigene
  Dateien\Embarcadero\Studio\21.0\Imports";c:\delphi\sydney\Imports;C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64;
  c:\delphi\sydney\include;c:\Projekte\Komponenten\develop\Finetech_VC;c:\Projekte\Komponenten\develop\Finetech_C;
  c:\Projekte\Komponenten\develop\Finetech_Design;c:\Projekte\Komponenten\develop\Finetech_Dialog;
  c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader;c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader\Pse;
  c:\Projekte\Komponenten\develop\Finetech_Public;c:\Projekte\Komponenten\develop\Finetech_Raize;c:\Projekte\Komponenten\develop\Finetech_Serial;
  c:\Projekte\Komponenten\develop\Finetech_SpaceNav;c:\Projekte\Komponenten\develop\Resources;C:\Delphi\Jedi\jcl\lib\d27\win64;
  C:\Delphi\Jedi\jcl\source\include;c:\Delphi\RaizeKonopka\Lib\RX10.4\Win64;c:\Delphi\FastMM;c:\Delphi\FastReport\LibD27x64;
  C:\Delphi\Jedi\jvcl\lib\D27\win64;C:\Delphi\Jedi\jvcl\common;C:\Delphi\Jedi\jvcl\Resources;"C:\Delphi\VirtualTreeview\Packages\RAD Studio
  10.4\Win64\Release";C:\Projekte\Komponenten\develop\Lib\D27\Win64\Release -LEC:\Users\Public\Documents\Embarcadero\Studio\21.0\Bpl\Win64 
  -LNC:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64 -NU.\Win64\Release -NSSystem;Xml;Data;Datasnap;Web;Soap;
  -Oc:\delphi\sydney\lib\Win64\release;"\\NAS\Nutzer_Doku\User\Eigene Dateien\Embarcadero\Studio\21.0\Imports";c:\delphi\sydney\Imports;
  C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64;c:\delphi\sydney\include;c:\Projekte\Komponenten\develop\Finetech_VC;
  c:\Projekte\Komponenten\develop\Finetech_C;c:\Projekte\Komponenten\develop\Finetech_Design;c:\Projekte\Komponenten\develop\Finetech_Dialog;
  c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader;c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader\Pse;
  c:\Projekte\Komponenten\develop\Finetech_Public;c:\Projekte\Komponenten\develop\Finetech_Raize;c:\Projekte\Komponenten\develop\Finetech_Serial;
  c:\Projekte\Komponenten\develop\Finetech_SpaceNav;c:\Projekte\Komponenten\develop\Resources;C:\Delphi\Jedi\jcl\lib\d27\win64;
  C:\Delphi\Jedi\jcl\source\include;c:\Delphi\RaizeKonopka\Lib\RX10.4\Win64;c:\Delphi\FastMM;c:\Delphi\FastReport\LibD27x64;
  C:\Delphi\Jedi\jvcl\lib\D27\win64;C:\Delphi\Jedi\jvcl\common;C:\Delphi\Jedi\jvcl\Resources;"C:\Delphi\VirtualTreeview\Packages\RAD Studio
  10.4\Win64\Release";C:\Projekte\Komponenten\develop\Lib\D27\Win64\Release -Rc:\delphi\sydney\lib\Win64\release\DE;c:\delphi\sydney\lib\Win64\release;
  "\\NAS\Nutzer_Doku\User\Eigene Dateien\Embarcadero\Studio\21.0\Imports";c:\delphi\sydney\Imports;
  C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64;c:\delphi\sydney\include;c:\Projekte\Komponenten\develop\Finetech_VC;
  c:\Projekte\Komponenten\develop\Finetech_C;c:\Projekte\Komponenten\develop\Finetech_Design;c:\Projekte\Komponenten\develop\Finetech_Dialog;
  c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader;c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader\Pse;
  c:\Projekte\Komponenten\develop\Finetech_Public;c:\Projekte\Komponenten\develop\Finetech_Raize;c:\Projekte\Komponenten\develop\Finetech_Serial;
  c:\Projekte\Komponenten\develop\Finetech_SpaceNav;c:\Projekte\Komponenten\develop\Resources;C:\Delphi\Jedi\jcl\lib\d27\win64;
  C:\Delphi\Jedi\jcl\source\include;c:\Delphi\RaizeKonopka\Lib\RX10.4\Win64;c:\Delphi\FastMM;c:\Delphi\FastReport\LibD27x64;
  C:\Delphi\Jedi\jvcl\lib\D27\win64;C:\Delphi\Jedi\jvcl\common;C:\Delphi\Jedi\jvcl\Resources;"C:\Delphi\VirtualTreeview\Packages\RAD Studio
  10.4\Win64\Release";C:\Projekte\Komponenten\develop\Lib\D27\Win64\Release -Uc:\delphi\sydney\lib\Win64\release\DE;c:\delphi\sydney\lib\Win64\release;
  "\\NAS\Nutzer_Doku\User\Eigene Dateien\Embarcadero\Studio\21.0\Imports";c:\delphi\sydney\Imports;
  C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64;c:\delphi\sydney\include;c:\Projekte\Komponenten\develop\Finetech_VC;
  c:\Projekte\Komponenten\develop\Finetech_C;c:\Projekte\Komponenten\develop\Finetech_Design;c:\Projekte\Komponenten\develop\Finetech_Dialog;
  c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader;c:\Projekte\Komponenten\develop\Finetech_ElfSectionReader\Pse;
  c:\Projekte\Komponenten\develop\Finetech_Public;c:\Projekte\Komponenten\develop\Finetech_Raize;c:\Projekte\Komponenten\develop\Finetech_Serial;
  c:\Projekte\Komponenten\develop\Finetech_SpaceNav;c:\Projekte\Komponenten\develop\Resources;C:\Delphi\Jedi\jcl\lib\d27\win64;
  C:\Delphi\Jedi\jcl\source\include;c:\Delphi\RaizeKonopka\Lib\RX10.4\Win64;c:\Delphi\FastMM;c:\Delphi\FastReport\LibD27x64;
  C:\Delphi\Jedi\jvcl\lib\D27\win64;C:\Delphi\Jedi\jvcl\common;C:\Delphi\Jedi\jvcl\Resources;"C:\Delphi\VirtualTreeview\Packages\RAD Studio
  10.4\Win64\Release";C:\Projekte\Komponenten\develop\Lib\D27\Win64\Release -CC -NBC:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp\Win64 
  -NHC:\Users\Public\Documents\Embarcadero\Studio\21.0\hpp\Win64 -NO.\Win64\Release SOP.dpr  
[dcc32 Error] SOP.dpr(21): E1025 Unsupported language feature: 'ASM'
[dcc32 Warning] SOP.dpr(23): W1011 Text after final 'END.' - ignored by compiler
Failed
Elapsed time: 00:00:00.3

[himitsu]

ganz einfacher Test:

• neues VCL-Projekt / Projektgruppe
• dort ins FormCreate ein
  Delphi-Quellcode:

  ShowMessage(SizeOf(Pointer).ToString);

• weiteres Projekt hinzu
• da Win64 hinzufügen und aktivieren
• die Abhängigkeit zum ersten Projekt einrichten
• nun das letzte Projekt kompilieren
• jetzt im Ausgabeverzeichnis nach der ersten EXE suchen und starten

= wird in Debug/Win64 gefunden und zeigt 8 statt 4, obwohl es im Projekt nur das Profil für Win32 gibt.

Ich dachte erst, die Abhängigkeit liegt in der DPROJ und übernimmt so (ausversehn) die Config des Aufrufers.
In der DPROJ steht oben ja

XML-Code:

<Platform Condition="'$(Platform)'==''">Win32</Platform>

, also diese Einstellung wird nur genommen, wenn nicht von außen vorgegeben,
aber es kommt aus der GROUPPROJ und da könnte Delphi/InlineCompiler es anders/richtig machen.

[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:

Zitat von himitsu (Beitrag 1502219)

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:

Zitat von himitsu (Beitrag 1502223)

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.

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1502234)

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.

Das liegt daran, dass du (anders als im Standard) keine Platzhalter für die Plattform im Pfad verwendest.

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1502236)

Zitat:

Zitat von venice2 (Beitrag 1502234)

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.

Das liegt daran, dass du (anders als im Standard) keine Platzhalter für die Plattform im Pfad verwendest.

Das

Zitat:

<Platform Condition="'$(Platform)'==''">Win32</Platform>

ist unproduktiv da beide Projekte im gleichen Binären Order geschrieben werden müssen um die Anwendung testen\ausführen zu können.
Plattform-Pfade machen so keinen Sinn.

Es dürfte auch keine Rolle spielen ob Plattform oder statische Pfade verwendet werden.

Wie himitsu schon hingewiesen hat ist nur von Interesse wo die Dcu's abgelegt\erstellt werden.
Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

[jaenicke]

Ich meine ja auch den DCU-Ausgabepfad ("Ausgabeverzeichnis für Units"). Der sieht normalerweise bei einem neuen Projekt so aus, eben nicht ohne Grund:

Code:

.\$(Platform)\$(Config)

Wenn du das auch so machst, kann nie eine DCU im falschen Format (x64 / x86) gefunden werden.

Zitat:

Zitat von venice2 (Beitrag 1502237)

Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

Wie gesagt:
Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1502243)

Ich meine ja auch den DCU-Ausgabepfad ("Ausgabeverzeichnis für Units"). Der sieht normalerweise bei einem neuen Projekt so aus, eben nicht ohne Grund:

Code:

.\$(Platform)\$(Config)

Wenn du das auch so machst, kann nie eine DCU im falschen Format (x64 / x86) gefunden werden.

Zitat:

Zitat von venice2 (Beitrag 1502237)

Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

Wie gesagt:
Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

Spielt keine Rolle..
Ob diese

Zitat:

Verzeichnis 1 - MyPhone64_SOP\_src\Win64\Debug
Verzeichnis 2 - MyPhone64_SOP\SOP\_src\Win32\Debug

oder die Pfade verwendet werden.

Zitat:

Verzeichnis 1 = ...\MyPhone64_SOP\_src\_dcu
Verzeichnis 2 = ...\MyPhone64_SOP\SOP\_src\_dcu

Ergebnis bleibt das gleiche.
Es werden die gleichen Fehler wie vorher erzeugt.

Zitat:

Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

Wenn die Zielplattform 64Bit ist aber das zweite Projekt 32Bit in der gleichen Projektgroup dann ist das ein Fehler
sollte 32Bit mit dem 64Bit Compiler kompiliert werden. (Was anscheinend der fall ist)

Aber gut! Bin damit durch da der Fehler von meiner Seite aus nicht behoben werden kann.
Muß dann halt jedes Projekt für sich erstellen ist zwar dumm aber nicht zu ändern.
Kann selber nichts für ein Fehlerhaftes verhalten von Delphi.

[jaenicke]

Das Problem kann ich nicht nachvollziehen. Wenn ich die Platzhalter im Ausgabepfad habe, wird die 64-Bit Version der Unit korrekt im 64-Bit Pfad erzeugt und gesucht. Und wenn ich die 32-Bit Anwendung einzeln erstelle, wird die 32-Bit Unit auch im 32-Bit Ordner abgelegt. Das kann ich abwechselnd erstellen, es funktioniert, genau so wie es auch sein soll.

Der Fehler tritt bei dir ja auch auf, wenn du die Projekte einzeln erstellst. Da gibt es ja auch kein abweichendes Verhalten durch die Abhängigkeiten und es würde auch bei der normalen Umschaltung zwischen 32-Bit und 64-Bit auftreten. Wenn das nicht funktionieren würde, hätten das Problem sehr viele Entwickler.

Funktioniert es denn, wenn du die Projekte manuell der Reihe nach kompilierst?

[TiGü]

Zitat:

Zitat von venice2 (Beitrag 1502244)

Muß dann halt jedes Projekt für sich erstellen ist zwar dumm aber nicht zu ändern.

Mit Rechtsklick -> Kontextmenü auf die Projekt-Gruppe (oberster Node!) kann man alle Projekte mit einem Klick erstellen in ihrer aktuellen Platfrom- und Config-Zusammensetzung.

[jaenicke]

Das hat er gemacht, wobei dann der Fehler mit dem inkompatiblen Unit-Format kam. Mit korrekt konfigurierten Ausgabepfaden, sprich den Platzhaltern statt fester Pfade, dürfte das aber nicht passieren, weder mit Abhängigkeiten noch mit dem Erstellen aller Projekte in der Gruppe.

Aus der Ferne weiß ich aber nicht woran es liegt, dass die Meldung laut seiner Antwort ja trotzdem weiter kommt. Ich kann nur vermuten, dass da in den verschiedenen Buildkonfigurationen noch irgendwo falsche Pfade drin sind. Um das zu prüfen, bräuchte ich allerdings die aktuellen .dproj Projektdateien.

[venice2]

Zitat:

Zitat von TiGü (Beitrag 1502268)

Zitat:

Zitat von venice2 (Beitrag 1502244)

Muß dann halt jedes Projekt für sich erstellen ist zwar dumm aber nicht zu ändern.

Mit Rechtsklick -> Kontextmenü auf die Projekt-Gruppe (oberster Node!) kann man alle Projekte mit einem Klick erstellen in ihrer aktuellen Platfrom- und Config-Zusammensetzung.

Danke ist mir bekannt funktioniert aber nicht mit aktivierter Abhängigkeit.

Zitat:

Der Fehler tritt bei dir ja auch auf, wenn du die Projekte einzeln erstellst.

Nur bei aktivierter Abhängigkeit.

Zitat:

Das hat er gemacht, wobei dann der Fehler mit dem inkompatiblen Unit-Format kam. Mit korrekt konfigurierten Ausgabepfaden, sprich den Platzhaltern statt fester Pfade, dürfte das aber nicht passieren, weder mit Abhängigkeiten noch mit dem Erstellen aller Projekte in der Gruppe.

Ich bekomme 6 Fehler genau wie vorher.

Thema erledigt.
Kompiliere jedes Projekt für sich und gut ist.
Delphi ist unfähig in der Hinsicht was von mir über Weitergabe eines Videos Dokumentiert (bewiesen) wurde.