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

[Brrr]

Solche Entwickler lässt MS einfach gehen??

Ruhestand

 

[MaverickM]

Die Wahrscheinlichkeit ist hoch, dass zumindest irgendein(!) Programm das native GUI-Framework des OS nutzt.

Welches? Das ist genau die Krux. Sieh dir doch den Wust an, der das Windows GUI Framework ist. Selbst Windows selbst nutzt diverse Versionen davon, viele stark veraltet. Deswegen haben wir ja auch noch immer die Systemsteuerung und den Mix aus verschiedenen alten und neuen Windows Dialogen.

Auf den laufenden Betreib haben ungenutzte Libraries vom OS normalerweise keinen Einfluss.

Ich habe genau deswegen bewusst GUI Frameworks als Beispiel gewählt. Die laufen bei Windows ja parallel, weil eben viele unterschiedliche Dialoge noch unterschiedliche GUIs verwenden.

 

[Eld0r]

Ich schau gern Dave's Garage. Es sollte mehr Entwickler wie Plummer geben.

 

[KitKat::new()]

Welches?

win32, uwp und winui3 - die anderen sind nur Frameworks oben drauf

Ich habe genau deswegen bewusst GUI Frameworks als Beispiel gewählt. Die laufen bei Windows ja parallel, weil eben viele unterschiedliche Dialoge noch unterschiedliche GUIs verwenden.

und? dann sind sie so oder so auf Rechner

 

[MaverickM]

und?

Eben nicht "und". Das war doch mein Punkt, dass dieser Wust an Frameworks völlig unnötig ist.

 

[DavidXanatos]

Also Wordpad einstampfen um den notepad zu einem neuem wordpad zu pervertieren das schaffen nur ganz ganz besondere entwickler.

Eine der aller erstens achen die ich immer deinstalliere auf win 11 ist der neue notepad, gut as die den alten win32 basierten als fallback drin gelassen haben.

 

[KitKat::new()]

Ich verstehe nicht, was daran genial sein soll. Das ist lediglich ein einfacher optimierter Wrapper, in Assembler geschrieben, für das RICHEDIT50W‑Steuerelement der WinAPI. Er frisst fast 600 MB Speicher. Genial wären 2,5 KB mit eigenen Funktionen …

Die 600 MB beziehen sich nicht auf die DLL, sondern auf das, was Windows zur Laufzeit für das Rich Edit Fenster anlegt

Hab mir jetzt übrigens mal den Spaß gemacht das Steuerelement selbst mal zu nutzen um zu sehen ob das mit den 600 MB wirklich stimmt.

Tatsächlich braucht eine App, die nur das Steuerelement nutzt nichtmal 1,6 MB, also liegen die 600 MB nicht an dem Steuerelement

Code angehängt

Ergänzung (Gestern um 17:47)

Eben nicht "und". Das war doch mein Punkt, dass dieser Wust an Frameworks völlig unnötig ist.

Du hast behauptet, dass du ohne die vorinstallierten Frameworks einen schlankeren Betrieb hättest, weil die Frameworks dann nicht installier werden müssten.
-> ich habe erwidert, dass ungenutzte Frameworks eh keine Auswirkungen auf den Betrieb hätten
Du hast behauptet, dass die Frameworks aber doch in Benutzung seien, weil die ja von verschiedenen Dialogen genutzt werden würden
-> ich schrieb, dass die Frameworks dann so oder so auf dem Rechner wären (egal ob seitens Windows allgemein zur Verfügung gestellt oder durch die Programme mit den Dialogen)

-> verstehe deine Antwort darauf im Kontext nicht

 

[input_iterator]

Hab mir jetzt übrigens mal den Spaß gemacht

Ein nacktes Rich Edit Control in einer Minimal App misst natürlich nur die Laufzeitzuweisung selbst. Das sagt aber nichts darüber aus, was passiert, wenn du ein komplettes Fenster Subsystem, Message Loop, Undo‑Stack, Text Layout Caches und die üblichen Direct Write Objekte eines realen Editors mit lädst. Du hast das Steuerelement isoliert getestet. Ich habe aber den tatsächlichen Runtime Footprint des Editors beschrieben. Ob der konkrete Wert dann bei dir 200, 400, oder 600 MB ist, hängt von System, Dateiinhalt und Nutzung ab.

 

[T3rm1]

Dazu gehören das Öffnen und Speichern von Dateien

Ab diesem Satz wusste ich sofort, wer den Artikel geschrieben hat. Es gibt nur einen "Redakteur", der so schreibt. Unglaublich.

 

[KitKat::new()]

wenn du ein komplettes Fenster Subsystem, Message Loop, Undo‑Stack, Text Layout Caches und die üblichen Direct Write Objekte eines realen Editors mit lädst

also Fenster, Message Loop, Undo Stack (wird vom Widget erledigt) beherrscht mein Code übrigens auch

Was für Text Layout Caches und übliche Direct Write Objekte meinst du?

Ich habe aber den tatsächlichen Runtime Footprint des Editors beschrieben.

für mich hat sich das gelesen als meintest du das Widget.

PS: Wenn man auf Crinkler verzichtet, kommt man anscheinend für den Code im Repo auf 1,7 MB RAM
Quelle: https://github.com/PlummersSoftwareLLC/TinyRetroPad/issues/21#issuecomment-4855897227

liegt also nicht am Code, dass so viel gebraucht wird

 

[Shio]

kA was daran jetzt so besonders sein soll.
Notepad++ braucht bei mir 10MB Arbeitsspeicher laut Prozessübersicht und ist 100 mal besser.
Hat ers mal wieder geschafft das die Presse über ihn schreibt. Der sollte eigentlich komplett ignoriert werden für den Ramsch den ich auf twitter schon von ihm lesen musste.

 

[Caramon2]

Gleichzeitig versteht sich TinyRetroPad als Kritik an der zunehmenden Komplexität und Funktionsüberladung aktueller Windows-Anwendungen wie Notepad unter Windows 11.

Nicht nur bei Windows. Bei Linux denke ich da als erstes an GNOME 3 (ich nutze Xfce), aber auch vieles andere geht in diese Richtung (macOS scheint mir auch keine Ausnahme davon zu sein):

Alles muss bunter, überladener und umständlicher werden, was man dann "modern" nennt.

 

[mibbio]

Das sagt aber nichts darüber aus, was passiert, wenn du ein komplettes Fenster Subsystem, Message Loop, Undo‑Stack, Text Layout Caches und die üblichen Direct Write Objekte eines realen Editors mit lädst

Diese Laufzeitendaten fallen dann aber auch bei Anwendungen an, die dieses spezifische Control nicht verwenden, sondern irgendein anderes (selbstimplementiertes). Jede grafische Anwendung hat ein Fenster-Subsystem, damit es überhaupt Fenster anzeigen kann und einen Message Loop, um auf Eingaben und Systemmessages reagieren zu können. Die Laufzeitedaten zum Rendering fallen ebenfalls bei jeder Anwendung mit grafischer Oberfläche an. Gleiches gilt für Laufzeitdaten zum Textlayout und dem Undo-Stack. Die Daten liegen dann auch irgendwo im RAM, wenn man es selbst implementiert.

 

[Manegarm]

Langweilig.

Kennt ihr terry a davis? Der hat ein eigenes Betriebssystem zu Hause entwickelt. Der hat sich während der Arbeit für Youtube gefilmt.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[input_iterator]

Diese Laufzeitendaten fallen dann aber auch bei Anwendungen an...

Ja klar, die grundlegenden Laufzeitstrukturen eines GUI Programm existieren immer, egal ob man ein Rich Edit Control nutzt oder ein eigenes Text Widget implementiert. Darum ging es aber eben nicht. Der Unterschied liegt doch darin, wo diese Strukturen entstehen und wie viel davon das jeweilige Control selbst erzeugt. Ein selbst implementiertes Text Witget erzeugt nur die Laufzeitdaten, die man selbst vorgesehen hat. 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. Dass jede GUI App ein Fenster Subsystem und eine Message Loop hat, ist ja trivial.

Ergänzung (Gestern um 18:40)

@ KitKat::new()

Ich habe die zusätzlichen Laufzeitstrukturen gemeint, die ein Rich Edit automatisch initialisiert, also die üblichen Glyph Runs, Format Caches, Rendering Targets und Font Fallback Tabellen, die bei einem selbst implementierten Widget nur entstehen, wenn man sie bewusst baut. Dass die Minimal App im Reppo ohne Crinkler bei 1,7 MB RAM liegt, bestätigt in meinen Augen genau das. Der große Foot print kommt nicht vom Assembler Wrapper, sondern vom restlichen Editor Kontext, der im eigentlichen Projekt darüber liegt.

 

[yahlov]

Windows 11 Bloom Gradient Dark Green und Purple sehen ja mal richtig hübsch aus

 

[Tornhoof]

Heh solche minimalen editor apps programmieren, war früher die Standardeinführung eines jeden MFC und/oder Visual C++ Buch in den 90ern. Die Assembler Varianten mit MASM waren dann eigentlich nur noch die 2. Stufe, jeder der sich an die Demo/Cracking/Warez Scene der 90er erinnert kann davon ein Lied singen.

 

[Mimir]

Fairerweise muss man sagen, dass Notepad in Windows 11 nach dem Start nur ca 35 MB RAM belegt, laut taskmanger, während der Editor im Artikel 4,6 MB belegt und sehr viel weniger Funktionen bietet.

Ich hätte mit schlimmerem gerechnet.

 

[KitKat::new()]

Dass die Minimal App im Reppo ohne Crinkler bei 1,7 MB RAM liegt, bestätigt in meinen Augen genau das. Der große Foot print kommt nicht vom Assembler Wrapper, sondern vom restlichen Editor Kontext, der im eigentlichen Projekt darüber liegt.

Crinkler ist ein (komprimierender) Linker... durch Crinkler kommt kein Editor Kontext dazu.

 

[Piktogramm]

Zweitens stelle ich mir die Frage, warum Windows überhaupt so viele Bibliotheken und Frameworks besitzt. 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

Deine Idee wäre ein sinnloses Betriebssystem. Betriebssysteme bieten Bibliotheken und Frameworks um die Hardware zu abstrahieren und dafür APIs anzubieten. Es wäre total sinnig, wenn die Anwendungsprogrammier·innen jedwede Sonderlocke von Hardware und jede immer wiederkehrende Funktionalität selber implementieren müssten.

Das bei Windows etwas das Gesamtkonzept fehlt und mehrere Altlasten mitgeschleppt werden, während man sich bei den neuen Dingern anscheinend nicht entscheiden mag, was die Goldlösung sein soll.. Das ist halt echt ungünstig.