> Even if we've managed to rebuild and patch Hyper-V Manager from source, this is not enough for a real community project to take place. As much as I would like to just upload the decompiled source code to GitHub to start making significant changes to it, there's no legal standing for this project
I did almost exactly the same thing with Microsoft Reporting Services / ReportViewer several years ago, but decided to go a step further and published whole thing on a GitHub and uploaded packages for .NET Core/5/6/7/8 to NuGet - both platform controlled by Microsoft.
Both repo and packages are still up. Only legal inquires came from other companies asking if they can really use it. For reasons I cannot fathom, Microsoft MVPs and community managers direct anyone asking for .NET Core version of ReportViewer to my recompiled package and sources, with links all over Microsoft's forums, reddit and Q&A sites. GitHub analytics shows some visitors come via direct links from docs.microsoft.com.
I guess Microsoft just doesn't care. Hell, they allow scripts for one-click product activation bypass to be hosted on GitHub.
> Hell, they allow scripts for one-click product activation bypass to be hosted on GitHub.
On one hand, it's a potential revenue center -- I would not be one bit surprised if data collected from these repos gets fed to processes like BSA audit targeting.
On the other hand, repos like that can be useful as well for software preservation and the like.
It doesn't surprise me. There are parts of Microsoft that are almost completely supported by the community. You've provided an improvement to their product for free. It's not like they're making money on it directly, and any easier you make it ensures stickiness in their platform.
> Even if we've managed to rebuild and patch Hyper-V Manager from source, this is not enough for a real community project to take place. As much as I would like to just upload the decompiled source code to GitHub to start making significant changes to it, there's no legal standing for this project. I can only go as far as streamlining the process of decompilation such that others can experiment making changes locally.
I don’t know what I’m missing here but something about this whole idea rubs me the wrong way. Who in their right mind is going to do this in a production environment where there is no apparent possibility to have a shared repository for the updates? And no possibility of any support or warranty (for what it’s worth). It’s worth about the price of whatever clicks the blog post generated.
It’s not like the software is that old. I don’t blame him for disliking the powershell interface but this isn’t the answer.
> I don’t know what I’m missing here but something about this whole idea rubs me the wrong way. Who in their right mind is going to do this in a production environment where there is no apparent possibility to have a shared repository for the updates?
They said right at the beginning:
> The primary goal of decompiling Hyper-V Manager is really to assess its value as a potential open source project, which is what I'm hoping Microsoft can be convinced to do.
Thank you for clarifying - I am in no way suggesting that locally patching a decompiled Hyper-V Manager makes sense beyond its experimental value. Having gone through the exercise, it confirmed it's potential value as an open source project, but this can only realistically happen if Microsoft open sources Hyper-V Manager like they've done for many things in the past, especially software that is no longer actively developed.
> The Hyper-V PowerShell cmdlets that wrap the underlying Hyper-V WMI provider are well maintained and provide complete access to many settings not properly exposed in Hyper-V Manager.
I'm very familiar with Hyper-V, HVManager, and SCVMM. If you want to do anything more than a light touch deployment of a VM you're going to use Powershell. Microsoft has made that abundantly clear and even their training courses have you deploy through PS. SCVMM adds a nice wrapper with some additional orchestration. And it also adds a whole other library of PS that are also not exposed in their very advanced Windows SCVMM GUI.
This is a cool experiment but completely unnecessary. You can write a Powershell GUI with the settings and options that you prefer. It's what I've done when I wanted to see nice tabular view of VM resources that the existing GUIs could not give me. Give in to Powershell!
It is easier to approach it, if instead of trying to see UNIX everywhere, one thinks of the REPL environments from Xerox PARC/ETHZ, or even AmigaDOS with REXX.
Former Windows Admin who still uses Powershell on *nix. Once you get over the hump, you will find it's pretty darn good scripting language. Personally, I find it much more maintainable since verb-noun is clunky while writing but much easier to read.
For me my brain can NOT stop trying to use it as a CMD replacement. The CMD commands just do not work (duh its not CMD!). I then have to have that 'kerthunk' spot where I try to use the newer commands. Nothing wrong with powershell. It is just my brain for some reason can not let go of CMD in this context. Jump to bash no sweat. But for some reason my brain just will not use powershell correctly and I have no idea why. Great scripting lang and way better than bash or CMD script.
I actually love PowerShell and use it extensively to automate Hyper-V labs, but there's a big difference between automation and one-off things like a checkbox to enable nested virtualization. There's also a large portion of users looking for something just good enough as a desktop GUI to manage just a few VMs with no automation, and Hyper-V Manager is definitely behind when compared to VirtualBox or VMware Workstation in that regard.
Just like Java, one of the (few) things I like about .NET languages is how they can be easily decompiled and recompiled, although I think it missed the era when disassembling and binary patching was really common even amongst non-programmers, so it didn't get as much attention and empower users as much as it could have.
As someone that works with both, one of the best design decisions of .NET was going back to the managed languages that predated Java, and include the same kind of features for low level programming, and proper value types.
Granted they didn't expose everything to C#, rather C++/CLI or having to emit MSIL directly, but since Midori, and Core reboot, those remaining features have been slowly exposed to C# as well.
Meanwhile on Java side we keep getting Valhala on little pieces, and most likely stuff like Panama or Vector types, will never make it to ART.
I use hyper-v regularly and never even heard of windows admin center. Another example of Microsoft changing something that isn't broke just for the sake of change.
I'm glad I've been building a homelab and can move all my studying too that since it seems hyper-v is being shoved out the door by Microsoft.
Windows Admin Center was created because everyone wanted to manage Windows from a web browser. The current result is it works, but it's far from an optimal GUI solution for managing Windows machines.
Windows Admin Center was created because Microsoft thinks sysadmins want to manage Windows from a web browser. Instead, most of them would rather use desktop apps over RDP, which is why the deprecated Microsoft Management Console (MMC) is still widely used. WAC adoption is nowhere near what it should be in practice at this point.
"Hyper-V is undeniably a critical component of the Microsoft virtualization stack runs on it, but it's also used in Virtualization-Based Security, Windows Containers, Windows Subsystem for Linux, Windows Subsystem for Android, and even the Xbox."
I just realized what you saw, I originally meant to say "Hyper-V is undeniably a critical component of the Microsoft virtualization stack as Azure runs on it", I've got it fixed and also removed the Windows Subsystem for Android mention since Microsoft killed it
Weird, right? That's exactly the argument repeated ad nauseam by Microsoft as "proof" that Hyper-V isn't dead, somehow excluding the lack of a good desktop GUI for Hyper-V VMs from why users would feel differently
Oh and the funny thing is that since writing this blog post Microsoft killed Windows Subsystem for Android despite its immense value as a developer tool
I did almost exactly the same thing with Microsoft Reporting Services / ReportViewer several years ago, but decided to go a step further and published whole thing on a GitHub and uploaded packages for .NET Core/5/6/7/8 to NuGet - both platform controlled by Microsoft.
Both repo and packages are still up. Only legal inquires came from other companies asking if they can really use it. For reasons I cannot fathom, Microsoft MVPs and community managers direct anyone asking for .NET Core version of ReportViewer to my recompiled package and sources, with links all over Microsoft's forums, reddit and Q&A sites. GitHub analytics shows some visitors come via direct links from docs.microsoft.com.
I guess Microsoft just doesn't care. Hell, they allow scripts for one-click product activation bypass to be hosted on GitHub.
On one hand, it's a potential revenue center -- I would not be one bit surprised if data collected from these repos gets fed to processes like BSA audit targeting.
On the other hand, repos like that can be useful as well for software preservation and the like.
I don’t know what I’m missing here but something about this whole idea rubs me the wrong way. Who in their right mind is going to do this in a production environment where there is no apparent possibility to have a shared repository for the updates? And no possibility of any support or warranty (for what it’s worth). It’s worth about the price of whatever clicks the blog post generated.
It’s not like the software is that old. I don’t blame him for disliking the powershell interface but this isn’t the answer.
They said right at the beginning:
> The primary goal of decompiling Hyper-V Manager is really to assess its value as a potential open source project, which is what I'm hoping Microsoft can be convinced to do.
I'm very familiar with Hyper-V, HVManager, and SCVMM. If you want to do anything more than a light touch deployment of a VM you're going to use Powershell. Microsoft has made that abundantly clear and even their training courses have you deploy through PS. SCVMM adds a nice wrapper with some additional orchestration. And it also adds a whole other library of PS that are also not exposed in their very advanced Windows SCVMM GUI.
This is a cool experiment but completely unnecessary. You can write a Powershell GUI with the settings and options that you prefer. It's what I've done when I wanted to see nice tabular view of VM resources that the existing GUIs could not give me. Give in to Powershell!
You really have to buy into it and that's a hard sell for those who aren't Windows power users.
Granted they didn't expose everything to C#, rather C++/CLI or having to emit MSIL directly, but since Midori, and Core reboot, those remaining features have been slowly exposed to C# as well.
Meanwhile on Java side we keep getting Valhala on little pieces, and most likely stuff like Panama or Vector types, will never make it to ART.
I'm glad I've been building a homelab and can move all my studying too that since it seems hyper-v is being shoved out the door by Microsoft.
weird sentence