Turbo Toolbox

home *** CD-ROM | disk | FTP | other *** search

/ Turbo Toolbox / Turbo_Toolbox.iso / turbo5 / doc / helpme.doc < prev next >

Wrap

Text File | 1988-10-09 | 24.1 KB | 547 lines

ALLGEMEINE FRAGEN UND ANTWORTEN ZU TURBO PASCAL 5.0 --------------------------------------------------- 1. Ist die Größe des Programmcodes und der Daten in irgendeiner Form begrenzt (wie in der Version 3.0)? Jedes Modul eines Programms (d.h. jedes Unit und das Hauptprogramm) arbeitet mit einem (konstanten) Code-Segment und kann deshalb maximal 64 KByte umfassen. Die Gesamtgröße eines Programms ist nur durch den verfügbaren Hauptspeicher begrenzt (max. 640 KByte). Alle globalen Variablen und Konstanten eines Programms werden in einem Daten-Segment gespeichert und sind nach wie vor auf 64 KByte beschränkt. Der Heap hat (wie in der Version 3.0) keine Größenbe- schränkung. Die entsprechenden Verwaltungsroutinen arbeiten wesentlich schneller und effizienter (minimale Blockgröße der Version 3.0: 8 Bytes, in der Version 5.0: 1 Byte). Zusätzlich läßt sich eine Fehlerbehandlungsroutine installieren, die automatisch aufgerufen wird, wenn New oder GetMem der Speicherplatz ausgeht. 2. Ist Turbo Pascal auf MS-DOS-Maschinen lauffähig, die nicht direkt "kompatibel" sind? Die Kommandozeilen-Version des Compilers (TPC.EXE) macht überhaupt keinen Gebrauch von PC-spezifischen Eigenschaften, wenn sie mit dem Zusatzparameter /Q aufgerufen wird; die Routinen der Units System, Dos und Printer sollten auf allen DOS-Maschinen lauffähig sein. Mit Turbo Pascal erzeugte .EXE-Dateien sind deshalb 100%ig DOS- kompatibel, solange nicht ein oder mehrere der PC-spezifischen Units (Crt, Graph und Graph3) verwendet werden. Die Software- Fließkommafunktionen und der Emulator sind auf jeder DOS-Maschine verwendbar; die 8087-Bibliothek (Modus {$N+,E-}) setzt voraus, daß ein entsprechender Coprozessor installiert ist, der hardware- mäßig in derselben Weise angesteuert wird wie bei einem Computer der PC-Serie. 3. Unterstützt die Version 5.0 verschieden große Integerwerte? Sie tut es - und zwar in jeder denkbaren Form vordefinierter Integertypen mit 8 Bit (ShortInt, Byte), 16 Bit (Integer, Word) und 32 Bit (LongInt). 4. Kann man die 4.0-Toolboxen mit 5.0 verwenden? Ja. Alles, was sich hier geändert hat, sind zwei Compiler-Schal- ter: {$T} ("TPM-Datei erzeugen") existiert nicht mehr; {$A} (für byte- bzw. wortweise Anordnung von Variablen im Speicher) ist neu dazugekommen. Die Datei README beschreibt detailliert, in welchem Toolbox-Quelltext welche Zeile zu ändern ist - und die Liste für sämtliche Toolboxen ist gerade eine viertel Seite lang. 5. Läßt sich die Compilierung von Programmteilen von Bedingungen abhängig machen (wie in Turbo C)? Ja - wobei nicht nur die Definition von Symbolen (mit {$DEFINE} und {$UNDEF}) und Prüfungen (mit {$IFDEF..$ELSE..$ENDIF}) möglich sind, sondern auch Tests von Compiler-Schaltern. Damit lassen sich beispielsweise Real-Datentypen abhängig davon definieren, ob der Computer mit einem numerischen Coprozessor ausgerüstet ist oder nicht. Zusätzlich lassen sich Symbole zur bedingten Compilierung auch direkt beim Aufruf des Compilers (d.h. ohne Veränderung des Quelltextes) definieren. 6. Wieviel Platz im Daten-Segment belegt das System, wieviel ist tatsächlich für das Programm verfügbar? Der Platzbedarf der Laufzeitbibliothek im Daten-Segment des Programms hängt davon ab, welche Units aufgenommen werden: UNIT Datengröße (in Bytes) ---- --------------------- SYSTEM 664 OVERLAY 10 DOS 6 CRT 20 PRINTER 256 GRAPH 1070 TURBO3 256 GRAPH3 0 ========= 2282 Die Gesamtgröße des Daten-Segments beträgt 65520 Bytes. Einem Programm, das nur das Unit System verwendet, stehen also 65520 - 664 = 64856 Bytes für globale Variablen und Konstanten zur Verfügung. 7. Welche Größe kann eine Datenstruktur maximal haben? Ein Aufruf von GetMem oder New kann maximal 65521 Bytes auf dem Heap belegen. Diese Grenze gilt im Prinzip auch für die Deklara- tion statischer (globaler) Variablen. 8. Läßt sich feststellen, wieviel Bytes Code und wieviele Bytes Daten die Compilierung eines Programms oder Units erzeugt? Innerhalb der integrierten Entwicklungsumgebung compilieren Sie das entsprechende Modul und wählen dann "Get info" aus dem Menü Compile. Die Kommandozeilen-Version von Turbo Pascal gibt die ent- sprechenden Daten automatisch am Ende einer Compilierung aus. 9. Wie sieht es mit der Kompatibilität zwischen Turbo Pascal 5.0 und .OBJ-Dateien aus, die mit Turbo C oder dem Turbo Assembler erzeugt worden sind? Mit Turbo C oder Turbo Assembler erzeugte .OBJ-Dateien können über den Compiler-Befehl {$L} in ein Pascal-Programm aufgenommen werden (siehe CPASDEMO.C und CPASDEMO.PAS auf der Diskette II). Turbo Pascal selbst erzeugt keine Object-, sondern .TPU-Dateien (wobei das Suffix TPU für "Turbo Pascal Unit" steht) Dafür gibt es mehere Gründe: - .TPU-Dateien enthalten neben dem Object-Code Informationen für die Fehlersuche und die strenge Typ-Prüfung von Pascal bei der Einbindung in ein Programm. Trotzdem sind sie wesentlich kleiner als .OBJ-Dateien. - .TPU-Dateien erlauben ein "intelligentes" Binden - nicht benutzte Code- und Datenbereiche werden vom Linker automatisch entfernt. - Das .TPU-Format ist wesentlich einfacher zu bearbeiten und einer der Gründe für die hohe Geschwindigkeit des Compilers (bis zu 34000 Zeilen pro Minute auf einem PS/2 Modell 60). 10. Lassen sich mit {$L} auch Dateien einbinden, die mit anderen Compilern erzeugt wurden (FORTRAN etc.)? Das hängt vom Compiler bzw. der Programmiersprache ab. Turbo Pascal erwartet den gesamten Programmcode einer .OBJ-Datei in *einem* Segment mit dem Namen CODE, sämtliche Daten müssen ebenfalls in einem Segment (mit dem Namen DATA) gespeichert sein. Wenn Sie Maschinenprogramme mit einem Assembler schreiben, lassen sich diese Bedingungen recht einfach erfüllen - anders sieht es dagegen mit einem Hochsprachen-Compiler aus, der in den meisten Fällen mit mehreren Segmenten für Code und Daten arbeiten wird. (Allerdings: Auch Turbo C arbeitet mit einer größeren Zahl von Segmenten - und mit dem Beispielprogramm CPASDEMO.C (auf der Diskette 3) haben wir bewiesen, daß die Sache so schwie- rig nicht ist). 11. Der Linker arbeitet "intelligent" und entfernt unbenutzten Code. Wie sieht es mit unbenutzten Datendeklarationen aus? Unbenutzte Datendeklarationen wurden in der Version 4.0 noch mitgeschleppt - in der Version 5.0 analyisert der Linker dagegen einzelne *Deklarationsabschnitte* und entfernt sie gegebenenfalls. (Im Kapitel 8 des Addendums finden Sie eine detaillierte Beschrei- bung des Wie und Wo). 12. Wenn ein Unit in zwei Modulen eines Programm mit uses angeführt ist, wird es dann auch doppelt in die .EXE-Datei aufgenommen? Nein. Unabhängig davon, wie komplex die gegenseitigen Abhängig- keiten einzelner Units und Programmteile aussehen, nimmt Turbo Pascal von jeder benötigten Prozedur oder Funktion exakt EINE Kopie in die .EXE-Datei auf - nicht mehr und nicht weniger. 13. Was passiert, wenn Compiler-Schalter in den Modulen eines Programms unterschiedlich gesetzt sind? Compiler-Befehle sind "lokal" zum jeweiligen Unit oder dem Haupt- programm; auch bei einem MAKE oder BUILD beginnt die Compilierung jedes Moduls mit den über die Menüs bzw. durch die Kommandozeilen- Parameter gesetzten Standardvorgaben. Die Schalterstellungen einzelner Module sind also unabhängig voneinander. 14. Ist die Erzeugung eigener Unit-Bibliotheken (.TPL-Dateien) möglich? Im Prinzip ja. Der Compiler verwendet allerdings nur eine einzige Bibliothek (TURBO.TPL). Mit dem Programm TPUMOVER können Sie TURBO.TPL eigene Units hinzufügen - es wäre also möglich, für jedes größere Projekt eine separate Version von TURBO.TPL zu erzeugen, die dann jeweils ins "Turbo directory" hineinkopiert werden müßte. 15. Welche Regeln sind bei der Erstellung von Interrupt-Behandlungsroutinen zu berücksichtigen? Abgesehen davon, daß Sie sich mit dem BIOS des Computers und mit Maschinensprache gut auskennen sollten, gibt es einige Punkte im Zusammenhang mit Turbo Pascal: - Verwenden Sie GetIntVec und SetIntVec (aus dem Unit Dos) zur Veränderung von Interrupt-Vektoren. - Deklarieren Sie die Behandlungsroutine als interrupt und verwenden Sie den Compiler-Befehl {$F+} - die Routine muß als FAR codiert werden. - Verwenden Sie innerhalb der Behandlungsroutine keine Aufrufe von DOS-Funktionen, der dynamischen Speicher- verwaltung oder der Overlay-Verwaltung - der entsprechende Code ist nicht reentrant. - Interrupt-Prozeduren und Funktionen müssen mit Compilerdirektive $F+ (far calls) compilert werden - ACHTUNG: Die Interrupt-Behandlungsroutine darf *nicht* als Teil eines Overlays codiert sein oder Routinen auf- rufen, die sich ihrerseits in Overlays befinden. 16. Wann ist eine Pascal-Routine als NEAR codiert, wann als FAR? Die allermeisten Programmierer werden sich um dieses Detail nie zu kümmern brauchen - schließlich wählt der Compiler die richtige Art des Aufrufs automatisch aus. FAR-Aufrufe und Rücksprünge werden nur benutzt, wenn - die Routine im Interface-Teil eines Units deklariert ist - oder der Compiler-Befehl {$F+} gegeben wurde. Dieser Befehl *muß* für die folgenden Routinen verwendet werden: + Interrupt-Behandlung + Fehlerbehandlung + Exit-Prozeduren + bei Verwendung von prozeduralen Typen + Overlays 17. Lassen sich mit Turbo Pascal reentrante Routinen schreiben? Ja, wenn Sie die folgenden Regeln berücksichtigen: - Alle Daten, die die Routine verändert, müssen sich auf dem Stack des Prozessors befinden (d.h. lokale Variablen oder übergebene Parameter sein). - Typisierte Konstanten werden auch dann im Datensegment gespeichert, wenn sie lokal deklariert sind. Sie dürfen durch die Routine nicht verändert werden. - Punkte, an denen die Routine nicht unterbrochen werden darf, müssen mit entsprechenden Befehlen (CLI / STI) eingefaßt werden. - Die Routine darf keine anderen Routinen aufrufen, die ihrerseits nicht ebenfalls reentrant sind (wie z.B. DOS). 18. Was muß bei Verwendung IEEE-Fließkommatypen beachtet werden ? Die Datentypen Single, Double, Extended und Comp sind nur im Modus {$N+} verfügbar. In der Version 5.0 setzt dieser Modus aber keinen numerischen Coprozessor voraus - mit dem Compiler-Befehl {$E+} läßt sich ein *Emulator* einbinden, der einen Coprozessor nötigenfalls softwaremäßig simuliert. Sie sollten allerdings überlegen, auf welchen Maschinen Ihr Programm später laufen wird: Wenn diese Maschinen überwiegend ohne Coprozessor auskommen müssen, dann empfiehlt sich trotz des Emulators der Modus {$N-} und der Datentyp Real: Variablen dieses Typs sind zwar um einiges ungenauer als das Format Double, werden aber auf Maschinen ohne Coprozessor erheblich schneller bearbeitet. Für Maschinen, die mit einem Coprozessor ausgerüstet sind, gilt das Gegenteil, weil der Typ Real vor jeder Rechenoperation soft- waremäßig in ein IEEE-Format umgerechnet werden muß - folglich sind hier der Modus {$N+} und die Datentypen Single..Extended immer die bessere Wahl. 19. Was bitte ist der Typ Comp? Der Datentyp Comp speichert extrem große Integerzahlen - ähnlich wie bei den BCD-Typen läßt er sich am besten für Operationen verwenden, bei denen keine Rundungsfehler auftreten dürfen. Obwohl Comp keine "Stellen nach dem Komma" definiert, lassen sich Geldbeträge sehr einfach mit Comp-Variablen berechnen, wenn man mit der Einheit "Pfennig" arbeitet und Ergebnisse bei der Ausgabe durch 100 dividiert. 20. Wieviele signifikante Stellen bieten die IEEE-Realtypen? Die Antwort auf diese Frage ist eine Tabelle: Typ signifikante Dezimalstellen Platzbedarf ------------------------------------------------------ Single 7-8 4 Bytes Double 15-16 8 Bytes Extended 19-20 10 Bytes Comp 19-20 8 Bytes 21. Wo und wie werden Zwischenergebnisse bei Operationen mit IEEE-Realtypen gespeichert? Auf dem Stack des 8086. Dasselbe gilt für die Übergabe von Fließkomma-Werten an Prozeduren und Funktionen (die in der Version 4.0 noch direkt in die Rechenregister des 8087 geladen wurden). 22. Wie werden IEEE-Fließkommazahlen gerundet? Der numerische Coprozessor verwendet ein Rundungsverfahren aus dem Bankwesen, das sich von der Schulmathematik leicht unterscheidet - er rundet "Werte in der Mitte" immer zum nächsten *geradzahligen* Wert hin. Einige Beispiele dazu: Round(0.4) -> 0 Round(0.5) -> 0 Round(0.6) -> 1 Round(1.4) -> 1 Round(1.5) -> 2 Round(1.6) -> 2 =============== 23. Lassen sich Ein-/Ausgaben eines Turbo Pascal-Programms umleiten? Solange Sie das Unit Crt *nicht* benutzen, läßt sich ein Turbo Pascal-Programm beim Aufruf von der DOS-Kommandoebene aus in derselben Weise umleiten wie jedes andere Programm auch. Wenn Sie Crt verwenden und sich die Möglichkeit zu Umleitung der Ein-/Ausgabe offenhalten wollen, können Sie die Textdatei- Variablen Input und Output mit Assign den Standardwegen von DOS zuordnen: Assign(Output,''); Rewrite(Output); Assign(Input, ''); Rewrite(Input); 24. Wie lassen sich 3.0-Programme konvertieren, die mit Chain-Dateien arbeiten? Chain und Execute sind für .EXE-Dateien prinzipbedingt nicht anwendbar. Die Version 5.0 bietet aber eine ganze Reihe von Alternativen: - Compilierung der einzelnen Chain-Module als Units - Compilierung der Module als eigenständige Programme und Aufruf über die neue Prozedur Exec des Units DOS - Compilierung der einzelnen Chain-Module als Overlays (was in den meisten Fällen die beste Lösung sein dürfte). 25. Wie war das mit Overlays? *Das* ist eine der vielen Erweiterungen der Version 5.0 gegen- über der Version 4.0. (Siehe Addendum, Kapitel 5, Beispielpro- gramme OVRDEMO.PAS...) 26. Unterstützt Turbo Pascal 5.0 das Sperren von Dateien und einzelnen Records beim Betrieb in Netzwerken? Im Prinzip ja. Das Unit System enthält eine Variable namens FileMode, über die die Art der Öffnung von Dateien festgelegt werden kann. Die Laufzeitbibliothek enthält keine speziellen Funktionen für das Sperren von Records und Dateiteilen (was aber durch entsprechende Aufrufe von DOS ohne weiteres möglich ist). 27. Lassen sich Routinen über Zeigervariablen aufrufen? Ja - und zwar (im Gegensatz zu den Versionen 3.0 und 4.0) ohne Tricks sowie mit sämtlichen Prüfmöglichkeiten durch den Com- piler (Parameterzahl, -reihenfolge und -typ, Codierung als NEAR oder FAR etc). Kurz gesagt: die berüchtigten "prozeduralen Para. meter" werden voll und ganz unterstützt. (Siehe Addendum, Kapitel 7, Beispielprogramm PROCVAR.PAS, DIRDEMO.PAS...) 28. Kennt Turbo Pascal berechnete Konstanten (wie z.B. Turbo C)? Ja. Ab der Version 5.0 sind const-Deklarationen als *Ausdrücke* definiert, die zum Zeitpunkt der Compilierung berechnet werden. Die Möglichkeiten sind fast unbegrenzt: const ElemCount = 100; var SortArray: array[1..ElemCount-1] of Integer; const SortSize: Integer = ElemCount * SizeOf(Integer); 29. Wie sieht es mit der größeren Effektivität der Version 5.0 im direkten Vergleich zur Version 3.0 aus? Die Programme belegen rund 30% weniger Platz auf der Diskette, die "typische" Geschwindigkeitssteigerung liegt zwischen 15 und 30%. 30. Welche Lizenzgebühren müssen für die Weitergabe selbst- entwickelter Turbo Pascal-Programme an Borland gezahlt werden? Wie bitte? So etwas haben wir noch nie nötig gehabt. 31. Wie sieht es mit der Fehlersuche aus, d.h. einem Debugger? In der Version 5.0 haben Sie schon fast die Qual der Wahl: - die integrierte Entwicklungsumgebung enthält einen Debugger, der *auf der Quelltext-Ebene* und mit Pascal-Befehlen arbeitet. Er erlaubt die schrittweise Ausführung, die Ausgabe und *Veränderung* von Variablenwerten des laufenden Programms, Abbruchpunkte... - für die Fehlersuche auf der Ebene der Maschinensprache bieten wir den Turbo Debugger an - ein separates, eigenständiges Programm, mit dem nicht nur Pascal-Programme untersucht werden können. - Und schließlich: Die von Turbo Pascal 5.0 erzeugten .EXE- Dateien lassen sich mit jedem Debugger analysieren, der auch mit .MAP-Dateien arbeiten kann. 31. Gibt es etwas ähnliches wie die statischen lokalen Variablen von C? Globale Variablen, die im Implementations-Teil eines Units deklariert sind, werden als lokal zum entsprechenden Unit behandelt und können über den Initialisierungs-Teil des Units auf vordefinierte Werte gesetzt werden. Diese Variablen behalten ihre Werte zwischen mehreren Aufrufen des Units (wie andere globale Variablen auch). Typisierte Konstanten, die innerhalb einer Prozedur oder Funk- tion deklariert sind, werden im Daten-Segment gespeichert und ver- halten sich exakt wie statische lokale Variablen von C: sie behalten ihren Wert zwischen mehreren Aufrufen, sind aber lokal zur entsprechenden Routine. 32. Wo sind die größten Probleme bei der Konvertierung von 3.0-Programmen zu erwarten? Das hängt natürlich von der Art des Programms ab - mit UPGRADE.EXE (auf der Diskette II) und den in Kapitel 8 des Benutzerhandbuchs beschriebenen Schritten sollte eine Konvertierung aber nur in seltenen Fällen größere Probleme bereiten. UPGRADE kann sogar große Programme in Units unterteilen (und dabei selbständig die notwendigen Deklarationen der jeweiligen Interface-Teile erzeugen). - Die Übergabe von Parametern wird in der Version 5.0 wesentlich effizienter ausgeführt - dementsprechend dürften bei den meisten inline-Routinen Änderungen notwendig sein. - Der Compiler führt eine strengere Typ-Prüfung aus und wird getrennt deklarierte Typen in einigen Fällen als nicht mit einander kompatibel ausweisen. - Die Prozeduren MsDos und Intr erwarten einen Parameter des Typs Registers, der im Unit Dos deklariert ist und die in der Version 3.0 notwendige Typ-Definition Regs = record .. (AX, BX, CX, DX..) ersetzt. 33. Lassen sich kommerziell vertriebene .BIN-Dateien zusammen mit der Version 5.0 verwenden? Solange diese .BIN-Dateien nur Daten enthalten, ist eine Konvertierung mit BINOBJ.EXE (auf der Diskette II) in eine .OBJ-Datei und die nachfolgende Aufnahme in das Pascal-Programm mit dem Befehl {$L} problemlos. Die Konvertierung von .BIN-Dateien, die ausführbaren Maschinen- code enthalten, ist mit BINOBJ nicht ohne weiteres möglich - sie sollten beim Vertreiber der .BIN-Datei anfragen, ob die entspre- chenden Routinen auch im .OBJ-Format erhältlich sind. 34. Werden Erweiterungen des Hauptspeichers (EMS) unterstützt? Ja - in mehrfacher Hinsicht: - Die integrierte Entwicklungsumgebung nutzt in der Version 5.0 eine EMS-Karte als Puffer für den Editor und spart so bis zu 64 KByte Platz im Hauptspeicher ein. - Die Overlay-Verwaltung macht es mit einer speziellen Initia- lisierungsroutine (OvrInitEMS) möglich, sämtliche Overlays von der Diskette in die EMS-Karte und von dort aus bei Bedarf in den Hauptspeicher zu laden - was natürlich beim Wechsel von Overlays erhebliche Geschwindigkeitsvor- teile mit sich bringt. - Direkte Steuerungen der EMS-Karte durch ein Programm sind ebenfalls kein Problem, wie die Datei EMS.PAS (in DEMOS.ARC auf der Diskette 2) demonstriert. 35. Lassen sich nach wie vor eigene Puffer für Textdateien anlegen? Ja - allerdings nicht über eine entsprechende Deklaration der Textdatei-Variablen, sondern mit der Prozedur SetTextBuf, die auch mit dynamisch belegten Puffervariablen arbeiten kann (siehe Kapitel 8 und 26 im 4.0-Handbuch). 36. Nach der Installation von TURBO.EXE mit dem Programm TINST werden die neuen Einstellungen von Compiler-Schaltern nur teilweise benutzt. Wieso? Wahrscheinlich haben Sie im momentanen Directory (oder dem "Turbo Directory") eine Konfigurationsdatei (TURBO.TP) gespeichert. TURBO.EXE lädt diese Datei beim Start automatisch - in ihr enthaltene Parameter setzen die mit TINST festgelegten Vorgaben außer Kraft. Nach der Löschung dieser Konfigurationsdatei sollte TURBO.EXE auch die mit TINST gesetzten Vorgaben benutzen. 37. Sind Strings nach wie vor auf 255 Zeichen begrenzt? Ja. Zur Verwaltung längerer Zeichenketten müssen Sie eigene Routinen schreiben. 38. Sind Schreibaktionen zum Gerät CON nach wie vor möglich? 'Con' ist nicht mehr implementiert - solange das Unit Crt nicht verwendet wird, entspricht ein Aufruf von Write oder Writeln (ohne Angabe einer Datei-Variablen) aber exakt einer Ausgabe zu diesem DOS-Standardgerät. Die Dateiverwaltung und -systematik ist bereits in der Version 4.0 völlig neu geschrieben worden, um die Verwendung eigener Textdatei-Gerätetreiber zu ermöglichen. Mit derartigen Treibern lassen sich Schnittstellen zu beliebigen Geräten implementieren (wie den seriellen Ports, Fenster-Oberflächen usw). 39. Was bedeutet "constant merging"? Wenn ein und dieselbe String-Konstante mehrfach innerhalb eines Programms angegeben ist, belegt der Compiler nur einmal Speicherplatz dafür und verwendet ansonsten Zeiger. 40. Wie sieht es mit Laufzeitfehlern aus? Die Version 5.0 verwendet die Fehlercodes von DOS - IOResult liefert also andere Resultate als in der Version 3.0. Darüber hinaus werden nicht nur "normale", sondern auch "kritische" Fehler (wie "Laufwerk nicht bereit..") von Turbo Pascal abgefangen und können über IOResult ermittelt werden. Anhang F des Referenzhand- buchs enthält eine Liste der Fehlermeldungen und -codes.