Windows 11 in Qubes

Thanks for the information. I was unaware of it, but now I have downloaded the file.

I checked with a Windows 7 template under Qubes R4.2.4 and got the following results so far:

  • If QWT 4.1.69 is installed, the installer can be started.
  • IF QWT was uninstalled and Windows was rebooted, the installer can be started and briefly shows a window with a text containing something about “Prerequisites”, but unfortunately too fast to read it. After that, the installer ends and cannot be started anymore by clicking on the exe-file.
  • The installer can be started from a command window and behaves ´like in the first alternative.
  • Installation proceeds without errors until the point when the Qubes services should be started. Then a message appears that the services cannot be started due to lack of privilege, only offering the option to roll back the installation.
  • When I try to start the services manually (before this roll-back), they cannot be started due to dependency problems:
    • The QubesDB daemon throws the Error 1075: The dependency service does not exist or has been marked for deletion.
    • The Qubes RPC agent throws the Error: 1068: The dependency service or group failed to start.
  • In both cases, the event log does not show which dependency is missing, and the service definitions also do not show such dependencies.

I’ll check now with Windows 10.

1 Like

Was testsigning enabled in this VM? Did you get prompts to confirm installing drivers with unknown signature? Some of the issues sound like drivers not being loaded.

Windows 10 shows a similar behavior. The main difference is that error 1075 is replaced by Error 1053 the service did not respond to the start or control request, which is also shown in the event log. Before that, the event log shows a warning that the Xenbus driver could not be loaded, which may cause the subsequent errors.

For Windows 10, the service "Xen agent " is shown as running. This is probably a remnant of the earlier QWT installation of version 4.1.69. (On Windows 7, this service is no longer there when QWT was uninstalled.) If I disable this service and walk through several reboots, the installation of the new QWT finishes on Windows 10.

In W10, even seamless mode is available!!! Still, the new graphics driver has its problems. In non-seamless mode, it sets - on my system - a screen resolution of 1920 x 1080, but does not fill that space, so the Windows menus are inaccessible. Setting the resolution to 1280 x 1024 allows using the system. In seamless mode, the Windows menu causes some funny flickering and finally ruins the whole screen. Getting to non-seamless mode again killed the Qube Manager, even in such a way that it could not be restarted, and finally, I had to reboot Qubes.

So it seems, there is still some work ahead! :sweat_smile:

1 Like

Testsigning was enabled in W7 and also in W10.

With W7 I guess there may be some remnants of previous QWT installation. Have you tried installing it in fresh W7?

I checked now with a “virgin” Windows 7 system that had no previous installation of QWT. The installation could be started but failed again when the Qubes services should be started, in the same way as in the previous system.

The service “Xen PV Driver Monitor” was installed and started in this system, but the installation produced the message

Application popup: \SystemRoot\system32\DRIVERS\xenbus.sys cannot find ntoskrnl.exe KeInitializeSpinLock

and then the warning

Error loading driver \Driver\xenbus for the device PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\3&267a616a&0&10.

After that, only three more events were logged, saying that the Qubes services were installed.

When I continued, the installation of QWT was rolled back, as in the previous tests, but the Xen PV Driver Monitor stayed installed.

After a reboot, the system complained that it could not be started, and tried a repair, which took about 10 minutes. After that, the system shut down and could be booted normally, and the Xen PV Driver Monitor had been removed.

Okay so the issue is actually because I am using a different user than the one initially set up with the VM. For some reason, the options are only available to the first user on the system.

Ok, so it looks like there is some API change in Windows between 7 and 10 that makes drivers built for 10 incompatible with 7. Given Windows 7 is not supported by MS for a long time already, how important is to keep QWT compatible with Windows 7?

I tried now to install QWT on Windows 11 23H2, and it behaved roughly like Windows 10. The installation first worked until the moment when the QWT services were started, which was not possible due to the same errors as in Windows 7.

Setting testsigning on allowed me to complete the installation, but left the system in a broken state which - up until now - could not be repaired. So W11 seems to be more like W7. So far, I could not find out what the missing dependencies are. Perhaps it’s the same for several Windows versions???

With regard to your question: That’s a difficult one, which probably has no simple, general answer. So I’ll try to collect some arguments that may have personal bias.

Omitting W7 from the supported Windows versions will affect those installations that require W7 and cannot be upgraded to a newer Windows version, due to applications not being supported there or, like in my case, due to special hardware, for which no drivers for W10 exist. (I have a high-resolution scanner needed for photographic work which runs under W7, but not W10.) It is difficult to say how many installations may be affected by this, but, on the other hand, there are installations with applications not supported by W7, but by W10.

The next aspect is usability. On my system, which is neither very fast nor very slow, there is a marked difference between the different Windows versions: W7 is acceptably fast, partially even faster than on a comparable computer where it is running on bare metal, but with a virus scanner. W10 is considerably slower, but you could still use it, with gnashing teeth. W11, however, is so slow that it is nearly unusable. All three systems have comparable resources allocated to them, so it is really a matter of efficiency.

This factor of efficiency extends to the UX. While W7 looks somewhat old-fashioned, it has a very efficient UX and allows one to perform many tasks fast and without much hassle, comparable to many Linux desktops. W10 has a much more unergonomic UX, often blurring the border between different, overlapping windows, and its menu structure requires much more navigating and scrolling. Finally, W11 is completely unergonomic, as well in its menu structure as in newly designed applications like the Explorer, which often hide the relevant options and features, while displaying a lot of stuff that is not needed for professional work, but can only be removed with a lot of work or not at all.

The next aspect is availability: Recent changes in Microsoft’s licensing terms and system requirements pose the risk that older versions of W10 and newer versions of W11 may suddenly turn out to be unsupported or require costly license structures.

Finally, the use of W10 or W11 may be illegal in some application areas in the EU, due to the telemetry functions in these systems violating the requirements of the GDPR, if personal data are processed. (In the documentation of Windows use under Qubes, I have suggested a way to mitigate this problem, but that solution may not be acceptable in many places.) So, if you are forced to use Windows, W7 may be your only option.

Using W7 poses a certain risk, as it is no longer supported by Microsoft, and the same will happen with W10 this autumn. But if these systems are run under Qubes, this risk is considerably lowered and may be acceptable. Furthermore, most attacks now focus on the newer Windows versions, so it may even help to stay with an older version - which, according to CVE statistics - has a much lower rate of security-relevant faults than W10 or W11.

Putting it all together: In my environment, I stick to W7 where I still need to use Windows, and where I have to move away from it, I try to switch to Linux and avoid W10 and, completely, W11. Clearly, this is not representative, but
may give some arguments to keep support for Windows 7. Running Windows 7 under Qubes may still be much preferable to running Windows 10 or 11, with or without Qubes.

1 Like

I also believe that keeping Windows 7 supported makes sense for the exact above reason alone. For example I know a cutter plotter and a UV Printer which are relatively old and left only with Windows 7 drivers. And I know many similar expensive hardware with the exact same conditions. With Qubes support, it would be possible to encapsulate Windows 7, specific drivers and applications within a network-less qube and keep using those hardware as long as the PCI pass-through and file transfer works.

2 Likes

There should be no issue to keep compatability. Just have one QWT installer for each OS that you want to have it for.

The interface into Qubes Domain-0 wouldn’t change or have any difference to it, since nothing there needs to change between any version of Windows or the tools.

The commands are the commands, it’s that simple.
If the tools in Win7 or 8 or 10 or 11 are calling “create window” then that is what it’s calling. It doesn’t need to change from 7 to 11.
So compatability will ALWAYS be there.
Don’t need to FORCE the REMOVAL of compatability.

There is an interest round here - for support of legacy software.

OTOH, if I had to choose a project for @ marmarek & Qubes team to concentrate valuable time on, it would probably not be that…

Maybe a little pointer to the documents explaining the work-arounds or tricks for compiling it ourselves?

1 Like

Some more information on the problems with Windows 7:

  • QWT is installed into a directory on drive Q:, at least as long as the installer is still running. Maybe it would be moved to its final destination if and when the installer finishes successfully. This should be C:\Program Files\InvisiblieThings\Qubes Tools\.
  • Starting the qubesDB-daemon.exe manually produces an error message
    “The program cannot be started because api-ms-win-core-path-l1-1-0.dll is missing”. This is perhaps caused by using Python > 3.8, and W7 does not support 3.9 or later. A solution for this problem that has been suggested is to download that file and put it into C:\Windows\SysWOW64\ and register it via regsvr32, but I doubt if this will help. Going back to Python 3.8 might be better, but it would probably mean two different versions of QWT for W7 and W10 or later.
  • The W7 device manager shows a device Xen PV bus which is inactive and cannot be started. Possibly, its version 9.1.0.0 is incompatible with W7, and only version 8.2.2 could be used on that system.

Windows 10 has its problems, too:

  • Only smaller screen resolutions can be used. On my system, 1280 x 1024 works, but anything larger leads to an unresponsive window, although I have set the video RAM appropriately. The seamless mode works, but it is terribly slow. Switching between both modes kills the Qube manager, probably because the fix manager v4.3.9-1 (r4.3) QubesOS/updates-status#5446 installed in Qubes R4.3 is missing in R4.2.4.
  • The QWT installation directory is C:\Qubes Tools\, but it should be C:\Program Files\InvisiblieThings\Qubes Tools\ instead.
  • If I try to start the qubesDB-daemon manually, I get the following message, which might be relevant or not - I don’t know:
[20250228.105549.516-796-E] SvcMainLoop: StartServiceCtrlDispatcher failed with error 0x427: Der Dienstprozess konnte keine Verbindung mit dem Dienstcontroller herstellen.

As usual, Windows is a mess. Currently, I am trying to collect enough courage to look further into W11.

Hello GWeck,

i installed both Windows 10 and Windows 11 in Qubes 4.2 without any problems.

I use the qubes-windows-tools 4.1.69-1 https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm (see the article in Qubes Windows Tools (QWT) | Qubes OS). These must be installed in dom0 via dnf after the download.

In the file /etc/dnf/dnf.conf you should add the entry exclude=qubes-windows-tools so that a dom0 update does not overwrite the package.

After installing the package you can start the qube with qvm-start [VMname] --install-windows-tools in a dom0-terminal and install the qube tools in the windows qube. Don’t forget to select all packages in the setup.

QWT 4.1.69-1 is the old (possibly, according to QSB-091, compromised) version. The version I am testing here is the alpha version of its planned successor, which will also provide the seamless mode that, so far, is not available for W10 and W11.

2 Likes

Thank you for being “on the front line” for all of us the rest!

2 Likes

I don’t know if I’m the only one, but for me the biggest problem with v4.1.6x drivers is that I cannot achieve USB speeds greater than v.3.0, meaning not above ~30MB/s.
Huge letdown… Let’s hope new drivers will allow 3.1 and 3.2 Gen1, Gen2 speeds you name them… Thunderbolt 4? Wishful thinking as for now…

I have now checked with Windows 11, and so far, the results do not look very promising. I used two different W11 versions: 24H2, where QWT 4.1.69 was installed and removed before the tests, and 23H2, where QWT was never before installed.

In both systems, the installation of QWT could be started and ran up to the start of the QWT services, where it stalled like in Windows 7. Trying to start the services manually again produced the Windows errors 1075 and 1068, and the installation had to be aborted.

On the system that had QWT installed previously, there was a marked difference to W7 and W10: In W11, some Xen components were not removed during uninstallation of QWT. Trying to remove them manually puts the system into an inconsistent state. W11 detected this during the next boot, tried to repair it automatically, and thereby rendered the system unbootable, i.e. ruined it completely.

I am not too sure if this inability to install QWT in W11 makes the situation any worse: Even without QWT, the system is quite unusable due to its slowness and bad UX design. From a productivity point of view, W7 is still superior to its successors, and if you start thinking about privacy … :rage:

1 Like

IMHO, the priority should be W11, since it will be the only non-EOL version soon. If there’s extra time after ensuring good W11 support, then feel free to work on W10 support. If there’s still extra time after that, then by all means go even further back and work on W7 support.

But, whatever you do, don’t end up in the backwards situation where W10 is supported while W11 is not, just as W10 approaches EOL (or, heaven forbid, the even worse scenario in which only W7 is supported).

People keep mentioning old hardware and software that only works with older versions of Windows as a reason for Qubes to support old Windows versions, but this ignores the fact that all baremetal Windows users (who outnumber Qubes users by ~1.6 billion) have already had to deal with these problems in one way or another, usually by replacing their old hardware and software or by installing some kind of compatibility layer into a newer version of Windows. There are already plentiful solutions to this problem in the marketplace. This always happens whenever a version of Windows reaches EOL. It’s been like this since the '80s, and it will happen again later this year when W10 reaches EOL.

Would it be nice if Qubes provided a better solution than the multi-trillion-dollar Microsoft Corporation can provide itself? Of course, but Qubes dev time is precious, and it should be carefully spent to deliver the biggest impact possible for Qubes. The core value of Qubes OS (and what sets it apart from other operating systems in the market) is security, not support for old printers.

4 Likes

Until WinVMs are offline, I can directly quote @adw defending whichever EOL fedora he did for dom0 (too lazy to find the qoutes).
I’m not disputing most recent reasoning, on the contrary.
And, my Win11 tiny is blazing fast on NVIDIA. Never meant to use it on iGPU, anyway.