WSLG ist kurz für das Windows -Subsystem für Linux -GUI. Der Zweck des Projekts besteht darin, die Unterstützung für das Ausführen von Linux -GUI -Anwendungen (X11 und Wayland) unter Windows in einem vollständig integrierten Desktop -Erlebnis zu ermöglichen.
WSLG bietet Entwicklern, Wissenschaftlern oder Enthusiasten eine integrierte Erfahrung, die Windows auf ihrem PC bevorzugen oder ausführen müssen, aber auch die Möglichkeit benötigen, Tools oder Anwendungen auszuführen, die am besten oder ausschließlich in einer Linux -Umgebung funktionieren. Während Benutzer dies heute mit einem mehrfacher System -Setup erreichen können, wobei einzelne PCs für Windows und Linux widmet, hostet das virtuelle Maschinenhosting entweder Windows oder Linux oder ein XServer, das unter Windows ausgeführt wird und in WSL projiziert wird. WSLG bietet eine integrierte, benutzerfreundlichere und produktive Alternative.
WSLG bemüht sich, Linux -GUI -Anwendungen nativ und natürlich für Windows zu verwenden. Von der Integration in das Startmenü zum Start bis hin zur Erscheinen in der Taskleiste über Alt-Tab-Erfahrung bis hin zur Aktivierung von Schnitt-/Einfügen über Windows- und Linux-Anwendungen ermöglicht WSLG eine nahtlose Desktop-Erfahrung und Workflow-Nutzung von Windows- und Linux-Anwendungen.
WSLG wird sowohl unter Windows 11 als auch unter Windows 10 unterstützt. Windows 10 -Benutzer müssen sicherstellen, dass die Windows 10 -Installation vollständig auf dem neuesten Stand ist, indem Sie Windows Update besuchen und alle verfügbaren Updates installieren.
WSLG ist sowohl als Teil des Windows 11 WSL -Posteingangs als auch über das Windows -Subsystem für Linux aus dem Microsoft Store erhältlich. Es wird dringend empfohlen, die Microsoft Store -Version von WSL zu verwenden, die sowohl Windows 10 als auch Windows 11 unterstützt und die aktuellste Version von WSL und WSLG enthält.
Stellen Sie sicher, dass Sie Ihren Grafiktreiber auf den neuesten Treiber auf der Website Ihres GPU -Herstellers aktualisieren, um von der GPU -Beschleunigung in Ihrer WSL -Umgebung zu profitieren.
Führen Sie aus einer Eingabeaufforderung mit Administrator -Berechtigungen den Befehl wsl --install -d Ubuntu
und starten Sie dann, falls sie aufgefordert werden.
Nach dem Neustart wird die Installation fortgesetzt. Sie werden gebeten, einen Benutzernamen und ein Passwort einzugeben. Dies sind Ihre Linux -Anmeldeinformationen, sie können alles sein, was Sie wollen, und müssen nicht mit Ihren Windows -Anmeldeinformationen übereinstimmen.
Voilà! WSL und WSLG sind installiert und sind bereit, verwendet zu werden!
Wenn Sie eine vorhandene WSL -Installation ohne WSLG haben und auf die neueste Version von WSL aktualisieren möchten, die WSLG enthält, führen Sie den Befehls wsl --update
von einer erhöhten Eingabeaufforderung aus.
Bitte beachten Sie, dass WSLG nur mit WSL 2 kompatibel ist und nicht für die WSL -Distribution funktioniert, die für die Arbeit im WSL 1 -Modus konfiguriert ist. Stellen Sie sicher, dass Ihre Linux -Distribu für das Ausführen im WSL 2 -Modus konfiguriert ist, wenn Sie nicht in WSL 2 wechseln 2. Nach der Installation von WSLG können Sie die Linux -Distriation im WSL 1 -Modus weiter ausführen. Kann nicht mit WSLG kommunizieren und können keine GUI -Anwendungen ausführen.
Sie können Ihre aktuell installierte Distribution und die Version von WSL auflisten, die für die Verwendung des folgenden Befehls aus einer erhöhten Eingabeaufforderung konfiguriert sind.
wsl -- list - v
Wenn Sie im Version 1 ausgeführt werden, wechseln Sie zu Version 2. Dies kann eine Weile dauern.
wsl -- set-version _distro_name_ 2
Starten Sie die WSL neu, indem Sie diesen Befehl von einer erhöhten Eingabeaufforderung ausführen, und speichern Sie zuerst alle anhängigen Arbeiten:
wsl -- shutdown
Um die neueste Version von WSL und WSLG für die Vorschau zu aktualisieren, führen Sie einfach wsl --update
von einer erhöhten Eingabeaufforderung oder PowerShell aus.
Sie müssen WSL neu starten, damit die Änderungen wirksam werden. Sie können WSL neu starten, indem Sie wsl --shutdown
aus einer erhöhten Eingabeaufforderung ausführen. Wenn die WSL derzeit ausgeführt wurde, speichern Sie zunächst die Arbeit! WSL wird beim nächsten Start einer WSL -Anwendung oder einem Terminal automatisch neu gestartet.
Wenn Sie die Ubuntu
-Linux -Distribution gemäß diesen Anweisungen installiert haben, finden Sie ein Ubuntu
-Symbol in Ihrem Startmenü und starten Sie es. Dadurch wird die WSL 2 VM gestartet, die Ubuntu WSL -Distribution in dieser VM starten und Ihnen ein Terminal zur Interaktion mit ihm geben. Voilà! Sie führen Linux unter Windows aus!
Wenn Sie zusätzliche Linux -Verteilungen für WSL erkunden möchten, können Sie den Befehl wsl --list --online
von einer erhöhten Eingabeaufforderung verwenden, um die Liste der verfügbaren Verteilungen für Ihr System zu zählen. Sie können mehrere Linux-Verteilungen in WSL installieren lassen, und sie werden gerne nebeneinander existieren. Haben Sie also keine Angst, zu experimentieren und Dinge auszuprobieren.
Herzlichen Glückwunsch, dass Sie fertig sind und bereit sind, GUI -Apps zu verwenden!
Wenn Sie mit einigen GUI -Apps beginnen möchten, können Sie die folgenden Befehle von Ihrem Linux -Terminal ausführen, um einige beliebte Anwendungen herunterzuladen und zu installieren. Wenn Sie eine andere Verteilung verwenden als Ubuntu, kann sie möglicherweise einen anderen Paketmanager verwenden.
# # Update list of available packages
sudo apt update
# # Gedit
sudo apt install gedit - y
# # GIMP
sudo apt install gimp - y
# # Nautilus
sudo apt install nautilus - y
# # VLC
sudo apt install vlc - y
# # X11 apps
sudo apt install x11 - apps - y
# # Google Chrome
cd / tmp
sudo wget https: // dl.google.com / linux / direct / google - chrome - stable_current_amd64.deb
sudo dpkg - i google - chrome - stable_current_amd64.deb
sudo apt install -- fix - broken - y
sudo dpkg - i google - chrome - stable_current_amd64.deb
# # Microsoft Teams
cd / tmp
sudo curl - L - o " ./teams.deb " " https://teams.microsoft.com/downloads/desktopurl?env=production&plat=linux&arch=x64&download=true&linuxArchiveType=deb "
sudo apt install . / teams.deb - y
# # Microsoft Edge Dev Browser
sudo curl https: // packages.microsoft.com / repos / edge / pool / main / m / microsoft - edge - dev / microsoft - edge - dev_118. 0.2060 . 1 - 1_amd64.deb - o / tmp / edge.deb
sudo apt install / tmp / edge.deb - y
Sobald diese Anwendungen installiert sind, finden Sie sie in Ihrem Startmenü unter dem Distribaumnamen. Zum Beispiel Ubuntu -> Microsoft Edge
. Sie können diese auch mit den Befehlen aus Ihrem Terminalfenster starten:
xcalc
, xclock
, xeyes
gimp
gedit ~/.bashrc
nautilus
vlc
google-chrome
teams
microsoft-edge
Die Benutzerdistribution ist im Wesentlichen die WSL -Verteilung, die Sie für Ihre Linux -Arbeit verwenden. Sie können die Befehls wsl --list --online
über eine erhöhte Windows -Eingabeaufforderung verwenden, um die auf Ihrem System verfügbaren WSL -Verteilungen aufzulisten. Sie können mehrere Benutzerdistrikten nebeneinander ausführen und sie werden friedlich koexistieren. Haben Sie also keine Angst davor, eine neue Distribution auszuprobieren. Jede Benutzerdistribution wird mit einer einzigartigen Instanz der Systemdistribution gepaart, aber Sie können dennoch übernotlos über GUI -Anwendungen interagieren, wie z. B. Schnitt/Einfügen zwischen ihnen. Die zugrunde liegende Containerisierung der verschiedenen Benutzerspace sollte für Sie unsichtbar sein.
Alle Benutzer- und Systemdistributiere für einen bestimmten Windows -Benutzer, der in derselben virtuellen WSL -Maschine ausführt, gegen eine einzelne Instanz des Linux -Kernels. Verschiedene Windows -Benutzer auf einem PC verfügen über eine eigene VM und Instanz von WSL. Ihre Linux -Umgebung ist garantiert immer Ihre eigene und wird nicht mit anderen Windows -Benutzern auf demselben PC geteilt.
In der Systemdistribution kommt es zu der gesamten Magie. Die Systemdistribution ist eine Container -Linux -Umgebung, in der der WSLG Xserver, Wayland Server und Pulse Audio Server ausgeführt werden. Kommunikationsbuchse für jeden dieser Server werden in die Benutzerdistribution projiziert, sodass Client -Anwendungen eine Verbindung zu ihnen herstellen können. Wir präsentieren die Variablen der Benutzerdistriumption, Wayland_Display und Pulse_Server, um diese Server standardmäßig zu verweisen, damit WSLG nicht über die Box leuchtet.
Benutzer, die verschiedene Server verwenden möchten als die von WSLG bereitgestellte, können diese Umgebungsvariablen ändern. Der Benutzer kann auch die Systemdistribution ausschalten, indem der folgende Eintrag in der .wslconfig
-Datei (befindet sich unter c:usersMyUser.wslconfig
). Dies deaktiviert die Unterstützung für GUI -Anwendungen in WSL.
[wsl2]
guiApplications=false
Die Systemdistribution basiert auf dem Microsoft CBL-Mariner Linux. Dies ist eine minimale Linux -Umgebung, die gerade genug ist, um die verschiedenen WSLG -Stücke zu betreiben. Weitere Informationen zum Erstellen und Bereitstellen einer privaten Systemdistribution finden Sie in unseren Build -Anweisungen.
Jede WSL 2 -Benutzerdistribution wird mit einer eigenen Instanz der Systemdistribution gepaart. Die Systemdistribution wird teilweise aus der Benutzerdistribution isoliert, in die sie in ihrem eigenen NS/PID/UTS -Namespace gepaart wird, aber andere Namespaces wie IPC teilt, um die gemeinsame Speicheroptimierung über die Grenze über die Grenze hinweg zu ermöglichen.
Während ein Benutzer ein Terminal in die Systemdistribution einbringen kann, soll die Systemdistribution nicht direkt von Benutzern verwendet werden. Jede Instanz der System-Distribution wird nur schreibgeschützt von ihrem Backing VHD geladen. Alle Änderungen, die an der In-Memory-Instanz der Systemdistribution vorgenommen wurden (z. B. neue Pakete oder eine neue Datei erstellen), werden effektiv verworfen, wenn WSL neu gestartet wird. Der Grund, warum wir dies tun, ist, ein Wartungsmodell für die Systemdistribution zu aktivieren, in dem wir den alten durch das neue ersetzen, ohne sich Sorgen um die Migration von Benutzerdaten zu ersetzen, die enthalten sind. Wir verwenden eine schreibgeschützte Zuordnung, sodass der Benutzer bei Änderungen ein bekanntes Verhaltensverhalten erhält, jedes Mal, wenn WSL neu gestartet wird, anstatt eine Überraschung zu erhalten, wenn WSL gewartet wird.
Obwohl die Microsoft die WSLG-Systemdistribution als schreibgeschützte veröffentlichte, möchten wir die Leute dazu ermutigen, daran zu basteln und zu experimentieren. Obwohl wir erwarten, dass nur sehr wenige Leute dies tatsächlich brauchen oder möchten, haben wir detaillierte Anweisungen auf unserer beitragenden Seite zum Erstellen und Bereitstellen einer privaten Version der Systemdistribution geteilt. Die meisten Benutzer, die nur GUI -Anwendungen in WSL verwenden möchten, müssen sich keine Sorgen um diese Details machen.
WSLGD ist der erste Prozess, der nach Init gestartet wird. WSLGD startet Weston (mit Xwayland), Pulseaudio und stellt die RDP -Verbindung her, indem er MSTSC.EXE im Stillenmodus auf den Host startet. Die RDP -Verbindung bleibt aktiv und bereit, neue GUI -Anwendungen zu zeigen, die nach einer Verbreitung von Verbindungseinrichtungen auf einen Moment gestartet werden. WSLGD überwacht dann diese Prozesse und wenn sie nach Fehler beenden (beispielsweise als Ergebnis eines Absturzes), startet sie automatisch neu.
Weston ist der Wayland Project Reference Compositor und das Herz von WSLG. Für WSLG haben wir das vorhandene RDP -Backend von Libweston erweitert, um ihm beizubringen, wie man Anwendungen anstelle von Überwachung/Desktop remote remote machen. Wir haben ihm auch verschiedene Funktionen hinzugefügt, z. B. Unterstützung für Multi-Monitor, Cut/Paste, Audio in/Out usw.
Die Anwendungsintegration wird über eine RDP -Technologie bezeichnet, die als Rail (Remote Application Integrated Lokal) und Vail (Virtualisierte Anwendung integriert). Der Hauptunterschied zwischen Schiene und Vail besteht darin, wie Pixel vom RDP -Server zum RDP -Client übertragen werden. Bei der Schiene wird angenommen, dass der Server und der Client auf verschiedenen physischen Systemen ausgeführt werden, die über das Netzwerk kommunizieren, und daher müssen Pixel über den RDP -Transport kopiert werden. In Vail wird davon ausgegangen, dass sich der Server und der Client auf demselben physischen System befinden und den Speicher über die Guest/Host -VM -Grenze teilen können. Wir haben sowohl Rail als auch Vail zum Libweston RDP -Backend unterstützt, obwohl für WSLG nur die Vail -Unterstützung effektiv verwendet wird. Während des Bauens von WSLG haben wir zuerst die Schiene implementiert, während die notwendigen Teile, die den Wechsel zu Vail parallel entwickelten, ermöglichten. Wir haben uns entschlossen, diese Unterstützung in anderen interessanten Szenarien außerhalb von WSLG wiederzuverwenden, beispielsweise für die Remotierung von Anwendungen von einem PI, das Linux ausführt. Um den Speicher zwischen dem Linux-Gast und dem Windows-Host zu teilen, verwenden wir Virtio-Fs.
Weston ist modular und verfügt heute über verschiedene Schalen, wie die Desktop -Shell, die Vollbildschale (AKA -Kiosk) und die automatische Shell. Für WSLG haben wir eine neue Hülle namens The Rail Shell eingeführt. Der Zweck der Schienenschale besteht darin, die Entfernung einzelner Fenster von Linux zu Windows zu unterstützen. Daher ist die Shell sehr simpel und beinhaltet keine tatsächlichen Widgets oder Pixel von Shellbesitz.
Weston nutzt FreerDP, um seinen Backend RDP -Server zu implementieren. FREERDP wird verwendet, um alle Kommunikationen zu codieren, die vom RDP -Server (in Weston) zum RDP -Client (MSTSC auf Windows) gemäß den RDP -Protokollspezifikationen wechseln. Es wird auch verwendet, um den gesamten Datenverkehr vom RDP -Client in den RDP -Server zu dekodieren.
Für Audio in (Mikrofon) und Out (Lautsprecher/Kopfhörer) wird WSLG einen Pulsaudio -Server ausführen. WSLG verwendet ein Sink -Plugin für Audio -Out und ein Quell -Plugin für Audio in. Diese Plugins übertragen Audio -Proben zwischen dem PulseServer und dem Weston RDP -Server effektiv. Die Audio -Streams werden vom Weston RDP -Server mit dem RDP -Transport verschmolzen, wodurch das Audio im Weston RDP -Backend in allen Szenarien (Desktop/Rail/Vail Style Remoting) einschließlich WSLG effektiv ein-/out ermöglicht wird.
WSLG verwendet einen benutzerdefinierten RDP -Virtual -Kanal zwischen dem Weston RDP -Server und dem MSTSC -RDP -Client, der auf dem Windows -Host ausgeführt wird. Dieser Kanal wird von Weston verwendet, um alle Linux -GUI -Anwendungen (dh Anwendungen mit einem Desktop -Dateieintrag vom Typ GUI) zusammen mit ihrer Startbefehlslinie und -Symbol aufzuzählen. Die Open Source WSLDVCplugin verarbeitet die Liste der über diesen Kanal gesendeten Linux -GUI -Anwendungen und erstellt Links für sie im Windows -Startmenü.
Während WSLG mit oder ohne virtuelle GPU -Unterstützung arbeitet, ist es am besten, auf einem System mit einem GPU und einem Treiber zu laufen, das WSL unterstützen kann, wenn Sie beabsichtigen, intensive Anwendungen wie Blender oder Gavebo auszuführen. Ein Überblick über unsere VGPU -Architektur und wie wir Linux -Anwendungen in WSL zugreifen können, ist in unserem DirectX -Blog verfügbar.
Die Unterstützung für das OpenGL -beschleunigte Rendering wird durch die Arbeit ermöglicht, die unser D3D -Team mit Collabora und der MESA -Community zur Schaffung eines D3D12 -Gallium -Fahrers durchgeführt hat.
Die Unterstützung für Linux, einschließlich der Unterstützung für WSLG, wurde stromaufwärts und Teil der MESA 21.0 -Version. Um diese Beschleunigung zu nutzen, müssen Sie die in Ihrer Benutzerdistribution installierte Version von MESA aktualisieren. Es erfordert auch, dass Ihr Distribonanbieter den neuen D3D12 -Gallium -Treiber für das Paketrepository erstellt und veröffentlichen. Wir arbeiten mit den verschiedenen WSL -Distribärverlagern zusammen, um sie über diese Änderungen zu informieren.
Bitte beachten Sie, dass VGPU für die erste Veröffentlichung von WSLG durch den Systemspeicher mit dem Weston Compositor interop. Wenn Sie auf einer diskreten GPU ausgeführt werden, bedeutet dies effektiv, dass die gerenderten Daten von VRAM zu Systemspeicher kopiert werden, bevor der Kompositor innerhalb von WSLG präsentiert und auf der Windows -Seite erneut auf die GPU hochgeladen wird. Infolgedessen gibt es eine Leistungsstrafe, die zur Präsentationsrate proportional ist. Bei sehr hohen Bildraten wie 600 fps bei einer diskreten GPU kann dieser Overhead bis zu 50%betragen. Bei niedrigerer Bildrate oder bei integrierter GPU kann die Leistung in Abhängigkeit von der Arbeitsbelastung viel näher am nativen erreicht werden. Die Verwendung einer VGPU bietet trotz dieser V1 -Begrenzung immer noch eine sehr bedeutende Leistung und Erfahrung im Umgang mit einem Software -Renderer.
WSLG baut auf der großartigen Arbeit der Linux -Community auf und nutzt eine große Anzahl von Open -Source -Projekten. Die meisten Komponenten werden nach ihrer vorgelagerten Version verwendet und benötigten keine Änderungen, um in WSLG zu beleuchten. Einige Komponenten im Herzen von WSLG, insbesondere Weston, FreerDP und Pulseaudio, erforderten Änderungen, um die reiche WSLG -Integration zu ermöglichen. Diese Änderungen sind noch nicht stromaufwärts. Microsoft arbeitet mit der Community zusammen, um diese Beiträge mit jedem Projekt so zu teilen, dass WSLG im Laufe der Zeit direkt aus vorgelagerten Komponenten erstellt werden kann, ohne dass WSLG -spezifische Modifikationen erforderlich sind.
All diese Beiträge während des Fluges werden in Microsoft Mirror Repos aufbewahrt. Wir halten diese Spiegel mit Upstream -Veröffentlichungen auf dem neuesten Stand und bilden unsere WSLG -Änderungen in diesen Repos. WSLG zieht und baut Code aus diesen Spiegelrepos als Teil unserer Insider WSLG Preview Releases. Diese Spiegel sind öffentlich und für alle zugänglich. Neugierige Entwickler können in frühen Phasen unseres Beitrags einen Blick darauf werfen, indem sie Code in diesen Spiegeln betrachten, und berücksichtigen die verschiedenen Projektbesitzer. Alle unsere Spiegel folgen dem gleichen Modell. Es gibt einen Hauptzweig , der dem stromaufwärts gelegenen Zweig an unserem letzten Synchronisationspunkt entspricht. Wir aktualisieren die Hauptzweig von Zeit zu Zeit, um Update aus dem Upstream -Projekt auszuwählen. Es gibt auch einen Arbeitszweig , der alle unsere Änderungen im Flug enthält. WSLG wird mit dem Arbeitszweig aus jedem der Spiegelprojekte gebaut.
Die Projekte, für die WSLG Spiegel unterhält, ändern sich im Laufe der Zeit, wenn sich die Beiträge im Flug entwickeln. Sobald einige Beiträge stromaufwärts sind, ist es möglicherweise nicht mehr erforderlich, einen Spiegel aufrechtzuerhalten. An diesem Punkt wird er entfernt und WSLG wird die vorgelagerte Version der Komponente direkt nutzen. Wenn wir neue Funktionen in WSLG beleuchten, können neue Spiegel eingeführt werden, um Beiträge zu neuen Komponenten zu steigern. Erwarten Sie daher, dass die Liste der Spiegel die Überstunden ändert.
Zu diesem Zeitpunkt haben wir die folgenden Projektspiegel für derzeit im Flugbeiträge.
Projekt | Upstream Repo | WSLG -Spiegel |
---|---|---|
Weston | https://github.com/wayland-project/weston | https://github.com/microsoft/weston-mirror |
Freerdp | https://github.com/freerdp/freerdp | https://github.com/microsoft/freerdp-mirror |
Pulsaudio | https://github.com/pulaudio/pulaudio | https://github.com/microsoft/pulaudio-mirror |
Das Folgende ist ein hoher Überblick über die derzeit im Fluginstitut in diesen Spiegeln enthaltenen Beiträgen.
WSLG nutzt Weston als Wayland Compositor, in dem die Linux- und Windows -Welten mithilfe der RDP -Technologie überfließen, um die Anwendungsinhalte zwischen ihnen zu remote. Weston hatte bereits ein RDP-Backend, aber es war auf ein Monitor-Desktop-Remoting beschränkt. Wir haben das RDP-Backend erheblich verbessert, um erweiterte Funktionen wie Support für Multi-Monitor, Zwischenablage-Integration für Kopieren/Einfügen und Audio-Ein-/Ausgänge einzubeziehen. Wir haben neue Remoting -Modi mit dem Namen Rail (Remote Application Integrated Lokal) und VAIL (Virtualisierte Anwendung integriert) aktiviert, bei denen einzelne Anwendungen anstelle von Desktops/Monitoren entfernt werden. Diese Änderungen sind nicht spezifisch für WSLG; Sie fügen dem vorhandenen RDP -Backend Funktionen hinzu und sind auch in anderen Szenarien wiederverwendbar (dh die Verwendung des neuen Weston RDP -Backends zur Remote -Anwendung, die auf einem Raspberry -Pi zu einem anderen Gerät ausgeführt wird, das einen RDP -Client ausführt).
Um eine reichhaltige Integration in WSLG zu ermöglichen, haben wir dem RDP -Backend spezifisch für WSLG auch ein kleines Plugin hinzugefügt. In Weston ist das Plugin dafür verantwortlich, an der Benutzerdistribution angewachsen zu sein und nach installierten Anwendungen zu suchen (auch bekannt als Desktop -Datei). Das Plugin sendet dem Windows -Host eine Liste aller Anwendungen zusammen mit ihren Startbefehlen und Symbolen. Auf dem Windows -Host verwendet ein Open -Source -MSTSC -Plugin -Teil des WSLG -Projekts diese Informationen, um Verknüpfungen für diese Linux -Anwendungen zum Windows -Startmenü zu erstellen.
Wir haben auch mehrere Fehler behoben, die sich auf verschiedene Anwendungen auswirken. Im Allgemeinen waren dies Probleme, die Weston in allen Modi beeinflussten und nicht spezifisch für WSLG waren.
Weston verwendet derzeit FreerDP für sein RDP -Backend. WSLG nutzt weiterhin freerDP und wir haben Unterstützung für ein neues RDP -Protokoll/-kanal hinzugefügt, um das Vail -optimierte Szenario sowie das WSLG -Plugin zu unterstützen. Wir haben auch verschiedene Fehler behoben, die Interops mit MSTSC beeinflussten oder Instabilität verursachten.
Für PulseAudio konzentrierten sich unsere Beiträge auf eine Spüle und ein Quell -Plugin, das Audiodaten zwischen Pulseaudio und dem Weston RDP -Backend senkt, sodass die Audiodaten über die RDP -Verbindung zurück zum Host integriert werden können. Es gibt keine Änderungen am Kern von Pulseatio außerhalb des Hinzufügens dieser neuen Plugins.
Wenn Sie an WSLG basteln oder zu einem beitragen, finden Sie auf unserer beitragenden Seite für Details, einschließlich der Erstellung und Ausführung einer privaten Version von WSLG.
Bei nicht sicheren Problemen, z. B. bei der Meldung eines Fehlers oder der Erstellung eines Vorschlags für eine neue Funktion, verwenden Sie bitte den Issues Tracker dieses Projekts.
Um Sicherheitsprobleme mit WSLG oder anderen Microsoft -Produkten zu melden, befolgen Sie bitte die hier beschriebenen Anweisungen.
Dieses Projekt kann Marken oder Logos für Projekte, Produkte oder Dienstleistungen enthalten. Die autorisierte Verwendung von Microsoft -Marken oder Logos unterliegt den Marken- und Markenrichtlinien von Microsoft und muss folgen. Die Verwendung von Microsoft -Marken oder Logos in geänderten Versionen dieses Projekts darf keine Verwirrung verursachen oder Microsoft -Sponsoring implizieren. Jede Verwendung von Marken oder Logos von Drittanbietern unterliegt den Richtlinien dieses Drittanbieters.