Open caschulz88 opened 8 years ago
- [ ] Capturing Start Menu and notifications (partial - works, but those windows have weirdly huge transparent areas that need to be detected and discarded)
Do you expect this to be a performance problem in practice? This is a great candidate for SIMD acceleration.
At least the start menu should be negligible, since it occupies a fixed space on the screen. The values for that can be hardcoded (boundaries of the visible window), no detection required.
I was not aware of that, which probably shows how long it has been since I used Windows.
At least the start menu should be negligible, since it occupies a fixed space on the screen.
In Windows 10, position and size of the start menu may be chaned, and in Windows 11, at least the position may be changed.
For both systems, there are alternative start menus, like ClassicShell, available, which may behave differently.
If possible, compatibility with Windows 7 should be checked/achieved, for at least two reasons:
In some environments, usage of Windows 10 / 11 may be illegal; e.g. when working with personal data in Europe, the telemetry used in these systems will collide with the legal requirements of the GDPR. So usage of these systems is forbidden in several application areas in some countries/regions, e.g. in schools in some areas of Germany.
Windows 10 and 11 are significantly slower than Windows 7 under Qubes,
Usage of Windows 7 under Qubes poses no additional security risk, as the system can be shielded against attacks from the net. So the lack of further support from Microsoft may not have significant effects on this system, and its use is still a good option if one is forced to use Windows.
From qubes isuue #9102: Windows qubes imported from R4.1.2 to R4.2.1 should retain their complete functionality or, alternatively, EOL of R4.2.1 should be postponed until such functionality is available under Qubes R4.2.1.
Hopefully, if the work described here proceeds successfully, QWT will be available before Qubes R4.1 EOL. :smile:
If possible, compatibility with Windows 7 should be checked/achieved, for at least two reasons:
- In some environments, usage of Windows 10 / 11 may be illegal; e.g. when working with personal data in Europe, the telemetry used in these systems will collide with the legal requirements of the GDPR. So usage of these systems is forbidden in several application areas in some countries/regions, e.g. in schools in some areas of Germany.
In these cases I would expect the use of Windows 10/11 Enterprise or Education, which allows telemetry to be completely turned off. Otherwise, there are no officially supported solutions other than blocking Microsoft telemetry servers at the DNS or proxy level.
- Windows 10 and 11 are significantly slower than Windows 7 under Qubes,
Usage of Windows 7 under Qubes poses no additional security risk, as the system can be shielded against attacks from the net. So the lack of further support from Microsoft may not have significant effects on this system, and its use is still a good option if one is forced to use Windows.
The only time I can think of where Windows 7 is safe is when the system is permanently offline and never receives untrusted input. A permanently offline system will never be able to transmit telemetry data, though.
Windows 7 compatibility would still be useful, especially as it comes to playing older windows games in net-isolated VMs. But I'd also be an advocate for seamless mode and file transfer in XP for the same reason, so I'm not certain I'm the ideal audience to chip in on backwards compatibility (as most of my games are Visual Novels, and I'd REALLY like them to run well and seamlessly on qubes)
Even if Windows telemetry itself is turned off, e.g. when using an education or an LTSC license, the use of this system is forbidden in the context of Microsoft 365 containing Office and other components like the Smart Screen checker. Turning access to Microsft servers off, as is sometimes suggested, does not work either: The telemetry functions access dozens of IP addresses that are permanently changing. So the only possibility to use the system in a legal way would be to block Internet access completely and allow access only to selected addresses via a whitelist, as can be done in Qubes. This, however, is no practical solution, because in smaller institutions there is no personnel available/able to maintain these lists.
For Windows, there are scenarios where the system is isolated from the Internet but allows local networks. This is allowed and, even for Windows 7, moderately secure. Working with the different Windows versions, I would not regard Windows 10 Internet access as any more secure than that of Windows 7 - both are crap, no matter what Microsoft tells. If you are using Windows 10, currently your system may be open to the Russian Midnight Blizzard hackers who stole important access tokens months ago - and Microsoft is not able to get them out.
So, in my opinion, it is extremely important to have good Windows support in Qubes. I see no other way to use Windows securely. Even if, as QSB-091 states, QWT is of doubtful security, this is still much better than using Windows natively, on bare metal.
With Windows 10 and 11, two other nuisances have crept up in the last few days:
Since the last update (?), Windows 10 sometimes shows a pop-up window trying to talk you into changing to Windows 11 - even if the same system tells you that your hardware will not support this system. Is this just an attempt to create additional electronic waste, or what?
According to a former Microsoft engineer, the performance of Windows 11 is rather bad - something that I observed for a Windows VM running under Qubes, too.
So where are you going if you are forced to use Windows for some tasks?
I have windows 7 with multi-monitor config and in older Qubes I used the "debug mode + qubes gui driver", with seamless GUI disables" to get two separate windows that act (mostly successfully) as two monitors and can be placed around my multi-monitor setup as I see fit
I would be very grateful if @omeg were to implement something to allow this kind of usecase. Stretching a single "virtual monitor" window (I don't use seamless mode much, prefer to keep all things windows as separate desktops) over multiple physical monitors is extremely punishing
Us multi-monitor users deserve happiness too :smile_cat:
Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.
Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.
Yes, it should be available for user testing soon.
Looking forward to that. And if anyone has any hints as to how to get a "modernish" windows going in multi-monitor mode (as in, spawn 2+ different windows each of which is essentially a "monitor" in context of windows multi-monitor behavior, a-la what I could have gotten with Windows 7 running QGA+Debug-mode) I would greatly appreciate it and gladly test it.
Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.
Yes, it should be available for user testing soon.
Sorry for bugging, but when you are expecting release?
Latest updates
Alright, since I (@omeg) have been working on this for a while now and finally it's in a state that will allow for user testing soon, here is the current status of Windows 10/11 support. More items might be added in case I forgot something.
All of the current code is here: https://github.com/omeg/qubes-installer-windows-tools/tree/omeg/win10 Don't use on production VMs, it's not ready yet. Make sure to set the
default-user
property for the qube manually as appropriate (https://github.com/QubesOS/qubes-issues/issues/9020).TODO:
qvm-run
with passthrough i/oNice to have (will most likely be done after an initial release):
Known issues (will be added to github once the code is merged):
Original issue text
Hi, I was wasn't able to find any already opened issue about this topic so I'm creating one right now. In all documentation on qubes-windows-tools there is always only the information that newer Windows versions than Windows 7 are in development. Can anyone please clarify what exactly this means? Do we have a roadmap or special features, which are missing at the moment? Because the MSI installer has a hard check for Windows 7 version in it I wasn't able to run the installer on Windows 8 and Windows 10 in comatibility mode (as the user cannot specify a specific Windows version in compatibility mode as he could do when running some executable file). I bet there are some reasons to include such a check there. Would be great to have this list posted here. I'm also willing to help to get support for Windows 8 and 10 of course!