Microsoft wil helpen zakelijke apps compatibel te maken met Windows 10 - update

Microsoft heeft zijn Desktop App Assure-programma gestart. Daarmee kunnen Enterprise-klanten met 150 licenties of meer zonder extra kosten een Microsoft-technicus laten meehelpen om bedrijfsapplicaties compatibel te maken met Windows 10.

Microsoft wil hiermee zo veel mogelijk zakelijke gebruikers over de streep trekken naar Windows 10. Het Redmondse bedrijf stelt dat 99 procent van de applicaties al compatibel zijn met Windows 10 en Office 365 ProPlus en dat het toegewijd is aan die laatste 1 procent. Microsoft stelt dat het zelfs bereid is om aanpassingen aan Windows 10 zelf te maken als dat nodig is.

Een voorwaarde voor ondersteuning is wel dat de applicatie bedoeld is om te werken op een ondersteunde versie van Windows 10. De dienst wordt ook aangeboden voor applicaties, macro's en add-ins voor Office 365 ProPlus.

De dienst is nu beschikbaar in tien talen: Engels, Italiaans, Duits, Spaans, Frans, Japans, Koreaans, Portugees en versimpeld en traditioneel Chinees. Tweakers heeft Microsoft gevraagd of Nederlands in de toekomst ook ondersteund wordt in het kader van dit programma en op wat voor termijn ondersteuning verwacht kan worden. Ook heeft Tweakers geïnformeerd naar de tarieven voor afnemers met minder dan 150 licenties. Het bedrijf heeft nog niet geantwoord. Microsoft kondigde de dienst in 2018 aan.

Update, 14:55: Microsoft laat weten dat er vooralsnog geen plannen zijn om deze dienst uit te breiden naar Nederlandstalige bedrijven en applicaties.

Reacties (47)

Microsoft wil hiermee zo veel mogelijk zakelijke gebruikers over de streep trekken naar Windows 10. Het Redmondse bedrijf dat 99 procent van de applicaties al compatibel zijn met Windows 10 en Office 365 ProPlus en dat het toegewijd is aan die laatste 1 procent.

Zolang Windows 10 Win32 applicaties ondersteunt zal het wel werken. Die laatste 1% klinkt als echt oud spul. Denk aan Win9x 32-bit applicaties of zelfs 16-bit applicaties.

Mits je Windows-applicatie 20 jaar geleden goed was geprogrammeerd en het zich houdt aan de toen geldende best programming practices zou het vandaag gewoon nog moeten werken.

De dienst wordt ook aangeboden voor applicaties, macro's en add-ins voor Office 365 ProPlus

Het zal dus voornamelijk legacy Office add-ins zijn.

[Reactie gewijzigd door The Zep Man op 4 februari 2019 12:15]

32-bit is dan ook gewoon sneller dan 64-bit applicaties in aardig veel gevallen.

Ik hoop eigenlijk wel dat er een Windows versie komt zonder WoW64 en dus native 64-bit.

[Reactie gewijzigd door MrFax op 4 februari 2019 17:09]

Veel verschil zal er niet zijn. Er zijn ook niet veel redenen waarom een 32bit versie sneller zou zijn dan een 64bit versie. En Wow64 is zo iets dat als je het niet gebruikt het ook geen invloed heeft. Als je heel je OS voorziet van alleen maar 64bit apps dan komt die vertaallaag op geen enkel moment tussen.

Maar het is wel een extra aanvalsvector voor kwaadwillende en een extra kostenpost kwa ondersteuning..

WoW64 (Windows on Win64) is toch juist enkel voor de 32-bit applicaties?
x64 (x86-64) Windows is dan toch juist al 'native' 64-bit?

Inderdaad, de WoW64 laag is er om de 32bit Win32 APIs te mappen op de 64bit zoals in het OS aanwezig. Elke 64bit windows heeft twee sets aan Win32 bibliotheken, maar slechts één kernel welke 64bit is. Roep je dus kernel functies of andere functies aan die laag genoeg zitten in de OS stack, ga je door de WoW64 heen met een kleine overhead. Denk aan het benaderen van het register of een geheugen allocatie doen.

De overhead is minimaal. Snelheidsverschillen tussen 32 en 64bit zitten vooral in zaken als dat 32bit code kleiner is en dus minder geheugen en processor cache ruimte gebruikt, plus iets sneller van disk leest. Nadelen is dat je bepaalde moderne instructies niet of moeilijker kunt gebruiken in 32 bit mode.

Een andere factor is dat Intel en AMD processoren vrijwel geen verschil hebben in het uitvoeren van de oude x86 vs nieuwe AMD64 instructies. Dat is bij ARM processoren soms niet het geval, waar ARM64 soms sneller is dan ARM32. Kwestie van prioriteren waar je je transistor budget aan besteed.

Snelheid zal geen probleem zijn omdat het gaat om oudere applicaties. Die zijn ontworpen voor langzamere hardware en zullen ook geen last hebben van het kleine stukje overhead.

Huh? Windows is native 64-bit. Alleen de Windows 32-bit applicaties (die geschreven zijn voor de Windows API en niet de .net) zijn iets trager omdat de 32-bit API een vertaling doet naar en van 64-bit.

Dus bijvoorbeeld:
Int32 APIcall32bit(struc32bit variabele) {
Var64= convertstruc32(variabele);
Varint64= APIcall64bit(Var64);
Return (varint64 && 0xFFFFFFFF);
}

Nee. Ik bedoelde dat 32-bit applicaties in veel gevallen juist wel sneller zijn dan 64-bit applicaties.

Dit heeft vooral te maken met de compilers en hoe je code is opgebouwt. Dit komt omdat (bijvoorbeeld) in veel gevallen 32-bit integers sneller uitgevoerd worden dan 64-bit integers, omdat je met kleinere adressen werkt. Ik meen me te herinneren dat een 32-bit console emulator(weet niet meer welke) bijna 1.5x zo snel was als de 64-bit editie, maar dit is dus heel specifiek. Dit is dus bijvoorbeeld zo met C#.

Mijn andere reactie was dat ik een Windows versie zou willen zien zonder WoW64, en dus native 64-bit, want dit zou bepaalde performance overheads weg kunnen halen. Zelfs veel systeem-componenten in Windows 10 zijn nog steeds 32-bit, zoals bijvoorbeeld OneDrive.

[Reactie gewijzigd door MrFax op 5 februari 2019 06:49]

Zelfs veel systeem-componenten in Windows 10 zijn nog steeds 32-bit, zoals bijvoorbeeld OneDrive.

Microsofts commerciële belangen hebben nog altijd voorrang boven de technische. Microsoft is al een tijdje OneDrive aan het pushen maar toen het gemaakt werd was het waarschijnlijk sneller om te ontwikkelen op 32-bits of, men wilde ook de 32-bits systemen over zetten naar OneDrive. Commercie dus.

Het zou me niets verbazen als hetzelfde geldt voor de Store app.

Ik hoop eigenlijk wel dat er een Windows versie komt zonder WoW64 en dus native 64-bit.

64-bit is toch gewoon native?

De standaard versie van Windows 10 IS 64bit, je moet juist apart de 32-bit versie draaien als je puur alleen 32-bit wilt. De wow64 map is juist voor 32bit 'legacy'. En als de applicatie zelf geen 64bit adressering nodig heeft, is het nut van 64bit helemaal niet interessant, het is niet alsof 64bit beter is dan 32bit, handiger wel als je grotere geheugenblokken als maximaal met 32bit kan aangesproken moet worden.
overigens is de doorsnee Windows 10 UWS app gewoon 64bit native hoor.

Die is er al op de server core:

https://docs.microsoft.co...l-feature-for-server-core

Maar voor de desktop is dat vrij zinloos, heel veel apps zijn nog 32-bit, vooral veel office addins. Met 64-bit only zou je al snel tegen beperkingen aanlopen.

Het is eerder andersom omdat je meer registers hebt bij x86_64. 32-bit pointer zijn alleen kleiner.

_{32-bit is dan ook gewoon sneller dan 64-bit applicaties in aardig veel gevallen. Ik hoop eigenlijk wel dat er een Windows versie komt zonder WoW64 en dus native 64-bit.}

Die is er . . . Neem gewoon Windows 10, 32-bits oftewel x86.

[Reactie gewijzigd door XeNoN62 op 4 februari 2019 12:20]

Dat is dus niet 64 bit maar 32 bit, precies niet wat @MrFax bedoelt

Mits je Windows-applicatie 20 jaar geleden goed was geprogrammeerd en het zich houdt aan de toen geldende best programming practices zou het vandaag gewoon nog moeten werken.

Dat is wel een vrij grote mits die in de praktijk lang niet altijd zal uitkomen. Zelfs applicaties die grotendeels netjes in elkaar zijn gezet kunnen her en der toch nog van die zaken hebben waardoor het onder windows10 net eventjes wat minder lekker werkt of minder betrouwbaar.

De zakelijke wereld is qua intern gebruikte applicaties sowieso soms wel enigszins apart te noemen in deze context.

en zelfs een diet total onjuist is;
zeker op gebied van offie addin's zal je aanpassingen moeten maken
omdat de office ap's veranderd zijn en veel opmaak objecten.
een macro van 20jaar geleden dus pre of rond office 97 dat met grafieken werkt zal niet werken omdat die naamgevingen veranderd zijn.
dus ook al volgde je mooi de regels , als de API van naam veranderd of een andere uitwerking kreeg, moest je je code aanpassen
er zijn zo 2 office aanpassingen geweest waarna het noodzakelijk je code aan te passen.
De eerst had vooral effect op kleuren, 2 2e was keiharde API change

Het is meer dan alleen 32 of 64-bit. Denk b.v. aan applicaties die er gewoon van uit gaan dat ze met admin privileges draaien. Kwam er laatst weer eentje tegen, een app gebouwd in een of andere crappy RAD tool, voor een hele specifieke doelgroep. De vraag is of er uberhaupt nog iemand aan die software werkt, waarschijnlijk niet.

16-bits applicaties werkten ook niet op 64-bit Vista (of XP, voor de paar die XP64 hadden).

Voor zover ik weet werken ze wel op Windows 10 32-bit.

Nou, je kunt je nog zo goed aan de programming practices houden, als MS iets 'verneukt' met betrekking tot security verbetering (zoals sinds de laatste patchronde van vorige maand bij bepaalde DLL's waarmee je connectie kunt leggen met ADO 3.6 en hoger een oudere Access95 database ineens geen tabellen meer kan lezen indien er een veldnaam wordt gebruikt langer dan 32 characters) dan ben je toch weer de pineut. Al vaker meegemaakt dat MS toch net iets gewijzigd had in oude DLL's waardoor de werking niet meer gelijk was en daardoor de boel ineens niet meer werkte.

Zolang Windows 10 Win32 applicaties ondersteunt zal het wel werken. Die laatste 1% klinkt als echt oud spul. Denk aan Win9x 32-bit applicaties of zelfs 16-bit applicaties.

Heel veel applicaties, zowel uit het tijdperk van XP als ook ten tijde van Vista zijn zelf welliswaar 32-bits en kunnen dus prima werken, ook op een 64-bits machine, maar maken nog gebruik van een installer die slechts 16-bits is en lopen daarop vast. Dat geldt zelfs al voor de meeste Win9x applicaties. Er zijn zelfs applicaties uit het Win3.x tijdperk die volledig 32 bits zijn op de installer na.

Mits je Windows-applicatie 20 jaar geleden goed was geprogrammeerd en het zich houdt aan de toen geldende best programming practices zou het vandaag gewoon nog moeten werken.

Dat was tot de komst van Vista dus ongeveer 1 procent. Pas vanaf Vista begonnen softwaremakers het belang in te zien van Mricosofts 'best programming practices' die overigens niet gelijk liepen met die van de rest van de industrie omdat juist in die tijd Microsoft hun 'best programming practices' een paar keer heeft veranderd. Dingen die eerst afgekeurd werden, werden opeens 'best practice' maar vooral omgekeerd gebeurde dat een aantal keer.

Het zal dus voornamelijk legacy Office add-ins zijn.

Waar ze effectief hulp bij bieden bedoel je? Dat denk ik ook. Met andere software die problemen veroorzaakt wordt het al gauw een stuk lastiger, zeker i.v.m. ontbreken broncodes.

Ik vraag mij toch wel af wat voor programmatuur dat kan zijn, wat wel onder windows 7 (of zelfs vista) draait, maar niet onder windows 10. Vanuit de applicatie gezien is het allemaal toch niet zo héél verschillend? En zelfs al was het dat wel, dan heeft ook W10 weer de nodige lijsten aan compatibility settings....

Gaat het hier om programmatuur met custom drivers o.i.d.?

Nou in 8.1 en 10 hebben ze bijvoorbeeld heel veel rechten angepast op folders. Een tool die zijn data in zijn install directory opslaat werkt daardoor niet meer.

Meestal is het prima mogelijk om de uitvoerenden van deze applicatie dan schrijfrechten op die locatie te geven; uiteraard wel alleen onder gecontroleerde omstandigheden.
Lukt dat niet, of is het niet gewenst dan kun je altijd nog naar folder- (file-) of zelfs complete applicatie-virtualisatie kijken.

ja, natuurlijk, maar wel weer een 'wtf' moment en voor de doorsnee gebruikers niet zelfstandig op te lossen.
Door een Update.

Gewoon installeren buiten de Program Files folder en je omzeilt daarmee ook dat probleem. MS had toen ineens besloten om met redirects etc te gaan werken zonder daar de (doorsnee) developers van op de hoogte te brengen. Zelf zie ik het nut ook niet zo van wat men met de program folder heeft proberen te doen. Maargoed, ieder zo zijn eigen gedachte over wat wel/niet goed is.

Het is toch niet zo gek dat je geen schrijf rechten voor gewone gebruikers in de Program Files wil hebben? Dat lijkt me 1 van de eerste makkelijke doelwitten voor iedere malware persistance module.

Dat is natuurlijk sowieso geen best practice, al een hele lange tijd niet. Multi-user support in Windows gaat dan eigenlijk ook mank.

Windows 10 heeft nogal wat backwards compatibility legacy laten vallen.

En windows 10 probeert niet helemaal de Windows versie er voor mee te nemen. Waar vista drivers nog op win8 kunnen werken bv. Oudere drivers installeren is op 10 een stuk lastiger.

Corel Paradox 8.0 (jaja 20 jaar oud) deed het met de eerste versies van Windows 10 prima maar sinds de 1803 update weigert hij ineens te werken.

Paradox is wel ouder, en nu weer van Wordperfect, waarvan ik niet wist dat dat als bedrijf nog bestond

It was originally developed as a MS-DOS program by Ansa Software. Later, Borland bought Ansa Software and published the program as “Borland Paradox” for Windows platform in 1992. Corel Paradox was first released in 1997. It was later bundled with WordPerfect Office Suite. Currently the features of Paradox is included with the latest WordPerfect Office.

Er zijn wel meerdere willekeurige applicaties die ineens niet meer werken.
Wij hebben ook een applicatie gehad die foutmeldingen aan het geven was na Win10 upgrades.
Er werd waarschijnlijk iets in de registry aangepast waardoor een functie niet meer werkte.
Na het uitvoeren van een repair d.m.v. de setup bestanden functioneerde het weer.

Ik vermoed dat wanneer je de software installeert op een clean install van 1803 deze gewoon zal werken.

Wij hebben hier nog een aantal applicaties die gewoon niet werkend te krijgen zijn op Windows 10. Daarom draaien er in ons netwerk nog een aantal Windows 7 PC's. We zijn echter al wel bezig om een alternatief te vinden voor deze applicaties, zodat de Windows 7 PC's uit ons netwerk verwijderd kunnen worden.

Wellicht maar eens kijken of we hier gebruik van kunnen maken..

mogelijk dat jongens van https://www.cloudhouse.com/ iets voor jullie kunnen betekenen? Dit doen al jaren niets anders dan oudere applicaties geschikt maken voor nieuwe versies van Microsoft producten.

Ergens zullen zij minder blij zijn met het aangekondigde voornemen van Microsoft in dit nieuws bericht geloof ik.

Het zou zomaar kunnen dat Microsoft mensen die hen contacteren doorsturen naar een partner.

Ik vindt het woord apps met betrekking tot dit artikel nogal misleidend, het gaat gewoon om pc programma's en niet om dingen die op de telefoon draaien

App is natuurlijk gewoon een afkorting van applicatie. Zo noemen we een PC programma ook. Het is ook niet echt iets anders een app of een applicatie. Voorheen waren apps vooral simpele programma's die op telefoons draaien maar die zijn niet meer zo simpel en microsoft noemt applicaties nu zelf ook apps.

In de Novell tijd maakten we al een volume aan dat APPS heette. Dat is niet iets nieuws of unieks, hoor.

Ben benieuwd of ze dit ook doen voor interne bedrijfskritische applicaties doen. Zitten nog enkele PC's op W7 omdat ze applicatie niet binnen 10 kunnen draaien

Maar ik vraag me dan toch echt af waarom ze niet kunnen draaien, afhankelijkheid van specifieke custom (legacy) drivers? Meestal moet toch wel de vinger te leggen zijn op waarom het niet werkt.

Dit gaat dus een stapje verder dan compatibiliteitsmodus. Wel netjes dat Microsoft gaat meehelpen.

Misschien moeten ze eens gaan beginnen aan een W10 versie zonder troep.

Die is er toch?

Windows 10 Enterprise

Windows IOT is wat hij meer bedoelt. Hier, een kaal OS. Doe de rest zelf maar.

Mensen met gebrek aan empathie. Je inleven in een doorsnee gebruiker kan niet. Shit moet naar zijn wens aangepast worden of het is troep.

Dat je Windows ook de andere kant op kan customizen en naar wens kan aanpassen. Komt in zulke figuren ook niet op.

Wat een rare reactie. Je kan de mensen toch een keuze geven? Dus of je installeert een kaal OS of je kiest ervoor dat Windows het een en ander al regelt tijdens de installatie..

Over het algemeen zijn gebruikers niet goed genoeg geïnformeerd om daadwerkelijk die keuze te maken, zelfde als met updates. Mensen maakten de verkeerde keuze, dus zijn ze nu geforceerd, eigenlijk puur om mensen tegen hun eigenwijsheid te beschermen.