Testing Windows and QWT in R4.1

What the point of Windows VM without any 3D acceleration support?

Security?

1 Like

Definitely security.

What’s the point of Windows?

Hello, you wrote:

I checked now the new version 4.1-65 of QWT under Qubes R4.1,

Where, may I ask, are you getting this version? When I build @fepitre 's crossbuild I get a file called qubes-windows-tools-4.1-1.noarch.rpm which sounds 64 revisions older (and when installed shows same vesion number). There is a file from @ooooooooo above your message https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm but this is now 404.

You need to use the upstream repo: https://github.com/tabit-pro/qwt-crossbuild, the repo you refer is an outdated fork from https://github.com/tabit-pro :wink:

2 Likes

Little correction https://github.com/tabit-pro/qubes-windows-tools-cross :slight_smile:

This repo is adapted to qubes-builder

1 Like

Thanks @jevank @fepitre! I did get it built and installed into win10. And now working! Well, at least it can move files, haven’t done much else :slight_smile:

I did have to do a “repair” second run of the installer to get things working, not sure why - possibly because I did not have Windows updates (going back to September) installed the first time. (I also did not have qvm-features VMNAME gui 1 set at that point but I am guessing that should only affect dom0 not the win10 qwt install.)

Thanks again.

1 Like

It took me a while to find out this part was missing.

@adw, you think this should be mentioned in the https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-vm.md#simple-windows-install ?

I don’t know enough to answer that question. I’m only the one who copied/moved the documentation there, not the one who wrote it.

I think you should add it. It will be useful.

I think you should add it. :slight_smile:

The documentation is a community effort, and the community documentation even more so.

1 Like

I´d love to contribute.

I have not done this before, but will do this now. Thanks for steering me into this direction.

3 Likes

The documentation on installing Windows and Qubes Windows Tools has been extended to cover Qubes version R4.1. See Windows qubes. Hopefully, this covers most of the problems discussed here - if not, just give me notice.

6 Likes

Thanks for a great resource. Since its title has word “Using” in it, maybe disposables should be covered too? I haven’t tested it with versions of Windows other than Win7.

Also, should Windows and sys-audio should be covered?

It’s not clear to me how this solution for Windows dispVMs works. I tried the standard way with a Windows 11 dispVM to open a PDF file, and the behavior was the same: The dispVM started alright, but then closed without executing anything. Using a Fedora-based dispVM worked, however, as expected.

Could you perhaps provide a short text on using Windows-based dispVMs? I’ll gladly include it in the documentation.

As to sys-audio, I am somewhat hesitating. This still is, like sys-gui, a very experimental feature, and I think it should currently be left out of the main Windows documentation. Possibly it might be better to create a new theme on sys-audio and sys-gui, put that as a separate chapter into the documentation and then link from the Windows part it it. What do you think about that?

The whole point is command line program to be started first, and everything else works then. Logical choice is cmd.exe.

So in a win-template is to be put in a ProgramData/Startup folder shortcut to cmd.exe and to shut down the template. Then , and only then to create win-dvm-template in a standard way, not before that.

[user@dom0 ~]$ qvm-create --template win-template --label red win-dvm-template
[user@dom0 ~]$ qvm-prefs win-dvm-template template_for_dispvms True
[user@dom0 ~]$ qvm-features win-dvm-template appmenus-dispvm 1

Open its Settings again then choose Default disposable template - itself. Back to win-template and choose win-dvm-template for Default disposable template, too (the latter is not mandatory, but naturally).

Now we should get Disposable: win-dvm-template entry in the Apllication menu.

If applications aren’t listed there, they’re neither listed in win-dvm-template, so we need to Refresh applications in win-dvm-template, so we could get list in Disposable: win-dvm-template too.

If this doesn’t work for some reason, we can try to create correspondent desktop file in dom0’s /home/user/.local/share/qubes-appmenus/win-dvm-template/apps.templates/Accessories-cmd.desktop:

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
X-Qubes-VmName=%VMNAME%
X-Qubes-AppName=Accessories-cmd
Icon=%VMDIR%/apps.icons/Accessories-cmd.png
Name=%VMNAME%: Accessories cmd
Comment=
Categories=X-Qubes-VM;
Exec=qvm-run -q -a --service – %VMNAME% qubes.StartApp+Accessories-cmd
X-Qubes-DispvmExec=qvm-run -q -a --service --dispvm=%VMNAME% – qubes.StartApp+Accessories-cmd

and/or (didn’t test neither because Refresh worked for me out of a box)

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
X-Qubes-VmName=win-dvm-template
X-Qubes-AppName=Accessories-cmd
Icon=/home/user/.local/share/qubes-appmenus/win-dvm-template/apps.icons/Accessories-cmd.png
Name=win-dvm-template: Accessories cmd
Comment=
Categories=X-Qubes-VM;
X-Qubes-NonDispvmExec=qvm-run -q -a --service – win-dvm-template qubes.StartApp+Accessories-cmd
Exec=qvm-run -q -a --service --dispvm=win-dvm-template – qubes.StartApp+Accessories-cmd

in /home/user/.local/share/qubes-appmenus/win-dvm-template/apps/org.qubes-os.dispvm.win-dvm-template.Accessories-cmd.desktop

Either way, we want to assure to get an entry in application menu for cmd.exe.

Now, there are 2 use cases of such dispxxxVMs:

  1. If we want to start dispVM directly from the Application menu, we have to choose command line program there - cmd.exe. When started, such dispVM will have 2 cmd windows opened: one from the startup folder and the other one from our choice on start up. If we try to start any GUI program, it will not work regardless of the fact cmd.exe is in startup folder. We can now close one instance of cmd.exe. Annoyance a bit, but it works. From here, WIN key and the menu opens and we can use DVM as needed.
  2. If we are in some other win or any other Linux based VM for which we choose win-dvm-template as default disposable VM, viewing/copying/editing works well and only one instance of cmd.exe will be opened prior to GUI editing/viewing program - the one from the Startup folder ensuring win-dispxxxVM will be started and functional.

Final remark: such win based dispxxxVMs will not be shutdown automatically by closing first opened program (meaning cmd.exe) like Linux based disposables would be and I didn’t investigate the possibility to overcome this yet. Hopefully, someone might be able to help with this. Until then, and instead, these disposables have to be shutdown via WIN key -> Shutdown regular Windows procedure.

I’ll be glad to further clarify, being aware that my English is far from good.

1 Like

I agree, but then again why we couldn’t just bold it with font size 36: Warning, experimental feature. There’s no documentation about sys-audi/gui at all and someone has to be first. So, why us “Windowers” wouldn’t be the first ones, hahah.
I assure you that it’s more than easy to create sys-audio and it works out of a box, beautifully and fluently.

Please do not consider this post as insisting or forcing, it just tends to clarify and demystify things. I am absolutely aware from psychology that the first reaction on any innovation is resistance, at least for a split second, but it’s unavoidably always the first one (I guess @adw would confirm this, :slight_smile: ).

It is important that it works and that we have a resource to reference to for now - quoted topic from my post above.

The sys-audio theme is still rather unclear to me. I tried to create an audio VM using qubesctl top.enable qvm.sys-audio and got a qube with my audio device attached to it. Is that the new audio VM?

Setting qvm-prefs <VMname> audiovm sys-audio for some Linux-based VM works, but not for a Windows-based VM, as is to be expected. In order to make it work, the stubdomain patch is obviously needed, or, preferrably, the method suggested by @marmarek:

You can use qemu cmdline (like we do for IP config already), which makes libvirt/libxl patching not needed.

But was has to be done exactly? For me, with about zero Linux knowledge, this is somewhat confusing…

I am still experimenting on this. So far, a Windows 7 dispvm can be used from Windows and Linux qubes. There was no need to create the .desktop files - the menu entries were created alright on entering qvm-sync-appmenus <VMname> - trying to refresh the menus from the GUI once crashed the Qube Manager. Afterward, I could refresh the menus from the Qube Manager, too.

The Disposable: menu currently shows only one entry (for the IrfanView application !???), while the other entries only show in the Template (disp): menu. When I start this entry, the application starts well in a dispvm, and when I close this application, the dispvm shuts down. On using the dispvm from some other (Windows or Linux) VM, the dispvm does not shut down after closing its application.