News TinyRetroPad: Ex-Microsoft-Entwickler schreibt Notepad mit 2,5 KB neu

Dass man mit gutem Code recht viel in eine kleine Datei birngt, ist nix neues. Zumal wenn der Rest vom BS gestellt wird.

Altes aber gutes 4KB Demo:
 
Wichtig das zu programmieren...
 
Hab mit gerade mit MiMo für ein paar Cent in C++ einen 3KB Editor schreiben lassen. Darauf hat die Welt bestimmt auch gewartet, kann ich bitte eine News haben?
 
@MaverickM
Diese Debian basierte Distribution wäre ein Beispiel FÜR ein Betriebssystem, welches mit gescheitem Abhänigkeitsmanagemant allerhand Bibliotheken, Frameworks und Laufzeitumgebungen mitbringt.
53,5 MiB allein für fonts
16,9 MiB für Perl + Bibliotheken in /usr/
26,5MB MiB python 3.11
QT5, GTK als GUI frameworks

Alles Kram, der nur einmal da ist und von allen Anwendungen genutzt werden kann. Anstatt jede Anwendung alle Fonts, eine Python-Umgebung oder eben GTK/QT5 GUI selber mitbringen muss. Würde jede Anwendung alles selber an Abhänigkeiten inkludieren, wäre es Damn Fat Linux.

Die auffälligste Anwendung, die ihre Abhänigkeiten selber mitbringt, obwohl sie Bibliotheken vom OS nutzen könnte ist FireFox ESR mit ~241MiB. Da könnte gut 1.1MiB allein gespart werden, würde Firefox die SQLite-Implementierung nutzen, die auch unter /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 liegt.
 
Piktogramm schrieb:
Diese Debian basierte Distribution wäre ein Beispiel FÜR ein Betriebssystem, welches mit gescheitem Abhänigkeitsmanagemant allerhand Bibliotheken, Frameworks und Laufzeitumgebungen mitbringt.

Eher nicht. Die Tatsache, dass auch dort immer noch Bibliotheken vorhanden sind, bestätigt eher meinen Punkt, bzw. das eigentliche Problem.

Ich hab auch nie behauptet, dass das Betriebssystem komplett ohne Bibliotheken/Frameworks auskommen muss. Aber man könnte den Overhead drastisch reduzieren und wirklich nur das allernötigste mitliefern. So wie DSL eben.
 
input_iterator schrieb:
Ein Rich Edit Control bringt einen kompletten, vorgefertigten Text Layout Stack, Undo Mechanismus, Formatierungslogik und diverse Direct Write‑Objekte mit unabhängig davon, ob man die braucht oder eben nicht.
Ich kann Deine Kritik dahingehend nachvollziehen, dass für einen Nicht-RTF-Editor ein RT-Control auf dem Papier zu schwergewichtig ist. Andererseits braucht doch jeder Editor einen minimalen Text Layout-, Undo-Stack etc..
Klar, kann man machen, und mit KI-Support und "etwas" Münzeinwurf ist das auch kein 1-Jahres-Projekt mehr.

Ich allerdings käme - außer aus Fun - never ever auf den Gedanken, einen weiteren OS-spezifischen Text-only Editor from scratch zu realisieren. Vor allem, weil es diese doch schon gibt (https://www.thewindowsclub.com/how-to-restore-the-classic-notepad-in-windows).

Herrn P. ging es m. E. auch nicht darum. Das ist vielmehr ein Showcase dafür, dass man - gerade die einfacheren - Anwendungen durch Komposition und Wiederwendung von Modulen/Komponenten, die seit Ewigkeiten existieren und robust sind, mit einem "Bisschen" glue code realisieren kann.

Eigentlich nur implementierte Kritik an den heutigen Umsetzungsansätzen in Redmond, oder?
 
  • Gefällt mir
Reaktionen: MaverickM
Ich hoffe jedem ist klar wer Dave Plummer ist, schaut mal seine Beiträge bei YT an und z.B. wer Task Manager oder ZIP Folders erfunden hat:)
 
Nach meiner Erinnerung hat er vor allem das UI für den Task Manager umgesetzt. Die ZIP Folders haben mich immer genervt, weil der Datei Manager die aufgrund seiner ikonischen "Reiterlosigkeit" immer in place geöffnet hatte.

Das soll aber objektiv seine Leistung nicht schmälern. Alle, die ASM können, sind eh' "Heroes".
 
MaverickM schrieb:
Eher nicht. Die Tatsache, dass auch dort immer noch Bibliotheken vorhanden sind, bestätigt eher meinen Punkt, bzw. das eigentliche Problem.
Welches Problem bitte? Mit shared libraries wird das Installationsmedium überhaupt so klein, wird Bedarf an Arbeitsspeicher im Betrieb verringert. DSL würde fix doppelt so groß werden, wenn jede Anwendung ihre eigene Anwendungsschicht vom Netzwerk inkl. Krypto implementieren müsste, wie auch Kompression, GUI, Fonts, ... Das wäre total gaga!
Ich hab auch nie behauptet, dass das Betriebssystem komplett ohne Bibliotheken/Frameworks auskommen muss. Aber man könnte den Overhead drastisch reduzieren und wirklich nur das allernötigste mitliefern. So wie DSL eben.
Der Minimalismus bei DSL geht doch aber grundlegend nur, weil möglichst viele geshared libraries zum Einsatz kommen und Abhänigkeiten jederzeit nachinstallier werden, wenn Anwendungen aus den Repos diese fordern.

Windows hat halt kein gescheiten Paketmanager, noch gescheites Abhänigkeitsmanagement. Da geht der Minimalismus in der Form halt nicht. Ist aber auch nicht sinnvoll, die Abmachung ist ja, dass das Wi Betriebssystem div. Funktionalität als Selbstverständlichkeit immer anbietet.
 
  • Gefällt mir
Reaktionen: mibbio
Eben DSL hat in der Grundausstattung gerade mal so viel, dass man eine eher simple Desktopumgebung mit Browser (Firefox ESR), einfachem Terminal, Dateimanager, Texteditor und 3-4 anderen Standardprogrammen bekommt. Bei diesen Programmen sind es wiederum auch eher simple Vertreter.

DSL ist primär dafür gedacht, auf Systemen mit (sehr) wenig Resourcen grundlegend Tätigkeiten zu machen, aber weit entfernt von einem im Alltag umfangreich produktiv nutzbar zu sein. Sobald du DSL wie ein vollwertiges, modernes Desktopsystem nutzen willst, muss man da auch gigabyteweise Pakete und Abhängigkeiten installieren und dann ist es auch nicht mehr schlanker als eine Installation von Debian oder anderer Desktop-Distributionen.
 
Luftgucker schrieb:
Auf dem besten Computer aller Zeiten mit 3583 Bytes free wurde besseres geleistet als ein Texteditor.
Welcher soll das gewesen sein?

Ich kannte nur den mit 38911Bytes. Sofern man das OS(inkl. Interpreter) nicht weglässt un in Assambler loslegt, dann standen einem sogar fast doppelt soviel RAM zur verfügung
 
KitKat::new() schrieb:
Crinkler ist ein (komprimierender) Linker... u.

Das habe ich auch nicht behauptet. Der Punkt ist ein anderer, Crinkler verändert nämlich das Speicherverhalten der Anwendung, weil es den Code extrem komprimiert und beim Start dekomprimiert, was sich auf das Working Set und die Commit Größe selber auswirkt. Wenn die Minimal App ohne Crinkler bei eben1,7 MB liegt, zeigt das nur, dass der Assembler Wrapper selbst praktisch nichts verbraucht. Der große Footprint entsteht erst im vollständigen Editor Projekt, weil dort zusätzliche Komponenten, Fenster, Buffers und Layout Strukturen aktiv sind, die im reinen selber Demo Code nicht existieren.
Ergänzung ()

ComputerJunge schrieb:
Eigentlich nur implementierte Kritik an den heutigen Umsetzungsansätzen in Redmond, oder?
Für einen reinen Text Editor ist ein komplettes Rich Edit Stack natürlich schwergewichtig und ja, jeder Editor braucht am Ende einen eigenen Undo Mechanismus, ein Text‑Layout und die üblichen Grundstrukturen. Der Unterschied ist nur, dass Rich Edit all das als vollwertiges Subsystem mitbringt, inklusive Glyph Runs, Format Caches, Fallback Tabellen und Direct Write‑Targets, während ein eigenes Widget nur das erzeugt, was man selbst implementiert. Dass man heute mit KI Unterstützung und Budget einen Editor from scratch bauen könnte, stimmt, aber genau darum ging es Herrn P. nicht. Sein Projekt demonstrierte, dass man einfache Anwendungen durch Komposition robuster, seit Jahrzehnten existierender Komponenten mit minimalem Integrationscode realisieren kann. In diesem Sinne ist es tatsächlich eine implementierte Kritik an modernen, überkomplexen Umsetzungsansätzenn.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ComputerJunge
Diese Art der Entwicklung feiere ich extrem! Leider ist sie bei Windows aber sehr riskant, da Microsoft sehr "sprunghaft" (oder eher willkürlich) mit den eigenen Systemkomponenten umgeht und man durch tiefgreifende Abhängigkeiten eben immer die Gefahr läuft, dass das nächste Windows-Update die Funktionsweise beeinträchtigt oder gar bricht. Zumal Windows ja nicht Open-Source ist.

Bei Android beispielsweise ist das völlig anders und viel durchdachter. Hier wird an der Funktionsweise einzelner Komponenten selten etwas geändert, sondern sie werden im Bedarfsfall schrittweise durch neuere Komponenten ersetzt, wobei sämtliche Änderungen immer sauber dokumentiert werden, und zwar lange im Voraus. Meist werden neuere Komponenten redundant eingeführt, das heißt, sie ersetzen alte Komponenten nicht sofort, sondern sie werden zunächst als Alternative mit neuem Funktionsumfang eingeführt, mit der Empfehlung, diese in Zukunft zu nutzen. Entwickler haben so die Zeit, "langsam" auf diese zu migrieren, bevor die alte Komponenten dann irgendwann "deprecated" und aus Android entfernt wird.

Leider nutzen die meisten Entwickler das heutzutage kaum noch, sondern packen sich die eigenen Apps mit zahlreichen externen Libraries voll, die selbst aus einer "Hello World"-App dann gerne mal eine adipöse 20 MB Pottsau machen, ohne jeglichen Mehrwert. Für mich eine absolut traurige Entwicklung!
 
@input_iterator
OK, wir sind bzgl. der Motivation für diese Umsetzung d'accord.

Privat bin ich in der node.js-Welt unterwegs. Das ist ok, weil ich nur persönliche nicht-funktionale Anforderungen habe. Aber diese beinhalten durchaus (sozusagen als NI-instruction.md): for non-major logic, using external dependencies is a strict no-go. For major logic explicitly ask for my "Go".
 
input_iterator schrieb:
Der große Footprint entsteht erst im vollständigen Editor Projekt, weil dort zusätzliche Komponenten, Fenster, Buffers und Layout Strukturen aktiv sind, die im reinen selber Demo Code nicht existieren.
nein, tut's nicht, sonst würde der Editor mit einem anderen Linker gar nicht funktionieren - ein Linker fügt sowas nicht hinzu
 
Bis fast 4KB hätte er schon gehen dürfen, gibt ja kein Dateisystem mehr, das wirklich darunter als Blockgröße nutzt :D

Ansonsten ists halt wie immer, gut das das so klein ist, aber auch das wird auch Systemfunktionalitäten und DLLs zurückgreifen natüelich :-) aber das ist ja ohnehin vorhanden.
 
Zurück
Oben