% Content-encoding: UTF-8
\documentclass[ngerman]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\setcounter{secnumdepth}{0}
\setcounter{tocdepth}{0}


\renewcommand{\reftextbefore}{auf der vorherigen Seite}
\renewcommand{\reftextfacebefore}{auf der gegenüberliegenden Seite}
\renewcommand{\reftextafter}{auf der nächsten Seite}
\renewcommand{\reftextfaceafter}{auf der gegenüberliegenden Seite}
\renewcommand{\reftextfaraway}[1]{auf Seite~\pageref{#1}}
\renewcommand{\reftextpagerange}[2]{auf Seiten~\pageref{#1}--\pageref{#2}}
\renewcommand{\reftextlabelrange}[2]{\ref{#1} bis~\ref{#2}}
\renewcommand{\figurename}{Bild}

\begin{document}

\title{Die ForthForm des Win32Forth erweitern — ein visualForth machen}
\author{Dirk Brühl}
\ifx\shorttitle\undefined\else
\shorttitle{visualForth}
\fi

\maketitle


\begin{figure*}[b]
\begin{center}
\includegraphics[width=0.6\textwidth]{2009-02/vf1}
\caption{\label{vf1}Ein neues Fenster (Form1) wird angelegt.}
\end{center}
\end{figure*}


\begin{figure*}[t]
\begin{center}
\includegraphics[width=0.6\textwidth]{2009-02/vf2}
\caption{\label{vf2}Beispiel für ein Projekt - erzeugen eines RPN Rechners.}
\end{center}
\end{figure*}


Dirk Brühl lebt heute im Pennsylvania, USA. 1993 hat er in Nürnberg die Forthtagung ausgerichtet, an der auch ein gewisser Herr Tom Zimmer teilgenommen hatte. Dessen Forths [1] haben etliche von uns inspiriert und seither begleitet, auch beruflich. Neulich im Internet sind wir uns wieder begegnet, Dirk Brühl und ich. Dabei ging es auch um Beiträge für die \emph{Vierte Dimension} --- und ich war erfreut zu erfahren, was sich so in dem Blockhaus in Pennsylvanien alles tut.

Dirk schrieb: \glqq... so will ich sehen, sobald wie möglich eine Vorabkopie zusammenzustellen und Dir zuzuschicken. Ist nicht sehr umfangreich, ich hoffe, dass Du Win32Forth Version 6.12 (oder 6.13) zur Verfügung hast. Mein visualForth ist eine Ergänzung zu ForthForm von Win32Forth Version 6.12 (Ezra Boyce hat unvorsichtigerweise irgendwo geschrieben, dass jeder damit machen kann, was er will), so werden nur einige Files benötigt, die in ForthForm einkopiert werden, und dann wird das System neu aufgebaut (geht praktisch automatisch). Also, falls Du Interesse hast, Dir mein visualForth mal kritisch anzuschauen, lass es mich wissen!
Mit den besten Grüßen aus dem noch teilweise weißen Springs\grqq

Und ob ich da interessiert war! Gleich schrieb ich zurück, dass ich das gerne ausprobieren und vorstellen wolle, und erhielt noch am selben Tage die Antwort: \glqq Habe ich womöglich irgendeinen Nerv getroffen?\grqq Na klar, hatte er --- den Forth--Nerv der \emph{Älteren}: Wissen wollen, ob und wie was geht. 
M.Kalus


\begin{multicols}{2}
\section{Warum die ForthForm von Win32Forth erweitert gehört.}

Wenn Du Win32Forth Version 6.12 installieren konntest, hast Du bereits ForthForm (ist unter Apps zu finden). Wenn Du versuchst, damit ein GUI zu machen, dann geht das perfekt, aber wenn Du versuchst, ein Forth--Programm damit zu verbinden, wird es Dir wahrscheinlich so wie mir gehen, dass Du da wie ein Ochs vorm Berg stehst und nicht weißt, wie das anzustellen ist. 

Ich habe dann versucht herauszufinden, wie das geht, erst für mich alleine, dann mit eMail--Fragen in der Forth--Yahoo--Gruppe, dann hatte ich einige Ideen, wie man das Ganze für mich und Leute wie mich verwendbar machen kann, und bat Ezra, das doch mal anzuschauen und einzubauen. Aber erst als ich mich dann selbst an die Arbeit machte und alle meine Widerstände gegen den Umgang mit Windows--Programmierung überwunden hatte und eine erste arbeitsfähige Lösung hatte, war Ezra auch begeistert, und das erste, was er machte, war, einen anderen Weg einzuschlagen und das Ganze in die IDE einzubinden. Da mir zum Weiterarbeiten dann deren Source--Code fehlte, bin ich bei meiner Lösung geblieben.

Beruflich hatte ich bei Lucent mit visualBasic zu tun.\footnote{EBID--tool; Windows--Programm, um EEPROMs automatisch mit Fertigungsdaten zu beschreiben.}
Ein passendes Forth gab es damals leider nicht. Aber wenigstens den BASIC--Code schrieb ich Forth--ähnlich, und die ganze Zeit dachte ich mir, wie schön es wäre, ein visualForth zu haben. Es ging anderen wohl ähnlich, Überlegungen dazu gab es in Foren und Konferenzen, z.~B.\ Knaggs [2] 
 oder Prinz [3]. Immer wurde der Gedanke verworfen, weil man dachte, es sei für Einzelne zu umfangreich und daher nicht zu verwirklichen. Bernd Paysan machte dann mit MINOS vor, dass diese Befürchtungen eigentlich unbegründet sind [4]. Minos ist ein erstaunliches Tool, um GUIs zu erstellen. Da Bernd aber vornehmlich in einer Linux Umgebung entwickelt, ist die Portierung in die Windowsumgebung nicht so glücklich verlaufen, es verweigert sich mir dort zu oft völlig, auch aus nicht ersichtlichen Gründen. 

Inzwischen ist ja einige Zeit verstrichen, es gibt mehr Leute, die Windows XP programmieren können, selbst unter denen, die Forth mögen. Und nun, da es die ForthForm des W32F gibt, ist es möglich geworden, den Gedanken an ein visualForth noch mal aufzugreifen, und eigene Wünsche umzusetzen.

So hatte ich kürzlich während der Arbeit an meinem Webpage--Maker einiges in einer Wunschliste notiert, die ich bei Gelegenheit abzuarbeiten gedachte. Jetzt war die Herausforderung da, und da nun alle wichtigen Leute geweckt 
wurden\footnote{Die versammelte Expertenrunde auf der Forthtagung 2009 in Neuenkirchen bei Rheine.}, bleibt mir nichts anderes mehr übrig, als die erste brauchbare Version verfügbar zu machen. 

\begin{figure*}[t]
\begin{center}
\includegraphics[width=0.5\textwidth]{2009-02/vf3}
\caption{\label{vf3}Eigenschaften der Form festlege, eine Forth Funktion zuweisen.}
\end{center}
\end{figure*}


\section{Was ich der ForthForm hinzugefügt habe --- neue Features.}

Man nehme ein Win32Forth zur Hand und patche die alpha--Version meines Ansatzes (visualForth0107) darüber, der Vorgang wird von einem Batch--Programm unterstützt. Dann stehen beide Ausführungen zur Verfügung, die bisherige ForthForm und das, was ich mir ausgehend davon derzeit unter visualForth vorstelle. Die simple Idee, die der ForthForm zugrunde liegt, wurde beibehalten: Eine neue Form öffnen, dann aus einem Menü ein Kontrollelement (control) auswählen --- also ein Knopf (button) oder Bildchen (bitmap) oder Dialogfeld --- das per Mausklick einfügen, fertig. Wirklich sehr simpel und sofort einsichtig. 

Dann der nächste Schritt. Ein Klick mit der rechten Maustaste auf so einen Knopf, und es erscheint ein Fenster, in dem allerlei Eigenschaften dieses Elementes eingestellt werden können (properties). In der ForthForm beschränkte sich das bisher auf wenige Eigenschaften, wie die Position des Elements, blättern von Element zu Element, Namen und Titel. Zusammen mit der Möglichkeit, das Ganze dann als Forthcode in ein File abzulegen, ermöglichte schon sehr viel. Von da an konnte man auf Forth--Quellcode--Ebene weiter machen, hatte den mühseligen Teil der Windowsprogrammierung schon geschafft. Eigentlich ein mächtiges Werkzeug in den Händen von Experten! Nur wurde Menschen wie mir dabei nicht klar, was denn damit gemeint ist, Code lokal oder global anzulegen, was es mit den Objekten auf sich hat, oder wo denn nun der ausführbare Code hingehört, der laufen soll, wenn man seinen soeben frisch erzeugten Knopf anklickt --- frustrierend. Also eigentlich genau das nicht, was Forth sonst immer bietet: Einen leichten Einstieg über einfache Funktionen, von wo aus man sich dann nach und nach im Selbststudium in kompliziertere Zusammenhänge der Maschine vorarbeiten kann. 

Also habe ich ein Feld zur Eingabe eines Forthwortes hinzugefügt und dem einen Editor hinzugefügt. So kann schon \emph{in} der Form dem Kontrollelement seine Forthfunktion hinzugefügt werden, auch als Dummy, um dann später im Quellcode die Stelle 
wiederzufinden, an der man weitermachen kann, falls man das dann überhaupt noch möchte (und dabei nicht die Hände über dem Kopf zusammenschlägt und gleich wieder zumacht angesichts all der Windows--Funktionen). Denn es geht auch so aus der Form heraus, seine Applikation zu erstellen. Das macht es ja gerade so einfach: Man konzentriert sich auf Forth. Dieses war der wichtigste Schritt.

Dann kamen zu den Hilfen, die man über die rechte Maustaste für das Propertiesfenster erhält, folgende hinzu: Die derzeit bearbeitete Form in ihrer Quelle sehen können (view source), komplette Kontrollelemente kopieren, auch multipel zu Elementfeldern (copy control), Elementengruppen markieren und löschen, Listen der schon generierten Elemente und controls erzeugen, und eine automatische Nummerierung dieser Elemente, damit man sie gezielt aufrufen und in der Quelle leicht finden kann.

Und schließlich habe ich noch hinzugefügt, testweise eine so erzeugte Form mit nur einem einzigen Mausklick in eine \texttt{EXE}--Datei umzusetzen. Damit man sofort sehen kann, ob und wie das läuft, was man da gerade gemacht hat. Also nicht nur die \emph{run}--Funktion der ForthForm, mit der man sehen kann, wie die Form im Forth compiliert und läuft, sondern Anlage der selbständigen ausführbaren Stand--Alone--Datei (\texttt{*.EXE}) um das Endergebnis sofort zu haben, wobei die gesamte Quelle dafür ebenfalls abgelegt wird (\texttt{*.frm}), was den Prozess der Fehlerbehebung unterstützt. Denn das war über die bisherige ForthForm alles doch sehr holperig: Quelle der Form generieren, händisch die turnkey--Prozedur anfügen, Funktionen den einzelnen Controls zuordnen, compilieren, \texttt{EXE} generieren, Fehler finden, alles von vorn; Form öffnen usw. Ich hoffe, dass dieser mühselige Zyklus mit dem vF nun erheblich abgekürzt werden konnte. 

\begin{figure*}[t]
\begin{center}
\includegraphics[width=0.5\textwidth]{2009-02/vf4}
\caption{\label{vf4}Der PLUS Taste ihre Forth Funktion zuweisen.}
\end{center}
\end{figure*}


\section{Arbeitsweise in visualForth}

Bei visualFORTH ist es so, dass mit einer leeren Form begonnen wird, und der graphische Teil zuerst gemacht wird. Meine Arbeitsweise bei der Erstellung des Webseitengenerators war so, dass ich erst einmal den graphischen Teil, also die Bedienoberfläche, erstellt habe, denn nur damit machte es Sinn, die anderen Programm--Module zu erstellen: Erst muss die I/O da sein. 

Das war auch stets bei der Entwicklung von Mikroprozessorsystemen bei mir so. Ohne Hardware gab es keine Möglichkeit, die Software zu testen --- manche tun es trotzdem, aber mit immensem Aufwand, den ich stets vermieden habe. Mit der bestehenden Testmöglichkeit in Form der GUI macht es Sinn, mit der Programmerstellung weiterzumachen. 

Das ist Forth--gemäßes Programmieren, auch inkrementelles Programmieren genannt. Dadurch, dass alle Verknüpfungen bereits in der Form untergebracht werden können, ist die Form an sich ihr eigener Projektmanager. Mit der einfachen ForthForm war das so nicht möglich. 


\section{Was zu tun war.}

Bis zum heutigen Stand (Mai2009) von visualFORTH 0.01.07, der Alpha--Version, habe ich 249 Änderungen und Ergänzungen in den 49 ForthForm--Files vorgenommen. Um eine Umleitung der Key-- und Emit--Funktionen in eine Form zu ermöglichen, waren zwei neue Files, und zwar FormKey.f und TextboxEmit.f erforderlich, und eine Änderung des Forthkernels in \texttt{fkernel.f}, also des \emph{Allerheiligsten}, weil im Gegensatz zu früheren Forth--Versionen in Win32Forth für \texttt{KEY} und \texttt{KEY?} inzwischen Windows--Funktionen verwendet werden, die diese I/O--Umleitung unmöglich machten. Also musste ich \texttt{KEY} neu definieren. Für mich als Mikroprozessor--Entwickler (Embedded Systems Engineer) ist diese Umleitungs--Möglichkeit außerordentlich wichtig, denn dadurch kann man einen Text auf ein LCD--Display mit dem gleichen Programm--Modul ausgeben, das den Text auf den PC--Bildschirm bringt. (Bei meinen Mikroprozessor--Programmen wurden Tasten der Hardware gescannt und durch I/O--Umleitung direkt ins Forth eingespeist, sodass das gleiche Programm sowohl mit Hardware als auch ohne Hardware laufen konnte; im RSC--Forth war das eingebaut.) So habe ich mir diese Funktionen jetzt mit visualFORTH und Win32Forth Version 6.12.07 auch gemacht, zur Verwendung von simulierter \emph{Hardware}, simulierten LEDs und Tasten, \emph{Form} genannt.

Das Zusammenspiel zwischen der erstellten und kompilierten Form und dem W32F--Kern ist außerordentlich interessant. Es ist eine Art von Multitasking. Von der W32F--Console aus (und damit auch von einem kompilierten Forth--Programm) kann mit dieser Form kommuniziert werden. 

Das eigentliche Problem war, all die Stellen zu finden, an denen Eingriffe möglich und erforderlich waren. Dabei war die Win32Forth--IDE mit \emph{Find Text in Files} ({\sf<Strg>+<Shift>+F}) eine großartige Hilfe. Ohne dieses speziell für Forth entwickelte Werkzeug wäre es nur mit erheblich höherem Zeitaufwand möglich gewesen, visualFORTH zum Leben zu erwecken. Aber bevor ich in den Tiefen irgendetwas geändert habe, musste zunächst einmal das Herzstück für visualFORTH gemacht werden: Funktionen den Objekten zuordnen. Angefangen habe ich mit einer einfachen Taste (button) im Fenster. Das war am einfachsten zu bewerkstelligen, es sollte überhaupt irgendetwas geschehen, wenn man auf diese Taste klickte. Dazu wurde das ForthForm--Fenster  \emph{Properties+} um ein Schreibfeld erweitert. Das wiederum war mit Hilfe der ForthForm nach Starten von  \texttt{FORMPROPERTY.ff} möglich. So gab es bald eine erweiterte \texttt{FORMPROPERTY.ff}, aber noch fehlte die Anbindung an Forth. 

Dazu habe ich nach den Texten in \emph{Properties+}, z.~B.\ nach \emph{Bitmap:} gesucht, und mit Hilfe der IDE alle damit zusammenhängenden Funktionen nacheinander gefunden. Diese Module habe ich kopiert und mit einem neuen Namen versehen, d.h. aus \emph{Bitmap:} habe ich letztendlich die \emph{Function:} gemacht. Das war im Grunde genommen alles für den ersten Schritt. Ein Problem dabei gab es allerdings dabei zu lösen: Wie werden die Eigenschaften (properties) einer Form eigentlich gespeichert und wo liegen diese Daten? Die Datenstruktur habe ich dann gefunden, und einfach meine Ergänzungen angehängt. Beim ersten Test dann funktionierte die ForthForm danach nicht mehr, stürzte ab mit einer Fehlermeldung. Bis ich herausgefunden hatte, dass der Speicherplatz für die Properties --- aus welchen Gründen auch immer --- begrenzt ist. Da in der Form selbst nur wenige Definitionen erforderlich sind, reicht aber der zur Verfügung stehende Speicherplatz gut aus. Hier liegt noch einiges im Dunkeln und ich hoffe auf Mitstreiter bei der Aufklärung.




\section{Kleine visuelle Vorschau}

In den im folgenden angesprochenen 
Bildern (screenshots) ist der Prozess dargestellt, mit dem im visualForth gearbeitet wird. Das \figurename\ \vref{vf1} zeigt eine neu angelegte Form. Die nächsten Bilder stammen aus dem Taschenrechner--Beispiel (RPN--Calc). Im \figurename\ \vref{vf2} sieht man, wie der Taschenrechner entsteht. In der Mitte davon siehst du den Entwurf der Taschenrechner--Form. Rechts davon ein Fenster, in dem gerade die Eigenschaften der ENTER--Taste festgelegt werden. Und links ein kleines Fenster mit dem die Position auf dem Bildschirm ausprobiert wird. In \figurename\ \vref{vf3} sieht man dann deutlicher, wie die ENTER--Taste angelegt wurde. Schließlich zeigt \figurename\ \vref{vf4} als Beispiel, wie die PLUS--Taste programmiert worden ist.



\section{Was ist zu tun?}

Noch viel. Und das hat weniger mit Forth selbst zu tun, daher ist es für mich schwierig. Und die Wunschliste erhebt nicht mal Anspruch auf Vollständigkeit ;-)
\begin{itemize}
\item Eine selbstentpackende Distributions--\texttt{EXE} automatisch erstellen.
\item Bilder (BMP) innerhalb einer Turnkey--\texttt{EXE} ablegen können.
\item Bimaps an verschiedene Fenstergrößen anpassen können, um ein automatisches Setzen von Bildern vom Programm aus reibungslos zu ermöglichen (ist irgendwo in den W32F--Sourcen oder in Windows selbst gegeben, habe es bisher nicht gefunden).
\item DLLs innerhalb einer Turnkey--\texttt{EXE} speichern, die beim Ausführen automatisch ausgeladen werden, falls erforderlich. Damit ist es dann möglich, alles in einem einzigen \texttt{EXE}--File zu haben. Denn es ist sehr ärgerlich, wenn ein Programm mit einer Fehlermeldung startet \emph{File nicht gefunden} und dann nicht läuft. Mit dem Einpacken aller erforderlichen Extras in die EXE ist diesem Frust ein Ende gesetzt. Alle anderen Bestandteile von Forth sind stets in der \texttt{EXE} enthalten, so sollte es auch mit Bildern und DLLs sein.
\end{itemize}


\section{Wie geht es weiter?}

Da die Quellen in der Win32Forth--Distribution (meine derzeit: Version 6.12.07) vorhanden sind, ist es gut möglich, dass, wer möchte und kann, einen Beitrag zur Vervollständigung von visualFORTH leistet, und dieser Beitrag muss nicht unbedingt ein Sourcecode sein --- Wünsche und Bemerkungen, was in visualFORTH fehlt, um es noch vollständiger zu machen und den Schritt zur Beta--Version zu gehen, sind herzlich willkommen und dienen allen, die mit visualFORTH arbeiten oder arbeiten wollen. 

Mit dem Konzept eines visualFORTH sind nun alle Fenster geöffnet, um frischen Wind ins Forth--Geschehen zu bringen, und alle Türen sind geöffnet, um die verborgenen Schätze von Forth zu heben und verfügbar zu machen. Mit einer vereinheitlichten und stabilen Version von visualFORTH ist es möglich, interessante, im Internet frei verfügbare Forth--Applikationen nutzbar zu machen. Jeder, der die Power von Forth erkannt hat, wird erkennen, dass diese Power mit visualFORTH potenziert wird! Alles, was für die Nutzbarmachung von Windows durch Forth benötigt wurde, ist bereits vorhanden. Alles ist fertig, Win32Forth ist ein mächtiges Forth--Werkzeug, das alle Wünsche erfüllt, wenn es richtig verwendet wird. Und das letzte Glied der Kette, \emph{the missing Link}, visualFORTH, ist jetzt auch da, und visualFORTH ist problemlos erweiterbar, kompatibel zum W32F von Anfang an. 

Jetzt geht es darum, die Power von Forth sichtbar zu machen, zu visualisieren, und in visualFORTH zum Ausdruck zu bringen! Ich hoffe, dass Du die Möglichkeit dieser Möglichkeiten auch siehst! 

\section{Nachtrag}

Inzwischen (Juli 2009) ist Win32Forth Version 6.13 da und wurde gegenüber 6.12 so überarbeitet, dass visualForth damit nicht mehr funktioniert. Das visualForth Konzept muss daher als eigenständig angesehen werden. Zur Drucklegung dieses Heftes wird visualForth0112 da sein. Der gesamte Code für ein damit erzeugtes \texttt{EXE}-File von einer eigenen Applikation ist in einem Quellfile *.ftk niedergelegt. Bitmaps werden darin jetzt automatisch eingebunden und auch das zoomen der Fenster funktioniert inzwischen. db

\end{multicols}

\section{Referenzen}
\begin{tabular}{p{3ex}p{16.5cm}}
{}[1]&\url{http://tomzimmer.blogspot.com/}\newline
\ldots\ Author or Co--Author of several Forth computer language development systems including VIC--Forth, ColorForth (for the Radio Shack Color COmputer), 64Forth (for the Commodore 64), F--PC (for DOS), Win32Forth (for Windows) and TCOM (a native DOS compiler), 
Thomas Zimmer, win32forth@me.com\vspace{1ex}\\
{}[2]&Peter K. Knaggs, Department of Computing and Information Systems, University of Paisley, Scotland; 1996; \emph{Visual Forth --- The Forth Integrated Development Environment}.\vspace{1ex}\\
{}[3]&Friedrich Prinz, Jahrestagung FG 2/1996. Bericht: Erfahrungen mit dem Win32Forth.\newline Dabei Wunsch nach einem VisualForth, das den Entwickler von der Kenntnis der Windowsprogrammierung befreien sollte und seine Konzentration auf das Inhaltliche ermöglichen kann. In der lebhaften Diskussion wurde
befürchtet, dass zum einen Windowsprogrammierung ohne Windowskenntnisse eine Utopie bleiben wird und dass zum anderen ein VisualForth mit den vorhandenen Entwicklungskapazitäten kaum zu machen sein wird.\vspace{1ex}\\
{}[4]&Bernd Paysan. Minos und bigForth
\url{http://www.jwdt.com/~paysan/bigforth.html}\newline
\glqq MINO$\Sigma$ ist die Antwort zu der Frage: \frqq Gibt es da etwas wie Visual BASIC in Forth?\flqq ... \emph{Visual Forth?} Etwas gibt mir zu denken: In diese Pakete, die echte Programmierung visueller Forms ermöglichen, sind viele Jahre Programmierung investiert. Microsoft, Borland, und IBM mögen Hunderte von Programmierern für so ein Projekt einstellen. Diese Manpower gibt es für kein Forth--Projekt. Aber halt: Forth behauptet, dass gute Programmierer mit Forth sehr viel effizienter programmieren können\ldots\grqq\\
\end{tabular}

\end{document}

