{"id":6232,"date":"2025-10-20T10:09:18","date_gmt":"2025-10-20T10:09:18","guid":{"rendered":"https:\/\/research.swissdigitization.ch\/?p=6232"},"modified":"2025-11-17T10:13:45","modified_gmt":"2025-11-17T10:13:45","slug":"von-klassischer-spielprogrammierung-macos-zu-java-applet-1996-virtualmaschines","status":"publish","type":"post","link":"https:\/\/research.swissdigitization.ch\/?p=6232","title":{"rendered":"Von klassischer Spielprogrammierung (MacOS) zu Java Applets 1996+ (VirtualMaschines) [Erfahrungsbericht]"},"content":{"rendered":"\n

Erfahrungsberichte dazu:
Applets (VM) sind da \u2013 Programmierung mit Events \u2013 1996+ [Erfahrungsbericht]
https:\/\/research.swissdigitization.ch\/?p=1860<\/a>
Flash & JavaApplets \u2013 die Idee von einer Zukunft jenseits von Plattformen [Erfahrungsbericht Zukunft 1996+]
https:\/\/research.swissdigitization.ch\/?p=4994<\/a><\/p>\n\n\n\n

Das neue Framework Java-Serverseitig und JavaApplet-Front-End<\/h2>\n\n\n\n

Java Applets erweiterten wie andere Plugins ab 1996 das Web. Dadurch wurde das Web um ein interaktives unpropriert\u00e4res offenes Format erweitert. Es war mit einer ’normalen‘ Programmiersprache gemacht und nicht wie FLASH oder Director mit etwas ‚abstraktem‘. Zus\u00e4tzlich liessen sich mit Java auch Serverseitige Dinge realaisieren. Die Idee war damit klar: Java konnte die umfassende neue klammer werden und schloss das Webfrontend auch f\u00fcr ’normale‘ Programmiersprachen aus der C-Familie (extended) auf. <\/p>\n\n\n\n

Konkreter<\/h2>\n\n\n\n

Sie waren wie ein Bild aber mit der M\u00f6glichkeit der Interaktion. Allgemein beschrieben etwa hier: <\/p>\n\n\n\n

\n

A Java applet is a Java program that is launched from HTML and run in a web browser. It takes code from server and run in a web browser. It can provide web applications with interactive features that cannot be provided by HTML. Since Java’s bytecode<\/a> is platform-independent, Java applets can be executed by browsers running under many platforms, including Windows<\/a>, Unix<\/a>, macOS<\/a>, and Linux<\/a>. When a Java technology-enabled web browser processes a page that contains an applet, the applet’s code<\/a> is transferred to the client’s system and executed by the browser’s Java virtual machine<\/a>.[5]<\/a><\/sup> An HTML page references an applet either via the deprecated<\/a> <applet><\/code>tag<\/a> or via its replacement, the <object><\/code> tag<\/a>.[6]<\/a><\/sup>
https:\/\/en.wikipedia.org\/wiki\/Java_applet<\/a><\/p>\n<\/blockquote>\n\n\n\n

Mehr dazu auch hier: https:\/\/medium.com\/@BitrockIT\/java-the-world-wide-web-the-beginnings-d186cb0d381<\/a><\/p>\n\n\n\n

HTML<\/h2>\n\n\n\n

Im HTML-Text sah dieses Objekt dann direkt so aus: <\/p>\n\n\n\n

<HTML>               \n<BODY>               \n<APPLET CODE=SimpleApplet.class WIDTH=200 HEIGHT=100>               \n<\/APPLET>               \n<\/BODY>               \n<\/HTML>\nhttps:\/\/www.oracle.com\/java\/technologies\/jpl1-building-applet.html<\/a><\/code><\/pre>\n\n\n\n
CodeStructure<\/h2>\n\n\n\n
Das Konzept der Applets unterscheidet sich grunds\u00e4tzlich von normaler Gameprogrammierung damals. <\/p>\n\n\n\n
CodeStructure MacOS (Klassische Spielprogrammierung)<\/h3>\n\n\n\n
Die Programmierung eines Macspiels wie etwa breakIn (Imp89) sah folgendermassen aus in C(++). Dabei kamen letztlich die genau gleichen Code-Paradigmen wie in Assembler \/ BASIC \/ Pascal zum Einsatz: Es war letztlich ein File – ein MainPrg, das den Prozessor nutzte. <\/p>\n\n\n\n
\"\"
Screenshot<\/figcaption><\/figure>\n\n\n\n
Das heisst, der ganze Code wurde von Oben nach Unten abgearbeitet, dann wurde falls n\u00f6tig auf den Vsync gewartet und es ging von vorne los. Das Resultat waren etwa die Spiele von Imp89.<\/p>\n\n\n\n\n\n\n\n
\"\"<\/figure>\n\n\n\n
Anders gesagt: Es gab eine „Funktion“ und die durchlief ewig bis zum „Exit“ eine Schlaufe. Der bekannte Gameloop. <\/p>\n\n\n\n
Mehr zu diesen Games siehe hier: https:\/\/www.la1n.ch\/macosclassic\/<\/a><\/p>\n\n\n\n
CodeStructure JavaApplets<\/h2>\n\n\n\n
JavaApplets hingegen funktionierten prinzipiell anders. Sie hatten Events. Der Code war also schon von Beginn an aufgest\u00fcckelt in verschiedene Bereiche, die von der VirtualMaschine dahinter aufgerufen wurden. <\/p>\n\n\n\n
Der SourceCode wurde hier nicht mehr in eine EXE f\u00fcr ein System \u00fcbersetzt sondern f\u00fcr eine JavaVirtualMaschine, die bei jedem System dann anders implementiert war. Diese JavaVM war schon abstrakt oder transparent f\u00fcr den Nutzer. Auf einer Webseite lief das Applet also dann in der VM des Browsers.  <\/p>\n\n\n\n
 Dabei entzog sich dem Developer, wie und was dahinter passierte. Die Events gab es nun einfach so, als Minimum der Ausf\u00fchrung. <\/p>\n\n\n\n
import java.applet.Applet;\nimport java.awt.Graphics;\nimport java.awt.Color;\n\npublic class SimpleApplet extends Applet{\n\n  String text = \"I'm a simple applet\";\n\n  public void init() {\n        text = \"I'm a simple applet\";\n        setBackground(Color.cyan);\n  }\n  public void start() {\n        System.out.println(\"starting...\");\n  }\n  public void stop() {\n        System.out.println(\"stopping...\");\n  }\n  public void destroy() {\n        System.out.println(\"preparing to unload...\");\n  }\n  public void paint(Graphics g){\n        System.out.println(\"Paint\");\n        g.setColor(Color.blue);\n        g.drawRect(0, 0,\n                   getSize().width -1,\n                   getSize().height -1);\n        g.setColor(Color.red);\n        g.drawString(text, 15, 25);\n  }\n}\nhttps:\/\/www.oracle.com\/java\/technologies\/jpl1-building-applet.html<\/a><\/code><\/pre>\n\n\n\n
<\/h2>\n\n\n\n
<\/p>\n\n\n\n
HTML-Umgebung – eine unsichere dynamisierte Welt<\/h2>\n\n\n\n
Die klassische Umgebung von MacOS\/Finder oder dann Win95 war klar: Ein Programm wird gestartet, l\u00e4uft und wird dann wieder beendet. Ausnahmefall: Taskmanager. Aber sonst war das Programm f\u00fcr seinen Lebenszyklus zust\u00e4ndig.<\/p>\n\n\n\n
Bei HTML war das ganz anders. Die Webseite wurde geladen HTML. Dann wurde die Webseite gerendert und die Zusatzinhalte wie Bilder oder etwa auch Applets hinzugeladen. All das konnte das Layout wieder ver\u00e4ndern. Oder der User machte das Fenster gr\u00f6sser oder kleiner. Anders gesagt: Ein Applet existierte in einem sehr dynamischen Umfeld oder pragmatischer: Applets mussten anpassungsf\u00e4hig sein. <\/p>\n\n\n\n
Und dies findet sich dann auch in den „Events“ und deren Parametern eines Applets. Wobei nie klar war wie die verschiedenen Umgebungen alias Browser genau damit umgingen. <\/p>\n\n\n\n
Dazu sind folgende Events einigermassen klar: init() > start() > stop() > destroy() <\/p>\n\n\n\n
OOP und AppletEvents<\/h2>\n\n\n\n
Diese Methoden sind selbstverst\u00e4ndlich schon vordefiniert in der Grundklasse Applet, auf die der Browser und die Virtual Maschine dann zugreift.  <\/p>\n\n\n\n
public class SimpleApplet extends Applet{ }<\/p>\n\n\n\n
Hier wird dann \u00fcberschrieben, was gebraucht wird und der Rest wird so belassen, wie es ist. <\/p>\n\n\n\n
Paint()<\/h2>\n\n\n\n
Die seltsamste Methode bleibt f\u00fcr das alte Paradigma die Methode Paint. Diese wird an verschiedenen Orten benutzt (println zeigt das). Wird etwa das Applet zuerst gezeichnet oder wird ein Bild dar\u00fcber geschoben, dann wird diese Methode ebenfalls aufgerufen. Das heisst, Paint wird nicht immer wieder aufgerufen. Es ist mehr eine Funktion.<\/p>\n\n\n\n
Deswegen eignet sie sich auch nicht als Gameloop-Funktion wie etwa bei Processing. Es muss also eine andere Methode benutzt werden.<\/p>\n\n\n\n
GameLoop<\/h2>\n\n\n\n
Aus diesem Grund wird oft in der Start Methode ein Thread konstruiert, der dann immer wieder aufgerufen wird und eine eigene Methode aufruft, die der GameLoop etwa update() ist. Darin wird dann die Grafik „repainted()“. Und so entsteht dann das interaktive Spiel, das sich immer selbstupdated. Dabei l\u00e4uft dann das Spiel in einem Browser in einer VirtualMaschine. Ist also maximal weit weg von der Hardware.<\/p>\n\n\n\n
Dies war nat\u00fcrlich auch die Idee dahinter. Der Vor- und auch gleichzeitig sein Nachteil: Es war langsamer. Daf\u00fcr gab es aber auch keine Probleme mehr mit Speichermangagement und verschiedenen Versionen – es gab ja Java (Garbage Collector). <\/p>\n\n\n\n
Zerst\u00fcckelung von Algorithmen\/Code – das Update\/GameLoop<\/h2>\n\n\n\n
Neu war allerdings auch, dass der Code irgendwie nicht mehr jener AssemblerCode war, der ein Methode war sondern eher ein Spiel war eher nun eine Ansammlung von Methoden, die ineinander griffen. Paint war getrennt vom Gameloop. Es entstand so eine Unabh\u00e4ngigkeit und Beil\u00e4ufigkeit im besten Fall. Datenstrukturen bedienten die Spielmechanik wie auch die Grafikgenerierung. Eine Tendenz, die auch bei den GameEngines  zu beobachten war: Das Spiel sollte nicht an der Ausgabe h\u00e4ngen.    <\/p>\n\n\n\n
Eines der wenigen \u00fcberlebten Beispiele findet sich hier. <\/p>\n\n\n\n
HotArkanoid<\/h2>\n\n\n\n
Ein Arkanoid mit den Grafiken von BreakIn. Im EditorMode. Die meist Neuprogrammierung war dabei (fast zu) einfach. Statt Komplexem C++ Code gerade f\u00fcr Visuelle Dinge, war Java einfach als Sprache mit einer grossen Grundausstattung, meist keine Zusatzlibraries, besass einen Garbage Collector und all das visuelle war wirklich simple. Die Grafiken etwa konnten direkt vom Web geladen werden. Auch das Abfragen von Keys oder Maus war simpel und auf allen Systemen selbstverst\u00e4ndlich dasselbe. Es gab in diesem Sinn keine Portierprobleme. Gr\u00f6sstes Mankos: Ladezeiten, man muss in das Applet klicken, damit man \u00fcberhaupt es \u00fcberhaupt spielen konnte und anfangs waren die JavaApplet Welten auch nicht besonders schnell.  <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Mehr dazu hier: https:\/\/vintagecomputing.ch\/?browseid=2820<\/a><\/p>\n\n\n\n
Microsofts Zerst\u00f6rungswerk<\/h2>\n\n\n\n
Die Java-Applets waren ein interessantes Framework im Gegensatz zu Shockwave oder Flash oder Active X (nur MicrosoftPlatform). Java war „offen“ als Programmsprache damals von SUN. Und Java h\u00e4tte sich entwickeln k\u00f6nnen, leider versucht dann Microsoft den Standard f\u00fcr sich zu „gewinnen“ und seine eigene Version daraus zu machen. Damit lief eigentlich nur JavaApplet 1.1 maximal auf ihren Browsern und damit entwickelte sich das Plugin dann leider nicht fl\u00e4chendeckend und starb geradezu an Inkompatibilit\u00e4t auf der Mainstreamplatform Windows.<\/p>\n\n\n\n
Im Anwendungsbereich auf dem Desktop entwickelt sich Java ebenfalls nicht schnell genug und die Performance war immer hinter native Applicationen zur\u00fcck. Besser war es auf der Serverseite, hier konnte Java sich durchsetzen – gerade weil es \u00fcberall lief. <\/p>\n\n\n\n
C# <\/h2>\n\n\n\n
Microsoft entwickelt dann ein eigenes Framework und eine Programmiersprache dazu: .NET. Dieses nutzt letztlich ein VM mit einer Java\u00e4hnlichen aber nun an C orientierten Sprache C#. Die Mono-Version davon kommt in vielen platform\u00fcbergreifenden Projekten zum Einsatz. Bestes Beispiel ist etwa Unity. Das dann so schnell funktionierte compiliert, dass es keine Scriptsprache mehr braucht f\u00fcr Unity 2003+. <\/p>\n","protected":false},"excerpt":{"rendered":"
Erfahrungsberichte dazu:Applets (VM) sind da \u2013 Programmierung mit Events \u2013 1996+ [Erfahrungsbericht] https:\/\/research.swissdigitization.ch\/?p=1860Flash & JavaApplets \u2013 die Idee von einer Zukunft jenseits von Plattformen [Erfahrungsbericht Zukunft 1996+] https:\/\/research.swissdigitization.ch\/?p=4994 Das neue Framework Java-Serverseitig und JavaApplet-Front-End Java Applets erweiterten wie andere Plugins ab 1996 das Web. Dadurch wurde das Web um ein interaktives unpropriert\u00e4res offenes Format erweitert. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6232","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/posts\/6232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6232"}],"version-history":[{"count":30,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/posts\/6232\/revisions"}],"predecessor-version":[{"id":7080,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=\/wp\/v2\/posts\/6232\/revisions\/7080"}],"wp:attachment":[{"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/research.swissdigitization.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}