Windows 11 laat gebruikers toegang tot camera en microfoon per app instellen

Win32 is de naam van de api die geintroduceerd is met de komst van NT en later ook in Windows 95 en als expliciet doel te dienen voor 32bit applicaties. Vandaag wordt het ook vaak gebruikt als verzamelnaam voor alle applicaties de gebruik maken van zowel de win32 als de win64 API. Applicaties die nog een pure executable zijn in plaats van dat ze via een moderne tussenlaag zoals .Net werken.

En waarom zou Microsoft de 32bit laag moeten weglaten? Wat win je er mee? En zelfs vandaag zijn er nog mensen die op een 64bit Windows weer met omwegen die 16 bit laag terugbrengen voor oude applicaties te kunnen blijven gebruiken.

Met Win32 worden hier de reguliere EXE & MSI's bedoelt. De apps uit de Windows Store (appx, etc.) konden al per applicatie geblokkeerd worden.

Win32 is volgens mij gewoon de naam van een api en heeft niks met 32 bit te maken.

Zoals anderen al stellen, Win32 is de naam van de API. Oorspronkelijk de 32 bits Windows API maar intussen al heel lang gewoon de Windows API dus 64 bits.

De speciale laag om 32 bits applicaties te kunnen draaien is wow64.

En vergis je niet, in de industrie wordt nog altijd 32 bits gebruikt. Zowel 32 bits applicaties als 32 bits communicatie protocollen. Daar wordt met hele lange termijnen gewerkt waarbij het 'don't fix it if it don't break' gehanteerd wordt.

Los van dat win32 slaat op een applicatie API om met Windows te communiceren,

Is microsoft van plan om die 32 bits applicaties te ondersteunen tot er een 128 bits versie van windows uit komt?

Reken er maar niet op dat we snel een conventionele 128-bit CPU of OS hoeven te verwachten. Met 64 bits zou een processor maximaal 16 exabyte aan geheugen kunnen gebruiken.

Ik weet dat ik nu herhaal wat ze vroeger zeiden over 32-bits met 4GB, maar 16EB is zo'n bizar grote hoeveelheid; met de huidige technieken hoe SRAM/DRAM gemaakt wordt, kunnen we dat realistisch gezien niet bereiken.

Daarnaast, als we zoveel geheugen nodig hebben voor Windows en wat applicaties te draaien dan lijkt me dat we eerder de plank mis hebben geslagen met optimalisaties De POST tijdens zullen ook niet lekker snel zijn

Maar toch hoop ik dat microsoft de 32-bits runtime omgeving toch snel achter zich laat.

Want?

Allemaal fout. Dit gaat om alle niet Store / UWP related apps, waarvoor dit soort 'permissies' nooit zijn bedacht. Hier heb je normaliter alleen user/elevation permissions (basic uitgelegd)

[Reactie gewijzigd door Marctraider op 19 augustus 2026 23:07]

Met die 128 bits versie van windows word onder andere ook door arm ondersteund microsoft is met de laptops daar al klaar mee.

als er nog een 128 bits versie van windows komt op het x86 platform dat weet ik niet.

De 32 in win32 heeft al heel lang geen 1:1 relatie met 32-bit. Meestal wordt daarvoor x86 (32-bit) of x64 (64-bit) voor gebruikt.

Windows zelf is al heel lang 64-bit, maar pas sinds Windows 11 is er geen 32-bit Windows versie meer. In verband met comptibiliteit heeft Microsoft de verwarring best groot gemaakt: C:\Windows\System32 bevat 64-bit executeerbare bestanden (o.a. .exe en.dll), C:\Windows\SysWOW64 juist 32-bit. In de registry zit dat op een soortgelijke manier. En in namen van Windows systeem DLL's zit ook nog wel de *32.dll naam, wat ook niet (meer) op het aantal bitjes slaat.

De term Win32 slaat ook op de 'Win32 API' (wat ook @Blokker_1999 zegt), zeg maar de laag waar tegenaan je programmeert als programmeur (kenners weten dan ook hoe je de term MSDN interpreteert, dat is/was de oude naam voor de documentatie van de Win32 API). Hoe de interactie 32-bit v.s. 64-bit zit gaat hier een beetje te ver, maar onder de motorkap loopt dat via System32 vs SysWOW64, zoals ik hierboven noem.

Overigens is .NET ook afhankelijk van de Win32 API (of op Linux, van die systeem API). Dingen als file operaties, proces beheer lopen via low-level OS routes, wat automatisch op Windows dus Win32 is.

In menselijke termen klinkt 64-bit is meer/beter dan 32-bit. Dat is deels een psychologische truc. De hoofdreden voor overstap naar 64-bit vanuit eindgebruikersperspectief is de mogelijkheid om meer dan 2GB geheugen aan te kunnen spreken (in 32-bit was dat met trucs beperkt mogelijk, maar nooit meer dan 4GB) + bijv. grotere files dan 2GB te kunnen gebruiken. Die extra mogelijkheden komen wel met een prijs, nl. een verwijzing naar geheugen met een 64-bit adres kost 2x zoveel ruimte als voor een 32-bit adres. Dus de extra mogelijkheden komen met een 'prijs'. Doordat de focus nu 100% op 64-bit ligt, Windows zelf ook iets vlotter op direct 64-bit werkt, dan 32-bit op 64-bit Windows (de WOW in SysWOW staat voor (32-bit)Windows-on-(64-bit)Windows en is een compatibilitetieslaag) is de 'prijs' van het extra geheugengebruik van een 64-bit executable t.o.v. een 32-bit executable voor lief genomen. Uit de tijd dat ik actief bezig was met overstap van 32-bit naar 64-bit was het extra geheugengebruik ca 30% (dat is uiteraard applicatie specifiek, afhankelijk hoe geheugenintensief een applicatie is). Een andere praktische reden van overstap op 64-bit is: iedereen doet het, waardoor 3rd party spul geen 32-bit interface meer aanbood (bijv. database leveranciers).

Dat gezegd hebbende: het zijn eigenlijk alleen nog oude apps, waar de leverancier niet meer van bestaat of deze geen tijd/geld (noem het) over heeft om een 64-bit versie te maken, die die oude lagen nog nodig hebben. Maar uitsterven van iets duurt heel lang. Daarom zal Microsoft oude meuk lang laten zitten, omdat verwijderen van code ook een risico op fouten/bugs oplevert. Voor een ontwikkelaar geldt dat oude code alleen weggehaald wordt, als het in de weg zit en je niet al te veel klanten dupeert (dat is nl. je inkomstenbron).

[Reactie gewijzigd door kdekker op 20 augustus 2026 11:50]

Veel apps, zoals Google Chrome en Microsoft Edge, hadden zelf al ingebouwde toestemmingsvensters

Dit dus. Waarschijnlijk heeft Vivaldi hun eigen ingebouwde toestemmingvenster.

Echter voorkomt dat niet dat Vivaldi alsnog bij jou microfoon kan. Aangezien het nooit op systeemniveau per app geblokkeerd kon worden. Dus technisch kon Vivaldi altijd je microfoon gebruiken. Hun eigen toestemmingvenster voorkomt dat natuurlijk technisch niet.

In de nieuwe functie kan je het nu op systeemniveau (Windows) het per app instellen.

“Mis ik iets of is dit een andere functie. Dit zit er toch al best lang in?”

Ik dacht hetzelfde maar ik had me vergist met MacOS

Ja, en ook bij een muisbeweging vragen of je dat toestaat, wel per app graag dan.

Alleen hopen dat het ook echt werkt. Voor nu nog te vaak een niet-werkende microfoon. En daar kom je meestal pas achter als het telaat is.

Precies. Nu GNOME en KDE nog en dan zullen alle veel gebruikte desktops het kunnen.

Precies. Gnome en KDE zullen nu dit trucje bekend is niet zo lang op zich laten wachten voordat ze dit ook kunnen.