- #INSTALL XQUARTZ HANGS INSTALL#
- #INSTALL XQUARTZ HANGS UPDATE#
- #INSTALL XQUARTZ HANGS FULL#
- #INSTALL XQUARTZ HANGS SOFTWARE#
- #INSTALL XQUARTZ HANGS WINDOWS#
#INSTALL XQUARTZ HANGS WINDOWS#
What is interesting about WSL is that it enables Linux to be run on a Windows system.
#INSTALL XQUARTZ HANGS UPDATE#
I did have to do a Windows feature update in order to support WSL 2 I followed the instructions from this how-to page:
#INSTALL XQUARTZ HANGS INSTALL#
The current industry standard for getting an X Server on Windows 10 is to enable the Windows Subsystem for Linux (WSL), and install and X Server package such as VcXsrv. Without running an X Server on Windows, the four VM applications’ windows, here displayed on Windows’ desktop, would instead have to be cramped inside their VM’s own virtual desktop. The thick red line represents the VM’s access to its own virtual device appearing on Windows’ desktop. In this way, the VM applications can break out of that overly small box carved out for the VM’s desktop. The X Server process is a Windows 10 process and therefore has access to the entire Windows desktop. My goal is to have an X Server running on Windows 10, and point all VM processes to that X Server. VirtualBox services on the host OS provide routing between the virtual subnet and the host OS’s original subnet. VMs will have addresses on that subnet rather than the host OS’s original subnet. That interface is on its own isolated subnet. In reality, VirtualBox sets up a new network interface on the host OS. Again, I simplify for the sake of keeping it easy to understand. TELNET, FTP, ssh, HTTP, ARP, DHCP … these protocols and more all work between the host operating system and its VMs as if we had multiple physical hosts on the same subnet. I am merely illustrating the X Window concepts so we can understand what I hope to set up with my VirtualBox VMs.įrom a purely network protocol perspective, a VM looks very much like just another host on a local subnet. I am leaving out many details (e.g., security and authentication). From a user’s perspective the only significant difference is that the local processes with communicate with the X Server via the host’s loopback address (127.0.0.1) – but the communication is still via TCP and follows the same procedures as a remote process. These local processes communicate with the X Server just as if the server were on a remote machine. It is worthwhile noting that X Window applications on the system that does have a monitor are not exempted from the X Window client/server model. Each remote process opens its own TCP connection with the display server. The X Server will then consume the data and display it on the physical monitor. The system with no physical monitor will have X applications that communicate via TCP with the X Server on the other system.
#INSTALL XQUARTZ HANGS SOFTWARE#
In this manner the you have a display server that receives (‘consumes’ in X parlance) display ‘jobs’ from clients and sends those jobs to a physical output device (i.e., your monitor) – much the same way print server software (whether it resides on your desktop as in days of yore, or on the printer itself) receives print jobs from clients and sends those jobs to a physical output device (i.e., a printer). When a process on either system needs to display something on the screen, rather than write to some dedicated display, an X Window application will instead look for an X Window display server and send its output to that server, not to an actual monitor or graphics card. The other system has no physical monitor of its own. One system has a physical monitor connected, and is also running an X Server process. In the image above I’ve illustrated various processes running on two separate systems. First of all, it is worth reviewing the X Window model. Hence the virtual screens you see in this screenshot are pretty much what I have to work with.īut there’s a solution … install an X Window server in my Windows 10 environment. and furthermore I am unable to increase the screen size beyond 1024×768 (I assume due to hardware – memory and/or graphics card – limitations). I need Linux apps in the VM to have access to my entire screen.Īs you can see, the two VMs I have running each have only limited real estate on my physical monitor… I have to make do with a Linux desktop that is modest in size and, frankly, very limiting.
#INSTALL XQUARTZ HANGS FULL#
My little system is not big and powerful enough to provide a full screen, dual-monitor capability to my VirtualBox VM. Their applications are constrained to the real estate the Linux virtual display was granted when it requested a new window from Windows 10. As such, they are, in a visual context, a Linux desktop on your Windows desktop. Though VirtualBox VMs have their own display device, these are of course virtual display devices.
0 kommentar(er)
