Multiplatform Programming Guide/de

From Lazarus wiki
Revision as of 20:22, 3 July 2006 by Swen (talk | contribs)
Jump to navigationJump to search

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) polski (pl) русский (ru) 中文(中国大陆)‎ (zh_CN)

Diese Seite ist der Beginn einer Einführung die das Hauptaugenmerk auf die Erstellung von Multiplattformanwendungen mit Lazarus richtet. Es werden die notwendigen Vorkehrungen, ein Programm portabel zu halten und auch der Portierungsprozess eines bereits bestehenden Programmes betrachtet. Ich lade den Leser dazu ein, diesen Artikel zu erweitern.


Einführung in die Multiplattform Programmierung

Welche Betriebssysteme sollen unterstützt werden?

Um diese Frage zu beantworten, müssen sie ermitteln, wer ihre potentiellen Nutzer sind und wie ihr Programm genutzt werden soll. Die Antwort auf diese Frage hängt davon ab, wo sie ihre Programm einsetzen möchten.

Zum Beispiel Europa: Wenn sie eine Desktop-Anwendung entwickeln, können sie entscheiden, dass es nur für Windows und OS X Sinn macht. OS X ist das populärste Unix der Welt und strömt auf Desktops, wohingegen Linux meist dort herausgezögert wird. Bedenken sie die 100:10:1 Regel, die besagt, dass in jeder größeren Organisation oder Benutzergruppe es nicht ungewöhnlich ist, Windows, OS X und Linux Arbeitsplätze in eben jener Aufteilung zu finden.

An anderen Orten wie beispielsweise Südamerika ist Windows größtenteils marktbeherrschend, wohingegen Linux als Dekstop Plattform aufstrebt und in einigen großen Marktketten fast gleich mit Windows verkauft wird. OS X wird hauptsächlich im Audio- und Videobereich eingesetzt.

Ist die handvoll OS X und Linux Nutzer den extra Portierungsaufwand der zum Entwickeln, Packen, Verteilen und Supporten benötigt ist, wert? Ein klares ja, wenn es das Projekt es verlangt. Oder wenn der mehr benötigte Aufwand gering ist, wird die Antwort ebenso warscheinlich ja sein. Wenn sie sie aus Prinzip unterstützen, wird die Antwort auch ja sein, solange der extra Aufwand nicht als Hinderungsgrund zur Fertigstellung des Projektes steht.

Wenn sie Software entwickeln, die auf einem Webserver laufen soll, ist die am meisten genutzte Plattform Unix. In diesem Fall ist es sinnvoll, Linux, Solaris, *BSD und andere Unix-Derivate als Zielplattform anzusehen, wobei zum Teil auch Windows Server zum Einsatz kommen.

Wenn sie nur für eine Plattform entwickeln, werden vielleicht Free Pascal und Lazarus nicht die besten Mittel dafür sein, es sei denn, sie möchten sich die Möglichkeit offen halten, spätere Versionen ihrer Software auf andere Plattformen zu portieren. Wenn sie beispielsweise nur Windows Desktopanwendungen erstellen, könnte Delphi die bessere Alternative sein.

Sobald sie die Plattformunabhängigkeit gemeistert haben, können Sie sich normalerweise auf das Problem konzentrieren, für das die Software entworfen werden soll und die Hauptzeit der Entwicklung auf der Plattform verbringen, über die sie verfügen oder auf der sie sich am wohlsten fühlen. Sie können, sobald Sie die Fallstricke der Plattformunabhängigkeit in Ihrem Design erkannt haben, größtenteils die anderen Plattformen ignorieren, ebenso, als wenn sie für eine einzelne Plattform entwickeln würden.

Jedoch kommen sie an einen Punkt, an dem sie die Verteilung und die Ausführung ihres Programmes auf den anderen Plattformen testen müssen. Spätestens dann ist es hilfreich, unbegrenzten Zugriff auf Rechner mit ihren gewählten Zielplattformen zu haben.

Wenn Sie nicht mehrere PC's haben möchten, können Sie ein Dual-Boot System mit Windows und Linux konfigurieren oder Windows und Linux auf ihrem Mac in einem Emulator wie Virtual PC oder iEmulator laufen lassen.

Der Portierungsvorgang zwischen Windows und Linux

Windows API Funktionen

Viele Windows Programme nutzen extensiv die Windows API. In plattformübergreifenden Anwendungen können diese Funktionen nicht direkt benutzt werden, sondern müssen in eine Kompilerdirektive eingeschlossen werden, z.B. {$IFDEF Win32}.

Glücklicherweise werden die meist genutzten Windows API Funktionen zur Verwendung in der Unit LCLIntf implementiert. Diese Unit kann die Lösung für Programme sein, die sehr stark die Windows API verwenden, obwohl die beste Lösung der Austausch dieser Aufrufe durch plattformübergreifende Komponenten der LCL ist. Sie können beispielsweise alle Aufrufe von GDI Zeichenfunktionen durch das TCanvas Objekt ersetzen.

Dateisystemunterschiede

Einer besonderen Beobachtung für die Portierung von Applikationen zwischen Linux und Windows bedarf das Dateisystem. Unter Windows sind Dateinamen beispielsweise nicht Case-Sensitiv, wohingegen sie es unter Unix-Plattformen sind. Dies kann der Grund für eine Menge nervenraubender Fehler sein. Daher sollte jede portable Anwendung konsistente Dateinamen verwenden.

Unix kennt kein "Programmverzeichnis"

Eine Sorge, wenn man Anwendungen zwischen Linux und Windows portiert, ist das Dateisystem. Viele Programmierer sind gewöhnt, ExtractFilePath(ParamStr(0)) oder Application.ExeName aufzurufen um den Ort des executable zu erhalten, und dann nach den notwendigen Dateien für die Programmausführung (Bilder, XML Dateien, Datenbankdateien, etc) zu suchen basierend auf dem Ort des executable. Das ist falsch unter Linux. Die Zeichenkette bei ParamStr(0) kann nicht nur das Verzeichnis des executable enthalten, ebenso variiert es zwischen verschiedenen Shell-Programmen (sh, bash, etc).

Sogar wenn Application.ExeName could in fact know the directory where the file under execution is, that file could be a symbolic link, so you would get the directory of the link instead.

Was sollen wir also tun? Unter Linux sollten sie zwei verschiedene Orte verwenden, um Konfigurations- und Ressourcen-Dateien zu speichern:

  • Ressourcendateien (z.B. Bilder, Hilfedateien)

A fixed privileged location for the executable and resource files which will not change.

This location can be something like: /usr/share/app_name or /opt/app_name

Most programs will be executed without root privileges and the fixed directory for a given application usually only available for the root user to write, so don't write on this directory. Only read information from it.

  • Konfigurationsdateien

Sie können die GetAppConfigDir Funktion aus der SysUtils Unit verwenden, to get a suitable place to store configuration files on different system. Diese Funktion hat einen Parameter, genannt Global. If it is True then the directory returned is a global directory, i.e. valid for all users on the system. Wenn der Parameter Global false ist, then the directory is specific for the user who is executing the program. Auf Systemen, die multi-user Umgebungen nicht unterstützen, these two directories may be the same.

Es gibt auch GetAppConfigFile, welches einen geeigneten Namen für eine Anwendungs-Konfigurationsdatei zurückgibt.

Hier ist ein Beispiel des output dieser Funktionen auf verschiedenen Systemen:

program project1;

{$mode objfpc}{$H+}

uses
  SysUtils;

begin
  WriteLn(GetAppConfigDir(True));
  WriteLn(GetAppConfigDir(False));
  WriteLn(GetAppConfigFile(True));
  WriteLn(GetAppConfigFile(False));
end.

Der output auf einem GNU/Linux System:

/etc
/home/felipe/project1
/etc/project1.cfg
/home/felipe/.project1

You can notice that glocal configuration files are stored on the /etc directory and local configurations are stored on a hidden folder on the user's home directory. Directories whose name begin with a dot (.) are hidden on Linux. You can create a directory on the location returned by GetAppConfigDir and then store configuration files there.

Der output unter Windows XP:

C:\Programas\teste
C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2
C:\Programas\teste\project2.cfg
C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2\project2.cfg

Notice that the function uses the directory where the application is to store global configurations on Windows.

Anmerkung: Die Verwendung von UPX stört die Verwendung von GetAppConfigDir und GetAppConfigFile Funktionen.

Storing data files for your applications

A very common question is where to store data files an application might need, like music, images, database files, and others. This section presents a particular solution where the data files are stores on the same directory as the executable (or any other directory based on it, like MyDirectory + 'data' + PathDelim + 'myfile.dat'), and on Unixes it will be on a directory read from a configuration file. If no configuration file exists or it contains no info, then a constant ('/usr/share/myapp/') is utilized as the default directory.

The configuration file path is located with the GetAppConfigFile function from the Runtime Library.

Bellow is a full unit which you can use at your applications.

unit appsettings;

interface

{$ifdef fpc}
  {$mode delphi}{$H+}
{$endif}

uses
{$IFDEF Win32}
  Windows,
{$ENDIF}
  Classes, SysUtils, Forms, IniFiles, constants;

type

 { TConfigurations }

 TConfigurations = class(TObject)
 private
   ConfigFilePath: string;
 public
   {other settings as fields here}
   MyDirectory: string;
   constructor Create;
   destructor Destroy; override;
   procedure ReadFromFile(Sender: TObject);
   procedure Save(Sender: TObject);
 end;


var
 vConfigurations: TConfigurations;

implementation

const
  DefaultDirectory = '/usr/share/myapp/';

  SectionGeneral = 'General';
  SectionUnix = 'UNIX';

  IdentMyDirectory = 'MyDirectory';

{ TConfigurations }

constructor TConfigurations.Create;
begin
{$ifdef win32}
 ConfigFilePath := ExtractFilePath(Application.EXEName) + 'myapp.ini';
{$endif}
{$ifdef Unix}
 ConfigFilePath := GetAppConfigFile(False) + '.conf';
{$endif}

 ReadFromFile(nil);
end;

destructor TConfigurations.Destroy;
begin
 Save(nil);

 inherited Destroy;
end;

procedure TConfigurations.Save(Sender: TObject);
var
 MyFile: TIniFile;
begin
 MyFile := TIniFile.Create(ConfigFilePath);
 try
   MyFile.WriteString(SectionUnix, IdentMyDirectory, MyDirectory);
 finally
   MyFile.Free;
 end;
end;

procedure TConfigurations.ReadFromFile(Sender: TObject);
var
 MyFile: TIniFile;
begin
 MyFile := TIniFile.Create(ConfigFilePath);
 try
{$ifdef Win32}
   MyDirectory := MyFile.ReadString(SectionUnix, IdentMyDirectory,
ExtractFilePath(Application.EXEName));
{$else}
   MyDirectory := MyFile.ReadString(SectionUnix, IdentMyDirectory,
DefaultDirectory);
{$endif}
 finally
   MyFile.Free;
 end;
end;

initialization

 vConfigurations := TConfigurations.Create;

finalization

 FreeAndNil(vTranslations);

end.

and here example code of how to use that unit:

  bmp := TBitmap.Create
  try
    bmp.LoadFromFile(vConfigurations.MyDirectory + 'MyBitmap.bmp');
  finally
    bmp.Free;
  end;

Making do without Windows COM Automation

With Windows, Automation is a powerful way not only of manipulating other programs remotely but also for allowing other programs to manipulate your program. With Delphi you can make your program both an Automation client and an Automation server, meaning it can both manipulate other programs and in turn be manipulated by other programs.

Leider ist Automation nicht verfügbar unter OS X und Linux. Jedoch können sie einen Teil der Funktionalität von Automation unter OS X simulieren unter Verwendung von AppleScript.

AppleScript ist ähnlich wie Automation in mancher Hinsicht. Zum Beispiel, sie können Skripte schreiben, die andere Programme manipulieren. Hier ist ein sehr einfaches Beispiel von AppleScript, das NeoOffice startet (die Mac Version von OpenOffice.org):

 tell application "NeoOffice"
   launch
 end tell

Eine Anwendung, die is designed to be manipulated by AppleScript provides a "dictionary" of classes and commands that can be used with the app, similar to the classes of a Windows Automation server. However, even apps like NeoOffice that don't provide a dictionary will still respond to the commands "launch", "activate" and "quit". AppleScript can be run from the OS X Script Editor or Finder or even converted to an app that you can drop on the dock just like any app. You can also run AppleScript from your program, as in this example:

 Shell('myscript.applescript');

Dies setzt voraus, daß das Skript in der angegebenen Datei ist. You can also run scripts on the fly from your app using the OS X OsaScript command:

 Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
       ' -e '#39'launch'#39' -e '#39'end tell'#39);
       {Note use of #39 to single-quote the parameters}

However, these examples are just the equivalent of the following Open command:

 Shell('open -a NeoOffice');

Die wirkliche Stärke von AppleScript is to manipulate programs remotely to create and open documents and automate other activities. How much you can do with a program depends on how extensive its AppleScript dictionary is (if it has one). For example, Microsoft's Office X programs are not very useable with AppleScript, whereas the newer Office 2004 programs have completely rewritten AppleScript dictionaries that compare in many ways with what's available via the Windows Office Automation servers.

While Linux shells support sophisticated command line scripting, the type of scripting is limited to what can be passed to a program on the command line. No access to a program's internal classes and commands are available with Linux the way they are via Windows Automation and OS X AppleScript.

As with Windows, many OS X and Linux programs are made up of multiple library files (.dylib and .so extensions). Sometimes these libraries are designed so you can also use them in programs you write. While this can be a way of adding some of the functionality of an external program to your program, it's not really the same as running and manipulating the external program itself. Instead, your program is just linking to and using the external program's library similar to the way it would use any programming library.

Weiterführende Links