Het zit in iedere applicatie hardcoded omdat 'we' als developer bang zijn dat we over een of andere obscure bug trippen als we die niet gebruiken. Verder is dit ook wat aan gebruikers getoond wordt wanneer ze de applicatie gebruiken. Als developer ervoor kiezen om expres gebruikers verwarren slaat nergens op. OS eerst; dan applicaties.
Dat zal dan nooit veranderen. Windows zal altijd beide moeten ondersteunen en als ontwikkelaars bang zijn voor dingen die al decennia gedocumenteerd zijn, gaan ze de komende decennia ook niet van gedrag veranderen.
Historisch gezien onjuist; UTF-8 werd ontworpen door Ken Thompson en Rob Pike in 1992. Windows NT, dat de basis vormt voor moderne Windows-versies, werd in 1993 uitgebracht en gebruikte inderdaad UCS-2 (later UTF-16). De keuze voor UCS-2/UTF-16 was niet omdat UTF-8 niet bestond, maar vanwege andere overwegingen, zoals efficiëntie voor bepaalde talen en compatibiliteit met bestaande systemen.
Goed punt; UTF-8 bestond wel, maar het Unicode-consortium raadde iedereen aan om UTF-16 te gebruiken, en is later van positie veranderd. Effectief hetzelfde, maar je hebt historisch gezien wel gelijk.
Verder; is de functie om UTF-8 aan te kunnen zetten praktisch waardeloos. Ik als developer heb daar niets aan want ik kan ervan uit gaan dat geen van de gebruikers waar ik mijn software uit rol deze functie aan heeft staan. Daarnaast gaan de meeste developers geen tijd krijgen om dit te testen/fixen van hun management zolang dit niet standaard aangezet wordt in Windows.
Dat klinkt wederom als een reden dat Microsoft er niets aan kan doen. Bestaande programma's moeten blijven werken, en developers zijn anders weer bang voor bugs in veranderd gedrag, zoals je zelf eerder beschreef.
Je kunt gewoon ActiveCodePage op UTF-8 zetten in je applicatiemanifest en UTF-8 gebruiken als je UTF-8 wilt.
[quote]
Voordat ik door ga met reageren even een ander punt. Ik wens dat Microsoft dit soort fundamentele problemen op lost. Maar het gaat niet gebeuren; precies voor de reden die je aangeeft. Er draaien een hele hoop oude applicaties die al lang niet meer geüpdatet worden bij bedrijven en overheden. Deze stoppen met werken als deze wijziging gedaan wordt en daar is Microsoft doodsbang voor.
Ik zou willen dat ze die angst los zouden laten want het zou twee positieve gevolgen hebben:
- Er kunnen fundamentele verbeteringen gedaan worden aan Windows die anders onmogelijk zijn.
- Het maakt third-party software beter: Het dwingt third party software om hun software tegen het licht te houden en deze te verbeteren. En het dwingt het bedrijfsleven en overheidsinstanties om oude software te vervangen die niet langer actief onderhouden wordt./quote]
Microsoft heeft dat geprobeerd met Windows 10S, een versie van Windows die alleen applicaties uit de Microsoft Store draaide, die destijds alleen uit UWP-applicaties die de nieuwe API volgden. Iedereen was boos, Microsoft heeft het project weggegooid. Als je denkt dat developers nu boos zijn op Windows, moet je developers eens zien als ze API's veranderen.
Ooit was er een tijd waar we ervan uitgingen dat serieuze softwarebedrijven bij release hun nieuwe UI in één keer goed uitrollen.
Ik kan me die tijd niet herinneren, eigenlijk. Pas met Android en iOS heb ik dit soort totale UI-overhauls voor het eerst gezien.
'Vroeger was het nog erger' is niet een sterk excuus. Mijn Linux bakken updaten al vijftien jaar in een fractie van de tijd die het Windows (en Mac OS) kost. Dus dit moet te doen zijn. Verder ben ik blij voor je dat jij die half uur wachttijden niet meer mee maakt. Ik heb een paar weken geleden het helaas wel mee gemaakt. Dat is waarom anekdotes er niet toe doen.
Ik kan niks tegen je anecdote inbrengen natuurlijk, maar ik geloof ook niet dat een Linux-update op zo'n systeem zoveel sneller zou zijn dat je niet alsnog een half uur zit te wachten. Tenzij het traag is omdat Windows een revert moet doen van een mislukte update, dan start je Linux-systeem niet meer op.
Er is vast genoeg winst te behalen, maar het is niet alsof Microsoft hier niks aan doet.
Maar ook hiervoor geldt wat ik eerder al schreef; geen developer gaat tijd/geld krijgen om deze problemen op te lossen zolang Microsoft de schijfletter functionaliteit blijft ondersteunen.
In de praktijk hoef je er niet zo heel veel voor te doen (de disk enumeration API geeft je al de nodige strings) dus ik denk dat het grotendeels gewoon per ongeluk goed gaat

Dat developers het geld niet krijgen om hun applicaties tegen alle edge cases te testen kan ik beamen, maar daar kan Microsoft ook niks aan doen.
Bedankt voor de uitleg, maar ik wist dit allemaal al. Erop vertrouwen dat developers zich aan normen houden gaat in de praktijk helaas vaak niet gebeuren wanneer er geen consequenties zijn voor developers die zich onbewust of bewust applicaties maken die zich misdragen. Er moet en vorm van controle/repercussie zijn denk ik. UWP is inderdaad een goede stap daarnaartoe. Helaas hebben ze bij veel beleidsregels afgezwakt. Verder doet Microsoft net als Apple niet voldoende aan controles in de store en kun je daar genoeg applicaties vinden die regels overtreden.
Aan de ene kant ben ik het met je eens dat het fijn zou zijn als die onzin niet meer voor zou komen ("ik zet mijn programma wel in appdata, dan kunnen gebruikers zonder adminrechten updaten" is een stomme hack). Aan de andere kant ligt de schuld toch echt bij de ontwikkelaars, vind ik. Als je software koopt van beunhazen, moet je de beunhazen aankijken op hun slechte software. Als ze niet eens hun applicatiedata kunnen opslaan zonder willekeurige paden aan te maken, betwijfel ik me dat ze zich aan andere standaarden houden.
Grappig dat je dit schrijft. Want In tegenstelling to Windows wordt er bij MacOS frequent backwards compatibility stuk gemaakt. En wat je ook ziet bij MacOS is dat hierdoor schiftingen plaatsvinden. Applicaties waarbij de developers zijn afgehaakt of traag zijn worden 'gestraft' door gebruikers die naar andere applicaties gaan wanneer hun huidige applicatie niet meer werkt. Mijn ervaring is dat dit een van de redenen is waardoor de overgebleven applicaties zo'n hoog niveau hebben.
Misschien, maar ik zie ook veel mensen online die nog op jarenoude macOS-versies zitten omdat hun favoriete tekstbewerker ineens niet meer werkt als ze updaten.
Ik denk dat de kwaliteit van die applicaties een stuk hoger is om een andere reden: mensen betalen er geld voor. Ik heb zelden Windows-gebruikers geld zien betalen voor tooling (games en misschien Office wel), maar op macOS lijkt iedereen een lijstje te hebben van must-have tools die je voor een paar euro moet kopen (en opnieuw mag kopen bij de volgende macOS-update). Ook daar is shareware, maar macOS-gebruikers lijken gewoon een grotere portemonnee te hebben.
Ik hoor weinig mensen die Windows nou heel fijn vinden. De meeste mensen kunnen ook met ChromeOS en macOS overweg, al dan niet na het installeren van wat tooltjes. De backwards compatibility is een van de grote selling points die geld in het laatje brengt bij Microsoft.
Dat wil niet zeggen dat ze soms compitabiliteit breken, overigens. De oude print spooler was zo kapot dat ze op een gegeven moment een update hebben uitgebracht die gewoon oude printers kapot maakte en allerlei adminpermissies vereiste. Sysadmins over de hele wereld waren woedend, maar Microsoft kon de beveiligingsproblemen niet tijdig op een andere manier oplossen.
Ze hebben met Windows 11 ook besloten een hele hoop oude hardware niet meer te ondersteunen. Geen checken of je SSE4 hebt, geen versioned API voor de TPM, geen DDR3 meer. Daar waar ze kunnen, knippen ze oude troep af. Ook op gebied van het drivermodel hebben ze de laatste jaren behoorlijk huisgehouden, iets dat je minder hard merkt doordat oude hardware sowieso niet zou moeten werken op Windows 11.
Het grootste probleem op Windows blijft de applicatieontwikkelaars die de regels niet volgen. Ik moet eerlijk zeggen op al mijn persoonlijke apparaten eigenlijk alleen Linux te draaien, maar daar heb ik allemaal soortgelijke problemen. Dingen die niet werken op Wayland, programma's die beter denken te weten waar ze hun applicatiegegevens moeten laten, updates die óf traag zijn óf bij problemen een onbootbaar systeem achterlaten, enzovoorts. UTF-8 support bestaat bij toeval; applicaties nemen aan dat je ASCII invult en meestal komt dat goed uit bij de renderlibrary (tot je zoekt op é als U+0065 + U+0301 maar U+00E9 in je bestand hebt staan).
Voor ieder probleem dat Windows heeft, heeft de concurrentie andere problemen. ChromeOS is altijd up to date, maar heeft ook geen API. macOS draait op een minimale subset van hardware, kan geen grafische kaarten aan, en is onbruikbaar voor het aansturen van apparaten die langer dan vijf jaar in het veld staan omdat de software ineens niet meer werkt. Linux is onmogeijk te beheren binnen een organisatie en heeft nog minder compatible software voor eindgebruikers dan macOS. En gebruikers van ieder platform hebben ook een waslijst van dingen die hadden moeten worden opgelost elke keer als er een UI-wijziging plaatsvindt

.