[vbox-dev] Windows 10 WDK/SDK and VCC 2019 toolset upgrade plans

[Klaus Espenlaub]

Hello Ribhi,

On 2020-06-25 06:06, Ribhi Kamal wrote:
> Hello VirtualBox,
> TL;DR; I noticed that there are attempts to get VirtualBox to compile
> using VS2017. I was hoping that you would be so kind as to share with
> me your plans (if any) to upgrade the tools for compiling VirtualBox
> for windows hosts and which WDK, SDK, VCC are you planning to upgrade
> to. I'm attempting to upgrade but to the latest of everything.

No point talking about this ongoing project until it is completed. The
result isn't clearly defined yet, and what's even less clear is when
this will hit the first release. It's not terribly likely (but also not
impossible) that it will be ever available for VirtualBox 6.1. It's the
nature of "trunk" that there are  unfinished projects where we cannot
make any commitments.

> The long version.
> About ~three month ago, a client reached out and requested that
> virtualbox drivers have complete secure boot support on Windows 10.
> This meant going through HLK since attestation did not provide
> complete support. Long story short, I agreed to give it a shot.

Can you please describe what's incomplete about attestation signing?
According to the Microsoft documentation, it is the minimum requirement
for recent Windows 10 to accept the drivers. No word anywhere that this
is in any way 2nd class, and no one other than you have reported
problems with the drivers we're shipping.

> After setting up the HLK environment, I used an already compiled OSE
> version of virtualbox that I had on hand to do some basic testing to
> see what kind of tests are failing. The results were promising
> considering that I was using V4.2 that was compiled eons ago using
> vs2010.  Some failing HLK tests required silly things like having a
> four digit version for the driver (aka 6.1.8.0 vs 6.1.8) while others
> seemed to be way more involved. But the following was obvious:
> 1- In order to pass HLK, a good reliable way was needed to bridge a
> hostonly adapter to a physical nic. The version that I was using
> didn't even have support for bridging on windows 10. My attempts to
> create a tunnel between two virtual machines failed as packets would
> suddenly start dropping. I believe this was an issue with vbox net
> service. So an upgrade to virtualbox was needed to see if using
> virtualbox bridging will work.

Another 'problem area' where you seem to be telling just the
uninteresting part of the story. I doubt that there is really a hard
requirement that a fully virtual adapter needs to somehow bridge to a
physical NIC...such virtual adapters are quite common (VPNs, ...) and
your test approach seems unusual.

> 2- The drivers must be compiled to target windows 10. Though, from
> experience, I know that you can target windows 7 and above and still
> pass the HLK and have a single driver that supports all.
> 3- The drivers must be compiled using the latest WDK.

Can't believe that Microsoft is really so picky, because that would make
Win10 drivers incompatible with older OS versions. Causing a big mess
with installing the right driver for older Windows versions when the
code is exactly the same.

> I set out to work on the upgrade process with the hopes that I could
> get it to work and either share with you what needs to be done or
> submit patches (if you are interested). If and when I pass the HLK
> tests, I would share with you my setup as well.
>
> All the prerequisites compiled fine without any headache for both
> 32bit and 64bit using vs2019. The instructions for building them using
> vs2010 needed small adjustments to make everything work.
> Next was virtualbox. I pulled down the latest virtualbox tgz tarball
> at the time (6.1.8) and started upgrading the tool sets.Then I started
> by upgrading kbuild by adding an SDK, VCC and WDK kmk files and
> updated configure.vbs to correctly detect the tool sets and configure
> kbuild. I was starting to have some success when I noticed that kbuild
> already has updated VCC and SDK (but no WDK). So I pulled these down
> and replaced the work that I did with kbuild's and patched the files
> with any required updates. Then I noticed that VirtualBox SVN source
> tree has already been updated to the latest kbuild and new options
> were being added to support VS2017 (I think). But I did not see any
> mention of the WDK, only the Windows 8. Whatever was going on, it
> seemed like work in progress. So I started to worry that everything
> that I'm doing is potentially a duplicated effort. That's why I'm
> interested in knowing your upgrade roadmap if you have one.

The kBuild used for 6.1.x has none of the updates you mentioned. So
you're creating a chimera between kBuild for VirtualBox trunk and the
code of VirtualBox 6.1. Not a supported combination ever, and possibly
causing all sorts of issues.

> Currently, I feel like I'm very close to getting all the user mode
> binaries to work. They currently compile but there are some linking
> issues that I'm trying to address. The next obstacle is going to be
> the removal of selfsign since it no longer exists in the WDK.

Those "some linking issues" could be anything, and since it's very
unlikely that 6.1 will ever be officially built with anything except
VS2010 there isn't all that much motivation on our side to spend time on
this.

> p.s. My main focus was to get the host drivers working first and then
> focus on the guest additions. I didn't know there are guest additions
> that go as far back as Windows NT!

Everyone underestimates the guest additions :) On the host there is a
much smaller range of OSes which is relevant. The guest additions
ideally work with absolutely everything which Microsoft ever released.
After all one purpose of VirtualBox is to run old OSes in a safe manner.

Klaus

>
> Thanks and stay safe,
> -- 
> Ribhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20200625/752cf97e/attachment.html>