Category : Miscellaneous Language Source Code
Archive   : EXEC33A.ZIP
Filename : LIESMICH.DOC

 
Output of file : LIESMICH.DOC contained in archive : EXEC33A.ZIP

Eine EXEC Funktion mit Speicherauslagerung
Version 3.3a, Freigegeben 93-06-22

Public Domain Software von
Thomas Wagner
Ferrari electronic GmbH
(Achtung Adress„nderung, siehe unten!)


Dieses Archiv enth„lt die Quellen fr eine 'EXEC'-Funktion die den
Aufruf externer Programme erlaubt, wobei der Programmspeicher
optional auf EMS, XMS, oder Datei ausgelagert wird. Bei Auslagerung
des Speichers werden nur noch wenige K des Hauptspeichers belegt
w„hrend das externe Programm ausgefhrt wird. Der Code/Daten-Bereich
betr„gt etwa 1k, der ben”tigte Speicherplatz ist abh„ngig von der
Speicherfragmentierung, sowie besonders von der GrӇe des
Umgebungsvariablenblocks. šblicherweise werden zwischen 2K und 7K
belegt.

Die Routinen sind kompatibel mit
Turbo C (Versionen 1.x, 2.x, sowie C++ 1.0)
Borland C++ (Version 2.0 und h”her),
Microsoft C (Versionen 5.1 und h”her),
Watcom C (Version 8.0),
Turbo Pascal (Versionen 4.x bis 6.x).

EMS (LIM 3.0 und sp„tere Versionen) oder XMS werden benutzt sofern
ausreichend Platz zur Verfgung steht. Wenn nicht, wird eine
tempor„re Plattendatei angelegt. Diese Datei wird in dem durch die
Umgebungsvariablen TEMP= oder TMP= gegebenen Pfad angelegt. Ist kein
solcher Pfad angegeben, wird der aktuelle Pfad benutzt.

Aufruf und Parameterversorgung sind in der Datei "exec.h" (C) bzw.
"exec.pas" (Pascal) detailliert dokumentiert.

Das allgemeine Format ist

retcode = do_exec (Name des auszufhrenden Programms,
Programm-Parameter und Redirection String,
Spawn-Optionen,
Ben”tigter Speicher (0xffff lagert stets aus, 0 nie),
Umgebungsvariablen-Zeiger/Flag)

zum Beispiel:

rc = do_exec ("cl", "-c -Od exec.c >&errout", USE_ALL, 0xffff, NULL);

oder, fr Pascal:

rc := do_exec ('tpc', '/$D+ exec >&errout', USE_ALL, $ffff, false);

Redirection fr Standard Input, Standard Output, und Standard Error
wird optional behandelt indem der Parameter-String nach den folgenden
Kombinationen durchsucht wird:

stdin: stdout: >file oder >>file zum Anfgen
stderr: >&file oder >&>file zum Anfgen

Redirection wird standardm„áig untersttzt. Um sie auszuschalten,
mssen Sie die Definitionen sowohl in spawn.asm als auch in
exec.c/exec.pas „ndern.

Wenn das auszufhrende Kommando eine Batch-Datei ist, wird
automatisch der Kommando-Prozessor aufgerufen. Der Kommandoprozessor
wird auch aufgerufen wenn das Kommando leer ist. Dabei wird die
COMSPEC-Umgebungsvariable benutzt um den Kommandoprozessor zu finden,
zus„tzliche Parameter in der COMSPEC-Zeile werden in die
Kommandoparameter eingefgt.

Zum Beispiel:

Es sei COMSPEC=C:\DOS\COMMAND.COM /E:960
PATH=C:\DOS;C:\CMD
Datei B.BAT existiert in C:\CMD
do_exec wird aufgerufen mit ('b', 'eins zwei >out', ...)

Dann ist das aufgerufene Kommando
C:\DOS\COMMAND.COM
mit dem Parameter-String
/E:720 /C C:\CMD\B.BAT eins zwei
und Standard Output wird umgeleitet auf die Datei 'out'.



INHALT
======

Dieses Archiv enth„lt die folgenden Dateien:

LIESMICH.DOC Diese Datei
README.DOC Englische Version dieser Datei

GETLANG.EXE Ein Hilfsprogramm zur Extraktion einer ein-
sprachigen Version aus der zweisprachigen
Quelle.
Alle C- und Assembler-Quellen (die Pascal-Quellen
leider nur teilweise) sind sowohl in Deutsch als
auch in Englisch dokumentiert, was die Quellen
schwer lesbar macht. Fr bessere Lesbarkeit
k”nnen Sie mit GETLANG eine der Sprachen
eliminieren.

Benutzung: GETLANG Sprache Compiler Ausgabe
wobei Sprache 'E' fr Englisch oder 'D' fr Deutsch
Compiler 'C' fr C Dateien, 'A' fr Assembler,
'P' fr Pascal.

Beispiele: GETLANG d a spawnd.asm
GETLANG d c extestd.c

DEUTSCH.BAT Batch-File zur Ausfhrung von GETLANG fr alle
Quelldateien, deutsche Version
ENGLISH.BAT Batch-File zur Ausfhrung von GETLANG fr alle
Quelldateien, englische Version

SPAWN.ASM Die Hauptfunktion fr exec.

Diese Datei ist fr die C und Pascal Versionen gleich.
Fr Benutzung mit Turbo Pascal muá mit dem Turbo-Assembler
assembliert werden. Die C Version kann mit TASM (geben Sie
/JMASM51 an) oder MASM 5.1 bersetzt werden.

Assemblieren mit:
tasm /DPASCAL spawn,spawnp; Fr Turbo Pascal, near calls
tasm /DPASCAL /DFARCALL spawn,spawnp;
Fr Turbo Pascal, far calls
?asm spawn; Fr C (Default small model)
?asm /DMODL=xxx spawn; For C (model 'xxx')
Beispiel:
masm /DMODL=large spawn; Large model C
tasm /DMODL=medium /JMASM51 spawn; Medium model C

SPAWNP.OBJ SPAWN assembliert fr Pascal, near calls
SPAWNCS.OBJ SPAWN assembliert fr C (small model)
SPAWNCL.OBJ SPAWN assembliert fr C (large model)

Die C Dateien wurden mit dem /MX-Schalter bersetzt um
Groá-/Kleinschreibung beim Linken zu bercksichtigen.

Hinweis fr Turbo Pascal: Sie k”nnen die "near call" Version
von SPAWN auch dann nutzen wenn Sie mit "force far calls"
kompilieren, indem Sie die "external"-Definitionen von
do_spawn und prep_swap in Datei exec.pas in {$F-} und {$F+}
einschlieáen.
Um Konfusion bei der Verwendung mehrerer Compiler zu
vermeiden, wurde das Pascal-Object "spawnp.obj" benannt.

CHECKPAT.ASM Hilfsfunktion zur Prfung und Aufl”sung eines Pfades

Diese Datei ist fr die C und Pascal Versionen gleich.
Fr Benutzung mit Turbo Pascal muá mit dem Turbo-Assembler
assembliert werden. Die C Version kann mit TASM (geben Sie
/JMASM51 an) oder MASM 5.1 bersetzt werden.

Assemblieren mit:
tasm /DPASCAL checkpat,checkpap; Fr Turbo Pascal, near calls
tasm /DPASCAL /DFARCALL checkpat,checkpap;
Fr Turbo Pascal, far calls
?asm checkpat; Fr C (Default small model)
?asm /DMODL=xxx checkpat; Fr C (model 'xxx')
Beispiel:
masm /DMODL=large checkpat; Large model C
tasm /DMODL=medium /JMASM51 checkpat; Medium model C

CHECKPAP.OBJ CHECKPAT assembliert fr Pascal, far calls
CHECKPCS.OBJ CHECKPAT assembliert fr C (small model)
CHECKPCL.OBJ CHECKPAT assembliert fr C (large model)
CHECKPAT.PAS Einbindungs-Unit fr checkpat (Nur Pascal)

Die C Dateien wurden mit dem /MX-Schalter bersetzt um
Groá-/Kleinschreibung beim Linken zu bercksichtigen.
Die Pascal-Version muá mit dem FARCALL-Schalter assembliert
werden wenn Sie sie mit der Einbindungs-Unit CHECKPAT.PAS
zusammen benutzen. Zumindest Turbo Pascal Version 5.5
verwendet offenbar stets einen Far Call wenn eine externe
Routine im Interface-Teil einer Unit definiert wird.

EXEC.PAS Interface Routinen und Dokumentation fr Turbo Pascal
EXEC.C Interface Routinen fr C
EXEC.H Interface Definitionen und Dokumentation fr C
COMPAT.H MS-C/TC Kompatibilit„ts-Definitionen fr C

Diese Dateien bereiten die Parameter fr die Hauptfunktion
vor und bearbeiten die Datei-Suche und Umgebungsvariablen.

EXTEST.C C Test-Programm fr EXEC
EXTEST.PAS Turbo Pascal Test-Programm fr EXEC

Das EXTEST Programm testet die Funktionalit„t der do_exec
Funktion. Es erwartet die Eingabe eines DOS-Kommandos und,
durch Komma getrennt, seiner Parameter. Die Eingabe einer
Leerzeile startet COMMAND.COM ohne Parameter.

MAKEPAS Make-Datei fr Turbo Pascal (Borland Make)
MAKETC Make-Datei fr Borland C++ (Borland Make)
MAKEMS Make-Datei fr Microsoft C (MS NMAKE)


Die Turbo Pascal Version von EXEC.PAS enth„lt Ersatzfunktionen fr
die Umgebungsvariablen-Zugriffsfunktionen 'envcount', 'envstr', und
'getenv', sowie eine zus„tzliche Funktion 'putenv'. Diese Funktion
erlaubt Ihnen, zur Umgebung des gerufenen Programms Strings
hinzuzufgen. Die Definition ist

procedure putenv (envvar: string);

wobei 'envstr' einen String der Form 'ENVVAR=wert' enth„lt. Das '='
ist notwendig. Um einen Umgebungsvariablenstring zu l”schen geben Sie
'ENVVAR=' an. Bitte nutzen Sie nur die Funktionen aus der EXEC Unit,
mischen Sie sie nicht mit Aufrufen der Funktionen der DOS Unit.


SUPPORT
=======

Diese Software ist "Public Domain", das heiát es gibt keinerlei
Einschr„nkungen bezglich ihrer Nutzung, ob privat oder in
kommerziellen Produkten. Es ist weder eine Registrierungsgebhr zu
zahlen, noch sind zur Nutzung irgendwelche Lizenzen erforderlich.

Dies heiát allerdings auch, daá der Autor zu keiner Leistung
gegenber dem Nutzer verpflichtet ist. Jegliche Ansprche auf
Schadenersatz bei Fehlfunktionen sind ausgeschlossen. Sie haben die
Quellen, bitte prfen Sie sie vor Nutzung.

Ich m”chte auch um Verst„ndnis bitten, daá ich nicht in der Lage bin,
kostenlose Programmierberatung zu erteilen, Spezialversionen fr
exotische Compiler zu erstellen, oder neue Versionen dieses Programms
kostenlos zu versenden.

Fehlermeldungen, Verbesserungsvorschl„ge und „hnliches senden Sie
bitte an meine Firmen-Adresse:

Ferrari electronic GmbH
Ruhlsdorfer Strasse 138
D-14513 Teltow

Tel.: (+49 3328) 474 626
Fax: (+49 3328) 438 04-0

BBS: (+49 3328) 438 04-8 (ab 15.8.93)
Bitte versuchen Sie nicht, vor dem 15.8. anzurufen!

Internet: [email protected]
BIX: twagner
Compuserve: 100023,2042

Ein eingeschr„nkter Support ist ber BIX, das Teleconferencing System
von McGraw-Hill, m”glich. Falls Sie Fragen oder Fehlermeldungen
haben, senden sie BIXmail an 'twagner'. Details ber BIX finden Sie
in der Englischsprachigen Version dieser Dokumentation.



EINSCHRŽNKUNGEN
===============

Der "keine Rckkehr"-Modus von do_exec ist nur der Vollst„ndigkeit
halber verfgbar. Er hat einige Nachteile gegenber den
Standard-Funktionen der Compiler-Bibliotheken. Insbesondere werden
offene Dateien nicht abgeschlossen, und durch die Laufzeitbibliothek
belegte Interrupt-Vektoren werden nicht auf den DOS-Standardwert
zurckgesetzt. Wenn m”glich, benutzen Sie fr diesen Modus die
Standardfunktionen.

Das Assembler-Modul "spawn" darf nicht das erste Modul beim Linken
sein. Fgen Sie es in eine Bibliothek ein, oder geben Sie spawn.obj
als eine der letzten zu linkenden Dateien an. Das spawn-Modul
berschreibt etwa 1k am Anfang des Programmspeichers. Dieser Speicher
wird zwar gesichert, er darf aber nicht Teile des Moduls selbst
enthalten, da der Programmcode dabei zerst”rt wrde. Die
do_exec-Funktion berprft diese Bedingung, und kehrt mit einem
entsprechenden Fehlercode zurck falls der Code in Gefahr w„re.

Bei Aufruf von do_exec drfen keine Interrupt-Handler installiert
sein. Dies schlieát Handler fr Control-C und Critical Errors ein.
Sofern Sie Interrupts bearbeiten wollen w„hrend Ihr Programm
ausgelagert ist, mssen Sie das spawn-Modul modifizieren, sodaá die
Handler in den residenten Teil bernommen werden.

Offene Dateien bleiben w„hrend der do_exec-Funktion ge”ffnet. Dies
reduziert die Zahl der m”glichen offenen Dateien fr das
Kind-Programm. Die Umgebungsvariable "C_FILE_INFO", die von einigen
C-Compilern bei Aufruf der Standard-Funktionen fr spawn erzeugt
wird, wird nicht untersttzt. Wenn NO_INHERIT in spawn.asm gesetzt
ist (Standard), werden alle offenen Dateien auáer den ersten fnf
Standard-Dateien vor dem Kindprozess "versteckt" und damit nicht
vererbt. Dies erlaubt dem Kindprozess, mehr Dateien zu ”ffnen, wobei
allerdings das Systemweite Limit (FILES= in config.sys) hoch genug
sein muá um alle offenen Dateien zu untersttzen.

Interne Kommandos (CD, DIR usw.) werden nicht automatisch bearbeitet.
Sie k”nnen diese ausfhren indem Sie den Kommandointerpreter laden
(durch šbergabe eines leeren Strings fr das auszufhrende Programm).
Zum Beispiel:

(C) retcode = do_exec ("dir", "*.*", USE_ALL, 0xffff, environ);
if (retcode == RC_NOFILE)
retcode = do_exec ("", "/c dir *.*", USE_ALL, 0xffff, environ);

(P) retcode := do_exec ('dir', '*.*', USE_ALL, $ffff, true);
if (retcode = RC_NOFILE)
retcode := do_exec ('', '/c dir *.*', USE_ALL, $ffff, true);



HINWEISE
========

Die Funktion sollte mit DOS bis herunter zu Version 2.11 kompatibel
sein. Getestet wurde jedoch nur unter DOS 3.3, DOS 4.0, DOS 5.0,
DOS 6.0 und DR-DOS 5.0.

Kompatibilit„t zu Compiler-Versionen wurde nur getestet mit Borland
C++ 3.1, Microsoft Visual C 1.0, und Turbo Pascal 5.5. Auf andere Compiler
habe ich leider keinen Zugriff. Turbo Pascal 6.0 scheint nach
Benutzerberichten keine Probleme mit EXEC zu haben. Eine Benutzung
mit dem DOS-Extender von Turbo Pascal 7.0 (oder anderen
DOS-Extendern) ist nicht m”glich.

Wird ein Kommando aufgerufen das resident bleibt (TSR), zum Beispiel
PRINT oder Sidekick, ist eine Rckkehr in das rufende Programm nicht
m”glich. Das Programm wird beendet, belegter Speicher in EMS/XMS wird
freigegeben, eine Auslagerungsdatei wird gel”scht.

Wenn der Programmspeicher aus mehreren DOS-Speicherbl”cken besteht,
benutzt die Auslagerungsfunktion undokumentierte DOS-Interna.
Insbesondere werden Speicherkontrollbl”cke direkt modifiziert. Dies
kann theoretisch zu Inkompatibilit„ten mit sp„teren DOS-Versionen,
oder mit DOS-Clones oder Emulatoren fhren. Im praktischen Betrieb
wurden bisher noch keine Probleme mit irgendwelchen DOS-Versionen,
einschlieálich DOS 6.0 und der DR-DOS Versionen, festgestellt.

Wenn NO_INHERIT in spawn.asm auf TRUE gesetzt ist, werden einige
undokumentierte Felder im PSP benutzt und modifiziert. Auch dies
sollte mit allen DOS-Versionen und Clones funktionieren. Sollten Sie
jedoch Probleme befrchten, k”nnen Sie NO_INHERIT auf FALSE setzen
(nicht jedoch, wenn Sie die Handle-Tabelle erweitern).


Žnderungsgeschichte
===================

Žnderungen von Version 3.3 auf 3.3a:

Auáer der Adress„nderung ist die einzige signifikante Žnderung eine
verbesserte Behandlung der Redirection. Wie unter DOS kann die
Redirection jetzt auch gemischt mit sonstigen Parametern angegeben
werden.

In der Pascal-Version wurde die Redirection nicht korrekt behandelt,
sofern mehr als eine Redirection angegeben war. Ebenso wurden
Parameter in der COMSPEC-Zeile nicht erkannt. Dies wurde korrigiert.


Žnderungen von Version 3.2a auf 3.3:

Neu ist die Bercksichtigung des unbenutzten Heap-Bereichs fr Turbo
Pascal. Dieser Bereich wird optional nicht ausgelagert, was in vielen
F„llen sowohl die Auslagerungsgeschwindigkeit erh”ht, als auch den
Speicherbedarf auf dem Auslagerungsmedium reduziert. Da dies
Versionsabh„ngig ist (Turbo Pascal Version 6 hat eine andere
Heap-Verwaltung als frhere Versionen), ist dieses Feature in der
vorbersetzten Version nicht eingeschaltet. Bitte setzen Sie PAS_FREE
in SPAWN.ASM auf TRUE, und setzen sie TPAS_6 je nach Ihrer
Turbo-Pascal-Version auf TRUE oder FALSE, um es zu nutzen.

Die Pascal "putenv" Funktion war fehlerhaft. Wenn eine Variable
gesetzt wurde, die bereits im Environment vorhanden war, wurde ein
doppelter Eintrag erzeugt statt den alten Eintrag zu l”schen.
Fehlermeldung und Korrektur von A. Bailey.

Bei der Bestimmung von Programmname und Pfad wurden Programme, deren
Basis-Name (ohne Extension) gleich dem Namen einer Subdirectory war,
unter Umst„nden nicht gefunden. Die checkpath Funktion wurde
modifiziert um diesen Fall korrekt zu behandeln. Fehlermeldung von H.
Lembke.

Bei Auslagerung auf Datei mit NO_INHERIT true und einer erweiterten
Handle-Tabelle war eine Rckkehr nicht m”glich. Dies lag daran, daá
der Tabellen-Zeiger im PSP wiederhergestellt wurde bevor der
dazugeh”rige MCB-Block alloziert und wiederhergestellt war. Der
PSP-Eintrag wird jetzt erst nach dem Zurckladen gesetzt.
Fehlermeldung von H. Lembke.

EXEC konnte nicht auslagern wenn eine erweiterte Handle-Tabelle mit
NO_INHERIT false verwendet wurde. Der MCB der die Handle-Tabelle
enth„lt wird jetzt nicht mehr ausgelagert. Dies fhrt allerdings
dazu, daá der Speicher fragmentiert wird, sodaá NO_INHERIT stets TRUE
sein sollte wenn die Handle-Tabelle erweitert werden soll.

Die C do_exec-Funktion verarbeitet jetzt auch NULL-Zeiger auf
Kommandozeile und Parameterstring korrekt.


Žnderungen von Version 3.2 auf 3.2a:

Ein Fehler in checkpat.asm, der zu nicht vollst„ndigen Pfadangaben
fhrte, wurde behoben.

Ein Fehler in spawn.asm, der dazu fhrte, daá die Dateiumleitungs-
Dateien selbst nach Programmende nicht geschlossen wurden, wurde
behoben.

Žnderungen von Version 3.1 auf 3.2:

Neu ist der Aufruf einer benutzerdefinierbaren Funktion (ber einen
Funktions-Pointer bzw. eine Prozedurvariable) aus do_exec vor
Ausfhrung des Programmaufrufs. Diese Funktion kann z.B. Meldungen
ausgeben und zus„tzliche Prfungen durchfhren. Die bisher interne
Struktur mit den Auslagerungs-Parametern wurde zug„nglich gemacht
um der Benutzerfunktion den Zugriff zu erlauben. Fr Details siehe
exec.h bzw. exec.pas, sowie das Beispiel in extest.c/extest.pas.

Ein Fehler in checkpat.asm, der bei Verwendung mit Turbo Pascal
zu Problemen mit der "exists"-Funktion fhrte, wurde behoben.

Die Pascal-Version von extest wurde (endlich) auf den gleichen
Stand wie die C-Version gebracht, ein Beispiel fr die Nutzung
der Benutzerfunktion wurde in beide Versionen eingefgt.

In exec.c wurde die Definition der internen Routinen auf "static"
ge„ndert, die Initialisierung einiger Variablen in do_exec wurde
korrigiert.


Žnderungen von Version 3.0a auf 3.1:

Neu sind vor allem die automatische Behandlung von .BAT-Dateien und
die Untersttzung der I/O-Dateiumleitung. Die Suchreihenfolge fr
Kommandos entspricht jetzt exakt der DOS-Reihenfolge, bis auf die
Bearbeitung interner Kommandos (es gibt keinen sicheren Weg fr die
Erkennung, ob ein Kommando intern oder extern ist). Dateiumleitung
ist optional. Das Interface zu do_exec hat sich nicht ge„ndert,
do_spawn ben”tigt drei neue Parameter wenn Redirection eingeschaltet
ist.

Eine Routine (checkpat.asm) die einen Pfad prft und aufl”st sowie in
seine Bestandteile aufteilt wurde hinzugefgt. Diese Routine fhrt
einige Prfungen des Pfades und des Dateinamens durch und behandelt
Critical Errors (ungltiges Laufwerk, Laufwerk nicht bereit) ohne
Benutzereingriff. Die Routine wird zur Bearbeitung des
Programm-Dateinamens, des Kommandoprozessor-Dateinamens und des
tempor„ren Dateipfades verwendet. Die Routine ist unabh„ngig von den
anderen EXEC/SPAWN-Funktionen, sie kann daher auch in anderen
Applikationen ntzlich sein.

Einige neue Fehlercodes erlauben eine bessere Analyse von
Fehlerursachen.

Der Pfad der tempor„ren Datei ist jetzt stets ein vollst„ndiger Pfad.
Ein Wechsel von Laufwerk oder Pfad w„hrend der Auslagerung kann daher
jetzt nicht mehr zum Verlust der Auslagerungsdatei fhren.

Die Prfung auf Existenz einer Datei wurde in checkpat.asm verlagert,
und von der 'find first'-Funktion auf 'get file attributes'
umgestellt. Dies scheint geringfgig schneller und vermeidet
Compiler-Abh„ngigkeiten.

Das Programm GETLANG wurde korrigiert, die Hilfs-Meldungen werden
jetzt auf stderr ausgegeben.


Žnderungen von Version 3.0 auf 3.0a:

Ein kleiner Fehler in EXEC.C wurde korrigiert: ein '<' fehlte in
einem deutschen Kommentar, sodaá bei GETLANG E ein groáer Teil der
Datei verschluckt wurde.

Ein Problem (Fehler? Feature?) bei der Turbo C/Borland C "stat"
Funktion, die fr Directories stets "read-only" liefern, verhinderte
die Benutzung der TEMP Directory beim Auslagern. Die Schreib-
Erlaubnis wird jetzt nicht mehr geprft.

Die Pr„allozierung der Auslagerungsdatei, die mit Version 3.0
eingefhrt wurde um sicherzustellen daá das Laufwerk den kompletten
Speicher fassen kann, fhrte zu starken Verz”gerungen wenn die
Auslagerungsdatei auf einem Novell-Netzwerk Laufwerk lag. Um dieses
Problem zu umgehen wurden zwei neue Flags fr den "method" Parameter
eingefhrt:

NO_PREALLOC - Nie Pr„allozieren
CHECK_NET - Nicht Pr„allozieren wenn Datei auf Netzwerk

Wenn die Datei nicht pr„alloziert wird, wird das Laufwerk nicht auf
ausreichenden Platz geprft. Die Alternative, der "get disk free
space" Aufruf, dauert im allgemeinen noch wesentlich l„nger als ein
Pr„allozieren. Dies ist allerdings kein groáes Problem, die
Auslagerung liefert lediglich den Fehlercode 0x502 wenn der
Speicherplatz nicht ausreicht.


Žnderungen fr Version 3.0:

Dies ist die erste Version mit Deutscher Dokumentation. Falls Sie mit
frheren Versionen gearbeitet haben, k”nnen Sie die Žnderungen in der
Englischen Beschreibung nachlesen - denn dann k”nnen Sie doch
Englisch, oder? 🙂


  3 Responses to “Category : Miscellaneous Language Source Code
Archive   : EXEC33A.ZIP
Filename : LIESMICH.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/