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

[fbg]

Quatsch.

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 ☝️

"Quatsch".
Deine Verwechslung von MacOS mit GUI framework läßt mich vermuten, daß der Kommentar nicht aus Entwicklersicht stammt.
Ohne enormen Zusatzaufwand warten rein Winforms oder WPF-basierte Windows Anwendungen mit dem Look des vergangenen Jahrtausends auf.
Daß die notfalls noch unter Windows 95 laufen war nicht Thema.
Und beim Verweis auf die 90er, der nicht gar keine aber sehr wenig Substanz hat, schau doch mal auf Laufwerk A: oder C: nach.

 

[Piktogramm]

Sehe ich angesichts der 8,4 MiB von Np++ jetzt nicht so.

[...] WinUI 3 erstellt werden sollen, was das ganze unsäglich aufbläht. Entwickle ich das gleiche Tool mit Windows Forms, wirds zehnmal kleiner.[...]
Mich hat dieses unnötige Aufblähen irgendwann so abgenervt, dass ich auf Linux gewechselt bin.

Also viele grafische Texteditoren unter Linux fressen RAM aber auch zum Frühstück und sind mit allen Plugins um ein Bruchteil der Funktionalität von N++ zu erreichen auf dem Festspeicher auch fetter.

Winget funktioniert dahingehend sehr gut.

Deine Forderungen/Beispiele sind beeindruckend inkonsequent.
WinGet installiert überwiegend ja auch nur Installer, bei denen die Anwendungen den Großteil ihrer Abhänigkeiten selber mitbringen. Was ein haufen Bloat bedingt, weil gängige Frameworks so mehrfach installiert werden, entsprechend Festspeicher brauchen und zur Laufzeit jeweils nur im Kontext der Anwendung laufen anstatt einmalig für alle Anwendungen zur Verfügung stehen.

Eben. Nur das allernötigste ist dabei.

Das stimmt halt nicht. Es ist eine sinnvolle, wenn auch minimierte Vorauswahl dabei. Das aller nötigste könnte noch viel "Ballast" bzw. Funktionalität abwerfen, wäre aber wirklich nicht schön in der Benutzung. Eine Distribution für Desktops würde diesen Minimalismus nie Verfolgen, weil es schlicht zu unprakisch ist.

genau, desegen gibts unter Linux sowas wie die Snap installation weil die Dependencies so super funktionieren :-D

Abhänigkeitshölle vs. Bibliotheksfäule..
Zudem Snap, Flatpack durchaus Abhänigkeiten zwischen Containern haben können. Der Vorteil ist hauptsächlich, dass diese Abhänigkeiten nur für Snap bzw. Flatpack zu verwalten sind und Nicht für die 10^666 Distributionen.

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.

Du beschreibst dynamisches Linking bzw. die Verwendung von bereits vorhandenen APIs..

Es ist ein Unding geworden, dass Anwendungen unter Windows auf so einen Schrott wie Qtk, Chrome oder Java zurückgreifen und jeweils alle Bibliotheken mitschleppen, statt einfach auf das Windows Framework zurückzugreifen.

Also Qtk, Electron, Java als Schrott zu bezeichnen ist ein starkes Stück. Das alternative Frameworks aufkamen hat ja vor allem damit zu tun, dass Microsoft die eigenen Frameworks immer als "walled garden" gestaltet. Plattformunabhänigkeit ist ein Unding, eine rote Linie ließen die Frameworks oftmals auch vermissen, Stand der Technik ist auch immer wieder mal hinten dran bis es eine Hauruckaktion gibt um dann wieder einzuschlafen.
Gleichzeitig fehlt ein gescheites Abhänigkeitenmanagement, sodass jede Anwendung ihr Java, Electron und Qt erstmal selber mitbringt und im eigenem Kontext laufen lässt.

Nicht einmal Microsoft hält sich an die eigenen Richtlinien. Man braucht sich nur Teams anzuschauen, was in der Anfängen auf einem Google Framework basierte und sich bis heute im Profilordner einnistet, statt regulär als Anwendung unter Windows installiert zu werden.

Konsequenz bei Microsoftprodukten

Oft hat es schon gute Gründe warum etwas größer ist, auch Games. Dass immer gesagt wird es ist 50-90% größer als es müsste weil sie heute alle zu faul sind zum Optimieren und alles aufgebläht wäre.. [...]

Lustigerweise ist eine Form der Optimierung, dass man Assets mehrfach vorhält, in der Hoffnung, dass man Lokalität beim Festspeicher hinbekommt um so Ladezeiten zu minimieren. Zumindest ist das eine Möglichkeit auf HDDs zu optimieren.

Das ist kein Einstiegssegment, das ist einfach nur billig, wo irgendwelche alte Hardware verramscht wird.

Diese Einstellung kann man nur haben, wenn man mindestens Medianeinkommen, aber keine all zu großen Ausgaben hat.

Und Microsoft täte gut daran, endlich mal alte Zöpfe abzuschneiden.

Welche Zöpfe sollen denn weg?

 

[MaverickM]

Welche Zöpfe sollen denn weg?

Die alten...

Altlasten wie die System Steuerung, veraltete Frameworks etc. Wurde alles schon genannt.

 

[Piktogramm]

Altlasten wie die System Steuerung, veraltete Frameworks etc. Wurde alles schon genannt.

Du meinst die Systemsteuerung, die wenigstens die Steuerung vom System zulässt?
Welche veralteten Frameworks denn und wie, auf was sollen dann Anwendungen bzw. Anwender migrieren?
Ohne konkret zu werden, ist es halt sinnloses Geblubber.

Bei Win32 Win64 wurde über die Zeit schon aussortiert, aber generell wäre Windows ohne WinAPI kein Windows.

 

[MaverickM]

Ohne konkret zu werden, ist es halt sinnloses Geblubber.

Vielleicht solltest Du das nachlesen, was schon diskutiert wurde... Es bringt nichts, dass alle paar Seiten erneut durchzukauen.

 

[Piktogramm]

@MaverickM
Ja Seiten mit viel Noise, wenig Signal, ohne konkrete, belastbare Aussagen. Ebensowas wie dein "Systemsteuerung, veraltete Frameworks".

 

[mibbio]

Du beschreibst dynamisches Linking bzw. die Verwendung von bereits vorhandenen APIs..

Nein, dynamischen Linken heißt erstmal nur, dass die DLL bzw. dessen API nicht fest ins Binary integriert wird, sondern separat als DLL vorliegt und lediglich referenziert wird. Statisches Linken baut die DLL dagegen fest ins Binary des Programms ein.

Prominentens Beispiel wären da FSR, DLSS oder XeSS in Spielen. Die Spiele verwenden die APIs davon und die zugehörigen DLLs, bspw. "amd_fidelityfx_dx12.dll", liefert das Spiel mit aus aus, als Teil der Spieldateien.

Dagegen verwendet 007 First Light statisches Linken (zumindest bei FSR), wodurch man die FSR-Version auch nicht treiberseitig überschreiben kann oder dem Spiel durch Austasch der DDL (gibt ja keine separate) eine neuere Version unterschieben kann.

 

[polyphase]

Das ist ein Programmierer der noch richtig programmieren kann 👍

Nicht so wie die Nieten von heute, die erstmal drölf Frameworks einbinden und dann so ne einfach App den halben Arbeitsspeicher belegt!

Ergänzung (Sonntag um 16:23)

Super spannend auch das Interview mit Windows NT-Vater Dave Cutler. :-)

Interessant fande ich das Konzept von Dave Cuttler "Eat your own dogfood" das sollte man bei heutigen Projekten zur Pflicht machen.

Dann merken die Entwickler direkt selbst, was für einen Mist sie verzapfen.

 

[aufkrawall]

Die alten...

Altlasten wie die System Steuerung, veraltete Frameworks etc. Wurde alles schon genannt.

Dadurch wird der neue Code auch nicht besser/schneller.

Das ist ein Programmierer der noch richtig programmieren kann 👍

Das beurteilst du anhand eines minimalistischen Texteditors mit seltsamem Hack-Packer? Urks.

 

[MaverickM]

@Piktogramm
Wenn Du nicht gewillt bist, das bisher diskutierte nachzulesen, kann ich dir auch nicht helfen. Dann war dein Argument auch scheinbar nicht wichtig genug.

 

[Piktogramm]

Das ist ein Programmierer der noch richtig programmieren kann 👍

Nicht so wie die Nieten von heute, die erstmal drölf Frameworks einbinden und dann so ne einfach App den halben Arbeitsspeicher belegt!

Aber Dave hat externe Bibliotheken/Frameworks eingebunden und realisiert damit essentiell die Funktionalität des Programms.

Wenn Du nicht gewillt bist, das bisher diskutierte nachzulesen, kann ich dir auch nicht helfen. Dann war dein Argument auch scheinbar nicht wichtig genug.

In dem ganzen Thread wird es halt nicht konkret. Ich kann beim besten Willen nicht finden, dass irgendwer irgendwo was schreibt zu: Diese (alte) API, dieses (alte) Framework work muss weg und dann irgendwie begründen kann, dass das Windows besser machen würde. Eher noch finden sich Aussagen, dass WinUI ein dickes Ding und nicht sonderlich schnell ist. WinUI gehört aber eben nicht zu den alten Zöpfen sondern ist vergleichsweise neu..

 

[mifritscher]

Das Richedit Steuerelement dürfte, wenn das MS nicht ebenfalls so richtig versaubeutelt hat, vernachlässigbar viel Speicher benötigen. Das Ding ist seit Windows 95 dabei und wurde von dessen Wordpad verwendet. Für einen Texteditor sollte aber auch das edit Steuerelement reichen, da muss man halt paar KB mehr schreiben (v.a. Rückgängig/Wiederherstellen). Und das ist einer der klassischsten Steuerelemente, die es gibt

Wobei, viel kaputtmachen kann da MS eigentlich auch nicht - das wird von sehr vielen Anwendungen verwendet, die dann alle brechen würden.

Übrigens: das "neue klassische" Wordpad benötigt nach dem Start 71 MB - und ist quasi instantan da. notepad benötigt 149 MB und 2-3 Sekunden. Und das obwohl dieses Wordpad deutlich mehr kann als das "klassische" Wordpad. Das zeigt schon überdeutlich, wie sehr falsch man da abgebogen ist.

 

[KitKat::new()]

Statisches Linken baut die DLL dagegen fest ins Binary des Programms ein.

es baut eher die Abhängigkeit fest in die Binärdatei ein, eine dll (ausgeschrieben dynamic link library) kann nicht statisch gelinkt werden

 

[Tinpoint]

@mischaef,
man darf da auch gerne auf den Youtube Kanal von Dave verlinken. Super interessante Videos rund um Windows und weiteren Retro Equipment. Super spannend auch das Interview mit Windows NT-Vater Dave Cutler. :-)
https://www.youtube.com/@DavesGarage

Ja der Kanal ist empfehlenswert, war er nicht für die Entwicklung des Task Managers bei win9x zusätndig

 

[mibbio]

Ja, war etwas falsch ausgedrückt, da das Linken ja mit den .o bzw. .obj Dateien als Zwischenstufe gemacht ist. Beim dynamischen Linken gibt's halt eine .dll (unter Linux eine .so) erstellt und das Programm referenziert diese, beim statischen Linken dagegen nicht, weil fest ins Programmbinary integriert.

Ändert aber letzlich nichts an der Grundaussage, dass dynamisches Linken halt nicht gleichbedeutend mit der Verwendung von Systembibliotheken ist. Denn es kann ja auch eine lokale, also im Programmordner liegende, Bibliothek referenziert werden.

 

[ICHBINDA]

Ist fraglich ob überhaupt noch ein aktueller Microsoft Dev in C oder C++ programmieren kann.

Ja können Sie.

Ergänzung (Sonntag um 18:25)

Ja der Kanal ist empfehlenswert, war er nicht für die Entwicklung des Task Managers bei win9x zusätndig

Dave Plummers Werk bei Microsoft​

Dave Plummer arbeitete von 1993 bis 2003 bei Microsoft und war dort an praktisch jedem großen Windows-Betriebssystem beteiligt – von MS-DOS 6.2 bis Windows XP und Server 2003.

Frühe Jahre unter MS-DOS​

Als Praktikant in der MS-DOS-Abteilung von Ben Slivka schrieb Plummer wichtige Features wie den SmartDrive-Cache für CD-ROMs sowie das DISKCOPY-Programm. In seiner MS-DOS-Zeit arbeitete er außerdem an Smartdrv, DoubleSpace und dem Setup-Programm.

Der Windows-Taskmanager​

Der Task-Manager ist wohl sein bekanntestes Werk: Plummer entwickelte ihn ursprünglich in seiner Freizeit zu Hause, zeigte das Projekt später Dave Cutler und durfte es dann offiziell fertigstellen – ausgeliefert wurde er mit den Microsoft-Computern von 1996. Bis heute ist er als "der Microsoft-Ingenieur, der den Task-Manager programmierte" bekannt.

Zip-Ordner und Windows-Shell​

Plummer entwickelte VisualZIP, ein visuelles Zip-Programm für den Windows-Explorer unter Windows 95, das er zunächst selbst verkaufte und später an Microsoft weiterveräußerte. Die Software wurde ab Microsoft Plus! 95 fest in den Explorer integriert und ist als "ZIP-Ordner" (ZIPFolders) bekannt. Im Zuge dessen wechselte er zu Windows NT, wo er zunächst an RPC/OLE arbeitete und dann die Portierung der Windows-95-Benutzeroberfläche auf Windows NT übernahm.

Space Cadet Pinball​

Plummer portierte das beliebte Spiel Space Cadet Pinball von Windows 95 auf Windows NT, konvertierte dabei den x86-Assembler-Code in C und passte ihn für RISC-Architekturen an. Diese Portierung wurde später mit vielen Windows-NT- und XP-Versionen mitgeliefert.

Weitere Beiträge​

Zu seinen weiteren Arbeiten zählen die Formatierungs-Dialogbox von Windows, der Windows-Rechner (Calc), eine frühe Version des Windows Media Center sowie die Windows-Produktaktivierung (Windows Product Activation, WPA) inklusive Anti-Piraterie-Mechanismen. Bei der Produktaktivierung nutzte er nach eigenen Angaben Bilddaten von "Microsoft Bob" als Startwert für den Zufallszahlengenerator, der die Ballastdaten erzeugte – so steckt der "digitale Geist von Bob" in rund 500 Millionen Windows-XP-Installationen.

Nach seinem Ausstieg bei Microsoft 2003 konzentrierte sich Plummer auf sein eigenes Unternehmen SoftwareOnline LLC und ist heute vor allem durch seinen YouTube-Kanal "Dave's Garage" bekannt, wo er Softwareentwicklung und Retro-Technik erklärt.

 

[Peter 23]

Sehr gut das er MS verlassen hat, dort würde seine Kreativität nur beschnitten werden.

Tolle Arbeit, Respekt 👍🏻

 

[xexex]

Also Qtk, Electron, Java als Schrott zu bezeichnen ist ein starkes Stück.

Unter Windows ist es Müll, zumindest wenn man reine Windows Software entwickelt. Bei Multiplattformlösungen geschenkt, da mag es bequemer sein, aber nicht bei reiner Windows Software wie dem EGS was einen ganzen Chrome Unterbau mitschleppt.

Leider sieht man es heutzutage viel zu oft und jede Applikation schleppt Bibliotheken mit eigenen Versionen und Sicherheitslücken mit, selbst für solche simplen Sachen wie einen Dateidialog.

Natürlich unterstützt dieser dann auch keine Erweiterungen, also sind Speicherorte wie SharePoint, Onedrive oder Dropbox damit unererreichbar und oft genug kommt solcher Müll nicht mal mit High-DPI Monitoren zurecht.

Ergänzung (Sonntag um 20:41)

Gleichzeitig fehlt ein gescheites Abhänigkeitenmanagement, sodass jede Anwendung ihr Java, Electron und Qt erstmal selber mitbringt und im eigenem Kontext laufen lässt.

Windows besitzt seit Windows Vista ein "Abhängigkeitsmanagement" in Form von WinSxS. Jeder Applikation steht es frei eine bestimmte Bibliothekversion anzufordern und/oder mitzuliefern oder schlichtweg eine beliebige zu nehmen.

Es sind die Entwickler die oft zu faul sind oder keinen Support leisten wollen und mit ihrer Minianwendung ein ganzes Framework in den Applikationsordner hinrotzen.

 

[DarkSoul]

Daran ist überhaupt nichts genial, er nutzt Windows-Funktionalitäten, die Windows ja bereitstellen muss, damit man überhaupt dafür Programme schreiben kann. Dazu zählen natürlich Fenster-Mangement genauso wie Datei- und Druckermanagement. So was nutzte man schon zu reinen Assembler-Programmierzeiten, es wäre schlimm, wenn es nicht sowäre und jedes Programm so was selbst mitbringen müsste.

 

[mibbio]

Bei Multiplattformlösungen mag es geschenkt sein, da mag es bequemer sein

Selbst dann kommt man noch ohne das fette Electron durchaus recht weit und auch bequem. Mit .NET MAUI bietet Microsoft selbst ein UI-Framework, welches Windows, MacOS (inkl. iOS) und Tizen unterstützt. Wenn man noch Linux mit abdecken möchte und im C#/.NET Ökosystem bleiben will, gäbe es bspw. AvaloniaUI (orientiert sich konzeptionell an WPF).

Die .NET Softwareplattform an sich ist ja bereits plattformunabhängig und sogar Open Source.