home  bbs  files  messages ]

      ZZDE4410             de.rec.fahrrad             5072 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  Msg # 4860 of 5072 on ZZDE4410, Saturday 8-15-25, 1:56  
  From: WOLFGANG STROBL  
  To: ALL  
  Subj: Re: OT: Softwareentwicklung damals und h  
 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) 

[ list messages | list forums | previous | next | reply ]

search for:

328,091 visits
(c) 1994,  bbs@darkrealms.ca