From: news5@mystrobl.de
Am Fri, 4 Oct 2024 15:25:47 +0200 schrieb Arno Welzel
:
>Wolfgang Strobl, 2024-09-23 17:35:
>
>> Am Mon, 23 Sep 2024 15:36:32 +0200 schrieb Arno Welzel
>> :
>>
>>> Wolfgang Strobl, 2024-09-14 21:39:
>
>[...]
>
>>>>> Vor ein paar Jahren war eine komplette Windows-Installation von Windows
>>>>> 7 oder Windows 10 etwa 20-30 GB gro€€ und das ISO-Image rund 4 GB.
>>>>
>>>> Windows gibt es seit 47 Jahren, wenn wir nur die Versionen z€€hlen, die
>>>
>>> Lenke nicht ab!
>>
>> Ok, ok, Ulli H. hat mich schon auf den Irrtum hingewiesen. Es sind jetzt
>> 37 Jahre, seit Windows 2 herauskam - die erste Windows-Version, gegen
>> deren API ("WIN16") ich programmiert habe. Solche Programme konnte man
>> bis zu einem viel weniger zur€€ckliegenden Zeitpunkt immer noch unter der
>> jeweils aktuellen Windows-Version laufen lassen und kann das mit eher
>> schlichten Anpassungen auch heute noch. Warum erw€€hne ich das? Weil
>[...]
>
>16-Bit-Anwendungen laufen auf einem aktuellen Windows mit 64 Bit nicht
>mehr. Auch nicht mit "schlichten Anpassungen". Und das galt auch schon
>f€€r viel €€ltere Windows-Versionen, wenn man 64 Bit einsetzt - konkret
>seit Windows XP, da WoW64 schlicht komplett inkompatibel zu Win16 ist.
Danke. Ich habe meine ersten Gehversuche auf einer IBM7090 und mit
Fortran IV gemacht. Die umf€€nglichen M€€glichkeiten eines GUI praktisch
zu erkunden, welche das WIN16-API unter Windows 2 bot, war f€€r mich
schon der f€€nfte oder sechste Wechsel auf eine wieder andere Plattform
(rgenwann habe ich aufgeh€€rt zu z€€hlen) und insofern kein wirklich neues
Erlebnis.
Mit einer Einschr€€nkung: dieses Windows-API lie€€ damals schon weitgehend
hardwareunabh€€ngige, vergleichsweise komplexe grafische Anwendungen zu,
welche noch sehr lange als Bin€€rprogramme weiter unterst€€tzt wurden, und
dar€€berhinaus weitgehend schematisch z.B. von WIN16 auf WIN32 portiert
werden konnten. Eine solche Kontinuit€€t, ein 1989 geschriebenes
Programm mit mehreren adjustierbaren, sich an die verf€€gbare Hardware
(Schirmgr€€€€e, Farbe/Monochrom) anpassenden Fenstern, variablen
Hintergrundtexturen, Sound usw. ohne viel Aufwand bis zu Windows 10
hin€€berretten zu k€€nnen, die gab es nirgendwo sonst. Das _war_ ein neues
Erlebnis.
Die heutige Situation, auf einer Plattform wie z.B. Linux gleich ein
halbes Dutzend konkurrierende GUIs zu haben, von denen man nicht wei€€,
welche der konkurrierenden Distributionen welches davon in den n€€chsten
Jahren pr€€feriert oder aufgibt, dazu zwei bis drei konkurrierende
Browser, f€€r die es dann gleich ein Dutzend mal mehr, mal weniger
veraltete JavaScript-Frameworks gibt, das ist gewiss kein Fortschritt
und einer der Gr€€nde daf€€r, dass sich Linux auf dem Desktop trotz aller
Vorz€€ge nicht durchsetzen konnte. Es ist nicht nur ein Insider-Joke,
dass WIN32 eigentlich das einzige stabile Bin€€rinterface von Linux ist.
:-)
>Ebenso laufen auch keine Anwendungen, die auf MS-DOS-Calls oder direkte
>Hardware-Zugriffe angewiesen sind und bis Windows 98 oder Me noch
>problemlos nutzbar waren. Seit Windows NT gibt es das alles nicht mehr,
>sondern nur eine Emulation mit NTVDM, wo aber l€€ngst nicht alles an
>Uralt-Software l€€uft. Und NTVDM gibt es nur mit 32 Bit-Unterbau. Sobald
[Hier fehlt der Rest des Satzes, ich nehme das zum Anlass, zu k€€rzen]
Die Kompromisse, die das erforderte, die Motive, die dahinterstehen,
sind mir wohlbekannt, ich habe das alles wie gesagt, von Anfang an aus
erster Hand mitgemacht, insofern grunds€€tzlich keine Einw€€nde. Wo ich
nicht mitgehe, das ist die Einsch€€tzung, dass das alles nur f€€r tr€€ge
Firmenkunden gemacht wurde, die den Schweinsgalopp von agilen
Entwicklern mit ihrer t€€glichen SCRUM-Standup-Comedy nicht mitmachen
wollen.
Eine Stabilit€€t, die vom UI €€ber das API bis zur Bin€€rebenen nach
M€€glichkeit durchgehalten wird (und die auch Microsoft inzwischen leider
aufgegeben hat, vielleicht um die Leute in die eigene Cloud zu treiben),
ist durchaus auch im Sinne von privaten Anwendern und kleinen Firmen,
die ihre Hard- und Software samt der zugeh€€rigen Erfahrung nicht
sp€€testens alle drei Jahre komplett in die Tonne klopfen wollen.
...
>> vieles von dem, was Apps wie die meiner Krankenkasse leisten, schon mit
>> den damaligen extrem begrenzten Mitteln from Prinzip her umsetzbar war,
>> wenn es um die Funktion und Darstellung und nicht um die Sch€€rkel geht.
>
>Vom Prinzip her brauchen wir GAR KEINEN COMPUTER f€€r GAR NICHTS! Du
>kannst auch Formulare per Post schicken.
>
>Und wenn es nur um die Eingabe Daten geht, gen€€gt ein serielles
>Terminal, was am RZ der Krankenkasse h€€ngt.
Ich denke, damit k€€nnen wir die Diskussion abschlie€€en. Auf dieses
Niveau m€€chte ich mich nicht weiter einlassen.
Aber ich gehe trotzdem noch kurz auf den erneuten Themenwechsel ein.
Meine durchaus differenzierte Kritik richtete sich gegen einige
inhaltliche Schw€€chen, also z.B. mangelnde oder unklare Funktionalit€€t.
Es ist albern, den einen Seitenhieb "In 99 MByte Code sollte so etwas
gewiss irgendwo unterzubringen sein" so aus dem Zusammenhang zu rei€€en
und sich dann derart daran abzuarbeiten.
Was neue, moderne App vs. "... gen€€gt ein serielles Terminal, was am RZ
der Krankenkasse h€€ngt." angeht:
Es geht nicht darum, dass man f€€r benutzerseitige neue
Hardwareinterfaces (etwa Touchscreens) neue Abstraktionen braucht. Das
ist keine neue Erkenntnis und war hier gar nicht angesprochen oder
Thema. Auch hat die konkrete App €€berhaupt keine Funktionen, f€€r die
Touchscreen oder das klassische Desktop/Laptop-Inteface einen
Unterschied macht.
Wenn wir aber die Entwicklung von Benutzerschnittstellen generell zum
Thema machen wollten (wof€€r de.rec.fahrrad wohl der so ziemlich
abwegigste Ort ist), dann sollte es IMO darum gehen, ob man die
Softwareentwicklung f€€r eine Hardware, die mit Maus, Tastatur und
Bildschirm seit gut vierzig Jahren weitgehend unver€€ndert in Gebrauch
ist, so betreiben sollte, als ginge es darum, eine Modezeitschrift im
Jahresrhythmus mit immer wieder neu und anders wirkenden "frischen
Inhalten" zu f€€llen.
Und das l€€€€t sich mit einigen Erg€€nzungen durchaus auch auf
Mobiltelefone €€bertragen. Wenn es offenbar f€€r einige Entwickler schon
zu viel Aufwand ist, f€€r eine letztlich webbasierte Anwendung lediglich
zwei verschiedene Userinterfaces (eines f€€r Desktop, eines f€€r Telefone)
zu pflegen - weswegen dann manche Anwendungen entlang von "Mobile First"
i.W. aus viel white space, gro€€er Schrift und vielen Seiten gl€€nzen, wo
fr€€her eine kompakte Seite reichte -, dann sollte man mit der
Produktion von zu viel Fashion, Trends & Styling dann doch etwas
vorsichtig sein.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|