'Microsoft werkt aan Windows 10-variant met gevirtualiseerde Win32-software'

Microsoft werkt volgens een gerucht aan een versie van Windows 10 op basis van het modulaire Windows Core OS, gericht op pc's. Bij het OS met codenaam Polaris zouden Win32-programma's alleen gevirtualiseerd kunnen draaien.

Microsoft zou veel traditionele eigenschappen en code uit Polaris geschrapt hebben, om er een veilig, snel en modern OS van te maken, schrijft Windows Central. Onder andere Win32-componenten zouden het veld moeten ruimen en in plaats daarvan zou de software volledig rond het Universal Windows Platform draaien, met apps uit de Windows Store. De software zou nog wel traditionele Windows-programma's kunnen draaien, maar dan via virtualisatie, vergelijkbaar met hoe de HP Elite X3 Win32-software op Windows 10 Mobile kon draaien. Bij Windows op ARM draaien de Win32-programma's via emulatie.

Verder zou Polaris de universele CShell, of Composable Shell, bevatten in plaats van de huidige Windows Shell. Microsoft zou de software speciaal voor pc's als desktops, laptops en convertibles samenstellen op basis van Windows Core OS, de modulaire kern die de basis moet vormen voor meer Windows-varianten. Eerder kwam informatie naar buiten over Andromeda OS voor mobiele apparaten, dat eveneens op Windows Core OS gebaseerd zou worden. Windows Central is goed ingelicht en brengt regelmatig nieuws rond Windows naar buiten voor officiële bekendmakingen.

Windows 10 S lijkt daarmee een voorloper op Polaris. Ook dit OS kan standaard alleen uwp-apps draaien, al is er nog wel een upgrade naar Windows 10 Pro mogelijk. Microsoft leek Windows 10 S vorig jaar nadrukkelijk naar voren te schuiven als de toekomst van Windows, maar lijkt daar wat van terug te komen. In de VS is de Surface-laptop van het bedrijf inmiddels niet meer exclusief met Windows 10 S te verkrijgen, maar optioneel ook direct met Windows 10 Pro.

Door Olaf van Miltenburg

Nieuwscoördinator

25-01-2018 • 20:25

56 Linkedin Whatsapp

Submitter: nickurt

Lees meer

Reacties (57)

57
55
41
3
0
3
Wijzig sortering
Dit zie ik niet direct als een negatieve ontwikkeling; er is aardig wat voor te zeggen om elke applicatie zijn eigen virtuele sandbox te geven. Op krachtige desktops is dit ook geen enkel probleem.. Virtualisatie is tegenwoordig echt een stuk sneller dan 10 jaar geleden. Het zou leuk zijn als we hier een virtueel filesystem (of betere/strictere rechten) bij kunnen krijgen waarbij elke applicatie zijn eigen stukje van mijn harde schijf krijgt. Dan kunnen kwaadaardige programma's niet zomaar mijn browsercookies of mailbox uitlezen.

Ik vraag me echter wel af of de emulatie niet erg ten koste gaat van de UX op low power ARM devices. Veel legacy software (en games!) zullen nog járen op de Win32 API blijven draaien, ben ik bang.. Schiet Microsoft zich niet een beetje in zijn eigen voet?

[Reactie gewijzigd door Laloeka op 25 januari 2018 20:34]

Dit zie ik niet direct als een negatieve ontwikkeling; er is aardig wat voor te zeggen om elke applicatie zijn eigen virtuele sandbox te geven. Op krachtige desktops is dit ook geen enkel probleem.. Virtualisatie is tegenwoordig echt een stuk sneller dan 10 jaar geleden.
Zeker weten. Ik draai Linux met daarop een Windows in VirtualBox.En op die virtuele Windows draai ik een emulator van een oude spelcomputer, zonder enig probleem allemaal.
Hierbij maakt het natuurlijk wel uit of je Windows volledig virtual draait of met hardware matige versnelling werkt. Als het guest OS op dezelfde CPU kan draaien als het host OS, dan kunnen sommige CPU, zeker de Intels, dit zelf doen. Waardoor de virtualisatie software de instructies van het OS niet een voor een hoeft te interpreteren.

Met Windows draaien op ARM en Win32 apps gemaakt voor x86 krijg je een ander verhaal. ARM kan niet direct x86 code draaien. In dit geval moet dus de virtualisatie software alles interpreteren zonder hardware ondersteuning. Dat gaat zeker een performance hit opleveren.
Ik vraag me echter wel af of de emulatie niet erg ten koste gaat van de UX op low power ARM devices. Veel legacy software (en games!) zullen nog járen op de Win32 API blijven draaien, ben ik bang.. Schiet Microsoft zich niet een beetje in zijn eigen voet?
Hoeveel legacy Win32 zal de gemiddelde gebruiker op een ARM device draaien? De meeste desktop apps zijn sowieso al slecht bruikbaar op tablets. Bovendien zijn veel van dergelijke apps in gebruik binnen bedrijven die ze op termijn uitfaseren en er niet zoveel moeite mee zullen hebben dat ze tot die tijd wat minder presteren als er al gekozen wordt voor ARM.

Wat betreft Win32 games zullen ARM devices nooit een goed alternatief zijn voor het Intel/AMD platform. Classic games moeten volgens mij ook in een gevirtualiseerde omgeving op Intel/AMD platform nog ruim voldoende presteren.
Op krachtige desktops is dit ook geen enkel probleem

Was het niet de bedoeling dat dit juist op minder krachtige hardware kan draaien
Anoniem: 636203
@Laloeka26 januari 2018 05:21
Volgens mij is er nauwelijks nog verschil tussen draaien in een VM en native, omdat veel moderne processoren virtualisatie hardwarematig ondersteunen.

Het is mij wel onduidelijk wat voor API Win32 dan gaat vervangen.
Waar ik me nog wel zorgen om maak is hoe goedaardige programma's dit gaan doen in zo'n strikte omgeving. Kan je binnenkort nog wel makkelijk zaken aanpassen als plugins (Chrome, Firefox, maar ook veel IDE's) of mods (Bethesda Games, Minecraft)? Zijn daar oplossingen voor?
De UWP API is een hele tijd lang erg afhankelijk geweest van de Win32 API en heeft daar tot nu toe voor een groot gedeelte op geleunt. Nu wordt dat omgedraait. Toch was er weinig mis met de performance.

MS is met dit concept al vele jaren aan het pielen. Deze stap lijkt heel erg veel op het security principe van Singularity, elke applicatie krijgt echt zijn eigen space. Dit is een ontzettende ingreep want Windows draaide op die Win32 API zelf. Nu kan de API in principe tot het einde der tijden netjes en veilig ondersteund worden zonder dat het een risico vormt voor de rest van je OS en/of je data.

Elke applicatie een eigen schrijf afdwingen is default in UWP, elke app krijgt default enkel rechten in zijn eigen mapje/lokatie. Dit afdwingen op Win32 software zal een boel software gewoon breken. Het heeft tien jaar geduurd voordat alle software kon omgaan met een write protecte program files.

MS schiet zichzelf niet in de voet, MS zet hiermee een enorme stap voorwaards.
De HP elite X3 gebruikt geen emulatie voor Win32 maar gebruikt servers van HP, dit noemt HP de workspace dienst. Staat ook in de preview hier op Tweakers: reviews: HP Elite x3 - Windows 10 Mobile met x86-programma's

Windows 10 op ARM voor de Qualcom SD830 ondersteunt wel de emulatie van x86 / Win32 code, zoals hier beschreven: nieuws: Microsoft presenteert ARM-versie Windows 10 die x86-programma's kan d...
Misschien een domme vraag (ik heb hier weinig kaas van gegeten), maar waarom geen X64 ondersteuning? Sommige apps worden niet x32 meer geschreven. Het zou toch zonde zijn als je dat gaan uitsluiten?

[Reactie gewijzigd door Luchtbakker op 25 januari 2018 20:36]

Win32 slaat niet zo zeer op de 32bit vs 64bit instructies. Win32 is de naam van de Windows API waarmee een programma systeemfuncties kan aanroepen, zoals een nieuw scherm openen, een geluidje afspelen, een bestand wegschrijven, etc.

Win32 doet erg veel, maar het raakt ook een beetje verouderd; daarom is Microsoft bezig met het uitrollen van een nieuw platform dat zowel op desktop als op mobile dezelfde manier van systeemfuncties aanroepen gebruikt: Universal Windows Platform. Het zou het voor ontwikkelaars makkelijker maken een app te ontwikkelen die zowel op desktop als op Windows Phone werkt.

Omdat Microsoft niet twee APIs wil blijven onderhouden, zal Win32 ergens in de toekomst verdwijnen. Deze virtualisatie stap lijkt een signaal van Microsoft te zijn dat het voor ontwikkelaars nu echt tijd is om over te stappen.

[Reactie gewijzigd door Laloeka op 25 januari 2018 20:40]

UWP is nog niet volwassen genoeg om alles maar over te zetten. Maar dat is denk ik nog maar een paar jaar weg. MS werkt er wel hard aan.

Dit is niet zo zeer een signaal naar developers toe om Win32 helemaal achter zich te laten. UWP is nog steeds niet zo krachtig en uitgebreid als Win32. De toekomst waar Win32 verdwijnt is nog heel ver weg.

Win32 krijgt nu dezelfde behandeling als de rest van het OS. Het wordt een module van het OS. Beetje zoals het Linux Subsystem ook als een losse module op Windows draait, draait "Windows" (zoals we nu nog kennen) nu als een module in Windows.

Dit zorg er tevens voor dat de Win32 API in principe tot in het einde der tijden ondersteund kan worden.
UWP is al goed genoeg voor heel veel applicaties. Natuurlijk duurt het nog lang voor het alles kan. Dat is voor Microsoft ook niet zo belangrijk. Via de Microsoft store is er betere controle op applicaties mogelijk en kan Microsoft ook wat geld verdienen met andermans applicaties en haar eigen abonnementsdiensten. Vooral als ze nog wat met Mobile gaan doen, een must.
Mja, alleen is dit een natte droom van wat WinDiv managers maar in de praktijk komt er weinig van terecht. Win32 is niet zozeer 'verouderd' (in wat voor opzicht dan?), het is meer een vergaarbak van APIs die niet weg kunnen ivm backwards compatibility.

UWP klinkt leuk, maar geen hond maakt apps voor UWP. Microsoft probeert het telkens opnieuw maar in de praktijk lukt het botweg niet omdat er zoveel software is dat gewoon op win32 leunt dat de gebruiker geen trek heeft in een gelimiteerd OS.

Los daarvan, delen van windows zelf zijn nog altijd niet geupdate, bv MMC en al z'n add-ins.

En wat is werkelijk slecht aan Win32? Linux runt nog steeds een binary die gecompileerd is tegen een api van tig jaar geleden, en dat is een groot goed. Het domme beeld dat bits kennelijk wegrotten en 'verouderen' is onnozel: men moet kennelijk weer leren dat software helemaal niet verouderd of wegrot als een peer op een fruitschaal.

[Reactie gewijzigd door EfBe op 26 januari 2018 10:37]

Dat is het niet, je moet enkel een steeds grotere en oudere codebase blijven onderhouden. Win32 doet allerlei dingen op een manier die we anno nu niet meer zo zouden opzetten, oa vanuit security aspecten die er in 1993 nog niet waren.

GNU/Linux heeft inderdaad een API uit het jaar kruik, maar dat is direct ook de reden van het succes van dingen als Android. Apple gooit ook regelmatig brokken legacy API de prullenbak in. Da's niet omdat ze op zichzelf niet meer werken, maar omdat ze geen zin hebben om hun mankracht over zoveel code te verspreiden.

[Reactie gewijzigd door Dreamvoid op 26 januari 2018 12:20]

Misschien een domme vraag, maar waarom geen X64 ondersteuning? Sommige apps worden niet x32 meer geschreven. Het zou toch zonde zijn als je dat gaan uitsluiten?
Win32 is een naam voor traditionele applicaties voor Windows op x86-64 platforms. Dit zijn de applicaties die je moet installeren. De nieuwe tegenhanger is UWP, dit zijn bijvoorbeeld de apps die je via de Windows Store kan verkrijgen.

Er staat hier nergens dat x64 applicaties niet zullen functioneren. Het geïsoleerd draaien van applicaties in hun eigen afgesloten omgeving is een flinke stap vooruit voor de veiligheid van het systeem.
Ik sta niet te popelen om te werken met Windows versie die niet meer is dan een veredelde mobiele versie. Waar je voor elke handeling afhankelijk bent van een specifieke app en waarbij je bijna altijd me het internet moet verbonden zijn. Security is belangrijk, maar ik vind de vrijheid van het systeem zoals nu ook belangrijk. Een soort dualboot lijkt mij misschien een tussenoptie? Waar je bij de ene (snel) kan opstarten en inderdaad gewoon apps kan starten, van rekenmachien tot Photoshop. Maar dan wel ook nog een optie om het systeem te benaderen en te gebruiken zoals te vergelijken met nu?

[Reactie gewijzigd door Mlazurro op 25 januari 2018 20:43]

Windows gaat niet in dat opzicht veranderen. Dankzij deze wijziging blijft de Win32 API juist beter ondersteund.

De UWP API is straks niets anders dan een moderne vervanging van de Win32 API in al zijn kracht en glorie. Maar dan opgezet met "security first" in plaats van Win32's "features, features, features", wat de ontwikkeling wat langzaam maakt.

Het veranderd verder niets in de werking van Windows. De desktop zoals je die gekend hebt blijft. De configureerbaarheid wordt enkel beter want je kan straks veel makkelijker onderdelen van Windows naar voorkeur uit- en inschakelen.

Op welke API de programma's geschreven worden... sinds wanneer maakt dat voor de eindgebruiker uit? Niets. Zolang de programma voldoet? Er is geen reden waarom desktop achtige applicaties niet op de UWP API gemaakt kunnen worden. De gebruikte API zegt niets over het uiterlijk en de werking van een applicatie.
Op welke API of tegen welke bibliotheek programma's geschreven worden, maakt voor de gebruiker best wat uit. MS saboteert soms zijn eigen software. Voorbeeld: Windows 2008 wordt nog ondersteund, maar de nieuwste .NET software loopt er van de ene op de andere dag niet meer op. Dus zonder dat de ontwikkelaars van een paar essentiële zakelijke pakketten daarvoor waarschuwden - mogelijk wisten ze het ook niet - moest een bedrijf op stel en sprong naar een nieuwe Windowsversie.
De UWP API is straks niets anders dan een moderne vervanging van de Win32 API in al zijn kracht en glorie. Maar dan opgezet met "security first" in plaats van Win32's "features, features, features", wat de ontwikkeling wat langzaam maakt.
Ga maar wat concrete voorbeelden noemen, want dit gaat anders nergens over. Win32 niet secure? Hoe wil UWP dat dan veranderen? Wat houdt 'security first' in dan bij UWP? Is dat hetzelfde als de security manifests in win32?
Het simpele feit dat Win32 gewoon overal toegang tot heeft zegt al meer dan genoeg. Dan heb je ook nog WinRT sandboxes, etc. Ga het zelf maar opzoeken, WinRT is in veel opzichten veel beter dan Win32, zeker op security-vlak.
Win32 is zoals @loller1 al zegt, een API met onbeperkte rechten en mogelijkheden. Api Calls die veel meer kunnen dan waar ze voor bedoelt zijn (Leuk om de Wine development te volgen en hun te horen voor al de achterlijke exceptions die developers misbruikt hebben in de Win32 API die MS er in heeft laten zitten).

Win32 is achteraf "veilig gemaakt", door de rechten enorm te beperken en allerlei laagjes over Win32 heen te bouwen die in de gaten houdt of troep hier niet misbruik van maakt (met de enorme lading uitzonderingen vanwege backwards compatibility).
De Application manifest is van die ductape om Win32 veiliger te maken.

Win32 is gebouwt om snel features te implementeren. Hoe die featues geimplementeerd werden, hoe veilig dit was en of het mogelijk meer kan dan de bedoeling is... Maakte allemaal niet uit, zolang er maar voor gezorgd werd dat feature X in de Win32 API mogelijk wordt.

Het feit dat de Win32 API uit een periode stamt waar security een non-issue was, helpt ook niet.

UWP is helemaal andersom opgezet. Veiligheid eerst, features komen wel. Alle features die in UWP gestopt worden, worden links en rechts getest op hun veiligheid. Zoals o.a.: Zorgen dat een UWP API call niet wat anders kan doen dan de bedoeling is, zorgen dat een API call niet meer rechten op het systeem krijgt dan absoluut nodig, zorgen dat API calls de stabiliteit van het systeem niet in het geding brengen.

Er wordt gewoon veel meer werk verzet voordat een feature bij de API toegevoegd wordt.
Beetje dubbel. Aan de ene kant is Windows groot geworden door de vrijheid die het de gebruikers geeft en de verregaande backwards compatibility. Aan de andere kant is het ook de grote makke van het systeem omdat het tal van voorzieningen nodig maakt om het systeem te beschermen en beveiligen. Deze nieuwe versie zal niet bij alle gebruikers in de smaak vallen, maar ik kan wel begrijpen dat Microsoft deze richting op wil om het systeem toekomstbestendig te maken.
Juist het omgekeerde, als MS dit goed uitwerkt ga je zelf niet merken dat je Win32 applicatie in een soort sandbox werkt.
Als ze dit goed uitwerken zouden ze er in slagen om oudere programma's ook in toekomstige Windows versies te laten draaien, zelf al is dat op een ARM cpu.
Dat laatste hebben ze zelfs al voor elkaar, op Windows 10 Pro ARM64 kun je gewoon .exe's installeren, die weliswaar de eerste keer langzaam zullen werken om een ARM-specifieke "vertaling" te maken maar daarna (naar het schijnt) vrijwel dezelfde performance zouden moeten bieden als op een vergelijkbare x86 processor.
Zouden ze daar een variant van de Roslyn compiler inzetten?
Of je nou van IL naar x64 gaat, of van x64 naar ARM zou niet echt veel uit moeten maken, Alleen de parsen en de tokenizer zouden wat uitgebreid moeten worden.
Mooi, het wordt hoog tijd dat Windows afstapt van die veel te lange legacy, goed dat er nog altijd een versie blijft bestaan die daar wel voor gemaakt is, maar de meeste mensen hebben dat absoluut niet nodig. Hopelijk maakt die push de nood die er nu nog voor is nog minder relevant. Naas Polaris voor PC is er overigens ook nog Andromeda voor Mobile, Aruba voor Team (Surface Hub, etc.) en Oasis voor Mixed Reality.
wat is er mooi aan? Je hebt totaal geen last van 'legacy' win32, ja wanneer het er niet meer is en jij een app wilt gebruiken die er tegenaan gecompileerd is.

Waarom wil men toch zo graag van win32 af? Heb je het uberhaupt wel eens gebruikt?
Laat het mij herhalen: Win32 is een verouderde API, legacy die het overgrote deel van de Windows gebruikers niet nodig hebben om te doen met hun devices wat ze vandaag doen. Win32 2 keer op je systeem hebben staan en dan nog eens WinRT maakt Windows onnodig groot en log. WinRT is de toekomst en op een gegeven moment moet je ondersteuning voor Win32 gewoon knippen.

Dat je er geen last van hebt is natuurlijk belachelijk, jij als eindgebruiker merkt het wel degelijk zelfs als je geen Win32 apps draait.
Wat een verwarrend artikel. Zowel Polaris en Core OS zijn bestaande OS’en.

verder ben ik wel heel benieuwd naar de uitwerking. Ik mag hopen dat de UWP onderdelen beter en efficiënter draaien dan op de huidige W10. Daar blijven apps op de achtergrond draaien en merk ik toch nog veel stabiliteitsissues.

[Reactie gewijzigd door mrdemc op 25 januari 2018 21:01]

Redstone, Blue, Vienna, Threshold, Whistler, Blackcomb en Longhorn zijn ook allemaal bestaande woorden. Wat maakt het uit dat Microsoft deze gebruikt? Alsof je deze versies van Windows ooit zo zal gaan noemen. En wat Windows Core OS betreft: als je de helft van de naam weglaat en woorden aan elkaar begint te plakken kun je natuurlijk van iedere langere naam een al bestaande kortere naam maken.
"Many Wine DLLs can be cross-compiled with mingw-w64 already, but Wine itself doesn't work yet."
http://web.archive.org/we....winehq.org/WineOnWindows
Ik ben heel benieuwd hoe viual studio in dit plaatje valt. Sommige onderdelen van dit pakket, als bijvoorbeel windows phone en android emulatie werken niet in een virtuele omgeving!
Nested Virtualization is al mogelijk. Het is al mogelijk om de Visual Studio emulators in een hyper-v instantie te draaien.

https://docs.microsoft.co...ide/nested-virtualization
Een beetje jammer dat term csh (wat in UNIX land een c-shell is, een shell die C-achtig is) nu een andere betekenis gegeven wordt.

Ik vraag me af of een complete nieuwe API set Microsoft gaat komen. Volgens de bron die tweakers noemt, gaat het om een laag op UWP. Maar UWP zelf leunt ook op APIs. Die kunnen ze niet zomaar verwijderen. Een API set verwijderen en volledig vervangen door een andere, is een proces waar gerust 10+ jaar uitgetrokken kan worden.

Daarnaast heeft - hoewel vaak op een eigenzinnige manier - compliance met POSIX/ANSI. Wil je als C/C++ ontwikkelaar code kunnen schrijven die op meerdere platformen draait, dan is compatibiliteit van APIs belangrijk. Microsoft maakt daar zelf ook gebruik van, want hoe anders zouden ze Linux-achtige zaken in Windows uitrollen? De afgelopen jaren zie je dat Microsoft eerder meer Linux-minded wordt (in Windows, maar ik in de media, en zelfs SQL server is op native Linux te krijgen, al is het daar een 'Windows-VM-op-Linux). Misschien zeg ik het niet goed, maar iets minder anti-Linux lijkt toch wel zo te zijn. Die richting impliceert volgens mij ook nog jarenlange support voor POSIX achtige API's.
Anoniem: 636203
@kdekker26 januari 2018 05:56
Volgens mij draaien de meeste Windows programma's nog direct of indirect op Win32 API's. Ik denk ook dat Microsoft niet duidelijk communiceert wat Win32 API's zou moeten vervangen. Je krijgt dan een wirwar van API's voorgeschoteld die grote overlap hebben en onder water wellicht weer gebruik maken van Win32 implementaties.

[Reactie gewijzigd door Anoniem: 636203 op 26 januari 2018 06:38]

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee