Programm-Code 64 Bit schreiben für Windows + Linux

[theo]

Aktuell entwickle ich unter Win/Lazarus 64bit und gehe ab und zu mal den Weg zu 32bit und zu Linux 32/64 um zu sehen, ob noch alles funktioniert, da sich doch oft Ungenauigkeiten einschleichen. ZB habe ich plötzlich wieder unter Linux eine Ergebnisdatei die 10Bytes kleiner ist als in Windows und wo die MD5 Summe nicht stimmt. Meine Werkzeuge unter Linux behaupten der Inhalt sei gleich. Sowas kriege ich dann nur unter Windows raus mit binären Editoren, für sowas bin ich unter Linux zu hilflos.

Könnte mit dem LineEnding zu tun haben. Aber ohne Kontext ist das nur eine Vermutung.
https://wiki.freepascal.org/End_of_Line

Und auf Linux sind einwandfreie Hex-Editoren dabei, wie z.B. Okteta.
Die muss man nur über die Paketverwaltung installieren.

[MmVisual]

Wegen der Frage nach einer seriellen Verbindung:

Schau mal nach "Synaser" von hier http://synapse.ararat.cz
Das habe ich schon erfolgreich in Linux und Windowsn eingesetzt. Einziger Unterschied ist die Bezeichnung der Ports COMx / ttyx

[PeterS]

Wegen der Frage nach einer seriellen Verbindung:
Schau mal nach "Synaser" von hier http://synapse.ararat.cz

Das Thema ist für mich "durch", die fertigen SerialPort Komponenten habe ich getestet,
und sie funktionieren für mich nicht, wie sie sollen.

[gelöst] SerialPort - TCommTimeouts - was einstellen ?
viewtopic.php?p=146695#p146695

=> "Ohne gesetzte Timeouts muss man natürlich mit mindestens einem secondary Thread arbeiten,
um den Input zu pollen .. sonst blockiert man sich den MainThread "

Seitdem ich die Dokumentation von Microsoft beachte in diesem Punkt,
komme ich prima aus ohne einen separaten Thread für SerialPort.

[alfware17]

Könnte mit dem LineEnding zu tun haben. Aber ohne Kontext ist das nur eine Vermutung.
https://wiki.freepascal.org/End_of_Line

Und auf Linux sind einwandfreie Hex-Editoren dabei, wie z.B. Okteta.
Die muss man nur über die Paketverwaltung installieren.

Ja hatte es... Und habe ich nun korrigiert. Ich lese TStringList zeilenweise in ein Blockwrite (ist bis zu 5x schneller als SaveToFile) und hatte kürzlich was optimiert. Im alten Puffer war schon #13#10 drin, im neuen eben LineEnd. Wenn man solche Konstanten schon liest sollten normal die Sturmglocken läuten, taten sie es bei mir aber nicht.
Normal lasse ich das eigentlich auch so betriebssystemspezifisch, nur leider (oder zum Glück) zählen LineEnds beim MD5 mit und wenn ich das mache, brauche ich halt #13#10 als Referenz.

[theo]

Ja hatte es... Und habe ich nun korrigiert. Ich lese TStringList zeilenweise in ein Blockwrite (ist bis zu 5x schneller als SaveToFile) und hatte kürzlich was optimiert. Im alten Puffer war schon #13#10 drin, im neuen eben LineEnd.

Nur der Vollständigkeit halber: Auch bei TStringList lässt sich das erzwingen:

StringList.TextLineBreakStyle:=tlbsCRLF;

[PeterS]

So, der SerialPort ist für die LINUX Variante meines Programms (erstmal) auskommentiert,
jetzt geht's an's Eingemachte

Daß alle Units KLEIN geschrieben werden müssen .. hab ich als WINDOWS Nutzer natürlich nicht.
Fällt mir jetzt bei JEDER meiner Units auf die Füße.

Und dann kommen die ersten Hürden - messages.inc - warum gibt's in LINUX kein

Code: Alles auswählen

lParamlo,
lParamhi : HALFPARAM;

Ist das Windows-spezifisch ?

=> von 2010:
https://forum.lazarus.freepascal.org/in ... pic=8923.0

"LParamLo is defined as Word and is used as such. In win64 LParam is a 64bit unsigned int, so LParamLo has no meaning there."

?? Code compiliert bei mir aber fehlerfrei mit Laz64 unter Windows 10 = Target Windows ???

[theo]

Das gelesen?
viewtopic.php?t=10370

[PeterS]

Das gelesen?
viewtopic.php?t=10370

Danke für den Tip !

Schau ich heut Abend gleich rein, und checke meinen Code.

[PeterS]

Das gelesen?
viewtopic.php?t=10370

Habe es grad gefunden, in lMessages.pp

Erklärt auch, warum es unter Laz64 mit Target Windows 32 und 64 funktioniert
Und mit Target UNIX / LINUX 64 nicht.

Code: Alles auswählen

{$ifndef windows}
  TLMessage = record
    Msg : Cardinal;
{$ifdef cpu64}
    UnusedMsg: Cardinal;
{$endif}
    case Integer of
      0 : (
        WParam: LclType.WPARAM;
        LParam: LclType.LPARAM;
        Result: LclType.LRESULT);
      {$IFNDEF CPU64}
      // on a 64 bit platform these make no sense
      1 : (
{$IFDEF FPC_LITTLE_ENDIAN}
        WParamLo: Word;
        WParamHi: Word;
        LParamLo: Word;
        LParamHi: Word;
        ResultLo: Word;
        ResultHi: Word);
{$ELSE}
        WParamHi: Word;
        WParamLo: Word;
        LParamHi: Word;
        LParamLo: Word;
        ResultHi: Word;
        ResultLo: Word);
{$ENDIF}
      {$endif}
    end;
{$else}
  TLMessage = TMessage;
{$endif}  

[PeterS]

Mit suchen kommt man weiter ..

Aus dem Jahr 2010:
viewtopic.php?p=40871#p40871

"PostMessage und Sendmessage sind in der LCL realisiert. Im der Windows "Widget-Type" sind das nur enkapsulierte API-Aufrufe an Windows. Im KDE "Widget-Type" sind sie als Delphi Code realisiert ..
...
Das ganze Ist also hochgradig nicht Plattform-unabhängig Über Verbesserungen wird immer wieder in den Lazarus und FPC Entwickler-Foren diskutiert, bisher aber ohne Ergebnis, da man den hohe Aufwand einer Änderung für diese selten verwendete Funktionalität scheut."


An den drei simplen Definitionen für "Nicht Windows" 64 hat sich also über die vielen Jahre nichts geändert.
???

Code: Alles auswählen

case Integer of
    0: (
        WParam: LclType.WPARAM;
        LParam: LclType.LPARAM;
        Result: LclType.LRESULT;
      );

[theo]

Dein Zitat sagt es ja:
"da man den hohen Aufwand einer Änderung für diese selten verwendete Funktionalität scheut."

Manchmal muss man etwas halt auf andere Weise lösen für Multi-Plattform.
Und manchmal muss man etwas Kontrolle abgeben und sich mit einem Kompromiss anfreunden..
So ist das halt.
Wenn man x-platform von Anfang an im Blick hat, geht es oft recht problemlos.

Aber eine Ausgangslage mit viel Winapi-zentrischem Code, kann schon etwas Kopfzerbrechen bereiten.

[PeterS]

Dein Zitat sagt es ja:
"da man den hohen Aufwand einer Änderung für diese selten verwendete Funktionalität scheut."

Manchmal muss man etwas halt auf andere Weise lösen für Multi-Plattform.
Und manchmal muss man etwas Kontrolle abgeben und sich mit einem Kompromiss anfreunden..
So ist das halt.
Wenn man x-platform von Anfang an im Blick hat, geht es oft recht problemlos.

Aber eine Ausgangslage mit viel Winapi-zentrischem Code, kann schon etwas Kopfzerbrechen bereiten.

Ich würde mal eher sagen, die haben keinen Bock, das umzusetzen.
Über die Motivation, das nicht umzusetzen für Linux, mag ich nicht spekulieren.
Die entsprechenen Threads, in denen das mal - und bestimmt heiß - diskutiert wurde, kenne ich auch nicht.

".. on a 64 bit platform these make no sense" ist meiner Meinung nach völlig falsch.
Wenn man im Auge behält, daß die LCL / Lazarus immer noch Dephi- und damit Windows-Gene trägt.

Es wäre mit {$ifdef cpu64}.. "Füll-bytes" {$endif} ohne weiteres möglich,
die alten Windows-Like Definitionen WParamHi, WParamLo etc.
für die Unix-Plattform zur Verfügung zu stellen.

Niemand wäre oder würde gezwungen, diese Definitionen unter Linux zu nutzen.

Code: Alles auswählen

{$ifndef windows}
  TLMessage = record
    Msg : Cardinal;
{$ifdef cpu64}
    UnusedMsg: Cardinal;
{$endif}
    case Integer of
      0 : (
        WParam: LclType.WPARAM;
        LParam: LclType.LPARAM;
        Result: LclType.LRESULT);
      {$IFNDEF CPU64}
      // on a 64 bit platform these make no sense
      1 : (
{$IFDEF FPC_LITTLE_ENDIAN}
        WParamLo: Word;
        WParamHi: Word;
        LParamLo: Word;
        LParamHi: Word;
        ResultLo: Word;
        ResultHi: Word);
{$ELSE}
        WParamHi: Word;
        WParamLo: Word;
        LParamHi: Word;
        LParamLo: Word;
        ResultHi: Word;
        ResultLo: Word);
{$ENDIF}
      {$endif}
    end;
{$else}
  TLMessage = TMessage;
{$endif}  

Also habe ich es passend für meine Zwecke selber gebaut, (hoffentlich richtig) mit

Code: Alles auswählen

...
var
  Msg_lParamhi : Word; // new 2025-11-27 - added for LINUX
  Msg_lParamlo : Word; // new 2025-11-26 - added for LINUX
begin   
  Msg_lParamhi:= word( dword( Msg.lParam) shr 16 and $0000FFFF); 
  Msg_lParamlo:= word( dword( Msg.lParam) and $0000FFFF);
  ...

Dann jedes Msg.lParamhi und Msg.lParamlo ersetzen mit Msg_lParamhi und Msg_lParamlo ist machbar.
Aber nicht schön.

[theo]

Ich würde mal eher sagen, die haben keinen Bock, das umzusetzen.

Die bist auch Du!
Wenn du was haben willst: Mach es und reiche einen Patch ein.
Das habe ich schon oft gemacht.
https://wiki.freepascal.org/Creating_A_Patch/de
https://gitlab.com/freepascal.org/lazar ... s/-/issues

[PeterS]

Ich würde mal eher sagen, die haben keinen Bock, das umzusetzen.

Die bist auch Du!

Du hast ja völlig recht, da "müßte man mal ..".

Aber irgendwie hat der Tag nur 24 Stunden, und je älter ich werde, desto kürzer kommen mir die vor


Wenn ich das hier lese .. (Google-Treffer)

"Gibt es überhaupt noch 32-Bit-Betriebssysteme?
Während 32-Bit-Architekturen in bestimmten Anwendungen immer noch weit verbreitet sind , hat sich der PC- und Servermarkt seit Mitte der 2000er Jahre auf 64 Bit mit x86-64 und anderen 64-Bit-Architekturen verlagert, ..."

.. ist es eh ein Anachronismus, daß ich bis jetzt (2025 !) noch alle meine Programme in 32 Bit compiliere - nur weil MS Windows das weiterhin unterstützt. War also an der Zeit daß ich das mal ändere


[Vorsicht, Wiederholung]
Aber irgendwie hat der Tag nur 24 Stunden, und je älter ich werde, desto kürzer kommen mir die vor

[af0815]

Aber irgendwie hat der Tag nur 24 Stunden, und je älter ich werde, desto kürzer kommen mir die vor

Alles wird im Alter kürzer, nicht nur die Tage - SCNR

Und klar alles geht in Richtung 64 Bit oder schon die ersten in Richtung 128 oder mehr. Momentan kenne ich 32 Bit nur mehr auf älteren RasPis und auf Win (weils so bequem ist)