Webbird Webbrowser

Mein eigener Webbrowser

Seit vielen Jahren entwickeln sich Webbrowser. Der Internet Explorer wurde von Microsoft entwickelt und immer wieder auf dem Markt ge- pusht. Sein konkurent war vor ewigkeiten der Netscape Navigator. Den hab ich sogar in meinen Anfängen noch benutzt. Später wurde als Konkurenz der Firefox von Mozilla beliebter (zumindestens hier in Deutschland). Ich wechselte dann irgend wann auch zu ihm. Denn der Netscape Navigator wurde nicht mehr weiter entwickelt. Den Google Chrome habe ich nie wirklich wahr genommen, da mir der Firefox eigentlich immer genügte. Bis auf einige Updates später. Da fand ein redesign statt und ich vermisste einige features. Außerdem fehlten mir einige Dinge schon länger.
Ich hatte gerade einige erste Versuche mit VB.NET gemacht. Ich bemerkte dabei bereits, dass mir die IDE ein "Webbrowser" Element gab. Bei einem kurzen schnell Test bemerkte ich, wie das keinen Unterschied vom Gefühl im vergleich zu einem anderen Webbrowser machte, wenn man es im eigenen Programm benutzte. Da bekam ich die Idee, mir einen eigenen Browser zu schaffen, den ich gestalten konnte wie ich dachte, dass es am besten sei.

Die Idee

Der Webbird hieß ganz zu Anfangs "Knight 2000 Mini Browser". Das Prefix im Namen liegt an der Entwicklung im Teenager alter. Der Name "Mini Browser" kam daher, dass der Browser ganz zu Anfangs mit wenigen Features ausgestattet war.
Der Browser an sich wurde aus den oben erwähnten Anfängen zunächst mit dem "Webbrowser" element aus dem Framework aufgebaut. Damit basierte er aber auf der Engine des Internet Explorers. Von Anfang an wollte ich in die Benutzbarkeit unter allen Bedingungen denken. So hatte der Browser immer eine Grund- Bildschirmauflösung von 640 mal 480 Pixeln, wenn man ihn frisch installiert hatte. Das habe ich deshalb gemacht, damit wenn ein Windows aus irgend einem Grund ohne spezifischen Bildschirmtreiber Arbeiten muss, sich diese Auflösung einstellt. Ferner hatte ich bereits daran gedacht, dass es gut ist wenn man den Browser nicht im System, sondern auf portablem Speicher installiernen kann. Einen Modus für eine Portable Environment gab es bereits ab der zweiten Version.
Leider begrenzte mich der .NET Framework auf Windows in der Zeit, in der der Browser entwickelt wurde. Ich hätte auch gerne "Old- School" Versionen von Windows, wie zum Beispiel Windows 98 unterstützt. Hab ich für einen moment sogar. Doch dafür musste ich eine alte Version des .NET Frameworks benutzen. Später wechselte ich noch auf die damals aktuellste Version. Doch den Browser auf anderen Systemen wie MacOS oder Linux zu bringen war (damals noch) unmöglich.
Alle anderen Browser (ja, auch der Internet Explorer :-D ) hatten mittlerweile Unterstüzung für Add-ons. So etwas habe ich aber nie geschafft zu entwickeln. Ich hätte auch keine Idee gehabt, wie Add-ons neben der Webseite mitlaufen können. Ich hatte zuletzt die Engine auf die alte Gecko Engine von Mozilla umgestellt. Damit wäre zwar auch das Mitbenutzen von Firefox Add-ons von interesse gewesen. Aber da fehlte mir die Idee, wie das gehen sollte.
Eine entwicklung in Richtung Touch Oberfläche gab es zwar noch, aber die wurde nicht mehr fertig gestellt. Und so mit der Zeit verwendete ich doch mehr den Firefox, weil ich auch immer mehr unter Linux unterwegs war und dort meine Add-ons nutzen konnte. So endete die Entwicklung des Browsers mit der Zeit. Die letzten Versionen wurden zwar unter Windows 7 entwickelt. Jedoch laufen sie bis Heute weiter, weil der .NET Framework bis heute unterstützt wird.

Features

Portable Environment

Der Webbird sollte seit der ersten Version nicht nur mit Installation ins System laufen. Man kann ihn auch in der PE-Version installieren.
Das bewirkt, dass nicht in das Windows User Profile geschrieben wird, von dem der Browser gestartet wird. Das Programm nutzt dann dafür sein Installations Verzeichnis.
Das kann ein USB-Stick, ein Netzlaufwerk oder zum Beispiel ein Cloud Verzeichnis sein.
Vorteil kann sein, dass man an einem fremden PC den Browser mit seinen Persönlichen Einstellungen starten kann und nicht die Einstellungen des Anderen benutzt.
Ein zweiter Vorteil sollte sein, dass man den Browser auch auf Windows Live Images (Setup / Recovery Umgebungen) starten könnte. Nur leider wäre hierfür immer die Verfügbarkeit von .NET-Framework vorrausetzung, was so nie normalerweise möglich war.

Auto Refresh

Ich hatte mal den Bedarf, eine Webseite in einem Zeitintervall neu laden zu lassen. Man sah nähmlich nur Änderungen, wenn man die Seite nach ein paar Minuten erneut geladen hatte. (Beispiel: Vorschläge, die sich nur im Minuten Abstand überhaupt änderten und nicht per Script nachgeladen wurden.)
Dafür brauchte man im Tab des Browsers nur einen Rechts- Klick machen und konnte dort Start oder Stopp auswählen. Für den Start tauchte noch eine Abfrage nach dem gewünschten Intervall auf.

Moved Home

Unter "Moved Home" versteht man, dass es möglich ist, den Ort der Benutzerdaten zu ändern. Im gegensatz zu PE ist hierbei nicht das Unabhängig sein vom im Betriebssystem eingeloggten User im Fokus. Der Browser benutzt für das Speichern der Benutzerdaten im normalfall den Speicherort des Benutzerkontos. Möchte man aber diese Daten woanders speichern (Anwendung zb Widerherstellbarkeit, teilen unter diversen Installationen von OS) kann man einfach die Funktion so auf einen anderen Ort einstellen. Sie kopiert ggf. die Datein vom Benutzerkonto an diesen Ort oder übernimmt lediglich den neuer Ort, sodass dessen Daten einfach benutzt werden. Umgekehrt ist ebenso der Umzug möglich.

Unabhängiger Downloader

Einige Browser hatten früher ein eigenes Download Fenster, dass die Download Prozesse zeigte und wo man diese öffnen oder löschen konnte. Wenn man das Hauptfenster des Browsers schloss, waren zwar die Browser Tabs zu, aber die Downloads wurden fortgesetzt. Bei späteren Design Updates wurden die separaten Fenster abgeschafft und alles durch eine Menü Blase im Hauptfenster ersetzt. Man konnte dann das Hauptfenster solange nicht schließen, bis der letzte Download fertig war. Der Webbird behielt das separate Download Fenster. Ferner fand sich dort auch ein Button, mit dem man ein neues Hauptfenster öffnen lassen konnte, sobald dieses einmal geschlossen war.

MUI

Es ist ansich nichts besonderes, dass ein Programm in mehreren Sprachen verfügbar ist. Jedoch habe ich mir diese Option so ausgedacht, dass sie auf einfachen Text Datein beruht, von denen die Texte eingelesen werden, den so genannten "Language Packs". Fast jeder Text wird aus diesen Datein geladen. Das Praktische ist, dass man diese einfach bearbeiten kann. Außerdem dachte ich an die Möglichkeit, Sprachen nach zu installieren. Einfach eine Sprachdatei herunterladen und über die Funktion im Menü die Datei zur installation auswählen. Das Programm installiert die Sprache und startet mit dieser neu.
Ein weiterer Vorteil der Lösung ist, dass einfach jemand das Programm selbst in seine Sprache übersetzen kann. Danach kann man die Sprachdatei dann öffentlich zur Verfügung stellen.
Damit der Nutzer immer das Menü für die Sprachen benutzen kann, auch wenn der rest des Programms in einer ihm unbekannten Sprache ist, ist dieses Menü einer der wenigen Punkte wo nie übersetzt wird. Dieses Menü ist immer in Englisch gehalten.

(Automatisch wechselnde) Touch Oberfläche

Leider erst in entwicklung war die Reaktion auf Windows Tablets. Einige Browser experimentierten mit einer Touch App Version. Jedoch ergab sich nicht der Markt für Windows Tablets und das zusatz Angebot wahr sehr aufwändig. Somit ließen die anderen Browser das Feature wieder fallen.
Ich hatte es so geplant, dass der Browser beide Oberflächen anbieten sollte. Dabei sollte der Browser erkennen, unter welcher Version von Windows er läuft und entsprechend starten. Das heißt unter Windows 8.x im Full Screen Touch Modus und sonst eher im Desktop Modus. Bei Windows 10 sollte der Browser den Wechsel zwischen "Tablet Modus" und "Desktop Modus" mitbekommen und dann die Tabs in die entsprechende Oberfläche portieren. Interessant dabei: Es sollte ohne einfaches neu laden der URLs im Tab ablaufen. Beispiel: Abspielen eines Videos auf YouTube. Es spielt weiter ab, während der Tab die Oberfläche wechselt. Außer dem "Umschaltmoment", was es sowieso gibt bei Windows 10, hätte man nichts bemerkt.

Versionen

Version 7 [WBT] (~ 2015-2016)
  • .NET-Framework: 4.0
  • Windows: XP-10
  • Engine: Gecko 29.0.9-33.0.3
  • In Entwicklung

Als Microsoft Windows 8.x auf den Markt gebracht hatte sollte sich die Windows Welt in Richtung Touch bewegen. Man wollte damit nicht nur im Desktop Markt aktiv sein, sondern auch bei Tablets. Dafür verpasste man dem Internet Explorer eine Touch App. Diese starte von der "Metro" Oberfläche aus automatisch als App (es sei denn es war ein anderer Browser Standard). Klickte man vom Desktop den IE an, startete er automatisch in der alten Desktop Variante. Tabs konnten zwischen beiden oberflächen übertragen werden, jedoch wurde die Seite einfach neu angesprungen. Auch der Firefox versuchte sich an gleichem. Nur beim Firefox 23 wurde die Oberfläche anfangs gut funktional ausgebaut. Nur wurde sie wahrscheinlich ungenügend fertig und man wollte den Firefox in Version 23 veröffentlichen. In der letzten Beta Version 23 verschwand die Funktion wieder. (Nun gut, der Tablet Markt kam bei Windows weder bei 8.x noch bei Windows 10 richtig.)
Ich wollte aber auch eine Touch optimierte Version anbieten. Nur Habe ich es nicht gekonnt, eine "richtige" App dazu zu entwickeln. Also wollte ich einfach den existierenden Browser auf Touch umbauen. Der WBT Build brachte zunächst eine neue Oberfläche mit großen Buttons und großer URL Zeile. Ich scheute mich, den Code erneut zu erfinden, deswegen nutzte ich erst den Code des WB6 mit. Außer dem einen neuen Hauptfenster kam auch noch nicht viel. Er wurde für Windows bis 8.1 entwickelt (Windows 10 gab es damals noch nicht). Da unter Windows 8.1 eine App immer im Full Screen startete, sollte der WBT dies auch tun. Nur wenn er unter einem älterem Windows gestartet wurde, sollte er als Fenster und kleiner Auflösung starten.

Doch das es zwei Programme gab und ich zwei Codes hatte fand ich nicht so toll. Außerdem plante ich das zum IE vergleichbare Umschalten zwischen Touch UI und Desktop. So kam ich auf die Idee beide Welten in eigene Bibliotheken zu verschieben und zusammen zu verwenden. Erst verschob ich die Entwicklung des WBT in eine Bibliothek um ersteinmal die Entwicklung zu testen. Später lagerte ich auch die Desktop Welt in eine Bibliothek aus. So sollten die Projekte einzeln wartbar sein. Nach dem ich nun drei Bibliotheken hatte, verschob ich die Touch Welt in das Original Projekt zurück. Seit dem nenne ich die Entwicklung auch WB7. Ein Ziel war es das Wechseln zwischen den beiden Oberflächen zu optimieren (siehe WBT Feature). Neben der Touch Oberfläche sollte noch ein Passwort Speicher kommen.
Doch in meinem Leben war Oft keine Zeit mehr um zu Programmieren. Die Entwicklung fand nur noch in sehr großen abständen statt. Ich Experimentierte mit neueren Visual Studio Versionen. Sie hätte mir andere möglichkeiten der Wartung eröffnet. Doch ich hatte doch nie Zeit. Ferner hat sich das Tablet Phänomen aus der Windows welt (fast) zurückgezogen. So wurde die Entwicklung nicht mehr fortgesetzt und steht an dem Punkt bis heute.


Version 6 (~ 2013-2014)
  • .NET-Framework: 4.0
  • Windows: XP-10
  • Engine: Gecko 22.0.0-29.0.0
  • Letzte stabile Version

Version 6 ist das größte Update, was je erfolgte. Nicht nur wegen dem neuen Namen. Der große Screenshot oben auf der Seite zeigt ihn. Zu aller erst fällt auf, dass der Browser eine neue Oberfläche bekam. Mir war nähmlich mit blick auf Version 5 aufgefallen, dass ich nie die Buttons durch Symbole ersetzt hatte, etwas kleiner und an einen anderen Platz. Das UI sah seit Version 1 im wesentlichen gleich (unfertig) aus. So bekamen die Buttons nun Symbole, wurden in Freiräume neben der Adressleiste verschoben und das Lesezeichen Menü kam weg vom Hauptmenü ein einen neuen Button. Dafür folgte im Menü oben eine Suchleiste. Für diese konnte man auch mehrere Suchanbieter auswählen. Später kam auch noch die möglichkeit den Browser per Programm Argument mit einer URL zu starten oder einer Webdatei (z.b. man lässt eine HTML Datei auf dem Symbol des Webbird fallen).
Doch ein weiteres großes Update war die Engine. Der Internet Explorer war mir ein Dorn im Auge. Glücklicherweise hatte jemand die damalige Engine des Firefox namens Gecko für .NET Anwendungen zugänglich gemacht. Diese funktionierte leider nur ab .NET Framework 4.0 . Deswegen musste ich den alten Framework aufgeben und damit den Support für alte Windows Versionen. Gestartet bin ich damals mit Gecko 22. Über die vielen Updates habe ich mich bis Gecko 29.0.9 durchgearbeitet. Mit dem wegfallen der alten IE Engine viel auch der alte Download weg. Somit kam nun der Downloader.
Eine weitere Sache war, dass ich gerne mehrere Systeme nebeneinander benutzt habe. Dazu noch virtuelle Maschinen. Somit war es mein Interesse, ähnlich zu PE, dass verschidene Installationen die gleichen Daten benutzen können. Nun waren diese Daten gerade erst in das Benutzerprofiel umgezogen. Und diese Abhängigkeit vom Benutzer, wo die Daten liegen sollten, wollte ich beibehalten. Das bedeutet: Wenn Nutzer 1 entscheidet, er möchte die Browser Daten wo anders speichern, gilt diese Einstellung für ihn. Wenn Nutzer 2 das nicht entscheidet, liegen die Daten wie gewohnt im Benuzerkonto. Bei PE wird davon ausgegangen, dass die Daten unbedingt naben der Installation liegen müssen (dh damit sie auf einem USB-Stick liegen können). In diesem Fall wollte ich aber, dass der Nutzer frei entscheiden kann, wo die Daten legen. Also entwickelte ich "Moved Home (MVH)". In späteren Updates des WB6 entwickelte ich auch och die Möglichkeit ihn als Standard Browser setzen zu können. Leider stellte ich aber fest, dass diese Methode nur unter Windows XP funktionierte.
Blieb noch das Update von Version 5. Diese war ja noch ohne Gecko Engine, .NET FW 4 und hatte kaum Daten. Der Support für alte Windows Versionen viel ebenfalls. Der Update Prozess durfte also bei alten Windows Versionen nicht gemacht werden. Auf der anderen Seite mussten viele Änderungen vorgenommen werden. Dies hätte der alte Updater auch nicht gekonnt.
Zum Glück hatte ich den WB6 neben dem alten WB5 entwickelt. So überlegte ich mir den WB5 mit einem Mini Update zu Versorgen. Ich entfernte die Suche nach einem neuen Updater und baute eine Sonderfunktion ein, die auf den WB6 wartete und ihn dann im Menü ankündigte. Dafür bekam der WB5 die Sonderfunktion, den im Bild gezeigten "Transformator" zu laden und zu starten. So war beim WB5 nach der letzten original Version "5.0.2.1" die Version mit dem Upgrade Fix "5.0.2.2" erschienen.
Der "Transformator" tut beim Starten erst einmal prüfen, ob mindesten Windows XP installiert ist, der richtige .NET Frwamework und ob der nötige Speicherplatz existiert. Dies gibt er mit den Vierecken mit Grün oder Rot wieder. Nur wenn alle drei kleinen Vierecke Grün sind, wird auch das vierte große grün und der Button freigegeben. Drückt man darauf, wird zunächst 7zip und die alten EXE Datein gelöscht. 7zip wird in der neuen Version nicht mehr gebraucht. Das zippen macht der neue Updater dann selbst. Weiter werden die neue Engine, ein neuer Updater und der neue Browser entpackt. In das Benutzerkonto wird noch eine Einstellungsdatei geschrieben, die von der Engine gebraucht wird. Danach wird der neue Browser gestartet. Dieser war eine Version lang darauf Programmiert den "Transformator" zu erkennen und zu löschen. Dieser würde ja danach nicht mehr gebraucht.


Version 5 (~ 2012-2013)
  • .NET-Framework: 2.0
  • Windows: 98-8.1
  • Engine: IE

Der fünfte Webbird ist interessanter Weise kurz vor einem markanten Bruch in der Entwicklung. Doch dazu später. Bei den Browsern anderer Hersteller kamen Features auf wie ein Syncronisieren von Tabs, dem Verlauf und Passwörtern über die Cloud. Ich wollte meinen Browser auch damit ausstatten. Doch habe ich das dann wieder verworfen.
Mir viel auf, das die Sprach Sets in einer Datei zu halten sehr unübersichtlich ist. Auserdem zogen pro Sprache auch alle UI Elemente ihre Texte aus einem Block. Das machte es noch unübersichtlicher. So überlegte ich mir, dass es besser wäre, jede Sprache in eine eigene Datei zu speichern und jedes Fenster in einem eigenen Block. Sobald die Umstellung erfolgt war, fügte ich als eigene Entwicklungen für die Sprachen noch die Italienische und Spanische übersetzung hinzu. Außerdem war gedacht, eine Plattform einzurichten, sodass andere eingene Übersetzungen für den Browser dazu steuern können. Ich wollte diese Übersetzungen dann meinerseits zum Download anbieten.
Dieser Webbird war der letzte Webbird, der noch garnicht so hieß. Außerdem war es der letzte den man bis Windows 98 benutzen konnte. Denn er war der letzte, der auf Basis des .NET Framework in Version 2.0 entwickelt wurde. Und damit der letzte, der auf der IE Engine setzte. Bis dahin sah der Browser im grunde so aus, wie im Bild zu sehen. Die im Bild gezeigte Version "5.0.2.1" war die fast letzte Version aus der fünfer Serie. Danach gab es noch ein kleines Update. Das hat aber mit der nächsten großen Version zu tun.


Version 4 (~ 2011-2012)
  • .NET-Framework: 2.0
  • Windows: 98-7
  • Engine: IE

Version 4 bedeutete viel Arbeit für wenig bemerkbare Änderungen. Ich dachte, das es nicht so sinvoll ist, wenn mein Programm nur in Deutsch verfügbar ist. Ich hatte erst mal keine Idee wie man eine Übersetzung am besten angeht. Dann dachte ich an die INI Technik, die ich nun einsetzte. Und andere Programme nutzten auch separate Datein um dort die Übersetzungen her zu holen. Also schrieb ich alle Texte in Werte für eine neu INI Datei. Der nächste logische Schritt war dann natürlich das Übersetzen. Als einzige Fremdsprache habe ich richtig Englisch gelernt. Also habe ich erstmal die Englische Übersetzung gemacht. Ein ganzes Programm zu übersetzen ist ... anstengend. Dazu musste dann natürlich code geschrieben werden, der den Text in der gewünschten Sprache aus den Datein lädt und an enstprechender Stelle im UI setzt. Doch nach langer Arbeit war dann das Programm in der lage zwischen Deutsch und Englisch zu wechseln.
Bei den INI-Datein viel mir noch was anderes auf. Ich arbeitete aus verschiedenen Gründen mit meheren Usern am Computer. Doch dadurch das der Browser alle Einstellungen set Version 3 in einer Datei neben sich speichert, waren die Einstellungen für beide Nutzer gleich. Also Arbeitete ich noch etwas an dem Verarbeiten der Einstellungen und legte eine neue INI-Datei an, die im Benutzerkono gespeichert wurde. Es waren nun also die Einstellungen die Nutzerabhängig sein sollten beim Benutzer gespeichert. Einige Werte waren nicht für den Benutzer, deswegen verblieb neben dem Programm die bereits existierende INI-Datei. Die Textdatei mit den Lesezeichen wanderte dann auch zum Benutzerverzeichnis. Doch um all diese Migrationen beim Update durchzuführen, brauchte es wieder einen ZUpdater.


Version 3 (~ 2011-2012)
  • .NET-Framework: 2.0
  • Windows: 98-7
  • Engine: IE

Version 3 war dann doch ein eher größeres Update. Browser wie Firefox und IE hatten bereits Tabs. Das war ein Feature was ich besonders mochte. Zum Glück sah ich ein Tutorial auf Youtube, was zeigte wie man sich einen Browser mit Tabs bauen kann. Damit kamen nun auch Tabs in den Browser hinein. Es war ein langer Prozess die Tab Funktion bis zum Ende zu gestalten.
Ferner hatte ich damals des öfteren das eine Seite mir völlig zufällig Vorschläge machte, die ich ganz in Ordnung fand. Nur diese Vorschläge änderten sich nur beim laden der gleichen bzw. einer anderen Subseite. An einer anderen Stelle hatte ich das Problem, dass eine Art Mini-Webspiel nicht den aktuellen Status wiedergab, der sich durch vergehen der Zeit ändern sollte. Doch ohne neu laden der Seite veränderte auch dieser sich nicht. Also baute ich eine Auto-Reload Funktion in den Browser ein. So konnte man frei einen Timer einstellen, der einfach die Seite erneut laden ließ. Zwischen einer und sechzig Minuten konnten gewählt werden.
Das aus Version 1-2 bekannte Problem mit den Einstellungen bekam auch ein Update. Ich gelangte an die Funktionen ein altes Datei Format für Konfigurations- Informationen zu nutzen, welches unter Windows früh durch die Registry abgelöst wurde. Das INI Format. Ein sehr Primitives Format, was sogar über Windows hinaus Anwendung findet. Doch zum speichern der Einstellungen reichte es aus. So speicherte der Webbird nun seine Einstellungen in einer INI Datei.
Doch da waren noch die alten Text Datein, die aus Version 2 übrig waren. Sie hießen nach den Einstellungen und enthielten nichts, außer den Werten der Einstellungen. Beim Update sollten die Einstellungen übernommen und die Text Datein entfernt werden. Diese Funktionen gab der Updater nicht her. Also musste ich noch einen neuen Mechanismus ausdenken, der das Problem umgang. Ich dachte über das zukünftige auspacken einer ZIP Datei nach. Also tarnte ich ein neues Tool als falschen Browser. Der ZUpdater war ein zweiter Updater der sich selbst erst vom Fake Browser zum ZUpdater machte und dann beide alte Programme aus dem Weg schaffte. Danach Packte er ein 7zip Tool, die neue Settings.ini und einen neuen Updater aus. Die alten Einstellungen migirerte der ZUpdater dann auch gleich in die INI-Datei und löschte die anderen Text Datein. Anschließend wurde der neue Updater einfach wieder ausgeführt. Dieser löschte dann "dumm" alles, was sich nach Browser anhörte. Um danach per 7zip die ZIP Datei auszupacken. Damit lag der wirkliche Browser wieder auf der Platte. Nun konnte der Browser wieder gestartet werden. Auch dieser suchte nocheinmal nach dem ZUpdater und entfernte ihn.


Version 2 (~ 2011)
  • .NET-Framework: 2.0
  • Windows: 98-7
  • Engine: IE

In Version 2 gab es so weit ich mich errinern kann kaum neuerungen. Das alte Problem mit dem Setup, Update und den Einstellungen wurde hauptsächlich gelöst. Ich hatte in der Zeit im Internet von "Inno Setup" erfahren und es ausprobiert. Ich konnte nun endlich ordentliche Setups anbieten. Eine Code Erweiteung für das Setup fand sich via Internetsuche auch noch. Damit konnte ich den Status einer .NET Framework installation abzufragen und ggf. das Setup zu beenden. In diesem Fall wurde der User auf die Download Seite für .NET Framework bei Microsoft geleitet um dies im Anschluss zu installieren. Damit war mein erster Ansatz, ein eigenes Setup Programm zu schreiben, wieder vom Tisch.
Für das Updaten entwickelte ich gleich ein Zweitprogramm. Es stellte die Update Routine bereit. Der Browser sollte den Updater zunächst herunterladen. Dieser enthielt die neue Version des Browsers im Gepäck. Der Browser startete dann den Updater und beendete sich selbst. So konnte der Updater dann einfach die Version des Browsers überschreiben.
Für die Einstellungen fehlten mir zunächst gute und praktische Ideen. So habe ich zunächst die Einstellungen in Text Datein geschrieben, die genau so hießen, wie meine Einstellungen. Und in diese Datein habe ich dann nur den Wert geschrieben.
Eine weitere Textdatei, die hinzu kam, diente zum Speichern der Lesezeichen. Diese waren auch die einzigsten Neuerungen, die im UI des Browser in Version 2 auftauchten.


Version 1 (~ 2010)
  • .NET-Framework: 2.0
  • Windows: 98-XP
  • Engine: IE

Dies war der erste Webbird. Er konnte nur die Basis Funktionen der Browser bedienung. Zum Beispiel Vor, Zurück, Startseite, Neu laden. Es war noch nicht möglich, URL-Files zu öffnen oder das der Browser eine URL öffnete, wenn man in der Eingabezeile die Eingabe Taste drückte. Tabs waren noch nicht möglich. Downloads wurden über den Internet Explorer organisiert. Eine Installation oder eine Update Routine fehlte komplett.
Das Programm wurde nur als EXE verteilt. Und zwar mit der Visual Studio Distributions Funtion. Diese Fand ich absolut unpraktisch. Ihr einziger Vorteil: sie prüft die Abhängikeit von .NET Framework. Aber sie machte leider eine ziemlich ungewöhnliche Installation. Außerdem guckte sie auf einer mir nie erschlossenen Quelle nach Updates. Erst danach wurde mein Browser gestartet. Während ich auf meinem Recher nur die EXE starten musste. Deshalb liefen bereits vor der Version 2 versuche ein eigenes Setup Programm dazu zu schreiben. Auch wenn es selbst .NET gewesen wäre, sollte es besser sein, als das Setup was von Visual Studio kam.
Ein weiteres Problem waren die Einstellungen. Diese wurden unter "AppData" gespeichert. Aber leider in einem Verzeichnis, das von der Version abhängt. Hatte ich innerhalb der Version 1 von z.B. Version "1.0.0.1" ein Update auf Version "1.0.0.2" gemacht, so wurde dafür ein neues Verzeichnis angelegt. Es war aber nicht möglich die alten Einstellungen zu übernehmen.