Vernieuwde Microsoft Store gaat Win32-apps niet updaten

Microsoft laat aan ontwikkelaars weten dat gebruikers via de vernieuwde Microsoft Store geen updates kunnen ontvangen voor Win32-apps. Ontwikkelaars worden door het bedrijf aangeraden om updates te verspreiden via Win32-apps zelf.

In de Win32-appontwikkelaarsvoorwaarden voor de Microsoft Store geeft Microsoft aan dat eindgebruikers geen updates kunnen ontvangen via de Store. Apps kunnen wel updates ontvangen via de app zelf, nadat deze bij de Store is gedownload. Deze updates moeten nog wel voldoen aan de voorwaarden van de Microsoft Store.

Ontwikkelaars kunnen daarnaast ook een Win32-app van een geüpdatete versie voorzien en deze geüpdatete versie daarna via de Microsoft Store verspreiden. Nieuwe gebruikers die die app downloaden, krijgen dan de geüpdatete versie. Gebruikers die een eerdere versie downloadden, krijgen dus niet automatisch die nieuwe versie. Overigens zijn ontwikkelaars niet verplicht om Win32-apps in de Store van updates te voorzien.

Microsoft introduceerde donderdag de nieuwe Store die met Windows 11 moet verschijnen. De nieuwe Store komt ook naar Windows 10. Met de nieuwe Store wil Microsoft de downloadwinkel nieuw leven inblazen en deze voor ontwikkelaars aantrekkelijker maken. Daarom wordt het mogelijk om Win32-apps toe te voegen aan de Store en kunnen deze ontwikkelaars eigen betaalsystemen integreren in software.

Reacties (96)

Dit is een vreselijk slecht geschreven artikel.

Win32 apps kunnen wél via de Microsoft Store worden bijgewerkt. Dat kan al jaren. Microsoft laat met de nieuwe Store nu ook unpackaged Win32 apps toe, dit zijn praktisch links naar gewone downloads waarbij de Microsoft Store commando's uitvoert voor een headless installatie te doen, maar vervolgens zich gewoon gedragen als software die buiten de Store om is geïnstalleerd. Dat is waar deze richtlijnen over gaan. Maar apps kunnen ook als packaged MSIX apps worden gebruikt in de Store welke wel gewoon via de Store updaten.

Dit artikel negeert volledig het verschil tussen packaged en unpackaged apps, wat juist de essentie van het verhaal hier is.

[Reactie gewijzigd door Loller1 op 30 juni 2021 12:40]

Dit is jammer. Ik had gehoopt dat Microsoft voor games zou afstappen van packaged apps, maar als wat je schrijft klopt dan is die kans wel erg klein geworden.

Inderdaad, gaat nooit gebeuren. Ik betwijfel zelfs of de volgende TES game in modifiablewindowsapps komt.

De weg die Microsoft is ingeslagen betekent de dood van het echte modden. Als ze zo door gaan koop ik nog een keer een Mac ...

Ik maak al een tijd de gewoonte om bij elk artikel de highest voted comment te controleren, omdat die (te) vaak zeer benodigde nuance toevoegd aan het verhaal.

Triest...

Van mij mogen ze 32bit snel de deur uit doen.

Zoals ik het begrijp staat 'win32' voor 'native desktop app', dus een reguliere Windows app, niet geschreven op .NET framework of WPF, maar rechtstreeks op Windows apis. (Bijv. geschreven in C++)
De term '32' is wat verwarrend, want dit kunnen ook 64-bits applicaties zijn.

Volgens mij vallen WPF- en WinForms-applicaties ook onder de 'win32'-noemer.

Klopt, enkel UWP en PWA vallen daar niet onder.

Inderdaad. Het gebruik van een van de vele frameworks veranderd niet dat het win32 is. Win32 apps zijn alle traditionele Windows applicaties. Het soort met een setup en een exe that is

Win32 gaat over alle apps die draaien op het oude Win32 systeem, dat ook wel bekend staat als de "Windows API".
Dat kan dus C++ zijn, of .NET, of zelfs een webapp die draait in een browsershell die intern weer de Windows API gebruikt.

Het enige alternatief is het Universal Windows Platform (UWP).

Zoals ik het had begrepen software die zijn ontwikkeld als zijn .exe of .msi bestand en dat die geconverteerd zijn naar de Windows Store formaat, in hoeverre dat ook verschillend mogen zijn.

Dergelijke software moet dus compleet opnieuw worden aangeboden in de store om waarschijnlijk tekortkomingen sneller op te sporen.

Een minor update kan eventueel ook via de app zelf worden uitgevoerd buiten de store om.

Lijkt me een risicovolle strategie om ontwikkelaars tevreden te stellen, alleen kwaadwillende kunnen er ook mee aan de slag.

Is altijd down compatible geweest zo had een 32 bit OS ondersteuning voor 16 bit apps en 64 bit OS voor 32 bit apps ondersteuning.

32-bit OS mag inderdaad wel eens afgelopen zijn, Windows 10 had nooit met 32 bit moeten uitkomen, de processors welke geen 64 bit hebben zijn sowieso te oud voor Windows 10, en heb je nog 16 bit apps draai die maar in een VM, zo heb ik dat laatst nog gedaan voor maatwerk software van een bedrijf wat van oorsprong nog op Windows 95 draait.

Software wordt weinig gebruikt dus geen 2000 euro over voor een upgrade dan dus maar houtjetouwtje met een VM aan de slag wat wel prima werkt(software wat je maar 2x per jaar gebruikt).

De Pentium 4 had al 64 bit ondersteuning, en dat is nou niet echt een PC om nog Windows 10 op te gaan draaien...

[Reactie gewijzigd door mr_evil08 op 30 juni 2021 12:29]

Die 16 bits applicatie die je in een VM draait? Goede kans dat dat de installer is van een 32 bits programma. Dat zag je historisch vaak. En dan is je 32 bits programma dus alleen geinstalleerd in je 16 bits VM, waar die niet draait.

En om precies dezelfde reden heeft Win64 nog support voor 32 bits installers.

Nee was echt 16 bit, het kon ook nog op Windows 3.1, een 64 bit OS kon er niks mee(start de installer niet eens en krijg je een vreemde foutmelding).

[Reactie gewijzigd door mr_evil08 op 30 juni 2021 12:48]

Er is nog steeds 16-bits software uit het vorige millenium dat in gebruik is. Microsoft wilde van XP in eerste instantie een 64bits only OS maken (al was dat voor Itanium), maar stapte daar tijdens de ontwikkeling van XP al vrij snel weer vanaf. Helemaal toen AMD64 geïntroduceerd werd, ging die noodzaak weg.

Over het algemeen heb je geen performance verschil van 32bit applicaties op een 64bit OS, maar er zijn een paar edge cases waarbij je beter een 32bit OS kan gebruiken. Tevens zit je met sommige antieke drivers die je never nooit aan de praat gaat krijgen op een 64bits OS.

De enige reden dat Windows 10 normaliter niet op zulke oude processors draait is eis voor SSE2, maar daar is zonder al te veel moeite omheen te werken. Je kan Windows 10 'prima' op een Pentium 4 draaien.

Het wordt nog dusdanig genoeg gebruikt dat Microsoft het waard vind om een 32bit OS uit te brengen.

Je snapt hoop ik ook dat Windows 10 op een pentium 4 meer sarcasme is ;-)
Het OS zal werken maar vrij verrot en niemand zal dat serieus doen maar puur gewoon "omdat het kan" dit soort oude hardware is niet alleen SSE2 maar ook goede drivers ontbreken, de hardware is gewoon veel te oud, (Core2Duo is wel het minimale voor Windows 10 en dan richting de E8400 en maar hopen dat er toevallig redelijke drivers nog van zijn).

[Reactie gewijzigd door mr_evil08 op 2 juli 2021 18:31]

Was het ook, vandaar prima tussen haakjes. Het draait, het doet zijn ding, voornamelijk alleen bagger sloom. Maar het werkt opzich prima.
P4 was sowieso al vrij crap dus dat helpt ook niet al te veel, kan beter een AMD uit die tijd pakken voor een betere ervaring

Opzich is het best indrukwekkend hoe weinig de hardware eisen gestegen zijn de afgelopen ~10-15 jaar.

Windows 10 32b draait anders nog steeds perfect op mijn (toegegeven, ondertussen vrij oude) Asus T100. Deze heeft een vrij trage Atom-chip zonder 64b-ondersteuning, maar is wel retezuinig (na 7 jaar bijna dagelijks gebruik nog steeds 8+ uur batterijgebruik, was 12 uur nieuw) en nog steeds snel genoeg voor mijn lesnotities via OneNote, PDF's lezen en licht browsen. Dus ik ben persoonlijk heel blij dat Microsoft nog even verdergaat met het updaten van Windows 10.

Trouwens, er zijn Atom-chips zonder 64b-ondersteuning uitgekomen NA de Windows 10-release, dus het hoeft niet persé om stokoude chips te gaan.

Dat Windows 11 nu wel volledig 64b wordt vind ik dan weer logisch, want sinds 2017 zijn er voorzover ik weet inderdaad geen 32b-only x86 cpu's meer verschenen.

Liever niet! In mijn veld (Lucht en Ruimtevaarttechniek) wordt er nog volop gebruik gemaakt van 32bit.

Programma’s als XFOIL en AVL, waarmee je resp 2D en 3D low level simulaties van vleugelprofielen / vleugels kan maken draaien op 32 bit.

Het zal je verbazen hoeveel software nog op 32bit gebaseerd is, juist ook in de wetenschappelijke / engineering community.

Het grootste gedeelte van Microsoft's Visual Studio is zelfs nog alleen beschikbaar in 32 bit, al komt daar gelukkig binnenkort verandering in

De meeste applicaties zijn Win32 applicaties.
UWP applicaties zijn dat niet, maar UWP is pas 4 jaar geleden geïntroduceerd.

Win32 is het systeemplatform waarop applicaties ontwikkeld zijn.
Je kunt je eigen Win32 applicaties voor 64-bit compileren, hoewel het niet voor alle applicaties echt nuttig is. Win32 applicaties voor 32-bit compileren is nog steeds praktisch want dan werkt het op alle systemen.

De Win32 api is 64 bit op een 64 bit Windows versie. Een integer is op een 64 bit Windows 2x zo groot als op een 32 bit Windows.

[Reactie gewijzigd door Sannr2 op 30 juni 2021 12:06]

Wat je hier zegt klopt niet, een signed int32 op een Windows 32 bit systeem is maximaal 2,147,483,647 en een signed int64- of long is 9,223,372,036,854,775,807

Signed betekend hier dat het getal ook negatieve waardes ondersteund. Een unsigned int32 kan namelijk 2x hoger dan signed alleen die kan geen negatieve waardes representeren. (uint32 kan maximaal t/m 4,294,967,295)

Dus 64bit is een stuk meer dan 2x 32bit we hebben het hier over bits dus 64 is idd 2x 32 maar dit werkt niet helemaal als 2x als je het omzet naar nummers.

Als voorbeeld een 8 bit integer is alsvlogt opgebouwt: https://ars.els-cdn.com/c...-f04-08-9780128033401.jpg

De grote van een integer en de waarde van een integer zijn 2 verschillende dingen.

het is zowiezo een beetje ambiguous, want een `integer` als we daarmee `int` bedoelen verandert niet van grootte tussen x86 en x64, die blijft 4 bytes groot op MSVC (en meeste andere compilers) tegenwoordig..
"al is dit niet guaranteed!!! In de toekomst kan een int vrij van grootte tussen 2 en N bytes veranderen"

wat verandert is de native word size, size_t en pointers veranderen in grootte.

Om dat te voorkomen kun je types als int8_t, int16_t, uint32_t enzovoorts gebruiken. Talen als Go, C# enzovoorts hebben ook dit soort definities.
Het is niet zo'n goed idee om voor alles "int" te kiezen, omdat die verschillend gedefinieerd kunnen zijn in verschillende compilers en voor verschillende platformen.

Ik weet prima hoe integers en floats opgeslagen worden. Maar op een 64 bit systeem kan je in een signed 32 bit integer meer opslaan dan dat 32 bit maximum. Probeer het maar eens als je het niet gelooft, tel 2 32bit signed ints op en zet het resultaat in een signed int, waarbij het resultaat voorbij die max gaat, en zet het om naar een string. Werkt gewoon zonder dat je int64 gebruikt, ook in een 32 bit applicatie. Op 64 bit Windows wordt altijd 64 bit ruimte gereserveerd. Zal een praktische reden qua adressering hebben denk ik.

[Reactie gewijzigd door Sannr2 op 30 juni 2021 16:31]

Ik verwacht zeker dat je niet gek bent. Alhoevel dit behoorlijk off-topic begint te worden heb ik het toch even geprobeerd in de taal waar ik full-time mee werk C#

Int32 x = int.MaxValue;
Int32 y = int.MaxValue;
Int32 z = x + y;

Console.WriteLine($"X: {x}");
Console.WriteLine($"Y: {y}");
Console.WriteLine($"Z: {z}");

Result:

X: 2147483647
Y: 2147483647
Z: -2

Dus ik krijg niet echt het juiste resultaat vergeleken wat jij voorsteld maar oke ik wilde alleen dit nog even delen want we gaan lekker off-topic xD

En als je gewoon integer gebruikt ipv int32 en dan compileert naar een 32 bit exe?

Ik kwam het tegen in een Delphi applicatie die de eerste twee cijfers van een dergelijk getal gebruikte als laatste twee cijfers van het jaartal en de volgende twee als weeknummer, ging goed tot 2021 week 47 (2147….) maar onder 64 bit OS bleef het goed gaan ook boven de int32 max, was lastig debuggen dus tot ik me realiseerde dat het niet zou moeten passen…

De meeste 64 bits versies van Windows bieden de WIn32 API nog steeds aan in beide smaken, 32 en 64 bits. Dat moet ook wel; veel installers zijn nog 32 bits ook al is de geinstalleerde applicatie zelf 64 bits.

Een integertype is doorgaans een zaak van de compiler, niet het OS, maar in <windows.h> is het type DWORD gewoon 32 bits gebleven, ook na de overstap naar 64 bits. Pointer types zoals PVOID zijn wel 64 bits geworden.

Beetje jammer, want de kracht zou juist zijn van zo'n store dat je al je apps up to date houd...

Met zulke opmerkingen komen we weer in de vicieuze circel. Eerst willen we dat apps in de store komen, dan komen ze er maar moeten ze zelf zaken regelen en dan is het weer niet goed.

Als men een app heeft die ze automatisch willen laten updaten, dan kunnen ze ook wel bedenken dat ze geen win32 app in de afgelopen jaren hebben moeten bouwen

Het hele voordeel van een appstore is juist dat je één plek hebt én één proces hebt die apps kan installeren en kan updaten

Toen MS kwam met de bewering dat win11 met een nieuwe store kwam voor alle apps dacht ik meteen aan winget en de Vijandige overname ervan

Technisch gezien had ms niet eens zozeer de updates hoeven regelen maar enkel een update definitie-bestand met de update info zoals compatibiliteit, versie, update url, en file check informatie en eventueel de licentievereisten

De daadwerkelijke updates kunnen prima op een externe server staan binnen azure of elders

Het we willen één store ging niet over de overzichtelijkheid van de bestaande apps
(Iedereen kan gratis office voor Windows, 5 beste zip programma’s of free video editor googelen)
maar over de stroomlijning en veiligheid van het update proces daar gaat hrt steevast de mist in

Vooral omdat bijna alle software doorgaans zonder admin rechten draait en zichzelf dus niet kunnen afsluiten, updaten en weer opstarten. Je merkt dat bijv bij libreoffice, qbittorrent en vlc heel erg

[Reactie gewijzigd door i-chat op 30 juni 2021 13:21]

Ook ik moest denken aan winget (de nieuwe windows package manager). Deze zou perfect kunnen integreren met store apps en op die wijze automatisch in de achtergrond de software up-to-date kunnen houden. Tot die tijd doe ik het dan maar zelf:

winget upgrade --all

Als men een app heeft die ze automatisch willen laten updaten, dan kunnen ze ook wel bedenken dat ze geen win32 app in de afgelopen jaren hebben moeten bouwen

Als je cross-platform wilt ontwikkelen en daarom bijvoorbeeld Qt gebruikt, is dat dan een Win32 applicatie? Want daar wil je geen update inbouwen, dat zou op Linux niet logisch zijn omdat je daar een package manager voor hebt.

Even lost van het feit of het nu wel of niet een Win32 applicatie is (volgens mij wel overigens), je vergelijking met Linux gaat sowieso niet op. Crossplatform applicaties leveren nu ook al in de meeste gevallen de libraries mee met de windows installer aangezien Windows geen package manager kent zoals Linux. Het update process werkt sowieso al anders.

aangezien Windows geen package manager kent zoals Linux.

Chocolatey, Ninite, Nuget, ...

"Ja, maar dat zit niet standaard in Windows!"

Niet elke Linux distributie heeft een package manager, en er zijn package managers die aan bestaande distributies toegevoegd kunnen worden.

[Reactie gewijzigd door The Zep Man op 30 juni 2021 13:06]

Sorry maar dat is weinig relevant in de context van de reactie die ik gaf. Windows kent zelf geen package manager dus worden historisch gezien Win32 applicaties met alle dependencies meegeleverd en is de hele OS structuur ook niet ingericht op het principe van gedeelde libraries. Dus of een applicatie gemaakt is met behulp van Qt is voor windows niet heel relevant en dat is waar ik op reageerde.

Niet elke Linux distributie heeft een package manager, en er zijn package managers die aan bestaande distributies toegevoegd kunnen worden.

Klopt, onderliggend is de OS structuur wel grotendeels hetzelfde met hoe libraries tussen applicaties worden gedeeld.

Dat ook, maar daarnaast heb je ook Flatpaks en AppImages die je los kunt draaien. (en een aantal andere minder populaire pakketbeheerloze formaten)

Niet elke Linux distributie heeft een package manager...

Heb je van dat deel van je uitspraak ook een voorbeeld? Ik ken geen enkele Linuxdistro zonder package manager

Oh ze bestaan wel, sterker nog in de ontwikkeling van Linux zijn package managers en latere ontwikkeling. Ze zijn dan ook ontstaan vanuit de zogenaamde "dependency hell" aangezien applicaties onder linux de libraries delen (in tegenstelling tot windows waar applicaties ze vaak meeleveren) waar bij handmatige installaties je eerst moest zorgen dat alle packages goed stonden, de juist versie hadden en geen conflict opleverde met andere applicaties die weer een net iets andere versie van de librarie verwachtten.

Package managers in de meest basale vorm automatiseren deze taak waardoor je daar geen omkijken meer naar hebt. Ik weet zo uit mijn hoofd geen recente distros die helemaal geen vorm van packagemangament aan boord hebben maar historisch gezien was slackware er bijvoorbeeld één.

Het is verder overigens geen argument op de eerdere reactie die ik gaf aangezien Linux in de basis al een andere structuur kent en conventies dan Windows.

[Reactie gewijzigd door Creesch op 30 juni 2021 13:23]

Elke Linux distro komt met een package manager. Diversen zelfs. Dat applicaties onder windows zich zelf gaan updaten is waanzinnig slecht vanuit security oogpunt (meer aanvalsoppervlak)

[Reactie gewijzigd door souplost op 30 juni 2021 23:57]

Sterker nog: Windows is zelfs een uitzondering daarop, want o.a. de meeste Linux-distro's, BSD, Haiku en AmigaOS 4 hebben pakketbeheer.

Niet echt relevant voor het argument wat ik maak

Hoeft ook niet, ik vulde je alleen maar goedbedoeld aan

Wat is dan een beter alternatief? Want een andere methode van MS lijkt me geen goed idee, mede door het gezwalk van het hele Windows Phone debacle en het steeds weer laten vallen van oude frameworks en oude software. Win32 is juist vanuit een wat naïef perspectief een goede keuze als je kijkt naar waar de bestaande Windows software uit bestaat en wat het meest waarschijnlijk is om de komende 10-20 jaar te overleven. Want het lijkt mij mijns inziens duidelijk dat MS met het hele Metro/MS Store op een soort Apple imitatie achtige power trip bezig is, terwijl de nood voor verbetering hoog is én de stappen die worden gezet maar erg langzaam gaan. Een betrouwbare optie om vanuit het OS om programma's automatisch te updaten had al minstens 10 jaar in Windows moeten zitten.

En win32 had al 10 jaar niet meer in windows hoeven zitten Microsoft heeft zat alternatieven om tegenwoordig een app te bouwen, zelfs crossplatform.

Probleem blijft dat microsoft win32 support wilt blijven houden voor obscure oude bedrijfsapplicaties (en photoshop ).

Met zulke opmerkingen komen we weer in de vicieuze circel. Eerst willen we dat apps in de store komen, dan komen ze er maar moeten ze zelf zaken regelen en dan is het weer niet goed.

Die volgordelijkheid zie ik niet. Vraag je af: Waarom zou je een programma in een winkel willen hebben? Het is een vorm van centraliseren, waarbij je dus -bij de winkels tot nu toe- ook updates centraal geregeld hebt. Maar helaas, dat mag dan weer niet. Waarom is dat?

Ik zie het als na lang zeuren ein-de-lijk je ijsje krijgen, maar je mag hem niet opeten. En vervolgens worden ze nog boos ook omdat het 'weer niet goed is' !

Als men een app heeft die ze automatisch willen laten updaten, dan kunnen ze ook wel bedenken dat ze geen win32 app in de afgelopen jaren hebben moeten bouwen

Win32 is nog behoorlijk populair. UWP applicaties kunnen alleen maar via de Microsoft Store gedistribueerd worden, en daarnaast is er 25 jaar aan code op Win32 gebaseerd.

Het fijne van applicaties in een app store zou juist de consistentie zijn. Als iedere applicatie z'n eigen update methode moet leveren dan is dat al een stuk minder consistent. Wel is het zo dat sommige apps niet bedoelt zijn om altijd te updaten. Dan is het wel fijn om voor die apps een eigen update methode te hebben, maar voor de meeste apps was het prima geweest.

[Reactie gewijzigd door Wolfos op 30 juni 2021 14:17]

Precies, in de eerdere aankondiging klonk het alsof het een soort package manager zou worden, zoals de meeste Linux distributies hebben, die handig al je software up-to-date houdt.

Dat is de package functie die los in Windows komt die staat helemaal los van de store.

Dat is de Store ook, maar daarvoor moeten ontwikkelaars hun apps ook in een package steken. Maar ontwikkelaars krijgen ook de optie om een headless installatie die voor de rest volledig hetzelfde is van een manuele installatie te verrichten.

Ik heb het artikel nu drie keer gelezen maar het spreekt zichzelf een paar keer tegen…

Klopt mijns inziens anders als een bus, hoor.
- win32 app update kan enkel nog via app zelf
- win32 app versie in store zelf kan worden geupdate
- MS Store stapt er dus tussen uit voor updates (fungeert niet meer als update-platform, enkel nog als download-platform)

Nee dus, de huidige manier (packaged Win32 apps zoals bijv Spotify) blijft gewoon werken. Je kunt straks echter ook 'normale' win32 apps in de store plaatsen, maar dan moet je zelf een updatemechanisme inbouwen.

Kijk, dat is duidelijk!

Wat een vreemde keuze. Ik heb Race Control juist in de Microsoft Store gezet zodat updates automatisch bij gebruikers worden geïnstalleerd. Als dat niet meer werkt dan is de meerwaarde van de Store ook niet groot meer.

Het automatisch updaten werkt wel voor WPF apps. Momenteel kun je in de Store geen Win32 apps uploaden, dus ik neem aan dat jouw app een WPF app is?

WPF apps zijn ook Win32 apps.
Zie Loller1 in 'nieuws: Vernieuwde Microsoft Store gaat Win32-apps niet updaten'

Win32 apps kunnen wel degelijk nog gewoon via de Microsoft Store updaten. Alleen unpackaged Win32 apps kunnen dat niet.

Dit is toch heel makkelijk op te lossen door een update knop in de Win32 app in te bouwen? Zoals we dus al jaren gewend zijn?
De Microsoft Store is een draak van een applicatie, met name het overzicht en beheer van updates van apps is gigantisch slecht. Vaak haalt mijn systeem de update 4x binnen voordat er 1x geinstalleerd wordt, en waar nou precies het verschil zit tussen "updates downloaden" en "software bijwerken" snap ik niet...

Update knop in de applicatie zelf, of automatsche check bij opstart van de app is inderdaad handig. Maar dan moet dus iedere dev dat zelf uitwerken.
Update check door apart process, zoals bvb Chrome dat doet, vind ik idioot. Heb je tientallen processen lopen enkel om de apps up-to-date te houden.
Ik ben van mening dat het OS dat in 2021 wel voor zich mag nemen.
Als de Store dat dan niet meer doet, vind ik dat vrij flauw.

Update knop in de applicatie zelf, of automatsche check bij opstart van de app is inderdaad handig

Ik vind dat super onhandig. Ik gebruik bijvoorbeeld Notepad++ maar een paar keer per jaar. Dat betekent dat Notepad++ grofweg 525000 minuten per jaar heeft waarin het zou kunnen updaten zonder dat ik er last van heb. Toch biedt Notepad++ pas aan om te updaten als het me niet uitkomt, namelijk als ik het opstart om te gebruiken.
Een eigen proces voor ieder programma is inderdaad ook absurd. Daarom is dit naar mijn mening typisch iets dat geconsolideerd moet worden, bijvoorbeeld in het OS of een package manager of een app store.

Toch biedt Notepad++ pas aan om te updaten als het me niet uitkomt, namelijk als ik het opstart om te gebruiken.

Andersom kan je het ook zien natuurlijk, die 525000 minuten per jaar wil je niet dat een applicatie die je toch nauwelijk gebruikt regelmatig naar updates zoekt en resources gebruikt (bandbreedte, cpu, etc) met dat updaten terwijl je feitelijk alleen de update nodig hebt als je de applicatie gaat gebruiken. Ik heb wel vaker ervaren dat update processen in de achtergrond zaken waar ik actief mee bezig ben vertragen.

Het alternatief is wat je bij Linux veel ziet is dat je er actief op gewezen wordt en zelf het update moment kiest. Waar ook weer nadelen aan zitten want dan wordt je er dus vaker op gewezen dat er updates zijn dan dat je de applicatie daadwerkelijk gebruikt.

Ik ben ik het niet geheel met je oneens maar er zitten wel meerdere kanten aan het verhaal wat mij betreft.

met dat updaten terwijl je feitelijk alleen de update nodig hebt als je de applicatie gaat gebruiken.

Klopt, dat is de reden dat ik bijvoorbeeld Netflix op mijn iPhone 'offload' als mijn abonnement beëindigt is. Tegen de tijd dat ik weer een abonnement neem is de app al tien keer geüpdate, allemaal updates die ik zou downloaden en installeren zonder ze ooit te gebruiken.

Waar ook weer nadelen aan zitten want dan wordt je er dus vaker op gewezen dat er updates zijn dan dat je de applicatie daadwerkelijk gebruikt.

Als je aan hebt staan dat je er op gewezen wordt, dan gaat het meestal ook om veiligheidsupdates. Die wil je toch altijd up to date hebben.

Nu neem je wel voor het gemak aan dat de Windows Store daadwerkelijk goed update op de achtergrond, maar ook dat loopt voor geen meter. Ik draai bijvoorbeeld de UWP versie van Spotify, maar loopt geregeld enkele versies achter terwijl ik mijn laptop dagelijks 7 tot 8 uur gebruik en het proces dus meer dan voldoende tijd heeft om op de achtergrond alles bij te werken.

Een app store krijg ik sowieso kriebels van; gesloten ecosysteem en gedwongen updates. Slechte ervaringen mee op mijn iPad en Samsung Galaxy S10 (al kan ik daar nog terug naar de fabrieksversie van sommige apps, wat mijn Android Auto al een paar keer weer bruikbaar gemaakt heeft na een verkeerde update vanuit Google). Geef mij maar zelf de controle, als het dan stuk gaat heb ik het in ieder geval nog zelf gedaan.

Een app store krijg ik sowieso kriebels van; gesloten ecosysteem en gedwongen updates.

Dat zijn jouw associaties. Bij Ubuntu is de app store optioneel. Of de updates te weigeren zijn weet ik niet, dat is een vraag die ik me werkelijk nog nooit heb hoeven stellen. Van de meeste updates merk ik niets, als ik al iets merk is dat vaak een verbetering.

(al kan ik daar nog terug naar de fabrieksversie van sommige apps, wat mijn Android Auto al een paar keer weer bruikbaar gemaakt heeft na een verkeerde update vanuit Google)

offtopic:
Dan heb je mazzel, op mijn telefoon (Nokia, Android One) is de fabrieksversie volgens mij een dummybestand.

Inderdaad een goed punt, ik vind eigenlijk het updaten bij het opstarten ook wel vervelend.
Zoals je zegt: liefst geconsolideerd in het OS of een package manager. Ik gebruik meestal Chocolatey, maar niet alles zit daarin.

Dit is toch heel makkelijk op te lossen door een update knop in de Win32 app in te bouwen? Zoals we dus al jaren gewend zijn?

Nee, niet makkelijk Permissie-probleem, de Win32 app draait naar alle waarschijnlijkheid met user-permissies en niet met admin-permissies. Je moet een UAC-elevated proces starten.

Nee, niet makkelijk Permissie-probleem, de Win32 app draait naar alle waarschijnlijkheid met user-permissies en niet met admin-permissies. Je moet een UAC-elevated proces starten.

Of de installatie moet naast de app ook een service neer zetten die onder verhoogde permissies draait en die de updates kan uitvoeren. Maar dat is ook niet zaligmakend, want die dingen zijn vaak zo lek als een vergiet en staan continu op je systeem 'beschikbaar' als ze eenmaal geinstalleerd zijn.

en waar nou precies het verschil zit tussen "updates downloaden" en "software bijwerken" snap ik niet...

Updates downloaden is precies wat het inhoud. Je OS download dan alle beschikbare updates naar je disk maar doet er verder niks mee. Pas als je op "Software bijwerken" klikt gaat je OS wat doen met de eerder gedownloadde data.

Tenminste, zo is het onder Fedora. Ik neem aan dat Windows niet veel verschilt, gezien de benamingen.

In de Store binnen Windows verschijnen en verdwijnen de knoppen naar mate er zaken beschikbaar zijn, maar consistent is het allerminst. Als ik de Store open en naar "Downloads en Updates" ga staat daar doorgaans een knop "Updates downloaden." Als ik daar op druk gaat het systeem op zoek naar updates voor applicaties en haalt deze binnen, maar vaker wel dan niet zie ik na dit update-process bij de "Recente activiteit" geen correcte weergave van deze updates en verschijnt er daarna een knop "Alles bijwerken" die vervolgens wéér updates binnen gaat halen en installeren. Ogenschijnlijk dus exact dezelfde handeling.

EDIT: De Store geeft bij beide handelingen weer dat niet alleen de updates voor de applicaties gedownload worden, maar ook dat deze geïnstalleerd worden.

[Reactie gewijzigd door Koen88 op 30 juni 2021 15:15]

Nouja, makkelijk? Zit nog wel wat achter qua proces. En voor de gebruiker was het ook lekker consistent geweest om applicaties ook te updaten via de store. Nu heb je er niet zo gek veel aan.

Microsoft laat aan ontwikkelaars weten dat gebruikers via de vernieuwde Microsoft Store geen updates kunnen ontvangen voor Win32-apps.

Maar waarom niet? Is er een technische reden voor of is het politiek?

Ik vind het eigenlijk best onverantwoord om wel de mogelijkheid te geven om software te installeren maar updates via diezelfde route niet toe te staan. Als je kan installeren dan kan ik geen goede reden bedenken waarom updates niet mogelijk zouden zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 30 juni 2021 12:14]

Zal wel technisch zijn. Iedere Win32 app is vaak op een andere manier gebouwd en heeft vaak een eigen update mechanisme.

MSFT ziet liever iedereen naar UWP gaan uiteraard, maar win32 apps zijn gewoon legacy en niet erg geschikt om via een centrale store te updaten. Veel Win32 apps kun je zelfs niet eens updaten zonder eerst de oude versie weg te halen.

MSFT ziet liever iedereen naar UWP gaan uiteraard, maar win32 apps zijn gewoon legacy en niet erg geschikt om via een centrale store te updaten.

Win64 apps dan wel?
Win32 is overigens niet legacy.

Veel Win32 apps kun je zelfs niet eens updaten zonder eerst de oude versie weg te halen.

Onzin, de meesten zijn prima te updaten. En zo niet, dan is dat nog geen reden om het uit de store te bannen.

Win32app is een algemene benaming voor legacy Windows apps. 32/64 bit apps. Bijv geinstalleerd met MSI of allerlei andere installers (Nullsoft, Installshield etc). Dat maakt het ook zo lastig om die centraal te updaten omdat ze allemaal op een andere manier worden geinstalleerd. Maar met MSI bijv zou het zeker kunnen. Op linux doen ze hetzelfde bijv op debian maken ze gewoon een .DEB package. Met Windows zou je ook gewoon een MSI package kunnen maken van iedere app en die updaten.

Dus ja het kan zeker, alles kan alleen het vereist een bepaalde inspanning. En aangezien win32 apps als legacy worden gezien wil men die inspanning niet meer doen.

Zal wel technisch zijn. Iedere Win32 app is vaak op een andere manier gebouwd en heeft vaak een eigen update mechanisme.

MSFT ziet liever iedereen naar UWP gaan uiteraard, maar win32 apps zijn gewoon legacy en niet erg geschikt om via een centrale store te updaten. Veel Win32 apps kun je zelfs niet eens updaten zonder eerst de oude versie weg te halen.

Ik ben vast verschikkelijk naief, maar het proces kan toch zo simpel zijn als "Download deze .exe en voer die uit"? Ik vind het geen mooi proces (ik ben meer van de Debian packages) maar het lijkt me niet te veel gevraagd als je dan toch een appstore voor Windows bouwt. Ik snap ook dat er nog steeds medewerking van de leverancier nodig is, maar dat is bij updates altijd zo.

Ik had het beter begrepen als ze het ook niet mogelijk was om dit soort software te installeren via de Microsoft Store, zelfs als dat een "politieke" keuze was om geen legacy te ondersteunen. Ik verwacht ook niet dat dpgk of prm een tarbal kan installeren. Maar als je wel kan installeren maar niet updaten dan snap ik het niet.

[Reactie gewijzigd door CAPSLOCK2000 op 30 juni 2021 13:08]

Je hoeft als store maar weinig te doen om centraal auto update mogelijk te maken

1 software signing (werkt al)
2 een Windows store portal voor publicatie
3 en manier om een centrale wachdogg service te laten weten dat er updates zijn
4 voldoende informatie om die update op de juiste manier en via de juiste verbinding [ niet onderweg via 4g] te updaten

Het is juist software als steam kan het wel maar bij ms wil het maar niet lukken

Het wordt een beetje een vlees nog vis scenario met de Windows store. Je hebt dadelijk zoveel verschillende opties naast elkaar draaien dat de ervaring van het downloaden van een applicatie per stuk gaat verschillen.

Verschillen in hoe ze updaten, hoe je moet betalen, welke voorwaarden je moet accepteren, welke restricties er zijn in het OS en nog vast nog veel meer.

Ik snap dat Microsoft iets moet proberen (hun huidige aanpak werkt niet) maar om nu te zeggen dat ik enthousiast wordt van de nieuwe manier, dat is ook niet het geval.

Uhmm, win32 apps in de huidige store kunnen automatisch geupdate worden via de store. Wordt dit er nu bewust uitgesloopt? Redenatie?

Unpackaged win32 apps in de huidige store? Waar

Uhmm, win32 apps in de huidige store kunnen automatisch geupdate worden via de store. Wordt dit er nu bewust uitgesloopt? Redenatie?

Dat zijn kennelijk een ander soort win32 apps. Die zijn speciaal geconverteerd naar een soort van packaged formaat, wat aan bepaalde eisen moet voldoen. Dit maakt o.a. updates vanuit de store ook mogelijk.

Wat MS nu gaat doen is ook unpackaged - kale - win32 apps in de store toelaten. Feitelijk gewoon de bestaande installer van een app, die silent/headless op de achtergrond gedraaid wordt met default instellingen.

Grote vergissing, denk ik persoonlijk. Situatie zal er enkel minder transparant en duidelijk voor eindgebruikers door worden. Daarnaast: een boel bestaande win32 apps wil je niet eens met default instellingen installeren.

[Reactie gewijzigd door R4gnax op 30 juni 2021 13:15]

En dit vind ik nou een teleurstelling