|
Was bedeutet API:
API bedeutet Advanced Programmer's Interface (engl.: die Oberfläche des fortgeschrittenen Programmierers), also eine erweiterte Programmierschnittstelle zu anderen Anwendungen bzw. Dateien.
Wozu benötigt man API - Funktionen:
API - Funktionen stellen einen wichtigen Bereich in der (Visual - Basic) Programmierung dar. Sie sind sozusagen die Schnittstelle zu wichtigen System - Funktionen. Mit ihrer Hilfe können die Möglichkeiten von Visual Basic erheblich gesteigert werden. Visual Basic zielt hauptsächlich darauf ab, die Systemstabilität zu gewährleisten. Dazu muß allerdings auch die Zahl der verfügbaren Funktionen erheblich eingeschränkt werden. Allerdings sind ein Großteil der wichtigen Funktionen nun über die API - Schnittstelle bzw. die API - Funktionen erreichbar. Man kann demzufolge sagen, daß die API - Routinen eine Schnittstelle zwischen den wirklich abgesicherten Visual Basic Funktionen und den absturzgefährdeten Windows - Routinen sind. Diese API - Routinen können von Visual Basic zwar nicht direkt angesprochen werden - sie müssen zuvor deklariert werden - sind später aber voll funktionsfähig. Der einzige Nachteil dieser Funktionen gegenüber den Visual Basic - Funktionen ist der, daß alle Sicherheitsmechanismen bei dem Aufruf einer API von Visual Basic außer Kraft gesetzt sind, da diese bekanntlich nicht zu Visual Basic sondern zu Windows selbst gehören.
Allgemeine Informationen:
Eine besondere Variante, die Leistungsfähigkeit von Visual Basic erheblich zu steigern, liegt im Einsatz von dynamischen Verbindungsbibliotheken, den sogenannten DLLs (Dynamic Link Library).
Auch die Windows API Funktionen sind in diesen Dateien enthalten. Visual Basic selbst kann keine DLLs mit exportierten Funktionen erzeugen. Höhere Programmiersprachen wie z.B.: Delphi oder C/C++ können Funktionen aus DLLs direkt exportieren.
Sicherheitsaspekte beim Gebrauch von API - Routinen:
Die Sicherheits- und Überprüfungsmöglichkeiten von Visual Basic sind beim Aufruf von DLL - Routinen außer Kraft gesetzt. Deshalb ist es notwendig, daß vor jedem Aufruf eines DLL beinhaltenden Programmes die Quelldatei gespeichert wird, um etwaigem Datenverlust vorzubeugen.
Die Deklaration von DLL - Routinen:
An dieser Stelle soll zuerst die Schnittstelle von Visual Basic erklärt werden, die den Zugriff auf DLL - Routinen ermöglicht. Jede DLL - Routine muß vor Ihrem Einsatz zunächst deklariert werden. Neben dem Prozedurnamen muß sowohl die dynamische Verbindungsbibliothek (DLL) als auch die Parameterliste genannt werden. Mit der Anweisung Declare kennzeichnen Sie eine Prozedur als extern (außenständig, nicht direkt in Visual Basic implementiert). Der DLL - Name muß angegeben werden, da die DLL dynamisch zur Laufzeit an ein Programm gebunden ist (sie wird erst während der Ausführung des Programms benötigt, nicht gleich beim Aufruf). Die DLL muß sich entweder im Programm- oder Windows - Systemverzeichnis befinden. Ist dies nicht der Fall, muß explizit der Suchpfad mit angegeben werden. Es sollten jeweils nur Deklarationen in ein Programm aufgenommen werden, die unbedingt benötigt werden.
Die allgemeine Syntax lautet:
DECLARE FUNCTION LIB "BIBLIOTHEK.DLL" [ALIAS "ORIGINALNAME"] ([[BYVAL|BYREF] VARIABLENNAME [AS VARIABLENTYP] [,[BYVAL|BYREF] VARIABLENNAME ...][....]])
BZW.
DECLARE SUB LIB "BIBLIOTHEK.DLL" [ALIAS "ORIGINALNAME"] ([[BYVAL|BYREF] VARIABLENNAME [AS VARIABLENTYP] [,[BYVAL|BYREF] VARIABLENNAME ...][....]])
Der Abschnitt Lib LibName in der Declare - Anweisung teilt Visual Basic mit, wo die Dynamic - Link Library gespeichert ist. Betriebssystem - DLLs sind entweder "User", "GDI" oder "Kernel" oder eine der anderen System - DLLs wie "MMSystem". Bei anderen DLLs ist LibName ein Dateiname, der auch eine Pfadangabe enthalten kann.
Mit der Alias - Klausel kann eine Prozedur deklariert und damit einhergehend umbenannt werden. Diese Umbenennung ist dann sinnvoll, wenn ein Name einer DLL - Prozedur in Visual Basic nicht gültig ist oder aber bereits definiert ist. Wird eine Routine innerhalb DLL lediglich unter einer Ordnungszahl verwaltet, muß die Prozedur wie unten beschrieben deklariert werden.
DECLARE PROZEDURNAME LIB "BIBLIOTHEK.DLL" ALIAS "#ZAHL" .......
Die Ordnungsnummer wird im Zeichenkettenformat angegeben und mit einem Doppelkreuz eingeleitet. Die Parameterliste ist optional, lediglich die runden Klammern sind in jedem Fall mit anzuführen. Die Parameterliste kann einen oder mehrere Parameter enthalten. Jeder Parameter muß mit einem Datentyp versehen werden. Folgende Besonderheiten sind bei der Übergabe von Werten an DLL - Routinen zu berücksichtigen.
Wert oder Referenzübergabe von Argumenten:
Standardmäßig übergibt Visual Basic alle Argumente als Referenz. d.h. Visual Basic übergibt die 32-Bit-Adresse, an der der Wert gespeichert ist, und nicht den eigentlichen Wert des Arguments. Das Schlüsselwort ByRef muß zwar nicht angegeben werden, man kann es aber zur Dokumentation im Code verwenden, damit offensichtlich ist, wie Daten übergeben werden.
Viele DLL - Prozeduren erwarten, daß ein Argument als Wert übergeben wird, d.h. sie erwarten den eigentlichen Wert und nicht die Speicheradresse des Wertes. Wenn ein Argument als Referenz an eine Prozedur übergeben wird, die eine Übergabe des Wertes erwartet, erhält die Prozedur falsche Daten und kann nicht korrekt ausgeführt werden.
Ein Argument kann als Wert übergeben werden, indem vor der Argumentdeklaration in der Declare - Anweisung das Schlüsselwort ByVal eingefügt wird. Dies gewährleistet, daß das Argument bei jedem Prozeduraufruf als Wert übergeben wird.
Konvertieren von C - Deklarationen nach Visual Basic:
Die Prozeduren in DLLs werden meistens in der Syntax der Programmiersprache C dokumentiert. Um sie von Visual Basic aus aufzurufen, müssen sie in gültige Declare - Anweisungen übersetzt und ordnungsgemäß aufgerufen werden. Die folgende Tabelle enthält eine Liste der wichtigsten C - Deklarationen und der jeweiligen Entsprechung in Visual Basic.
Zeichenkettenübergabe:
Zeichenketten, die an DLL - Routinen übergeben werden, enden im Regelfall mit Chr$(0) (ASCII - String). Das Nullzeichen wird automatisch an eine Zeichenkette, die an eine DLL Routine übergeben wird, angehängt, wenn sie innerhalb der Parameterliste mit dem Schlüssel ByVal deklariert ist. Zeichenketten werden an DLL - Routinen immer als Referenz übergeben. DLL - Routinen liefern in der Regel nur Zeichenketten mit maximal 255 Zeichen zurück. Die Länge einer Zeichenkette kann in der DLL nicht geändert werden, sofern die Routine nicht speziell für Visual Basic geschrieben wurde. Eine Zeichenkette, die ein Ergebnis zurückliefert, muß daher in der Regel zunächst auf 255 Zeichen initialisiert werden. Dies kann mit dem Befehl Variable1$ = Space$(255). Funktionen, die in einem Parameter eine Zeichenkette mit dem Wert Null erwarten, können die Visual Basic Konstante VbNullString erhalten. Zeichenketten fester Länge können an DLL - Funktionen nicht übergeben werden. Gibt eine DLL - Funktion eine Zeichenkette zurück, so ist diese ebenfalls mit Chr$(0) abgeschlossen. Left$(Rückgabewert$, InStr(Rückgabewert$, Chr$(0)) - 1) liefert dann einen String in der richtigen Länge.
Hierzu ein Beispiel: Mit Hilfe einer API - Routine wird versucht, das Systemverzeichnis des Betriebsystemes Windows95 zu eruieren. Angenommen es lautet "C:\\WINDOWS\\SYSTEM". Diese Variable benötigt mindestens eine Länge von 17 Zeichen. Wird das Feld, also die Variable, in die der Wert geschrieben wird nur mit 15 Zeichen initialisiert, so werden die letzten zwei Zeichen in den Speicher geschrieben. Anstelle der ansonsten reservierten 255 Zeichen (Visual Basic liefert keinen String zurück, der länger ist als 255 Zeichen) sind nun nur 15 Zeichen im Speicher frei. Angenommen, im Speicher würde hinter unserer Variable gleich anschließend eine wichtige Windows - Systemdatei stehen, so würde es zu einem Datenverlust kommen, da die ersten beiden Zeichen der Variable die ersten Zeichen der Systemdatei überschreiben würden. Unter Umständen könnte es auch zu einem Systemabsturz kommen, wenn auf die wichtige Datei unmittelbar danach zugegriffen wird, da sie 2 Byte an Fehlinformationen enthält. Um dies zu verdeutlichen habe ich eine Zeichnung angefertigt.
Hier wurde die Systemdatei Kernel.dll mit der Variable, die die gewünschten Informationen enthält überschrieben. Es wäre aber ebenso möglich, daß unsere Variable von einer anderen Datei überschrieben werden würde, was wiederum einen Datenverlust, nur diesmal bei unserem Programm, zur Folge hätte.
Normalerweise nimmt eine Variable, die mit 255 Zeichen initialisiert wurde, immer 255 Zeichen Platz ein. Es wären also im Normalfall 17 Zeichen und 208 Leerzeichen (208 + 17 = 255).
Ungültige Namen:
Mitunter hat eine DLL - Prozedur einen Namen, der kein gültiger Bezeichner ist. Der Name kann ein ungültiges Zeichen (beispielsweise einen Bindestrich) enthalten oder mit einem reservierten Wort von Visual Basic (beispielsweise GetObject) übereinstimmen. In diesem Fall muß das Schlüsselwort Alias verwendet werden.
Einige Prozeduren in den DLLs der Betriebsumgebung beginnen beispielsweise mit einem Unterstrich. Zwar können Sie Unterstriche in Visual Basic - Bezeichnern verwenden, doch darf der Unterstrich nicht das erste Zeichen sein. Um solche Prozeduren verwenden zu können, muß die Prozedur mit Alias deklariert werden:
DECLARE FUNCTION LOPEN LIB \"KERNEL\" ALIAS \"_LOPEN\" (BYVAL FN AS STRING, BYVAL F AS INTEGER) AS INTEGER
In diesem Beispiel ist LOpen der Name der Prozedur, wie er in der Visual Basic - Prozedur verwendet wird. Der Name _lopen ist der Name, der in der DLL erkannt wird.
Der Alias - Abschnitt, kann verwendet werden, wenn immer es angebracht ist. Die folgende Declare - Anweisung ersetzt beispielsweise einen langen Namen (GetWindowsDirectory) durch einen kürzeren Namen (WinDir):
DECLARE FUNCTION WINDIR LIB \"KERNEL\" ALIAS \"GETWINDOWSDIRECTORY\" (BYVAL LPBUFFER AS STRING, BYVAL NSIZE AS INTEGER) AS INTEGER
Nun kann die Funktion mit einem kürzeren Namen aufgerufen werden:
DIM WINPATH AS STRING
WINPATH = STRING(145, CHR(0))
WINPATH = LEFT(WINPATH, WINDIR(WINPATH, LEN(WINPATH)))
Übergeben von Zeichenfolgen:
Visual Basic verwendet einen String - Datentyp, der als BSTR bezeichnet wird und einen Datentyp darstellt, der durch die OLE-Automatisierung definiert wird. Ein BSTR - Wert verhält sich wie ein Zeiger auf das erste Datenbyte. BSTR - Werte verweisen auf Zeichenfolgen, die durch ein Null - Zeichen (ANSI-Wert Null) begrenzt sind. Den Daten ist ein Header vorangestellt, der von Visual Basic verwendete Informationen enthält. Der BSTR - Wert ignoriert diesen Header und verweist auf das erste Datenbyte in der Zeichenfolge.
Die folgende Funktion würde Daten in eine Variable schreiben. Ist diese Variable aber nicht lange genug (z.B.: weniger als zehn Zeichen, obwohl 17 benötigt würden), so würde die API - Funktion über den reservierten Speicher hinausschreiben, ein anderer Inhalt würde überschrieben werden und ein Datenverlust wäre die Folge.
DECLARE FUNCTION GETWINDOWSDIRECTORY LIB \"KERNEL\" (BYVAL LPBUFFER AS STRING, BYVAL NSIZE AS INTEGER) AS INTEGER
Eine sichere Lösung zum Aufrufen der Prozedur ist das Erstellen eines Rückgabearguments, das mindestens 255 Zeichen lang ist, durch Auffüllen des Arguments mit Zeichen - in diesem Fall mit Null - Zeichen (Binärwert Null):
PATH = STRING(255, 0)
RETURNLENGTH = GETWINDOWSDIRECTORY(PATH, LEN(PATH))
PATH = LEFT(PATH, RETURNLENGTH)
16/32 bit - Anwendungen:
Sehr wichtig bei der Betrachtung von 16-Bit- und 32-Bit-Versionen von Visual Basic 4.0 sind Fragen im Zusammenhang mit ANSI und UNICODE. Wenn DLLs geschrieben werden, verwenden ANSI-Zeichenfolgen ein Byte pro Zeichen und UNICODE - Zeichenfolgen zwei Byte pro Zeichen.
Die 16-Bit-Version von Visual Basic verwendet entweder ANSI- oder DBCS - Zeichenfolgen. Die 32-Bit-Version von Visual Basic verwendet UNICODE - Zeichenfolgen. Deshalb sollte eine Reihe von Dingen berücksichtigt werden, wenn DLLs für die Verwendung mit Visual Basic 4.0 geschrieben werden.
1.) Wenn eine 1-Byte-Variable benötigt wird, kann \'String * 1\' in der 16-Bit-Version von Visual Basic verwendet werden. In der 32-Bit-Version von Visual Basic nimmt \'String * 1\' jedoch tatsächlich zwei Bytes im Speicher ein. Darum wurde der Datentyp Byte eingeführt. Dieser Datentyp nimmt 1-Byte im Speicher ein, unabhängig davon, ob er in der 16-Bit- oder in der 32-Bit-Version von Visual Basic verwendet wird.
2.) In Win32 (32bit Bsp.: Win95, WINNT) wird bei Namen von DLL - Prozeduren zwischen Groß- und Kleinschreibung unterschieden. In Win16 (16bit Bsp.: Windows 3.11) ist dies nicht der Fall. GetSystemMetrics und GETSYSTEMMETRICS sind daher unterschiedliche Funktionen. Dennoch ist in diesem Fall nur der erste Name korrekt, so wie er in USER32.DLL existiert. Wenn also die normale DECLARE - Anweisung für diese Funktion:
DECLARE FUNCTION GETSYSTEMMETRICS LIB \"USER32\" (BYVAL N AS INTEGER) AS INTEGER
auch an anderer Stelle im Projekt existiert (z.B. wenn die FESTSTELL - TASTE bei der Eingabe des Funktionsnamens zufällig gedrückt wird), z.B. als
DECLARE FUNCTION GETSYSTEMMETRICS LIB \"USER32\" (BYVAL N AS INTEGER) AS INTEGER
wird auch die vorherige Definition dementsprechend geändert.
In Win16 gibt es diesen Unterschied nicht, da bei Funktionsnamen nicht zwischen Groß- und Kleinschreibung unterschieden wird. In Win32 würde jedoch ein Laufzeitfehler auftreten, da GETSYSTEMMETRICS nicht in der DLL existiert. Dieses Problem kann dadurch umgangen werden, indem der Alias - Abschnitt wie folgt verwendet wird:
DECLARE FUNCTION GETSYSTEMMETRICS LIB \"USER32\" ALIAS GETSYSTEMMETRICS (BYVAL N AS INTEGER) AS INTEGER
So wird sichergestellt, daß der im Alias verwendete Name nicht von einer Umwandlung (falls sie vorkommt) betroffen ist. Unabhängig davon, wie der Name in anderen Teilen des Codes verwendet wird, bezieht sich die Deklaration somit weiterhin auf den korrekten Prozedurnamen in der DLL.
Bedingte Kompilierung:
Die Befehle, die zur bedingten Kompilierung notwendig sind, gleichen den normalen Visual Basic Befehlen (If, ElseIf, Else, End If). Der einzig große Unterschied besteht darin, daß diese Befehle nur einmal ausgeführt werden, und zwar dann, wenn das Programm kompiliert wird. Um dies zu verdeutlichen muß ich an dieser Stelle ein Beispiel aufzeigen: Es ist möglich, daß ein Programm sowohl unter Windows 3.11 (o.ä.) als auch unter Windows95 ausgeführt werden soll. Nun lauten aber die Aufrufe für die Win16 API anders als für die Win32 API. Hier schaltet sich nun die bedingte Kompilierung ein. Falls die Win32 API benötigt wird, werden die Anweisungen für diese geladen und die Anweisungen für die Win16 API übersprungen und umgekehrt.
|
