Windows 11 kan mappen delen met Windows Subsystem for Android

Het Windows Subsystem for Android krijgt een update die bestanden delen tussen Windows- en Android-apps mogelijk maakt. Daarnaast worden drag & drop en het delen van bestanden door middel van het klembord mogelijk.

Gebruikers kunnen na deze update alleen hun persoonlijke map delen, die de naam van de gebruikersaccount heeft en mappen als Documenten en Afbeeldingen bevat. Het delen is standaard ingeschakeld voor gebruikers van de preview van deze Android-functionaliteit. Wel moeten Android-apps toestemming hebben om in mappen van het systeem te grasduinen, zoals ze dat in Android op telefoons ook moeten hebben. De gedeelde mappen verschijnen onder /sdcard/Windows/.

Daarnaast is het mogelijk om een bestand naar een Android-app toe te slepen, oftewel drag & drop. Dat kan bij apps 'die bestanden delen ondersteunen'. Als een app het ondersteunt, kan hij ook een bestand op het klembord uitlezen. Het delen van tekst op het klembord met een Android-app was al mogelijk.

Op het moment van schrijven is deze update alleen relevant voor Belgische gebruikers. In België zijn het Windows Subsystem for Android en de bijbehorende Amazon Appstore voor Windows beschikbaar. Het is niet bekend wanneer gebruikers in Nederland die krijgen.

Reacties (33)

[Strebor]

Allemaal leuk en aardig. Maar Windows 11 filesystem kan nog steeds niet fatsoenlijk met lange paden omgaan. In Windows 10 was dat gefixt. In Windows 11 is het eigenlijk altijd al stuk geweest **. Belachelijk dat je anno 2023 nog steeds gebonden bent aan 256 karakters.

** Ja, in sommige gevallen kan het gefixt worden met een Regedit of Local Group Policy. Echter, als je met Intune/Endpoint een policy wil uitrollen op W11 clients, dan werkt het niet (in de verkenner).

[GertMenkel]

Je grootste beperking zal zijn dat zelfs met deze toggle het long path-gedrag opt-in is via het applicatiemanifest. Als een applicatie niet aangeeft met lange paden om te kunnen gaan, zal het ook niet werken. De Windows-API heeft hier al jaren geen last meer van, maar weinig programma's geven aan met lange paden te werken. Zodra dat soort programma's mainstream worden, weet ik zeker dat Microsoft de feature opt-out maakt in plaats van opt-in.

Je kunt proberen om handmatig overal .manifest-bestanden neer te zetten naast de .exes of de bestaande aan te passen. Dit werkt als het manifest niet in de executable zelf zit. Okee, veel programma's gemaakt zonder die flag zullen crashen of alsnog incomplete paden laten zien als je dit doet, maar hé, de Windows-API gedraagt zich tenminste.

Je breekt tenslotte het contract tussen OS en applicatie achteraf. GetLongPathNameW heeft sinds zijn introductie altijd maximaal 260 tekens naar een array geschreven, nu kan daar ineens 32k in gaan. Dat gaat niet werken, dat wordt regelrechte geheugencorruptie. Zo'n beetje API accepteert daarom ook een argument voor de buffergrootte welke doorgaans... MAX_PATH is.

Handmatig inschakelen van lange paden zal dus alleen effect hebben op bestaande programma's als ze buggy zijn geschreven of onnodig veel geheugen alloceerden die nooit gevuld zal worden.

Maar waarom doet Windows Verkenner dit niet uit zichzelf? Ik kan verschillende redenen bedenken. Ten eerste zijn er tal van plugins die integreren met Windows Verkenner, denk 7zip en Git, die dezelfde assumoties hebben als dat ze twintig jaar geleden hadden. Ten tweede is Verkenner ook gedeeltelijk verantwoordelijk voor de COM shell API, welke door nog veel meer programma's wordt aangeroepen. Als Windows ineens 32k aan data gaat sturen in programma's die een memcpy doen naar 260 bytes in het geheugen dan krijg je een aantal spectaculaire crashes en mogelijk zelfs kwetsbaarheden en exploits. Stel je voor dat je een bestand downloadt dat een buffer overflow triggert in die Winrar-extensie en je computer infecteert zodra je erop rechtsklikt! De beperkingen die ervoor moeten zorgen dat dit goed gaat zitten namelijk aan de kant die geheugen alloceert voor paden, maar met dit soort extensies kom je API's tegen waar Windows dit voor je doet.

Wat je wel kunt doen is de bedrijven of projecten waar je je tooling vandaan haalt op de hoogte brengen van het bestaan van deze functie. De meeste ontwikkelaars zullen niet weten dat het een optie is, namelijk. Verkenner zal nog wel een tijdje geen lange paden aankunnen vanwege alle programma's die erop inhaken, maar alle andere programma's op je systeem kunnen daar dan nog wel mee werken.

Je kunt natuurlijk ook met \\?\C:\ om de beperkingen heen gaan zolang het programma daar mee overweg kan. Op die manier kun je ook andere beperkingen omzeilen (mkdir \\?\C:\con is een mooi voorbeeld daarvan, die map kun je daarna niet zomaar verwijderen)

Voor de mensen die niet weten over de optie om lange paden in te schakelen:

De Windows API kan al een tijdje zonder MAX_PATH-beperkingen werken maar die wijziging is opt-in:

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

Zet het DWORD Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled op 1, reboot, en klaar is Kees. Zoals je zegt is group policy ook een optie natuurlijk.

[Strebor]

@GertMenkel Wat een fantastische reactie (en dat voor mijn eigenlijk offtopic post). Dank!

[the_shadow]

Belachelijk dat je anno 2023 nog steeds gebonden bent aan 256 karakters.

Dat is een beperking van de Win32 API, en dus van de applicaties die gebruik maken van deze API. NTFS heeft ondersteunig voor padnamen van 32.767 UTF-16 characters.

[BobJung]

https://support.microsoft...630fa#filenamepathlengths dit geld voor de hele office suite.
Regelmatig mee van doen op het bedrijfs netwerk. De Shares paden zijn al lang, dus in een project heb je zo een probleem. Excel is nog erger.
Toch krijg je mij niet ergens anders heen , maar ze mogen dit wel eens oplossen.
Onedrive an zich heeft hier geen probleem mee, pas als je opend krijg je foutmedlingen.

[Reactie gewijzigd door BobJung op 25 juli 2024 15:28]

[xFeverr]

je kunt ook nog steeds niet je bestandsnaam 'con' of 'aux' noemen (ook niet voor een extensie), terwijl dat voor 99,9% van alle gebruikers geen enkel probleem zou moeten zijn. Het heeft allemaal met backwards compatibility te maken.

Vanaf WIndows 10 versie 1607 kun je aanzetten dat je lange paden wilt gebruiken via het register. Het is dus opt-in. Met een korte zoektocht lijkt het erop dat dit altijd al opt-in was, en dat zou passen bij hoe Microsoft omgaat met veranderingen in Windows.

[GertMenkel]

con en aux kunnen wel, als je maar expliciet \\?\ ervoor zet om om de API-filters heen te gaan. Ooit als vervelende tiener een programma geschreven dat je hele bureaublad vol zet met mappen genaamd con.1, con.2, con.3, etcetera, waar je met Windows verkenner helemaal niks meer mee kon doen.

Ik geloof dat "mkdir \\?\%userprofile%\Desktop\con.1" nog steeds zou moeten werken.

[xFeverr]

ja dat is waar, die prefix kun je ook gebruiken als je langere bestandsnamen wilt gebruiken. Eigenlijk dus nog steeds een soort opt-in

[GertMenkel]

Het is eigenlijk een truc om allerlei API-beveiligingen te omzeilen, niet echt een opt-in. Als je ergens \\?\ voor zet, zeg je tegen Windows "geloof me maar, ik heb zelf de nodige filtering al gedaan, stuur het verzoek maar direct door naar NTFS".

Het gevolg is dat je allerlei dingen kan doen met het bestandssysteem waar programma's die de officiële API gebruiken gewoon niet meer overweg kunnen. Bestandsnamen worden ineens 32k lang terwijl de documentatie van de API zegt dat ze maximaal 259 tekens lang zullen zijn. Mappen als con en aux kunnen niet worden geopend, verwijderd, of verplaatst. Je kunt zelfs bestanden met de naam .. maken, waar menig tool niet meer overweg zal kunnen gaan.

Het is geen goed idee om deze zogeheten DOS device paths te gebruiken in het dagelijks leven, maar zolang niet ieder programma is geüpdatet om van lange paden gebruik te kunnen maken (en <ws2:longPathAware>true</ws2:longPathAware> in het manifest van de executable) is zelfs de registersleutel om lange paden die sinds Win10 1604 ingebakken zit in te schakelen nog vaak geen oplossing.

[akimosan]

Probleem is daarom ook niet het filesystem. Probleem is de client app (zoals Explorer) en apps die gebruikmaken van de shell functies van Explorer
Alternatieven kunnen prima overweg met +260 char limit.

[Strebor]

Dank voor je feedback.
Ik heb even gezocht. Ik denk dat ik Total Commander ga proberen.

[KeesAlderlieste]

Prima tool! Gebruik 't al jaren, nooit meer naar Explorer omgekeken (behalve incidenteel op andermans pc bijv)

[!GN!T!ON]

Gebruik Total Commander al bijna 30 jaar, kan je niet mis mee gaan

[Jeffrey2107]

aan de andere kant hoe vaak is die 256 tekens limiet nou echt een probleem?

als ik er al tegenaanloop zit ik bijna 10 mappen diep en dan heb ik een groter probleem dan die 256 karakters. in dat geval is mijn mappenstructuur een enorme chaos.

[Strebor]

Helaas veel vaker dan ik zou willen.

Bijvoorbeeld bij een organisatie die allemaal in de cloud vanuit Office apps absurd lange paden maken, en een verplichting hebben backups niet alleen in de cloud te laten lopen, maar ook eens per kwartaal op een fysiek medium, welke vervolgens bij de bank in een kluis moet worden bewaard. Juist dan (bij de local backup naar hey fysieke medium) kom je dit soort fratsen tegen.

[Reactie gewijzigd door Strebor op 25 juli 2024 15:28]

[Themperror]

Zeker wel? Alleen dit is meestal aan de devs van de applicatie, elk path dat prefixed is met //?/ is een long file path en kan veel langer zijn dan 255 tekens.. Software zoals excel however.. doet dat niet vanwege backwards compat..

[GeroldM]

Belachelijk dat je anno 2023 nog steeds gebonden bent aan 256 karakters.

Ligt er maar net aan hoe ver/diep je wil gaan. Kom dit tegen bij mensen die alles met superlange namen diep in subfolders willen "verstoppen". Vaak maakt dat het er allemaal niet duidelijker op. Niet voor het bestandssysteem en eigenlijk ook niet voor de gebruiker.

Waar ik het wel mee eens ben is dat er geen echte keuze is tussen bestandsystemen in Windows. De opties die er zijn, zijn niet echte beter dan NTFS. Linux heeft wat dat betreft veel meer opties en vooral verbeterde opties die het waard zijn om te gebruiken.

[wica]

Hoe gaat dit in zijn werk?
Verbind mijn Android zich met mijn Windows PC direct? Of zit er een server van Microsoft er tussen?

[Croga]

Dit gaat over Windows Subsystem for Android; een manier om Android applicaties op je Windows PC te draaien. De verbinding is van je eigen PC naar je eigen PC, daar hoeft Microsoft verder niet tussen te komen.

[wica]

Ah. dank je.
Kende het nog niet.

[mjl]

Uiteraard moet je wel rekening houden met de app permissies en bijkomende phone-home functionaliteiten van de Android apps. Als een APL toegang heeft tot je Android bestands systeem dan komen ze hier ook bij.

[dcm360]

Dit gaat geloof ik om een heel ander onderdeel, namelijk de feature waarmee je Android-Apps op een Windows-apparaat kan gebruiken. Jouw Android (vermoedelijk een losse telefoon of tablet) staat hier los van.

[- peter -]

Denk dat 'kladblok' -> 'klembord' moet zijn?

[Mark_88]

Klopt, en fixed, dank.

[StGermain]

Hmmm eens kijken of ik de android orange tv app kan installeren, die heeft helaas geen windows client.

[Dutch2007]

Kan je de website waar je (mee) kijkt niet als PWA wrappen?

Zo heb ik dat in het verleden wel eens gedaan met sites waar geen Windows phone/mobile app voor beschikbaar was.

https://www.pwabuilder.com/

[Reactie gewijzigd door Dutch2007 op 25 juli 2024 15:28]

[StGermain]

Nee, dat is het probleem juist, er is geen website maar enkel apps voor phone en tablet.

Ik heb de android app kunnen sideloaden maar ze crashte na het linken aan de decoder...

[Dutch2007]

Wellicht kan je hier iets mee:

https://www.silicondust.com/support/downloads/

HD homerun

[jimshatt]

Fijn voor de ca. 1500 mensen op Tokelau. Ik vraag me af hoe ze bepalen waar dit soort dingen als eerste beschikbaar komen. Zal wel iets juridisch zijn.

[Dark Angel 58]

voor of na droppen wordt een bestand op malwares en virussen gecontroleerd?
Maak het sandbox, zodat een bestand andere delen van besturingssysteem niet kan besmetten.

[leuk_he]

Het android subsystem is een soort van VM, dus draait in een soort van sandbox. Files delen tussen een VM en en Host operating system was altijd al mogelijk, als je een antivirus oplossing draait die scannen nodig maakt, werkt dat uiteindelijk gewoon als je de file opent in windows.

Files die ergens staan, maar niet geopend worden zijn zondermeer geen probleem, het is niet zo dat een virus automatisch gestart wordt.

[Microwilly]

Als dit zo allemaal werkt. Wanneer komt Windows 11 mobile?

[Ralph84]

Amazon Appstore, echt een store die bijna niemand gebruikt in de EU. Superhandig!