[Free Pascal]
Free Pascal (abgekürzt FPC) ist ein freier und offener 32- und 64-Bit-Pascal-Compiler, 
der sich besonders durch folgende Eigenschaften auszeichnet:
   1. Verfügbar für zahlreiche Betriebssysteme (z. B. Windows, Linux, Mac OS, DOS, Game Boy)
   2. 	Verfügbar auf zahlreichen Plattformen (z. B. IA32=Intel-PC, AMD64, ARM, Sun Sparc)
   3. Kompatibel zu zahlreichen verbreiteten Pascal-Dialekten (z. B. Turbo-Pascal, Delphi, MacPascal)
   4. Integrierte Assembler sowohl für AT&T als auch für die Intel-Syntax.
   5. Optionale Ausgabe des Compilats als Assembler-Quelltext
   6. Für kommerzielle Programme verwendbar (unter Nutzung der LGPL).

Da sich Pascal durch eine sehr weitreichende Trennung zwischen Hardware/Betriebssystem 
und Programmcode auszeichnet, sind FPC-Programme in hohem Maße portierbar 
(in aller Regel genügt einfaches Compilieren auf dem Zielsystem, 
um aus einem Windows-Programm ein Linux oder DOS-Programm zu machen).

Für die Nutzung stehen verschiedene (ebenfalls frei verfügbare) integrierte Entwicklungsumgebungen (IDE) zur Verfügung: 
1. Lazarus eine Delphi-ähnliche IDE.
2. Eine Textmodus-IDE, die der Borland Turbo Pascal IDE sehr ähnlich ist (ist Teil des FPC-Paketes). 
3. Eine Kommandozeilenversion, die sich mit den meisten Editorprogrammen (z. B. QEdit, EMacs.) 
   sehr gut kombinieren lässt (ist Teil des FPC-Paketes).

Die Nutzung der LGPL ermöglicht es, kommerzielle Programme mit Free Pascal zu schreiben. 
Ein gutes Beispiel für die hohe Qualität des FPC ist z. B. das kommerzielle Grafikprogramm Pixel. 

[Sprachdialekt]
Free Pascal beherrscht den De-facto-Standard, die Borland-Pascal-Dialekte. 
In der Version 2.x ist Free Pascal nahezu Delphi-7-kompatibel. Weitere (bereits zu großen Teilen realisierte) Ziele sind: 
Implementierung der ANSI/ISO Pascal-Dialekte und von Apple Pascal.
Außerdem existiert ein OBJFPC-Modus, der umfangreiche Objekt-Pascal-Erweiterungen und zahlreiche Schnittstellen 
z. B. zu Datenbanken aktiviert. Zur Zeit sind auch Generics in Entwicklung.

Die verschiedenen Dialekte können über Kommandozeilenschalter, oder (besser) im Quelltext durch $MODE ausgewählt werden. 
Derzeit sind folgende Einstellungen möglich:
    * Delphi – Delphi-Kompatibilitätsmodus
    * TP – Turbo-Pascal-Kompatibilitätsmodus (Object-Pascal-Erweiterungen werden abgeschaltet)
    * FPC – Der Vorgabemodus
    * OBJFPC – FPC mit Object-Pascal-Erweiterungen
    * GPC – GNU Pascal-Kompatibilitätsmodus
    * MACPAS – Kompatibilitätsmodus für Pascaldialekte auf Mac OS, wie Think Pascal, Metrowerks Pascal und MPW Pascal

[Lieferumfang und Installation]
Auf der FPC-Website befinden sich direkt installierbare Versionen für die meisten Betriebssysteme. 
Die Installationen z. B. unter Windows lassen sich jederzeit problemlos und vollständig wieder entfernen. Es existieren u. a. 
folgende Komponenten/Erweiterungen (ein aktueller Überblick findet sich auf der FPC-Website):
    * FPC – Der Compiler selbst
    * RTL – Die Laufzeitbibliothek
    * FCL – Die Free Component Library (analog zur Delphi VCL)
    * Textmode IDE
    * Mehreren Paketen (Units):
          o bfd – Schnittstelle zur GNU-Binary-Format-Beschreibung
          o cdrom – CDROM-Schnittstelle
          o forms – Schnittstelle zu X-Forms
          o fpgtk – GTK
          o fv – Free Vision
          o gconf
          o gdbint – Schnittstelle zum gdb-Debugger
          o gdbm
          o ggi
          o gnome – GNOME-Schnittstelle
          o gtk – GTK-Schnittstelle
          o gtk2 – GTK-2-Schnittstelle
          o ibase – Schnittstelle zur Interbase-API
          o imlib
          o inet – Routinen zur Internet-Programmierung
          o libasync – Prozeduren für asynchrones I/O
          o libc
          o libgd
          o libpng
          o md5 – Routinen zur Berechnung von MD5-Prüfsummen
          o mysql – Schnittstelle zu MySQL
          o ncurses – Ncurses-Schnittstelle
          o netdb
          o newt
          o odbc – Schnittstelle zu ODBC
          o opengl – OpenGL-Schnittstelle
          o oracle – Schnittstelle zur Oracle-Datenbank
          o paszlib – Implementation der zlib-Routinen
          o pasjpeg
          o postgres – Schnittstelle zu PostgreSQL
          o pthreads
          o regexpr – Reguläre Ausdrücke
          o sqlite – SQLite-Schnittstelle
          o svgalib
          o syslog
          o tcl – Tcl-Schnittstelle
          o unixutil
          o unzip
          o utmp
          o uuid
          o x11 – X11-Schnittstelle
          o zlib
          o zvt
          o weitere Pakete/Units von Free-Pascal-Nutzern

gf  [Geschichte]
Free Pascal entstand aus dem Wunsch heraus, 32-Bit Pascalprogramme einfach und portierbar erstellen zu können. 
Damals konzentrierte Borland seine Entwicklung ganz auf Windows (das spätere Delphi) und lehnte die Weiterentwicklung des
bis heute an Qualität und Geschwindigkeit immer noch vorbildlichen, aber fast komplett in Assembler programmierten Borland Pascal (TP/BP) Compilers ab 
(selbst einfache Fehler wie der mit BP7 eingeführte „RuntimeError200“ – 
ein Überlauf in einer Schleife, welche die Geschwindigkeit der Hardware bestimmen sollte, 
wurden nicht mehr beseitigt). Der Student Florian Paul Klämpfl entwickelte darauf hin einen eigenen 32-Bit Pascal-Compiler. 
Er nannte ihn zunächst FPK, nach den Initialen seines Namens.

Die erste Version war noch ausschließlich für den DOS-Extender go32v1 geschrieben, 
was jedoch bereits ein enormer Fortschritt war, da jetzt bis zu 2 GB große Datenbereiche 
(z. B. Felder für Fast-Fourier-Analysen oder Digitale Filter) äußerst einfach verwaltet werden konnten. 
Die Entwicklergemeinde erweiterte sich rasch und nach einiger Zeit portierte Michael van Canneyt Free Pascal auf Linux. 
Für OS/2 wurde die DOS-Portierung angepasst, sodass sie mit dem EMX-Extender zusammenarbeitet. Auch eine Win32-Portierung wurde durchgeführt.

Im Juli 2000 erschien Version 1.0. Diese Version hatte schon nahezu Turbo-Pascal-7/Delphi-2-Kompatibilität. 
In der Folgezeit wurde Free Pascal noch auf zahlreiche andere Plattformen und Architekturen portiert, u. a. PowerPC, Sparc und ARM. 
Version 1.9.4 war dann die erste Version mit Mac OS X-Support.

Die Entwicklung wurde fortgesetzt und die Version 2.0.0 schließlich im Mai 2005 veröffentlicht.

Die aktuelle Version 2.2 wurde im September 2007 veröffentlicht und unterstützt auch Windows CE, Game Boy Advance und Nintendo DS als Plattform.

[Plattformen]
In der Version 2.0.4 unterstützt Free Pascal folgende Architekturen:
    * IA-32 (Intel 80386 und Kompatible)
    * PowerPC
    * PowerPC64
    * ARM (Zaurus)
    * Sparc v8 und v9
    * AMD64 (x86_64)

Folgende Betriebssysteme werden unterstützt:
    * AmigaOS (Version 4.0)
    * Linux (alle CPUs)
    * FreeBSD
    * Mac OS X und Darwin (PowerPC)
    * Mac OS
    * DOS (Go32V2 extender)
    * Win32
    * OS/2 (EMX und nativ)
    * Novell NetWare
    * ZETA
    * Windows CE
    * Game Boy Advance
    * Nintendo DS

http://wiki.lazarus.freepascal.org/Lazarus_For_Delphi_Users/de
[Delphi -> Lazarus]
Lazarus ist ein Rapid Application Development (RAD) Tool wie Delphi. Das bedeutet, 
es enthält eine visuelle Komponentenbibliothek und eine IDE. Die Lazarus Component Library (LCL) 
ist sehr ähnlich zu Delphi's VCL. Die meisten Units, Klassen und Eigenschaften haben den selben Namen 
und die selbe Funktionalität. Dies macht eine Portierung (von Delphi zu Lazarus) einfach. Aber Lazarus ist
kein 'Open Source Delphi Klon'. Erwarten sie daher keine 100%ige Kompatibilität. 

{Die größten Unterschiede]

Lazarus ist komplett Open Source, ist plattformunabhängig geschrieben und benutzt den 
mächtigen Free Pascal Compiler (FPC). FPC läuft auf mehr als 15 Plattformen. 
Aber nicht alle Packages und Bibliotheken sind portiert, so dass Lazarus gegenwärtig unter 
Linux (i386, x86_64), FreeBSD (i386), Mac OS X (powerpc, i386) und Windows (i386, x86_64) läuft.

Lazarus ist nicht komplett, wie es dieser Text ist. Wir suchen ständig neue Entwickler, 
Package-Entwickler, Portierer, Dokumentations-Schreiber, ... . 

Die erste Aktion bei der Konversion eines Delphi Projekts

Nachdem Lazarus gestartet ist, gehen sie zu Tools und dann zu 
Convert Delphi Project to Lazarus Project. Das wird nicht alles für sie erledigen, 
sie aber ein gutes Stück weiter bringen. 

[Delphi IDE -> Lazarus IDE]
Die Hauptdatei einer Delphi Anwendung ist die .dpr Datei. Die Hauptdatei eines Lazarus Projekts ist die .lpi Datei 
(Lazarus Project Information). Eine .dpr Datei ist die Hauptquelle eines Programms und die Delphi IDE speichert 
hier einige Informationen über die Compiler-Schalter und Units. Eine Lazarus-Anwendung hat auch eine .lpr Datei, 
die auch die wichtigste Quelldatei ist. Aber alle anderen Informationen werden in der .lpi Datei gespeichert. 
Daher ist die .lpi Datei die wichtigste Datei.

Eine wichtige Regel: Es gibt immer ein Projekt. Der einzige Weg, um ein Projekt "zu beenden", ist, Lazarus zu beenden oder 
ein anderes Projekt zu öffnen. Das ist so, weil ein Lazarus Projekt auch eine "Sitzung" ist. Das bedeutet, dass die aktuellen 
Editoreinstellungen auch in der .lpi Datei gespeichert sind und wiederhergestellt werden, wenn sie das Projekt wieder öffnen. 
Zum Beispiel: Sie debuggen eine Anwendung, setzen eine Menge Haltepunkte (Breakpoints) und Lesezeichen (Bookmarks). 
Sie können das Projekt jederzeit speichern, Lazarus schließen oder ein anderes Projekt öffnen. Wenn sie das Projekt wieder 
öffnen, sogar auf einem anderen Computer, werden alle ihre Haltepunkte, Lesezeichen, geöffneten Dateien, Cursorpositionen, 
Sprunghistorie, ... wieder hergestellt. 

[Quelltext Editor]

Beinahe alle Tasten und Abkürzungen (short cuts) können definiert werden unter Einstellungen -> Editoreinstellungen -> Tastaturbelegung.

Die Lazarus IDE besitzt eine Menge von Werkzeugen für Quelltexte. Viele von ihnen sehen aus und arbeiten sehr ähnlich wie Delphi. 
Aber es gibt einen wichtigen Unterschied: Lazarus benutzt nicht den Compiler, um Code-Informationen zu erhalten. 
Es analysiert die Quelltexte direkt. Dies hat eine Menge von bedeutenden Vorteilen:

Der Quelltext-Editor berücksichtigt Kommentare. Für Delphi sind die Kommentare in den Quellen einfach nur Leerzeichen im Code. 
Kein Code-Werkzeug funktioniert dort und wenn neuer Code automatisch eingefügt wird, dann wandern ihre Kommentare. 
Unter Lazarus können sie eine find declaration sogar für Code in den Kommentaren erstellen. 
Obwohl dies nicht komplett verlässlich ist, funktioniert es oftmals. Und wenn neuer Code eingefügt ist, 
dann benutzt die IDE einige heuristische Methoden, um Kommentare und Code zusammen zu halten. Zum Beispiel: 
Es wird die Zeile "c: char; // comment" nicht aufteilen.

Delphi's "Code Completion" (Strg+Space) wird "Identifier Completion" genannt unter Lazarus. 
Der Lazarus Begriff "Codevervollständigung" ist ein Werkzeug, das "Automatic Class Completion" (das gleiche wie unter Delphi), 
"Local Variable Completion" und "Event Assignment Completion" kombiniert. Alle von ihnen werden mit Strg+Shift+C aufgerufen 
und die IDE ermittelt über die Cursor Position, was gemeint ist. 

[Beispiel für Local Variable Completion]
Gehen sie davon aus, dass sie gerade eine neue Methode erzeugt haben und die Anweisung schreiben "i:=3;"
 procedure TForm1.DoSomething;
 begin
   i:=3;
 end;

Positionieren sie den Cursor über den Bezeichner "i" und drücken sie Strg+Shift+C und sie erhalten:
 procedure TForm1.DoSomething;
 var i: Integer;
 begin
   i:=3;
 end;

[Beispiel für Event Assignment Completion]
Ein nettes Feature des Objektinspektors ist die automatische Erzeugung von Methoden. Das selbe können sie im Quelltext Editor erhalten.
Zum Beispiel: Button1.OnClick:= 
Positionieren sie den Cursor hinter den assign operator ":=" und drücken sie Strg+Shift+C. 

[Beispiel für Procedure Call Completion]
Assume you just wrote the statement "DoSomething(Width);" 
procedure SomeProcedure;
var
  Width: integer;
begin
  Width:=3;
  DoSomething(Width);
end;
 

Position the cursor over the identifier "DoSomething" and press Strg+Shift+C to get: 
procedure DoSomething(aWidth: LongInt);
begin
 
end;
 
procedure SomeProcedure;
var
  Width: integer;
begin
  Width:=3;
  DoSomething(Width);
end;

["Word Completion" Strg+W]

Es arbeitet ähnlich wie die "Identifier Completion", aber es funktioniert nicht nur mit Pascal-Bezeichnern, 
sondern mit allen Wörtern. Es lässt sie alle Wörter in allen geöffneten Dateien wählen, die mit dem selben Buchstaben beginnen. 


[Unterstützt Include Dateien]

Delphi unterstützt es nicht, und daher haben sie wahrscheinlich noch nicht viele Include-Dateien erstellt. 
Aber Include-Dateien haben einen großen Vorteil: Sie machen es möglich, plattform-unabhängigen 
Code zu schreiben ohne ihren Code durch IFDEFs unübersichtlich zu machen. Zum Beispiel: Method jumping, Class Completion, 
find declaration, .. arbeiten alle mit Include Dateien.

Es gibt viele Optionen für die Code Features. 

[Objektinspektor]

In den Delphi und Lazarus IDE's wird der Objektinspektor benutzt, um Komponenteneigenschaften zu editieren und Ereignisse zuzuweisen etc. Die folgenden Zeilen zeigen einige kleinere Unterschiede, auf die man achten muss:
   1. Nach dem Start von Delphi gibt es einen Objekt-Treeview, der zum Navigieren und Auswählen von Objekten unter Darstellung ihrer Hierarchie genutzt werden kann und so wahlweise die Dropdown-Liste des Objektinspektors ersetzt. In Lazarus ist dieser Treeview fester Bestandteil des Objektinspectors und es ersetzt 
      die Dropdown-Liste völlig. Die Anzeige kann über das Kontextmenü "Komponentenbaum anzeigen" aktiviert bzw. deaktiviert werden.
   2. In Delphi wird ein Doppelklick auf ein leeres Ereignis automatisch eines erzeugen und den Quelltext-Editor an dieser Position öffnen, in Lazarus gibt es alternativ eine Schaltfläche auf der rechten Seite der ausgewählten drop-down, das diese Aktion ebenfalls ausführt.
   3. In Delphi müssen sie den Namen eines Ereignisses in der Editierzeile manuell löschen, um Anhänge zu entfernen. In Lazarus können sie mittels Dropdown "none" auswählen.
   4. Ähnlich wie bei Ereignissen, wird doppeltes Klicken normaler Eigenschaften wie boolean nicht den Wert ändern. Sie müssen ihn aus einem drop down wählen. Und um diese mit einem zugeordneten Editorformular zu öffnen, müssen sie auf den '...' Button rechts vom edit/drop-down klicken. 

[Packages]
F: Kann Lazarus Delphi-Packages installieren und verwenden?
A: Nein, weil sie die Delphi Compiler Magie benötigen.
F: Brauchen wir ein speziell erstelltes Package für Lazarus?
A: Ja. Erzeugen Sie ein neues Package, speichern sie es im Package-Quellen-Verzeichnis (normalerweise das selbe Verzeichnis wie das der .dpk Datei), 
fügen Sie die LCL als benötigtes Paket und schließlich die .pas Dateien selbst hinzu. Sie können es installieren oder es ab jetzt in ihren Projekten verwenden. 
Es gibt einige Unterschiede zwischen Lazarus und Delphi Packages, 
daher lesen sie bitte
- die docs/Packages.txt in den Lazarus Quellen. 

[VCL -> LCL]
Während die VCL und die LCL beide meist dem selben Zwecken dienen - zu einer objekt-orientierten 
Komponenten-Hierarchie besonders verzahnt in Richtung Rapid Application Development - sind sie nicht identisch. 
Während zum Beispiel die VCL viele nicht-visuelle Komponenten enthält, versucht die LCL nur visuelle Komponenten zu liefern, 
während die meisten nicht-visuellen Komponenten (wie zum Beispiel db access) von der FCL zur Verfügung gestellt werden, die in Free Pascal enthalten ist.

Zusätzlich mögen viele Bedienelemente, die in der VCL enthalten sind, nicht in der LCL existieren, oder umgekehrt. 
Sogar wenn Bedienelemente in beiden existieren, sind VCL und LCL keine echten Klone. Änderungen müssen gemacht werden 
in Anwendungen, Komponenten und Bedienelementen, wenn sie portiert werden.

Das Folgende ist eine unvollständige Beschreibung der wichtigsten Unterschiede oder Inkompatibilitäten zwischen Delphi 
und Lazarus für Delphi-Benutzer. Es behandelt hauptsächlich die Unterschiede der VCL von D4, teilweise aber auch D5, D6, oder D7, 
mit der gegenwärtigen LCL, wie sie im SVN vorliegt. Insoweit können Unterschiede zu den von ihnen verwendeten Versionen von Delphi und LCL bestehen. 
Sollten ihnen Unterschiede oder Ungenauigkeiten zwischen dem Folgenden und der aktuellen LCL oder ihrem Delphi auffallen, dann bitten wir sie, 
den vorliegenden Text entsprechend zu modifizieren oder neue Abschnitte anzufügen. Wir möchten diese Beschreibung 
so umfassend und aktuell wie möglich für alle Lazarus-User zur Verfügung stellen. 

[TControl.Font/TControl.ParentFont]
In der VCL ist es ziemlich einfach und normal, einen spezifischen Schriftart-Namen und Schriftart-Eigenschaften wie 
'fett' und 'kursiv' für die Bedienelemente zu benutzen. 
In aller Regel werden diese Voreinstellungen auch entsprechend verwendet. 
Im laufenden Programm können sich diese Einstellungen von den Vorgaben von Windows unterscheiden. 
Ferner wird die TControl.ParentFont Eigenschaft mitgeliefert, 
die sicher stellt, dass ein Bedienelement immer seiner parent's Schriftart folgt.

Dies trifft in der LCL nicht immer zu. Die LCL als cross-Plattform/cross-Interface hingegen, 
benutzt das Widget-Toolset, das aktuell auf dem benutztem Betriebssystem verwendet wird. 
Wenn ihr Desktop also gerade das GTK Interface benutzt, so wird LCL immer die Themes und spezifischen Schriftarten 
für Schaltflächen des GTK Widget-Toolset benutzen.

Das bedeutet, dass die meisten LCL Bedienelemente dem Desktop-Design 
des Zielrechners entsprechen werden. Das look and feel ihrer Progammoberfläche kann sich also auf verschiedenen 
Zielrechnern auch entsprechend der Desktop-Einstellungen ändern.

[TEdit/TCustomEdit]

Die Edit-Bedienelemente, die grundsätzlich gleich in der LCL wie in der VCL funktionieren, 
besitzen einige Besonderheiten, die bei einer Konvertierung beachtet werden sollten -
   1. Wegen Restriktionen in den Interfaces, arbeitet TEdit.PasswordChar noch nicht 
      mit allen Interfaces (obwohl es mit der Zeit möglich sein wird), anstelle von TCustomEdit.EchoMode sollte emPassword benutzt werden, falls der Text verborgen werden muss.
   2. On Drag/Dock Ereignisse sind noch nicht implementiert. Für mehr Informationen schauen 
      Sie bitte im vorherigen Abschnitt Bedienelemente ziehen und andocken nach.
   3. Font-Eigenschaften werden üblicherweise für die Interface-Konsistenz ignoriert, 
      für eine detaillierte Beschreibung schauen Sie bitte TControl.Font/TControl.ParentFont an.

[(optional) TSplitter -> TPairSplitter]
Bitte verbessern sie mich
Es gibt jetzt ein TSplitter Bedienelement in der LCL, so dass kein Bedarf zum Konvertieren besteht.
Nichtsdestoweniger, wenn sie es doch wollen, hier ist es beschrieben:
Das folgende basiert lose auf den Fragen von Vincent Snijders in der mailing Liste, und Antworten von Andrew Johnson:
Das in Delphi enthaltene "Splitting"-Control, das zwischen zwei Komponenten platziert werden kann, 
um dem einen oder anderen mehr Platz zu geben, wird in der VCL durch einen TSplitter realisiert. 
Dieses wird oft benutzt, beispielsweise in Delphi zwischen dem angedockten Codeexplorer und dem Quelltextfenster.
In der LCL gibt es dafür allerdings ein eigenes Control, den TPairSplitter, das den selben Zweck erfüllt, 
wie der TSplitter, allerdings zu diesem nicht kompatibel ist. Es sind also, wenn sie ihr Programm von einem 
TSplitter auf einen TPairsplitter ändern wollen, einige Anpassungen nötig.

Was sind nun genau die Unterschiede ?
Der größte Unterschied ist, dass ein TSplitter keine "Kinder" besitzt. Stattdessen wird es 
zwischen zwei Controls positioniert, die mittels Align ausgerichtet werden. So erlaubt er während der 
Laufzeit die dynamische Größenanpassung dieser Controls. Um dies zu ermöglichen, muss links und rechts 
ein mittels Align ausgerichtetes Control vorhanden sein. (Beispielsweise ein left-aligned Panel + ein left-aligned TSplitter + ein client-aligned Panel).

In der LCL ist der TPairSplitter ein spezielles Control mit zwei Panels. Er kann nur nützlich werden, 
wenn die zu verändernden Kontrols auf beiden Panels liegen. Er vergrößert bzw. verkleinert also die beiden Panels, 
unabhängig davon, ob sie Komponenten enthalten oder nicht.

Der andere entscheidende Unterschied ist, dass der TSplitter der VCL seine Position relativ zu den anderen Komponenten verändert, 
abhängig von seiner split-Position. In der LCL dagegen besitzt der TPairSplitter durch die Panels eine absolute Position, 
wie andere Controls auch, die sich nach den Eigenschaften top und left richtet. So verändert sich die Position nicht automatisch, 
wenn die Split-Position verändert wird. Ist dies erwünscht, ist es nötig, einen entsprechenden Callback zu setzen und 
die entsprechenden Einstellungen zu setzen. Beispielsweise befindet sich in einem verticalen TPairSplitter eine Komponente mit alClient. 
Soll diese automatisch bei Größenänderungen des Formulars im Verhältnis angepasst werden, ist es nötig, im OnResize des Formulars die neue Position zu setzen: 

[The Power of Proper Planning and Practices]
Plan for cross-platform up front

There are several advantages to doing your development in a cross-platform way. 
Probably the most important advantage is that it can result in better, more reliable software. This is because cross-platform development 
requires that you spend more time planning your software before you start writing code. It also forces you to develop good programming habits, 
to test your software more, and to develop a more disciplined approach toward what you're doing. These things (planning, testing, discipline) 
tend to spill over into other aspects of your development, resulting in still more improvements in design and reliability.

Another advantage to cross-platform development is that it exposes you to other platforms. For example, 
many Windows developers and probably all Linux developers could benefit from some time spent simply using a Mac as a 
way of developing an appreciation for software ease of use and aesthetics. And many Windows developers could benefit 
from seeing how Linux tends to use text files and scripts for many things, without any loss of application performance.

A third advantage to cross-platform development is that it is by definition inclusive, which forces you to consider 
your users more than most single-platform programmers do.

The best way to make an application cross-platform is to design it to be cross-platform. If you plan on adding 
cross-platform support to your finished application later, you may find that you'll have to rewrite parts of it or, 
worse, find yourself in a Windows-only cul-de-sac that makes adding cross-platform support difficult or impossible.

If you've already developed an application for Windows with Delphi, it's possible in some situations to convert 
it to cross-platform app without starting over. If you want to do a one-way conversion of your Delphi code and forms 
to Lazarus, you can use some of the conversion commands on the Lazarus Tools menu. You can also convert your Delphi app 
to Lazarus, but retain Delphi compatibility (see this link for more information). 

Separate code into UI and non-UI units

Probably one of the most important programming practices you can employ with any application, 
whether cross-platform or not, is to divide your code into user-interface (UI) units and non-user interface (non-UI) units. In general, 
this means that your non-UI units should not implement any of the program's user 
interface and your UI units should not contain any of the computational or database parts of the program. In practice, 
a good way to enforce this separation is to require that the units you develop only use units 
that are appropriate to their side of this "divide". For example, your non-UI units should not use LCL units such as Forms, 
Dialogs, StdCtrls, Button, Graphics, Controls, LMessages, and so forth, or any of your own units that use these units. 
And your UI units should probably not be using units such as Math, Dbf, MySQLDB4, etc. Follow the example of the 
Free Pascal and Lazarus units themselves, where general-purpose units like SysUtils, Classes and Variants don't use any
LCL units and LCL units like Forms and Controls don't supply any general-purpose routines.

There are several advantages to dividing up your code like this. For example, it means that you will be able to u
se your non-UI units in any type of program, whether a GUI app, library, console app, even a Web app, without 
making any changes to the code. And it also means that if necessary you could develop a completely different user 
interface for your program or switch to a different UI library or control without changing the underlying non-UI code. 
It's also critical that this partitioning be done in large projects so that multiple developers can work on different parts 
of the program without stepping on each other's toes.

You may also find it helpful to further subdivide your non-UI code. For example, you might want to put all 
database access code in one set of units and all business logic and number-crunching code in another set of units. 
In addition, you might want to put all platform-dependent code (shelling, registry, clipboard, etc.) in its own set 
of units to isolate that code and make it easier to port to other platforms. 

Use batch files and shell files
Even though Lazarus allows you to edit and compile code and set most compiler switches without ever leaving the IDE, 
you'll probably find it useful to create several batch files for each project. Batch files are just special text files 
containing console commands; you create them with a text editor. With Windows, batch files have a .bat or .cmd extension; 
with OS X and Linux, batch files have an .sh extension. You typically run a batch file by entering its name in a console window, 
as follows:
With Windows:mybatch.bat

Note that you can omit the .bat extension if there's no .exe 
file with the same name.

With Unix:./mybatch.sh

There are many way that batch files can be used in development. 
For example, you might have one set of compiler options that you use during 
development and another set that you use to create the executable that you distribute. 
Here's an example of a command you can put in a batch file that runs the Free Pascal compiler:
With Windows: c:\lazarus\pp\bin\i386-win32\fpc.exe -Sda -Cirot -gl %1
With Unix: /usr/local/bin/fpc -Sda -Cirot -gl $@

The above command compiles the unit or non-GUI program specified on 
the command line with Delphi compatibility, assertions, I/O checking, 
range checking, overflow checking, stack checking, and line number tracing 
turned on. Note that you can add additional pre- and post-compile commands to a 
batch file. For example, you could run the strip.exe utility to shrink the size of 
your executable or copy the executable to a different folder for testing.

Here's a similar command that you can put in a batch file to compile a GUI program that you specify on the command line:
With Windows (all on one line): c:\lazarus\pp\bin\i386-win32\fpc.exe -dLCL -WG -Sda -Cirot -gl -Fuc:\lazarus\lcl\units\i386-win32;c:\lazarus\lcl\units\i386-win32\win32 %1

With OS X (all on one line): /usr/local/bin/fpc -dLCL -WG -Sda -Cirot -gl -Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin
-Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin/gtk -Fl/usr/X11R6/lib/ -Fl/sw/lib/ $@

How to avoid using a debugger

Using a debugger is rarely much fun. It often means that you've given up trying to figure out what's wrong with your program and 
have turned to the debugger as a last resort. Here are some simple techniques that you can employ that will 
help minimize your use of a debugger:

    * Develop with all run-time checks turned on. You can turn off some or all checks when you create an executable 
for distribution, although the code-size and performance improvements of turning checks off are pretty negligible. 
Plus, leaving checks turned on can help you locate bugs that turn up later. 

    * Use assertions. Like run-time checks, assertions can be turned off later, although leaving 
them on can help you diagnose bugs that your users encounter.
    * Compile with line number tracing turned on. You can turn this off when you release your program to 
shrink the size of the executable.
    * If your code handles exceptions, you can still determine the line number and source file name of where the 
exception occurred using line number tracing and the FPC BackTraceStrFunc function, as in this example code: 
   try
     raise Exception.Create('Exception here');  
   except
 // Handle exception here.
 {$IFDEF FPC}
     WriteLn(BackTraceStrFunc(ExceptAddr));
 {$ENDIF}
     end;

The {$IFDEF} and {$ENDIF} lines ensure that you can compile this code with Delphi too.

    * Initialize variables. Although both Delphi and FPC initialize global variables and object fields, 
variables local to routines are not initialized. It's a good idea to initialize all variables just to be clear about what their initial values are.
    * Turn on compiler warnings and pay attention to them.
    * Use "with" sparingly. Although the Pascal with statement can save you a lot of typing, 
it can also hide incorrect field references if you use nested with statements or if a field with the same name as a 
field in your with's target is added someday to an ancestor class.
    * Run your code through multiple compilers. There will always be differences in how different compilers process your code. 
Sometimes these differences are dictated by the underlying operating system or hardware. 
Try to compile your program (or at least the non-UI units) with two or three compilers. For example, if your code 
compiles and runs correctly with Delphi and on at least two of FPC's platforms, you'll be that much closer not only 
to a stable cross-platform app but also to having a program that you know will work. 


[Lazarus (Entwicklungsumgebung)]
Lazarus ist eine freie Entwicklungsumgebung für Rapid Application Development (RAD) mit Free Pascal (FPC). 
Lazarus orientiert sich an Borland Delphi, im Gegensatz zu anderen integrierten Entwicklungsumgebungen (IDE) für Pascal, 
die eine an Turbo Pascal angelehnte Oberfläche besitzen. Die Lazarus Component Library (LCL) ist sehr ähnlich zu Borland Delphis VCL. Die meisten Units, 
Klassen und Eigenschaften haben denselben Namen und dieselbe Funktionalität. 
Auch für Entwickler proprietärer Software ist Lazarus geeignet, da die LCL-Komponentenbibliothek unter den 
Bedingungen der LGPL lizenziert wird.

Lazarus ermöglicht die schnelle Erstellung grafischer Bedienoberflächen (GUI) und bietet derzeit Unterstützung für
die Grafikbibliotheken (Widget Toolkits) GTK bzw. GTK2 (mit GNOME-Unterstützung), Qt, Carbon (Mac OS X), Windows CE und WinAPI (Win32 Forms) 
auf einem hohen Abstraktionsgrad, was den erzeugten Code in Verbindung mit Free Pascal in einem hohen Grad plattformunabhängig macht.

Einmal erstellter Quellcode kann meist problemlos auf unterstützten Betriebssystemen 
(derzeit vor allem Linux, Mac OS X und Windows) kompiliert und ausgeführt werden.

Der Projektname „Lazarus“ basiert auf dem Namen der biblischen Figur Lazarus. 
Er wurde gewählt, nachdem das Projekt Megido 1999 scheiterte, 
eine visuelle Programmierumgebung für Free Pascal zu entwickeln, 
und die aktiven Entwickler ein neues Projekt starteten.

[Funktionen]
    * Open-Source-Projekt
    * Unterstützt mehrere Betriebssysteme
    * WYSIWYG-Editor zur Erstellung von Bedienoberflächen („Designer“)
    * Syntax-Highlighting (Hervorhebung von Schlüsselworten)
    * Code Completion (Automatische Vervollständigung)
    * Lazarus kann sich selbst kompilieren (z.B. für individuelle Optimierungen)
    * Viele Einstellmöglichkeiten
    * Delphi-Projekte können recht einfach portiert werden

[Einschränkungen]
    * Lazarus ist kein Open-Source-Borland-Delphi-Klon und daher nicht vollständig kompatibel.
    * Viele Medien- und Netzwerkbibliotheken sind noch nicht für alle Plattformen verfügbar.
