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

[PeterS]

Hallo zusammen,

ich habe die Gelegenheit genutzt (Support-Ende Windows 10) und habe auf einem alten Notebook eine Win10-Installation mit einer Linux-Distribution überschrieben.

Ich war dann etwas überrascht als ich rausgefunden habe, daß in dem Gerät Platz ist für eine weitere Notebook-Festplatte. Auf die habe ich dann Windows 10 wieder installiert (da wird dann in Zukunft Netzwerk / WLAN abgeschaltet ..). Ich kann also jetzt in Linux und in Windows 10 reinbooten

Nun will ich mich für diesen neuen Anlauf auch gleich verabschieden von Win32-Programmen und -Code.
Ich ahne schon, das wird etliche neue Baustellen aufwerfen, wenn ich meine Programme
1) kompatibel mit Windows und mit Linux machen muss (Units, Komponenten, ..)
2) der Sprung von schlampigem 32-Bit-Code (=> Typ-Definionen) zu funktionsfähigem 64-Bit-Code

Was ich übrigens zunächst nicht vorhabe: Cross-Compiling


Wer kann mir Tips geben zu dieser Doppel-Challenge ?
Wo finde ich Such-Treffer zum sauberen Konvertieren von 32- zu 64-Bit Code ?
Und für sauberen Source-Code, der für Windows + für Linux compilierbar ist ?

[af0815]

ich habe die Gelegenheit genutzt (Support-Ende Windows 10) und habe auf einem alten Notebook eine Win10-Installation mit einer Linux-Distribution überschrieben.

Guter Ansatz

Ich ahne schon, das wird etliche neue Baustellen aufwerfen, wenn ich meine Programme
1) kompatibel mit Windows und mit Linux machen muss (Units, Komponenten, ..)
2) der Sprung von schlampigem 32-Bit-Code (=> Typ-Definionen) zu funktionsfähigem 64-Bit-Code

Was ich übrigens zunächst nicht vorhabe: Cross-Compiling


Wer kann mir Tips geben zu dieser Doppel-Challenge ?
Wo finde ich Such-Treffer zum sauberen Konvertieren von 32- zu 64-Bit Code ?
Und für sauberen Source-Code, der für Windows + für Linux compilierbar ist ?

Ich würde einmal auf beiden Systemen die gleiche (64Bit) Version von FPC und Lazarus installieren und dann die benötigten Komponenten. Das ist einmal der erste Schritt, dann auf Windows einmal das Programm mit 64 Bit testen. Meiner Erfahrung nach spießt es sich bei den dll's die man sich eingeschleppt hat, das man dann eine saubere 64 Bit Installation hat. Auch würde ich einmal die unit Windows versuchen unbedingt zu vermeiden.

Der Schritt auf Linux ist dann interessant, weil man da erst sieht, wieweit das ganze auf Windows speziell zugeschnitten ist. Je weniger Windows spezialitäten verwendet wurden, umso mehr bleibt eigentlich über, das Layout wieder ins Lot zu bringen, weil halt Schriften, Schriftgrößen etc. sich unterscheiden. Wenn man da bereits sehr viel mit Ankern gearbeitet hat und das Layout sich relativ dynamisch anpasst, so wird der Unterschied zwischen Windows und Linux nicht so massiv sein.

BTW: Meine Programme mussten auf Windows, Linux (Debian, Ubuntu) und RasPian laufen, geht mit etwas Wissen auch.

[theo]

Wo finde ich Such-Treffer zum sauberen Konvertieren von 32- zu 64-Bit Code ?
Und für sauberen Source-Code, der für Windows + für Linux compilierbar ist ?

Ich finde es etwas schwierig, allgemeine Tipps zu geben.

Achte mal auf die Meldungen im Nachrichtenfenster.
Du wirst vllt. so etwas sehen:

Code: Alles auswählen

Warning: Conversion between ordinals and pointers is not portable

Das passiert, wenn man z.B. Integer auf Pointer gecastet hat (Was man sowieso nicht tut... )

Ansonsten wie AF schon sagt: Je Winapi-lastiger dein Code, desto schwieriger die Anpassung.

Fange doch einfach mal an, dann siehst du schon wo's hakt.

[Zvoni]

Hallo zusammen,

ich habe die Gelegenheit genutzt (Support-Ende Windows 10) und habe auf einem alten Notebook eine Win10-Installation mit einer Linux-Distribution überschrieben.

Gute Entscheidung. Hab ich vor 8 Jahren gemacht

*schnipp*
1) kompatibel mit Windows und mit Linux machen muss (Units, Komponenten, ..)
*schnipp*
Und für sauberen Source-Code, der für Windows + für Linux compilierbar ist ?

Zusätzlich, was af0815 geschrieben hat:
Kommt drauf an:
Wenn du reine Monolithen hast (also nur eine "exe"), und das wars, dann einfach Windows-spezifisches Zeug vermeiden.
Also so Schweinereien wie ActiveX, direkte API-Aufrufe usw.

Wenn du auch "Satelliten-Bibliotheken" ("dll"'s) hast, auf welche du per LoadLibrary zugreifst, ist es relativ einfach per bedingter Kompilierung das in einer Code-Basis zu halten

[PeterS]

Fange doch einfach mal an, dann siehst du schon wo's hakt.

Klar, learning by doing ist der einzige Weg.

Habe gestern Abend (Nacht ) mal ein neues Projekt angelegt,
ein absolut funktionsloses Fenster mit nur einem TButton drauf,
und kriege gleich Fragezeichen ..

Bildschirmfoto vom 2025-11-20 22-52-44 Ausschnitt.png (19.01 KiB) 379 mal betrachtet

Dazu habe ich auch im WIKI einen Link gefunden.

https://wiki.lazarus.freepascal.org/Laz ... _not_found

"I receive a warning during the linking that states: Warning: "crtbeginS.o" (or "crtendS.o") not found
The actual filename may also be "crtbegin.o" or "crtend.o"
In most cases linking will not fail.
.."

Weiß aber nicht so recht, was das aussagen soll.
Ich mag keine Warnungen, bin immer bestrebt,
beim Compilieren keinen Wust von Meldungen zu bekommen,
damit echte Fehler und Warnungen nicht untergehen.

[theo]

Das mit dem crtbeginS.o etc. kannst du getrost vergessen.
Man muss nicht jedem Hint oder jeder Warnung nachgehen. Das ist nicht effizient.
Und eine Warnung ist noch kein Fehler.
Aber ja, es braucht etwas Erfahrung um beurteilen zu können, was wichtig ist und was nicht.

Die meisten Hints sind wie wenn Mutti fragt: "Hast du die Mütze und die Handschuhe dabei?"
Dann sagst du "Ja, klar".

[af0815]

[Dazu habe ich auch im WIKI einen Link gefunden.

https://wiki.lazarus.freepascal.org/Laz ... _not_found
..

Weiß aber nicht so recht, was das aussagen soll.
Ich mag keine Warnungen, bin immer bestrebt,
beim Compilieren keinen Wust von Meldungen zu bekommen,
damit echte Fehler und Warnungen nicht untergehen.

Es geht einmal darum, das diese Warnung sagt, das er beim Linken etwas nicht gefunden hat, das kann jetzt je nach der Plattform/Betriebssystem unterschiedlich sein.

Könnte er das Linken nicht beenden, so würde das in einen Link-Error münden und du hast kein Kompilat, aber den Hinweis, was beim Linken schiefgelaufen sein könnte. Wenn das Programm trotzdem startet, so hat der Linker das zwar nicht gefunden, es wurde aber oiffensichtlich nicht im Code benötigt. Und die Meldung ist eher auf Linux Systemen wichtiger, wenn es um die Pfade geht, wo manche Sachen hinterlegt sind. Das ist in dem Artikel. Du bist auf Linux, damit dürfte er dann die beiden Dateien doch beim Linken in den Pfaden gefunden haben.

Auf manchen Plattformen (wie Windows) verwendet der fpc einen internen Linker, damit sind die Meldungen anders oder gar nicht vorhanden, weil er es intern auflösen kann. Bei den Plattformen wo extern gelinkt wird, kann es sein, das der Linker mehr findet, der fpc aber das nicht mitbekommen hat.

[Mathias]

Das passiert, wenn man z.B. Integer auf Pointer gecastet hat (Was man sowieso nicht tut... )

Und wen, das immer mit dem PtrInt/PtrUint.

[photor]

Das mit dem crtbeginS.o etc. kannst du getrost vergessen.
Man muss nicht jedem Hint oder jeder Warnung nachgehen. Das ist nicht effizient.
Und eine Warnung ist noch kein Fehler.
Aber ja, es braucht etwas Erfahrung um beurteilen zu können, was wichtig ist und was nicht.

Die Warnung bekommt man weg, wenn man in ~/.fpc.cfg die folgende Stelle sucht und entsprechend der gcc-Version anpasst:

Code: Alles auswählen

...
# path to the gcclib
#ifdef cpui386
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/32
#endif
#ifdef cpux86_64
#-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1
## for gcc 14.2 -- Photor (2024-12-13)
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1
#endif
... 

(der gezeigte BEreich ist etwas älter ).
Die GCC-Version bekommt man mit

Code: Alles auswählen

╭─[photor@Spock:~]
╰─>$ gcc --version
gcc (GCC) 15.2.1 20251112
Copyright (C) 2025 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

In dem Fall also 14.2.1 durch 15.2.1 erstzen.

Ciao,
Photor

[PeterS]

Ich würde einmal auf beiden Systemen die gleiche (64Bit) Version von FPC und Lazarus installieren ..

Heute erledigt (4.4), und mein simples Mini-Testprogramm compiliert auch ohne Zicken,
egal ob ich das Projekt unter Linux oder unter Windows 10 lade.

Jetzt muss ich erstmal eines meiner Programme auswählen
und Stück für Stück in ein neues 64bit-Projekt rüberholen.
Dann wird sich wohl schnell zeigen, wo ich schlampig
falsche Typen verwendet habe, die in 32 und 64 Bit unterschiedlich lang sind.
Bleibt man in der 32 Bit Welt, fällt das ja nie auf ..

[PeterS]

Die Warnung bekommt man weg, wenn man in ~/.fpc.cfg ...

Danke für den Tip ! Probiere ich morgen gleich mal aus.

[hum4n0id3]

Man muss nicht jedem Hint oder jeder Warnung nachgehen. Das ist nicht effizient.
Und eine Warnung ist noch kein Fehler.
Aber ja, es braucht etwas Erfahrung um beurteilen zu können, was wichtig ist und was nicht.

Sehe ich wiederum anders, weil anders gelernt und es hängt auch von Sprache und Werkzeugen ab. Ich arbeite meistens mit PHP, JS oder Python, was interpretiert wird und über kurz, selten lang werden selbst warnings behoben, weil auch diese als Fehler betrachtet werden.

Bei kompilierten Sprachen ist das vielleicht etwas anderes, weil je nach Compiler andere Voraussetzungen herrschen, aber im Grunde sehe ich das gleiche wie bei Interpretern. Ist aber nur meine Meinung mit Erfahrungen aus meiner Bubble.

Was ich als Tipp für mitgeben würde, wenn man Software für mehrere Betriebssystem entwickeln will, hört auf Software für mehrere Betriebssysteme zu entwickeln. Da geht man mit der Zeit einfach unter. Nutzt aber Sprachen und Werkzeuge die für mehrere Betriebssysteme zur Verfügung stehen, zum Beispiel Lazarus. Schreibt dann Software für das Zielsystem und sollte ein Port für ein anderes Betriebssystem nötig werden, kann man einfacher portieren weil Vorraussetzungen bereits da sind.

Ich habe früher auch Software für mehrere Betriebssysteme geschrieben und habe sehr schnell die Lust verloren, weil man primär ein OS nutzt, das Projekt sich wegen Tests von anderen Systemen ewig in die Länge zieht, das Projekt auf anderen OS niemand nutzt, etc. Wenn sich jemand findet der das Projekt braucht, soll er einsteigen und das Projekt für sein OS über Pull Requests dir zur Verfügung stellen. Haben alle was davon.

[theo]

Sehe ich wiederum anders, weil anders gelernt und es hängt auch von Sprache und Werkzeugen ab. Ich arbeite meistens mit PHP, JS oder Python, was interpretiert wird und über kurz, selten lang werden selbst warnings behoben, weil auch diese als Fehler betrachtet werden.

Ein grosser Unterschied ist, dass z.B. bei PHP die "deprecated" Warnungen bedeuten können, dass der Code nach dem nächsten Versionsupdate nicht mehr läuft. Da schaue ich auch drauf.
Da fliegt auch schon mal eine alte Syntax raus und das ist leider nicht selten.

Das passiert so bei FPC nicht.
Bei den FPC Hints braucht man sich nicht hineinsteigern.
Ist ja oftmals auch nur blabla:

Hint: Start of reading config file /home/theo/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.cfg
Hint: End of reading config file /home/theo/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.cfg
unit1.pas(16,28) Verbose: Parameter "Sender" not used

Was will man damit?

Natürlich sollte man Warnungen anschauen und dann entscheiden, ob sie im gegebenen Kontext auf ein mögliches Problem hinweisen.
Aber es gibt Programmierer, die wollen diese einfach um jeden Preis "weg haben" und verwenden aus meiner Sicht zu viel Zeit darauf.
Aber das ist wohl Ansichtssache.

[MmVisual]

Wenn man unbedingt die Windows Unit benötigt dann kann man die so einbinden:

Code: Alles auswählen

{$ifdef WINDOWS}Windows, WinUtilPrn,{$endif}  // Windows sollte vor Classes stehen

Ich brauche die in meinem Programm auch nur deshalb weil ich spezielle Eigenschaften von Labeldrucker beschreiben muss. Das ist zwischen Windows und Linux komplett anders.
Wenn das übersetzen dann nicht klappt, dann müsen die betroffenen Programmzeilen ebenfalls für Linux mit {$ifdef WINDOWS}....{$endif} auskommentiert werden und stattdessen mit einem Linux Kompatiblen Code ersetzt werden, wenn man auf die Funktion nicht verzichten möchte.

Das gute ist bei Lazarus: bei 99,9% ist der Code Windows und Linux Kompatibel. Es betrifft wirklich nur Dinge die man direkt aus dem OS benutzen muss / möchte.

[theo]

Ein Tipp wäre noch: Versuche auch auf Windows ohne die Unit "windows" auszukommen.
Nimm stattdessen die units LCLIntf, LCLType und LMessages, wenn noch Winapi Code vorhanden ist.
Dort sind viele Winapi Funktionen/Typen als x-platform Varianten vorhanden.
Man kann es einfach mal ausprobieren, ob es damit und ohne die Unit "windows" auch kompiliert.
Vielleicht geht nicht alles auf Anhieb, aber das spart sicher mal Arbeit.