Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsTinyRetroPad: Ex-Microsoft-Entwickler schreibt Notepad mit 2,5 KB neu
Gibt doch auch son Trend, eher Wettbewerb, spiele in paar KB zu bauen. Mit über Algorithmus generierten Texturen usw. Sehr witzig. Das ist Software anständig bauen. Den Rest macht mittlerweile eh KI 🤣.
Z. B. .kkrieger
Mal nachlesen, ist echt krass.
Ich bin mir gerade nicht sicher, aber ich halte es für möglich, dass das Zombi-FS Reiser 4/5 wie sein nicht verwandter Vorgänger ReiserFS die Fähigkeit besitzt, so kleine Dateien nicht in den Blöcken speichern zu müssen, sondern "direkt in die Nodes" schreiben kann, oder wie das damals hieß. Ich weiß aber gerade auch nicht wirklich, ob Edward Shishkin immernoch an Reiser5 arbeitet. Windows NT hat seit jeher eine IFS-Schnittstelle (installable file system), die tatsächlich einigermaßen stabi sein soll - im Sinne von, da ändert sich selten was.
Sehe ich angesichts der 8,4 MiB von Np++ jetzt nicht so.
Ich hab mich auch immer, meiner Ansicht nach völlig zurecht, darüber aufgeregt, dass selbst das kleinste Tool einen unsäglichen Ressourcenhunger besitzt. Und warum? Weil die UIs doch bitte mit WinUI 3 erstellt werden sollen, was das ganze unsäglich aufbläht. Entwickle ich das gleiche Tool mit Windows Forms, wirds zehnmal kleiner. Und genau das hat Dave Plummer wohl gemacht, seinen Texteditor einfach mit Windows Forms als UI geschrieben.
Mich hat dieses unnötige Aufblähen irgendwann so abgenervt, dass ich auf Linux gewechselt bin.
Die Tab- und die Autospeicherfunktion des aktuellen Notepad auf Windows nutze ich an sich sehr gerne. Notepad ist für mich eine Art "Notizettel" in dem ich diverse Codeschnipsel und Informationen dort vorhalte.
Aber cool, das es eine "Retro" Version gibt.
Können sich ja alle installieren, die nur einen 8 GB RAM Riegel im System haben kicher
Gleichzeitig versteht sich TinyRetroPad als Kritik an der zunehmenden Komplexität und Funktionsüberladung aktueller Windows-Anwendungen wie Notepad unter Windows 11.
Selten so einen BS gelesen! Notepad öffnet auf jedem Computer (mindestens) der letzten 10 Jahre in Sekundenbruchteilen nach Klick auf das Icon.
Welcher Editor öffnet sich denn (merklich) schneller? Keiner! Danke dass wir das geklärt haben.
Dazu zählen unter anderem Tabs, automatische Speicherung, Markdown-Unterstützung, Tabellenfunktionen, Bildunterstützung sowie die Integration von Copilot- beziehungsweise Writing-Tools.
Und das ist auch gut so!
Tabs und Auto-save sind das Beste was dem Editor seit Erscheinen passiert ist.
Ergänzung ()
mibbio schrieb:
Der Trick ist dann ja gerade, dass die Anwendungen letztlich eben diese ohnehin vorhandene Funktionalität von Windows nutzen und diese quasi nur orchestrieren, statt lieber alles nochmal selber zu implementieren und damit unnötig nochmal x MB zusätzlich zu den Standard-DLLs belegen.
Auch das offizielle Notepad nutzt natürlich zu großen Teilen bereits in Windows integrierte Funktionen.
Nur hat die App noch so einige (meist) sinnvolle Funktionen mehr, weshalb sie natürlich auch etwas größer ist.
Aber doppelt ist auch hier nichts. Keine Ahnung wie der Autor auf so eine Vermutung kommt.
Ergänzung ()
SaschaHa schrieb:
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.
Quatsch. Das ist unter Windows seit Urzeiten genau so Standard.
Open Source muss das auch nicht sein. Die Dokumentation ist bei Windows extrem detailliert. Wenn man sich an die Programmiervorgaben hält, dann hat man eine absolute Rock-Solid Anwendung, die im Normalfall auch mehrere Windows-Versionen übersteht - genau DAS ist die Stärke von Windows, dass auch 30 Jahre alte Programme problemlos heute noch laufen - solange sich an die Regeln gehalten worden ist.
Ergänzung ()
Iwona_C schrieb:
Da fällt mir ein:
Sumatra PDF (war früher noch kleiner)
versus
Acrobat Reader
Natürlich ist der Adobe Reader viel zu fett.
Aber der Vergleich hinkt, weil der Adobe Reader viel mächtiger ist.
Wenn du ein PDF mit einigen speziellen Features öffnen willst, verkacken Programme wie Sumatra (und viele andere).
Ergänzung ()
fbg schrieb:
Zu den großen Einschränkungen von Windows, insbesondere im Vergleich zu MacOS, gehört gerade das nicht-Vorhandensein einer leistungsfähigen GUI Bibliothek.
Und gerade MacOS als leistungsfähige GUI bezeichnen... 😂
Einigen mag es zwar besser gefallen, oder sie kommen damit besser klar, aber technisch ist die teilweise in den 90ern hängen geblieben.
Ich arbeite übrigens mit beiden ☝️
Ergänzung ()
MaverickM schrieb:
Wäre es nicht deutlich sinnvoller solche Dinge nicht mitzuliefern und es den Programmen überlassen, diese einzubinden/mitzuliefern? Das würde doch eigentlich Windows deutlich verschlanken. Ja, die Programmgröße würde anwachsen, aber eben dafür Windows schmaler werden.
Oh mein Gott, auf keinen Fall! Das wäre dann irgendwie 80er Style. Gruseliger Gedanke.
Und was bringt es dir, wenn Windows selbst schmaler wird? Windows ist schmal.
Es belegt auf einer zeitgemäßen SSD/HDD nur einen Bruchteil des vorhandenen Platz.
Ergänzung ()
mischaef schrieb:
Welche sollen das sein? Also welche, die für viele Anwender einen so großen Nutzen darstellen, dass sich der größere Speicherverbrauch lohnt
Der Mann ist seit über 20 Jahren nicht mehr bei MS.
Und wenn er noch da arbeiten würde, sollte man ihn wegen all seiner dubiosen Geschäfte und seiner sonstigen Gesinnung und kaputten Psyche im hohen Bogen rauswerfen.
Ergänzung ()
Spriti schrieb:
Sobald Windows etwas ändert, irgendeine Komponente weglässt, funktioniert der Editor nicht mehr und muss angepasst werden.
Das ist so der absolute Standard in Windows seit Jahrzehnten.
Windows ändert da nichts oder lässt etwas weg. Wenn man sich an die Dokumentation gehalten hat beim Programmieren, dann laufen deine Programme seit Jahrzehnten über diverse Windows-Versionen absolut problemlos.
Ergänzung ()
DaDare schrieb:
man darf da auch gerne auf den Youtube Kanal von Dave verlinken.
Naja, Größe ist mir ziemlich egal. Zumindest wenn es um diese Größenordnung geht. Mehr Funktionen stören nicht, solange das Programm genau so schnell startet wie die schlanke Version.
Es ist wichtig, Basisprogramme zu haben die Instant geöffnet sind
Glaube da ist wohl Verständnis Problem. Das eine Programm was Ressourcen sinnlos verschwendet ist nicht schlimm und fällt den Nutzer nicht auf. Bloß besteht Windows aus 100 von solchen Diensten und jedes Software wird so Ressourcen verschwenderisch geschrieben das am Ende das ganze System darunter leidet. Daher braucht Windows minimal 8GB und nicht 4GB ram oder noch weniger.
Daher Frist Windows bei jeden Game auch etwas an der Performance.
Hier wird halt genau gezeigt was bei der aktuelle Programmierung von Software schief läuft. Es wird nicht Ressourcen sparend programmiert.
Ich hab mich auch immer, meiner Ansicht nach völlig zurecht, darüber aufgeregt, dass selbst das kleinste Tool einen unsäglichen Ressourcenhunger besitzt. Und warum? Weil die UIs doch bitte mit WinUI 3 erstellt werden sollen, was das ganze unsäglich aufbläht. Entwickle ich das gleiche Tool mit Windows Forms, wirds zehnmal kleiner. Und genau das hat Dave Plummer wohl gemacht, seinen Texteditor einfach mit Windows Forms als UI geschrieben.
Plummers Kritikpunkt ist nicht das Notepad allein, sondern die Kultur, die das an jedem Code-Schnipsel sagt, was am Ende, mit allen zwölfundneunzig anderen Programmen zusammen, dazu führt, dass du den Filebrowser von Windows 11 auf nem zehn Jahre alten Rechner nicht mehr flüssig öffnen kannst. Ob er da irgendwelche Schwurbleransichten zum Klimawandel vertrete (hab kurz recherchiert und kein einheitliches Urteil dazu gefunden) oder Trumpist sei, wie auch immer, das hat mit diesem Kritikpunkt nichts zu tun.
Früher war die eine relevante Anwendung, die viele Ressourcen benötigte, der Browser.
(Von wenigen Spezialanwendungen eben mal abgesehen).
Irgendwie hat sich die "tolle" Idee durchgesetzt, fast jedes Mini-Pups-Werkzeug nun auf Browser-Basis zu implementieren.
Moderne Spiele verbrauchen heute auch sehr viel Platz (Disk wie RAM), weil oft 4K-Grafik angeboten wird. Aber davon läuft eben auch in der Regel nur eines.
Das Problem ist wohl auf deiner Seite. Wo genau wird hier gezeigt, dass wenig Arbeitsspeicher benötigt wird? Genau das Gegenteil ist der Fall. Es wurde lediglich gezeigt, dass es deutlich kleiner geht. Die Größe der Anwendung hat nicht viel mit dem Verbrauch von Arbeitsspeicher zu tun.
Die Dependencies sind super, wenn die Software gepflegt wird. Sollen die Entwickler einer Lib auf Tools Rücksicht nehmen, die seit 10 Jahren nicht mehr gepflegt werden?
Das Problem ist wohl auf deiner Seite. Wo genau wird hier gezeigt, dass wenig Arbeitsspeicher benötigt wird? Genau das Gegenteil ist der Fall. Es wurde lediglich gezeigt, dass es deutlich kleiner geht. Die Größe der Anwendung hat nicht viel mit dem Verbrauch von Arbeitsspeicher zu tun.
Doch hat wenn die Bibilotheken vom OS verwendet werden, statt diese im Programmcode zu intrigieren. So wie ich verstanden habe wurde das hier gemacht.
Der Unterschied im Detail 1. Wenn Sie die DLL in die Anwendung einbinden (Statisches Linking)
Speicherverbrauch: Der gesamte Code der Bibliothek wird fest in Ihre .exe-Datei einkompiliert. Wenn Sie fünf verschiedene Programme starten, die diese DLL nutzen, wird der Code fünfmal komplett in den Arbeitsspeicher geladen. Das verbraucht unnötig viel RAM. [1, 2, 3]
Vorteil: Ihre Anwendung ist "selbstständig". Sie müssen keine separaten DLL-Dateien mitliefern oder befürchten, dass die falsche Version auf dem System installiert ist. [1, 2, 3]
2. Wenn das OS die DLL verwendet (Dynamisches Linking / Shared Library)
Speicherverbrauch: Die DLL bleibt eine eigenständige Datei auf der Festplatte. Starten Sie mehrere Anwendungen, die auf dieselbe DLL zugreifen, lädt Windows den reinen Programmcode nur einmal in den Arbeitsspeicher. Die Anwendungen teilen sich diesen Speicherbereich. Der Speicherverbrauch sinkt auf Systemebene drastisch. [1, 2, 3, 4, 5, 6]
Vorteil: Geringer RAM-Bedarf. Außerdem profitiert die DLL von Windows-Updates – wird die System-DLL zentral gepatcht, sind automatisch alle Anwendungen auf dem neuesten Stand. [1, 2]
Sorry das ich KI verwende für Erklärungen die ich mühseelig zusammenschreibe und am ende Text rauskommt der nicht so gut verständlich ist. Weil ich Programmierer und Techniker bin und kein Lehrer.
"Plummer betont, dass die geringe Größe des Editors keineswegs ein Wunderwerk sei. Windows selbst stelle nahezu alle Funktionen bereit, die klassische Desktop-Anwendungen benötigen. Dazu gehören unter anderem Fensterverwaltung, Menüs, Dialogfenster, Zwischenablage, Druckfunktionen, Schriftartauswahl und Textsteuerungen, die bereits fester Bestandteil des Betriebssystems sind. Eine kleine Anwendung müsse diese Komponenten lediglich nutzen, anstatt eigene Bibliotheken oder Frameworks mitzuliefern. Dies beschreibt Plummer mit dem Vergleich, dass ein kleines Windows-Programm lediglich „mit einer Brotdose und einem Stadtplan“ anreise, während das Betriebssystem bereits die gesamte Infrastruktur bereitstelle."
"Auch im Arbeitsspeicher benötigt das TinyRetroPad wenig Platz (Bild: Windows Latest)"
Das war die stelle wo ich daraus schließe das er die Bibiliotheken aus dem OS zieht statt im Editor zu intrigieren.
Es geht bei dem Anliegen gar nicht primär umd dynamisches oder statisches Linken, auch wenn das indirekt auch mit reinspielt.
Am Beispiel des Editor geht es primär um das Konzept, überhaupt die von Windows schon bereitgestellten Standardfunktionen & -controls zu verwenden anstatt dass jede Anwendung seine eigene oder eine 3rd-party Implementierung davon mitbringt. Also beispielsweise den "Datei öffnen" oder "Datei speichern" Dialog nutzen, den Windows bereits nativ anbietet, statt einen solchen Dialog für jede Anwendung selber zu schreiben (oder per 3rd-party DLL einzubinden).
Es geht letzlich auch nicht unbedingt darum, ob der Editor im Speziellen zu fett geworden ist oder wie klein man den bekommen könnte. Der bietet sich halt als prominentes Beispiel mit einem sehr überschaubarem Funktionsumfang als Grundlage an, um damit das Konzept zu erklären.
