Explore possibility to create ReactOS-based template for Qubes

[rootkovska]

Inspired by this thread: https://twitter.com/reactos/status/863673534710788096

Idea is to distribute ReactOS-based template for Windows AppVMs for Qubes. Specifically a template optimized to run specific MS Windows applications, such as MS Office.

In Qubes 4.1 or 4.2, i.e. when we will have GUI domain, we could even consider using RactOS as an alternate GUI domain, to provide some users with familiar Windows look and feel.

Potential benefits:

1. Seamless integration for Windows-based AppVMs done right. We have faced lots of troubles when implementing proper seamless mode for MS Windows-based AppVMs. On Linux-based (X-based) AppVMs, we can easily get addresses of all the windows composition buffers and send their PFNs to our GUI daemon, which provides a very nice, native look and feel. However this task seems undoable on MS Windows because of undocumented win32k internals. AFAIK no body else, i.e. no other VMM vendor, has implemented proper seamless mode for Windows VMs. Most (all?) attempts revolve around cutting rectangles from one framebuffer, which has many disadvantages: 1) non-zerocopy, so slower, 2) visible artifacts when one moves overlapping windows, 3) occasional difficulty in determining windows structuring.

2. ReactOS is GPL and BSD licensed according to the project wiki [1]. This is a great benefit in itself in a few ares: transparency (think: backdoors), easy of tinkering (think: better integration with Qubes), ability to distribute freely, no need for users to worry about licenses (yet still would need to have licenses e.g. for MS Office).

[1] http://www.reactos.org/wiki/ReactOS

3. Possibility to create much lighter (i.e. with smaller memory footprint) Windows AppVM, likely due to ability to customize (disable) unneeded stuff.

Steps to proceed:

• determine if there is joint interest between ReactOS devs and Qubes
• determine resources needed (developer-months), discuss funding possibilities
• sketch roadmap
• apply for funding

Likely stages of creating ReactOS-based template:

• Run in Qubes HVM (should just work)
• Try porting qrexec and all Qubes Tools, except for the GUI agent, run in full desktop mode
• Ensure works well as Qubes template (i.e. root/system filesystem separated from "home dir")
• Write GUI agent

Many of these tasks could likely be directly copied from our MS Windows Qubes Tools:
https://github.com/QubesOS/qubes-core-agent-windows
https://github.com/QubesOS/qubes-windows-utils
https://github.com/QubesOS/qubes-vmm-xen-windows-pvdrivers
https://github.com/QubesOS/qubes-builder-windows
https://github.com/QubesOS/qubes-gui-agent-windows (with not-so-great seamless mode)

[erkinalp]

ReactOS corresponding issue https://jira.reactos.org/browse/CORE-13358

[erkinalp]

ReactOS corresponding issue https://jira.reactos.org/browse/CORE-13358

[Jeeppler]

I created a ReactOS HVM in QubesOS. The VM worked out of the box. I tested several applications and functionalities to evaluate potential use cases. Software developed for Windows XP and before works. However, there is no guarantee that software will work. The QubesOS community should work with the ReactOS community to evaluate which use cases and scenarios would be important to support. Skype, Adobe Reader and MS Office support are some of the use cases I had in mind, but maybe there are more. It would be helpful to create a simple survey on the mailing list or something like that to figure out what the community wants.

One issue which I run into was that I had to use the VirtualBox image and convert the .vhd file into a raw .img file to use ReactOS, because the live and iso edition did not work and the QEMU version is not an image file. The problem with the VirtualBox image is the size. After converting the .vhd file to a raw .vhd file the image was 20 GB in size. I assume the .vhd file uses a dynamically allocated VirtualBox harddrive type. The first thing I would like to see is an image for Qubes OS. This is something where the ReactOS and QubesOS community could immediately work together.

Tested:

• Internet connection: works out of the box

• Sound: does not work

• Playing videos youtube: works well in firefox

• USB Pass-through: does now work

• Window resizing in ReactOS works

• Microphones cannot be attached

• Games:

  • Pingus (works)
  • Age of Empires Demo (works)
  • Anno 1602 Demo (works)
  • Stronghold Demo (works well)
  • Cossacks European Wars (mouse does not work)
  • Empire Earth Demo (memory error)
  • Soldier of Fortune 2 (error needs OpenGL)
  • Praetorians (does not work)

• PDF reader:

  • Adobe Reader 11 (Connection fails)
  • Adobe Reader 9 does not work (rendering issues)

• Haxe Development: FlashDevelop

  • Requires at least .Net 3.5
    • Can be downloaded (XP version)
    • Installation of .Net 3.5 fails

• VoIP:

  • Skype: Has problems while installing and running (Skype 7.3.6)

• Reverse Engineering:

  • IDA 5.0 Freeware (works)

• Password Safe:

  • Keepass 2.3 (error during installation)
  • Keepass 1.3 (works)

• 512 MB RAM are enough to run ReactOS smooth

• Startup and shutdown are fast

Note: The author's computer does not have Intel VT-d

Feel free to look at my notes if you want to reproduce my setup or you want to have more information.

[Jeeppler]

I created a ReactOS HVM in QubesOS. The VM worked out of the box. I tested several applications and functionalities to evaluate potential use cases. Software developed for Windows XP and before works. However, there is no guarantee that software will work. The QubesOS community should work with the ReactOS community to evaluate which use cases and scenarios would be important to support. Skype, Adobe Reader and MS Office support are some of the use cases I had in mind, but maybe there are more. It would be helpful to create a simple survey on the mailing list or something like that to figure out what the community wants.

One issue which I run into was that I had to use the VirtualBox image and convert the .vhd file into a raw .img file to use ReactOS, because the live and iso edition did not work and the QEMU version is not an image file. The problem with the VirtualBox image is the size. After converting the .vhd file to a raw .vhd file the image was 20 GB in size. I assume the .vhd file uses a dynamically allocated VirtualBox harddrive type. The first thing I would like to see is an image for Qubes OS. This is something where the ReactOS and QubesOS community could immediately work together.

Tested:

• Internet connection: works out of the box

• Sound: does not work

• Playing videos youtube: works well in firefox

• USB Pass-through: does now work

• Window resizing in ReactOS works

• Microphones cannot be attached

• Games:

  • Pingus (works)
  • Age of Empires Demo (works)
  • Anno 1602 Demo (works)
  • Stronghold Demo (works well)
  • Cossacks European Wars (mouse does not work)
  • Empire Earth Demo (memory error)
  • Soldier of Fortune 2 (error needs OpenGL)
  • Praetorians (does not work)

• PDF reader:

  • Adobe Reader 11 (Connection fails)
  • Adobe Reader 9 does not work (rendering issues)

• Haxe Development: FlashDevelop

  • Requires at least .Net 3.5
    • Can be downloaded (XP version)
    • Installation of .Net 3.5 fails

• VoIP:

  • Skype: Has problems while installing and running (Skype 7.3.6)

• Reverse Engineering:

  • IDA 5.0 Freeware (works)

• Password Safe:

  • Keepass 2.3 (error during installation)
  • Keepass 1.3 (works)

• 512 MB RAM are enough to run ReactOS smooth

• Startup and shutdown are fast

Note: The author's computer does not have Intel VT-d

Feel free to look at my notes if you want to reproduce my setup or you want to have more information.

[Jeeppler]

I posted in the ReactOS forum to promote the idea of QubesOS + ReactOS a little in the ReactOS community: https://www.reactos.org/forum/viewtopic.php?f=2&t=16480

[Jeeppler]

I posted in the ReactOS forum to promote the idea of QubesOS + ReactOS a little in the ReactOS community: https://www.reactos.org/forum/viewtopic.php?f=2&t=16480

[rootkovska]

Thanks! Just a few comments:

1. Sound is not expected to work for any HVM at this moment, because... we don't have an audio agent for stubdoms yet. This also applies to mics, of course.

2. Similarly, qvm-usb is also not expected to work for HVMs generally. We're currently in the process of implementing qvm-usb support for Windows-based AppVMs, using USBIP drivers, similarly as we did for Linux AppVMs. Note these tools are to be installed within the Windows VMs (not in the stubdom) and are currently being developed for MS Windows, and likely will need some (hopefully minor) porting to run on ReactOS.

[rootkovska]

Thanks! Just a few comments:

1. Sound is not expected to work for any HVM at this moment, because... we don't have an audio agent for stubdoms yet. This also applies to mics, of course.

2. Similarly, qvm-usb is also not expected to work for HVMs generally. We're currently in the process of implementing qvm-usb support for Windows-based AppVMs, using USBIP drivers, similarly as we did for Linux AppVMs. Note these tools are to be installed within the Windows VMs (not in the stubdom) and are currently being developed for MS Windows, and likely will need some (hopefully minor) porting to run on ReactOS.

[rootkovska]

Also, some apps I personally consider useful (and which have essentially no Linux alternatives, so one is destined to use Windows to get their functionality):

1. iTunes -- very useful for offline syncing and provisioning iPhones and other iOS devices.

2. Skydemon (for VFR pilots): http://www.skydemon.aero/start/

[rootkovska]

Also, some apps I personally consider useful (and which have essentially no Linux alternatives, so one is destined to use Windows to get their functionality):

1. iTunes -- very useful for offline syncing and provisioning iPhones and other iOS devices.

2. Skydemon (for VFR pilots): http://www.skydemon.aero/start/

[v6ak]

- USB Pass-through: does now work (author's computer don't have Intel VT-d)

Do you mean USB passthrough, or PCI passthrough of USB controller? USB passthrough would be surprising to work without any further modification of guest OS and it is unrelated to VT-d. PCI passthrough should theoretically work to the same degree as the USB controller works with ReactOS on bare metal.

[v6ak]

- USB Pass-through: does now work (author's computer don't have Intel VT-d)

Do you mean USB passthrough, or PCI passthrough of USB controller? USB passthrough would be surprising to work without any further modification of guest OS and it is unrelated to VT-d. PCI passthrough should theoretically work to the same degree as the USB controller works with ReactOS on bare metal.

[v6ak]

I've tried ReactOS in HVM. Installation was pretty fast, oldschool and without serious issues. It also boots very quickly. The usage itself was like… Well, what's ReactOS advantage over Wine? First, I have tried to install Firefox. The repository contains pretty outdated versions (I haven't checked if there is any verification of signatures, just tried it and believed everything will be OK). OK, let's install some old version, Firefox updater will make it up-to-date. Yes, updater works pretty automatically, but updated Firefox doesn't. So, I can browse the Internet just with some browser without recent security updates. I've tried installing DeeControl, and I got probably slightly further than with Wine. But a short while later, I got a BSOD. Never mind, let's try it again. ReactOS hasn't written some changes (DeeControl wasn't even downloaded), but let's try it again. The result is, sadly, the same. I also had various minor issues, most prominently desynced mouse cursors. (Workaround: hit the edges of virtual screen, cursors get synces.) I also had some graphic artifacts and one boot-time freeze. Well, I see there must have been huge amount of work done, but frankly, I don't see much practical benefits. Wine is subjectively more stable and Qubes integration is for free. ReactOS in QubesOS might have some niche (maybe for applications that need USB and few other apps), but my experience hasn't been much encouraging. When needing some Windows app, I'd probably try Wine before ReactOS, even if ReactOS integration to Qubes was already done.

[v6ak]

I've tried ReactOS in HVM. Installation was pretty fast, oldschool and without serious issues. It also boots very quickly. The usage itself was like… Well, what's ReactOS advantage over Wine? First, I have tried to install Firefox. The repository contains pretty outdated versions (I haven't checked if there is any verification of signatures, just tried it and believed everything will be OK). OK, let's install some old version, Firefox updater will make it up-to-date. Yes, updater works pretty automatically, but updated Firefox doesn't. So, I can browse the Internet just with some browser without recent security updates. I've tried installing DeeControl, and I got probably slightly further than with Wine. But a short while later, I got a BSOD. Never mind, let's try it again. ReactOS hasn't written some changes (DeeControl wasn't even downloaded), but let's try it again. The result is, sadly, the same. I also had various minor issues, most prominently desynced mouse cursors. (Workaround: hit the edges of virtual screen, cursors get synces.) I also had some graphic artifacts and one boot-time freeze. Well, I see there must have been huge amount of work done, but frankly, I don't see much practical benefits. Wine is subjectively more stable and Qubes integration is for free. ReactOS in QubesOS might have some niche (maybe for applications that need USB and few other apps), but my experience hasn't been much encouraging. When needing some Windows app, I'd probably try Wine before ReactOS, even if ReactOS integration to Qubes was already done.

[rootkovska]

FWIW, last time I tried Wine (IIRC in Debian 8 AppVM) I was disappointed by the very slow GUI. Admittedly I tested this on a GUI intensive software (the previously mentioned SkyDemon), but the very same software ran much faster on native Windows 7-based AppVM.

[rootkovska]

FWIW, last time I tried Wine (IIRC in Debian 8 AppVM) I was disappointed by the very slow GUI. Admittedly I tested this on a GUI intensive software (the previously mentioned SkyDemon), but the very same software ran much faster on native Windows 7-based AppVM.

[marmarek]

Have you tried this on Fedora? Debian 8 have _very_ old version...

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

Have you tried this on Fedora? Debian 8 have _very_ old version...

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[rootkovska]

IIRC, there was a specific reason I decided to try on Debian, but I don't remember now what that was... I should try this at some point on Fedora, maybe on 25th this time ;)

[rootkovska]

IIRC, there was a specific reason I decided to try on Debian, but I don't remember now what that was... I should try this at some point on Fedora, maybe on 25th this time ;)

[Jeeppler]

@v6ak what is DeeControl? Could you provide a link to the software.

[Jeeppler]

@v6ak what is DeeControl? Could you provide a link to the software.

[Jeeppler]

@v6ak What method/medium did you use to install ReactOS?

[Jeeppler]

@v6ak What method/medium did you use to install ReactOS?

[Jeeppler]

For me the top reasons to support ReactOS are:

1. No license issues
2. Running old applications from the Windows XP era and before
   • Specific application which only or still run on Windows XP and before
   • Games
   • Device software (Printer/Scanner)
   • Development tools made for XP
3. Education
   • Learning about Windows internals

[Jeeppler]

For me the top reasons to support ReactOS are:

1. No license issues
2. Running old applications from the Windows XP era and before
   • Specific application which only or still run on Windows XP and before
   • Games
   • Device software (Printer/Scanner)
   • Development tools made for XP
3. Education
   • Learning about Windows internals

[AS383]

You can find more information about tested APPs on current ReactOS release: https://www.reactos.org/wiki/Tests_for_0.4.5
About Wine. There are some ugly hacks. For example Wine creates some registry keys "on the fly" if they doesn't exist. This hacks can introduce some regressions in future. It is the reason why ReactOS developers clear Wine code before importing it into trunk. The pay is making some applications unsuported.

[AS383]

You can find more information about tested APPs on current ReactOS release: https://www.reactos.org/wiki/Tests_for_0.4.5
About Wine. There are some ugly hacks. For example Wine creates some registry keys "on the fly" if they doesn't exist. This hacks can introduce some regressions in future. It is the reason why ReactOS developers clear Wine code before importing it into trunk. The pay is making some applications unsuported.

[Jeeppler]

Here are more testing results:

• iTunes 12.1.3.6 32-bit (works until "registering modules" phase in the installation)
  • I assume registry key issues
• Skydemon 3.8.1 (installer: works, application can not be started)
  • Requires .NET Framework 2.0 -> can be found in ReactOS Application repo

Games:

• Robin Hood - The Legend of Sherwood Demo (installation: works, game hangs at start screen)
• Wild Life Park Demo (installer does not work -> does not recognize language)
• GTA 2 Demo (installer errors, fails afterwards)
• Stronghold Crusader Multiplayer Demo (works well)
• Age of Empires II: Age of Kings Demo (installation: no sound card warning, game works)
• Battlefield 1942 Multiplayer Demo (installer hangs)

[Jeeppler]

Here are more testing results:

• iTunes 12.1.3.6 32-bit (works until "registering modules" phase in the installation)
  • I assume registry key issues
• Skydemon 3.8.1 (installer: works, application can not be started)
  • Requires .NET Framework 2.0 -> can be found in ReactOS Application repo

Games:

• Robin Hood - The Legend of Sherwood Demo (installation: works, game hangs at start screen)
• Wild Life Park Demo (installer does not work -> does not recognize language)
• GTA 2 Demo (installer errors, fails afterwards)
• Stronghold Crusader Multiplayer Demo (works well)
• Age of Empires II: Age of Kings Demo (installation: no sound card warning, game works)
• Battlefield 1942 Multiplayer Demo (installer hangs)

[Jeeppler]

In addition I tested the Xen PV Driver:

https://www.xenproject.org/developers/teams/windows-pv-drivers.html

• all driver installed without showing any visible error
• can't load drivers xenbus.sys and xenfilt.sys -> system start

However, I don't know how to test if the device driver are working.

[Jeeppler]

In addition I tested the Xen PV Driver:

https://www.xenproject.org/developers/teams/windows-pv-drivers.html

• all driver installed without showing any visible error
• can't load drivers xenbus.sys and xenfilt.sys -> system start

However, I don't know how to test if the device driver are working.

[v6ak]

@Jeeppler I've installed ReactOS from BootCD. I've missed Advanced downloads at https://www.reactos.org/download . Well, now I read it did not work for you.

DeeControl is controlling software for be3D 3D printers: https://www.ysoft.com/cs/support-and-download

[v6ak]

@Jeeppler I've installed ReactOS from BootCD. I've missed Advanced downloads at https://www.reactos.org/download . Well, now I read it did not work for you.

DeeControl is controlling software for be3D 3D printers: https://www.ysoft.com/cs/support-and-download

[v6ak]

BTW, the qemu download also contains an image (ReactOS.vmdk). I've converted both VirtualBox and QEMU images and it does not look like there are much differences. The VHD is larger, has more users, additional Internel Explorer and some probably rather formal differences (different time in log files etc.). Maybe in ReactOS/system32/config, there can be some important difference, but a brief look via vbindiff does not suggest any real difference.

Screenshot of directory diff (with excluded differences in Documents and Settings):

So, there might be no reason to try the QEMU image.

[v6ak]

BTW, the qemu download also contains an image (ReactOS.vmdk). I've converted both VirtualBox and QEMU images and it does not look like there are much differences. The VHD is larger, has more users, additional Internel Explorer and some probably rather formal differences (different time in log files etc.). Maybe in ReactOS/system32/config, there can be some important difference, but a brief look via vbindiff does not suggest any real difference.

Screenshot of directory diff (with excluded differences in Documents and Settings):

So, there might be no reason to try the QEMU image.

[blackcrack]

Hi Joanna :)
(sorry for my bad english)
i have read what you have wrote on the top, you have the Factory Microsoft in the hand if you think about WinNT, but it is wrong *imho* we have now a WinNT, so an Windows Network OS as better to say a its a Surface Programmed, Gui Related Ordering System and belongs not only the Factory Microsoft(with their Facility's in the background *g*) so it is possible to have an WinNT with
WindowsApi in a Community also, like the Linux Communitys, so have maybe canonical ubuntu as a debian related Distribution, but exist other Community's also like OpenMandriva.org (with clang) and other Community's of a Distributions be also Linux (by side the "linux" it is the kernel with other tools as Distribution) , so it is this Reactos an WinNT Community where work together with the community of Wine where programming Windows Api's and this be what also used in Reactos.org as Community work together.. (only to bring out of your Brain the word "MS" , because all what do you association together with Microsoft it is also a advertising for the Factory in Redmond and we want not support this factory, isn't it ? :) *g* we want give the peoples something better .. and more honest and less commerce ..)

edit: and by the way you can download daily Builds, => head page, right-sided, more down, clicking on "Daily Builds" => "Download here!" this link it is for you interesting, because they are the daily Builds iso into 7Zip's (you can also write into the Revision textbox "75000 - 75070" with this become you all iso's from 75000 up to 75070 to see..

best regards
Blacky

[blackcrack]

Hi Joanna :)
(sorry for my bad english)
i have read what you have wrote on the top, you have the Factory Microsoft in the hand if you think about WinNT, but it is wrong *imho* we have now a WinNT, so an Windows Network OS as better to say a its a Surface Programmed, Gui Related Ordering System and belongs not only the Factory Microsoft(with their Facility's in the background *g*) so it is possible to have an WinNT with
WindowsApi in a Community also, like the Linux Communitys, so have maybe canonical ubuntu as a debian related Distribution, but exist other Community's also like OpenMandriva.org (with clang) and other Community's of a Distributions be also Linux (by side the "linux" it is the kernel with other tools as Distribution) , so it is this Reactos an WinNT Community where work together with the community of Wine where programming Windows Api's and this be what also used in Reactos.org as Community work together.. (only to bring out of your Brain the word "MS" , because all what do you association together with Microsoft it is also a advertising for the Factory in Redmond and we want not support this factory, isn't it ? :) *g* we want give the peoples something better .. and more honest and less commerce ..)

edit: and by the way you can download daily Builds, => head page, right-sided, more down, clicking on "Daily Builds" => "Download here!" this link it is for you interesting, because they are the daily Builds iso into 7Zip's (you can also write into the Revision textbox "75000 - 75070" with this become you all iso's from 75000 up to 75070 to see..

best regards
Blacky

[marmarek]

Cross referencing: https://jira.reactos.org/browse/CORE-13358

[marmarek]

Cross referencing: https://jira.reactos.org/browse/CORE-13358

[ColinFinck]

I'm Colin, developer at the ReactOS Project, and I have discussed a possible ReactOS and Qubes collaboration with @marmarek and @woju at FOSDEM in February. I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

Apart from that, possible ideas for a collaboration include:

• Running Qubes drivers and tools on ReactOS, possibly porting them to NT 5.2 (what ReactOS is currently targeting at the kernel level) and fixing related bugs in ReactOS
• Improving ReactOS application compatibility towards specific applications (like MS Office)

These tasks should be of mutual interest to both projects.
Independent of Qubes, ReactOS developer @ThFabba also proposed a Google Summer of Code idea for improving paravirtualization support: https://reactos.org/wiki/Google_Summer_of_Code_2018_Ideas#Paravirtualization_Support
We don't expect a student to take the idea this summer, but the interest definitely exists in our project as well.

Furthermore, Qubes and ReactOS also fit well together from the organizational standpoint: ReactOS is backed by the German non-profit organization ReactOS Deutschland e.V. while Qubes has the Invisible Things Lab company behind it. ReactOS Deutschland e.V. is getting a lot of donations from individual people, however - as a non-profit - the only way for it to fund development is granting scholarships (up to ~1000 EUR/month) to students or hiring IT freelancers who invoice us. Hiring developers directly has never been an option for us, but this should be different for Invisible Things Lab.
That means, if we find a task of mutual interest and a suitable developer, the person may be hired by ITL and partly funded by ReactOS Deutschland e.V. (having ITL invoice ReactOS Deutschland e.V.).
Additionally, I was told that ITL may acquire some customers to pay for Windows application support on Qubes. This adds another source of funding to these tasks, which is currently unavailable to ReactOS Deutschland e.V.

Finally, @vicmarcal of the ReactOS Project also explored possible collaborations with your project earlier.
Adding him to this discussion.

[ColinFinck]

I'm Colin, developer at the ReactOS Project, and I have discussed a possible ReactOS and Qubes collaboration with @marmarek and @woju at FOSDEM in February. I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

Apart from that, possible ideas for a collaboration include:

• Running Qubes drivers and tools on ReactOS, possibly porting them to NT 5.2 (what ReactOS is currently targeting at the kernel level) and fixing related bugs in ReactOS
• Improving ReactOS application compatibility towards specific applications (like MS Office)

These tasks should be of mutual interest to both projects.
Independent of Qubes, ReactOS developer @ThFabba also proposed a Google Summer of Code idea for improving paravirtualization support: https://reactos.org/wiki/Google_Summer_of_Code_2018_Ideas#Paravirtualization_Support
We don't expect a student to take the idea this summer, but the interest definitely exists in our project as well.

Furthermore, Qubes and ReactOS also fit well together from the organizational standpoint: ReactOS is backed by the German non-profit organization ReactOS Deutschland e.V. while Qubes has the Invisible Things Lab company behind it. ReactOS Deutschland e.V. is getting a lot of donations from individual people, however - as a non-profit - the only way for it to fund development is granting scholarships (up to ~1000 EUR/month) to students or hiring IT freelancers who invoice us. Hiring developers directly has never been an option for us, but this should be different for Invisible Things Lab.
That means, if we find a task of mutual interest and a suitable developer, the person may be hired by ITL and partly funded by ReactOS Deutschland e.V. (having ITL invoice ReactOS Deutschland e.V.).
Additionally, I was told that ITL may acquire some customers to pay for Windows application support on Qubes. This adds another source of funding to these tasks, which is currently unavailable to ReactOS Deutschland e.V.

Finally, @vicmarcal of the ReactOS Project also explored possible collaborations with your project earlier.
Adding him to this discussion.

[marmarek]

Thanks for writing @ColinFinck !

I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

There are a little more technical details about the problem here: https://groups.google.com/d/msgid/qubes-users/20180318152707.GH8712%40mail-itl
In short: installation fails (either lack of disk drivers, or some weird crash - also in disk drivers?). But live image more or less works.

As of today, Windows support is pretty low on ITL's priority list, so it's unlikely we'll commit significant resources to it. But we're more than happy to help coordinating this work, review code, test things. There are also multiple people in Qubes community interested in this work, maybe someone is able to help here.

[marmarek]

Thanks for writing @ColinFinck !

I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

There are a little more technical details about the problem here: https://groups.google.com/d/msgid/qubes-users/20180318152707.GH8712%40mail-itl
In short: installation fails (either lack of disk drivers, or some weird crash - also in disk drivers?). But live image more or less works.

As of today, Windows support is pretty low on ITL's priority list, so it's unlikely we'll commit significant resources to it. But we're more than happy to help coordinating this work, review code, test things. There are also multiple people in Qubes community interested in this work, maybe someone is able to help here.

[vicmarcal]

Hi! Victor here. Aside the potential income stream from QubesOS customers willing to be running Windows software, there is a nice opportunity of several Horizon2020 R&D grant opportunities from the EU. These grants could be used to fund the R&D and integration needed for this project. These grants need 3 parties from different countries. The amount that can be requested are up to 3M$, covering 70% of the amount requested. (100% in case all the parties are non-profit ones). QubesOS+ReactOS would be 2, a 3rd one could be one of these potential final companies/customers as part of the pilot phase. This way we could leverage QubesOS plus ReactOS investment in this project.
I'm glad to help with anything related to H2020 Grants, and while this talk should follow up in private(in case we are both interested in it) just willing to highlight here this potential funding way that probably you're already aware.

[vicmarcal]

Hi! Victor here. Aside the potential income stream from QubesOS customers willing to be running Windows software, there is a nice opportunity of several Horizon2020 R&D grant opportunities from the EU. These grants could be used to fund the R&D and integration needed for this project. These grants need 3 parties from different countries. The amount that can be requested are up to 3M$, covering 70% of the amount requested. (100% in case all the parties are non-profit ones). QubesOS+ReactOS would be 2, a 3rd one could be one of these potential final companies/customers as part of the pilot phase. This way we could leverage QubesOS plus ReactOS investment in this project.
I'm glad to help with anything related to H2020 Grants, and while this talk should follow up in private(in case we are both interested in it) just willing to highlight here this potential funding way that probably you're already aware.

[blackcrack]

the Eu support is a good thing, good to hear/know ! :))

[blackcrack]

the Eu support is a good thing, good to hear/know ! :))