FoxPro ist tot. Jetzt gibt es FoxPro wieder.
Diese neue Edition von Visual FoxPro, genannt FoxDev Studio, überwindet die Zwei-Gigabyte-Grenze, die die ursprüngliche Software aufhielt, während es dieselbe Sprache beibehält. Es basiert auf einer Grundlage, die seit 2007 nicht eingefroren wurde. Das Ergebnis ist eine Sprache, die auf Version 9 eingefroren ist und jetzt ohne vollständige Neuschreibung erneut läuft.
Die alte Grenze
Die Software hörte auf, ihre Versionsnummerierung bei 9 zu führen, und ihre Architektur ist auf 32 Bit beschränkt. Dadurch kann eine Tabelle nicht mehr als zwei Gigabyte fassen, eine Memo-Datei ist ebenfalls auf zwei Gigabyte begrenzt, und ein langer Bericht kann Speicher auf einem Computer erschöpfen, auf dem noch viel verfügbar ist. Diese Grenzen sind nicht das Ergebnis von Lizenzentscheidungen, die von irgendjemandem getroffen wurden. Stattdessen stammen sie von vorzeichenbehafteten 32-Bit-Zahlen, die in den Code zur Dateiverarbeitung eingebaut sind.
FoxDev Studio läuft vollständig in 64-Bit. Jeder Dateiaufwand wird in 64-Bit behandelt, und eine Tabelle wird überhaupt nicht in den Speicher geladen. Das bedeutet, dass eine .dbf-Datei, die einst aufhörte zu funktionieren, jetzt in die Hundertgigabyte-Bereich weiterlaufen kann. Es gibt einen zu beachtenden Haken: Sobald eine Tabelle die Zwei-Gigabyte-Grenze überschreitet, kann sie nicht mehr in Visual FoxPro geöffnet werden. Wenn Sie also weiterhin in beiden Systemen arbeiten, wird daraus eine Einbahnstraße.
Das Fundament des Builds ist eine Sprache, die 2007 eingefroren wurde, rekonstruiert auf einer Grundlage, die seitdem nicht eingefroren wurde.
Die Laufzeitumgebung
Ihr Visual FoxPro-Programm wurde in P-Code kompiliert und kam mit einer Laufzeitumgebung für die Ausführung. FoxDev Studio wiederholt diese Struktur: einen Compiler und einen Bytecode-Interpreter, erstellt in Rust und kompiliert zu WebAssembly, sodass eine Maschine Ihren Code ausführt, wo auch immer die Anwendung läuft. Der Editor prüft, was Sie eintippen, anhand desselben Compilers, sodass das, was er unterstreicht, und das, was die Laufzeitumgebung ablehnt, nicht abweichen können.
Die Laufzeitumgebung ist neu zusammengesetzt, schnell zu starten und eigenständig. Sie räumt offen ein, welche Bereiche sie noch nicht erkundet hat, und füllt diese Lücken aus, indem sie Visual FoxPro selbst fragt, wie die Dinge funktionieren sollen, anstatt sich auf eine Referenzseite zu verlassen und zu hoffen, dass sie übereinstimmt.
Das Formular und die Brücke
Ein laufendes Programm ist ein Thread. Wenn es etwas von der Außenwelt benötigt (eine Meldungsbox, ein modales Formular, der nächste Datensatz), greift es nicht aus und pausiert; es weicht zurück, und die Aufgabe wird ausgeführt, während die Maschine vom Stack wegtritt, mit der Antwort im Gepäck. Deshalb stoppt MESSAGEBOX Ihr Programm, ohne das Fenster dahinter einzufrieren, warum READ EVENTS wartet, ohne sich im Kreis zu drehen, und warum SetFocus GotFocus auslösen und Init laufen kann, während ein Formular noch erstellt wird, wie FoxPro es immer getan hat.
React zeichnet die Benutzeroberfläche aus einem lebenden Baum von Objekten, der die erwarteten Eigenschaften enthält. Jedes Objekt beobachtet nur sich selbst, so dass das Ändern von THISFORM.lblGreeting.Caption zu cMsg nur ein Label neu zeichnet anstatt das ganze Formular. Auf einem überfüllten Bildschirm ist das der Unterschied zwischen augenblicklich und träge.
Ein einzelner Baum ist das, was der Designer formt, ein Stadium vor dem Endspurt. Kein zweites Modell hält mit dem ersten Schritt, so dass das Formular und sein Designer nie anfangen, getrennte Geschichten zu erzählen. Der Build vermeidet diese Schwierigkeiten, indem er den Baum selbst formt, anstatt eine Kopie zu behalten.
Das 32-Bit-Problem
Die .fll-Datei ist ein 32-Bit-Image, und jeder einzelne Prozess innerhalb einer 64-Bit-Anwendung ist 64-Bit, was bedeutet, dass die Anwendung selbst eines nicht öffnen kann. Anstatt Sie darauf hinzuweisen, dass dies unmöglich ist, startet SET LIBRARY TO einen kleinen 32-Bit-Prozess, dessen einzige Aufgabe es ist, Ihre Bibliothek zu halten, wobei die Laufzeit mit ihm kommuniziert. Die Aufrufe sind synchron, da ein Programm eine Bibliothek mitten in einem Ausdruck aufrufen kann, und eine Antwort, die später ankommt, nicht zur Anfrage passen würde. Es wurde anhand echter Bibliotheken gemessen: der Verschlüsselungsbibliothek, FoxTools und Bibliotheken, die aus Microsofts eigenen API-Beispielen erstellt wurden.
Es gibt keine 64-Bit-Anforderung für die Brücke: eine DECLARE … DLL-Anweisung verbindet sich mit einer modernen Bibliothek im selben Prozess, und Automatisierungs-Objekte werden erreicht, wie sie immer erreicht wurden. Der alte Pfad bleibt offen; er ist einfach nicht der einzige noch.
Der Code, den Sie bereits geschrieben haben
Was Sie komponiert haben, behält seine ursprüngliche Bedeutung vollständig bei. FoxScript baut lediglich darauf auf: ein Mechanismus, der es Ihnen ermöglicht, einen Block an etwas anderes zur späteren Ausführung zu übergeben, zusammen mit einer Methode zur Reaktion auf eine Webanfrage aus dem Code, der bereits Ihre Geschäftsprozesse versteht.
&& Ihre alten Add-In-Bibliotheken werden wie zuvor geladen SET LIBRARY TO „vfpencryption71.fll“ ADDITIVE LOCAL oServer oServer = FoxScript.Http.CreateServer() oServer.Get(„/api/v1/customers/:id“, LAMBDA(req, res) LOCAL lnId lnId = VAL(req.Params(„id“)) SELECT * FROM customer WHERE cust_id = lnId INTO CURSOR c_cust IF RECCOUNT(„c_cust“) > 0 res.Status(200).Json(FoxScript.Data.CursorToJson(„c_cust“)) ELSE res.Status(404).Json(‚{„error“: „Not found“}‘) ENDIF USE IN c_cust ENDLAMBDA) oServer.Listen(8080) READ EVENTS
Diese Plattform läuft mit derselben Laufzeit, die auch Ihre Formulare verwenden. Die Abfragen, der Cursor und der Bibliotheksaufruf sind Standard-FoxPro-Tools; was FoxScript hinzufügt, sind die Lambda-Funktion und der Server, ohne dass eine separate Sprache oder ein neben dem Code befindlicher Dienst erforderlich ist. Die Schlüsselwörter und die HTTP-API sind jeweils vollständig definiert.
Der Build und der Zeitplan
FoxDev Studio läuft von oben bis unten in 64-Bit-Architektur. Alle Dateioffsets werden als 64-Bit behandelt, und Tabellen werden niemals in den Speicher gelesen, was bedeutet, dass eine .dbf-Datei, die zuvor zum Stillstand kam, nun in die Hunderte von Gigabytes übergehen kann. Es gibt eine Einschränkung zu beachten: Eine Tabelle, die über zwei Gigabyte hinausgewachsen ist, kann Visual FoxPro nicht mehr öffnen.
Eine Vorabversion des Projekts ist auf GitHub veröffentlicht und wird bei jeder Änderung im Hauptzweig (main) nightly neu erstellt. Der Build ist nicht signiert, was bedeutet, dass der erste Start Sie zur Bestätigung auffordert. Die Dokumentation deckt jeden Teil des Produkts ab, einschließlich der Funktionen, die noch nicht gebaut wurden. Auch die grobe Reihenfolge der geplanten und abgebildeten Arbeiten ist enthalten.
| Schritt | Was es ist | Wo es läuft |
|---|---|---|
| Compiler | Rust, kompiliert zu WebAssembly | Jede Maschine |
| Laufzeitumgebung (Runtime) | Liest Tabellen direkt (Reads tables in place) | Jede Maschine (Every machine) |
| Faser-Modell (Fiber model) | Behandelt Nachrichtenfenster und modale Formulare. ) | Jede Maschine (Every machine) |
| .fll-Brücke (.fll bridge) | Kleiner 32-Bit-Prozess (Small 32-bit process) | Im Hintergrund (Behind the scenes) |
| FoxScript | Fügt Lambdas und HTTP-Server hinzu (Adds lambdas and HTTP servers) | Auf derselben Laufzeitumgebung wie Formulare (On the same runtime as forms) |
Was das eigentlich bedeutet )
Der Build hält Ihre Projekte, Formulare und Tabellen auf die gleiche Weise bei, wie sie waren. Er schreibt sie nicht neu und verfälscht sie auch nicht durch Konvertierung in eine neue Form. Er öffnet einfach den Ordner, auf den Sie verweisen, und was sich darin befindet, ist das, was Sie sehen, genau so wie es war.
Was versprochen wird, ist echt und wird durch das Design des Builds selbst unterstützt. Die Laufzeit fragt Visual FoxPro, wie Dinge funktionieren sollen, und passt sich dann der Antwort an, was bedeutet, dass selbst eine kleine Abweichung in einem Ereignis oder einer Fehlernummer nicht neu geschrieben, sondern stattdessen erhalten bleibt.
„Die Grenzen sind 32-Bit-Zahlen mit Vorzeichen, die in der Dateihandhabung eingebettet sind, nicht eine Lizenzentscheidung, die jemand getroffen hat.“
Der Build entfernt die Speichergrenzen, die die ursprüngliche Sprache einst zurückhielten. Eine Tabelle, die zuvor bei zwei Gigabyte aufhörte, kann diesen Punkt nun überschreiten und auf mehrere hundert Gigabyte anwachsen. Dies ist eine technische Lösung, aber auch eine praktische: Wenn Sie Daten hatten, die in diese Obergrenze stießen, haben Sie jetzt einen Weg, wieder damit zu arbeiten.
Der Kompromiss )
Das Öffnen einer Tabelle, die zwei Gigabyte überschritten hat, ist in Visual FoxPro nicht mehr möglich. Alle, die noch damit arbeiten, werden ausgesperrt, ohne einen Ausweg.
Ein kleiner Zugeständnis führt die Brücke herbei, die Benutzer mit alten Bibliotheken verbindet. Das direkte Öffnen einer 32-Bit-.fll-Datei innerhalb eines 64-Bit-Prozesses funktioniert nicht, was bedeutet, dass der Build einen kleinen 32-Bit-Prozess startet, dessen einzige Aufgabe es ist, Ihre Bibliothek zu halten. Diese Brücke hält Maß mit echten Bibliotheken – der Verschlüsselungsbibliothek, FoxTools und solchen, die aus Microsofts eigenen API-Beispielen erstellt wurden – und funktioniert, obwohl es sie noch nie gab.
Das Urteil )
Vor sechs Jahren wurde diese Sprache in den Wartestand versetzt, und jetzt läuft sie wieder, ohne neu geschrieben werden zu müssen. Der Build erhält das, was Sie geschrieben haben, anstatt einen Neuanfang zu erzwingen, und entfernt die Speichergrenzen, die das Original zum Erliegen brachten. Es ist die Art von Projekt, die einen glücklich macht, weil sich jemand darum gekümmert hat, eine Sprache am Leben zu erhalten.
Es löscht die Vergangenheit nicht. Es liest sie.
Quellenmaterial: „Microsoft hat FoxPro im Jahr 2007 abgewürgt. Wie dem auch sei, hier ist FoxPro wiederbelebt“, foxscript.org.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.