5 ms·

I think you're doing Hyper-V a misfavor here. Hyper-V is essentially a server-only product; VirtualBox has had long since taken over as the desktop virtualizati

I think you're doing Hyper-V a misfavor here. Hyper-V is essentially a server-only product; VirtualBox has had long since taken over as the desktop virtualization of choice. So it's not surprising to see no fuzz about graphics or mouse, the current expierence is just enough to install an OS from which point on you'd want to do anything remotely anyways. And, for better or for worse, even VirtualBox needs those "shiny advanced features" (that are in just about every non-Atom intel processor since, like, 2006ish) to virtualize x86-64 code, because that's just how the instruction set works; there is nothing that can be done to avoid that. Nobody really wants to run a VM cluster on x86 hardware, not even back then. Also, these special hardware features are what made virtualization finally fast enough for everything and are one part of what made it possible to virtualize just about any workload you'd imagine today.

garganzol 8y ago
Hyper-V was indeed designed to work presumably on servers. But the story does not end there. Let me continue the story. Windows Phone 8 came out in 2012. It was the version that signified the shift from Silverlight-based runtime to so called WinRT. How on Earth Virtual PC could be related to Windows Phone? Here is the thing. Windows Phone Emulator required a working Hyper-V setup. Say, you had no real Windows Phone device, but wanted to take a look at this new shiny thing. Run an emulator! But wait. Emulator was based on Hyper-V, and Hyper-V required a CPU with SLAT feature. To give you a context, if you had an Intel Core i3 CPU, you were out of luck. You could not run the Windows Phone emulator! The same applied to a lot of other widespread CPU models. I guess only 8% of developers world-wide were lucky enough to have a CPU with a SLAT at that time. So Microsoft ended in an intricate situation when Hyper-V was originally designed for server use only, but ended up as a critical dependency for an important desktop component (Windows Phone Emulator). I guess you know where that headed. Just a few developers could take a grasp on Windows Phone Emulator, while the majority of them were out of luck. This factor undermined Windows Phone development. It was essentially a time bomb that led to Windows Phone app starvation in upcoming years, among other factors. Combined with a Moore law slowdown, SLAT requirement turned out to be a weapon of mass destruction for Windows Phone. People who bought Core i3 in 2012 usually didn't bother to upgrade. So Windows Phone Emulator was much of a dead horse from the start. -------------------------------------------------- Regarding those fancy CPU features for virtualization assistance. One may think that SLAT was an absolute requirement for Hyper-V, but here is a funny point of anecdata. In order to workaround that nasty SLAT requirement, some developers resorted to the following scheme on CPUs that din't support SLAT: they installed VMware, installed a guest Windows OS. Then, they enabled nested virtualization in VMware machine settings. Then, they were able to set up Hyper-V in guest OS. Imagine that, VMware actually emulated SLAT guest CPU on SLAT-less host CPU. And only then, after all those hoops and wiggles those poor souls were able to run Windows Phone Emulator. What an experience. Interestingly enough, Windows Phone Emulator was pretty snappy in that double virtualization setup. But the whole experience was ruined. In a hindsight, that was a writing on the wall for Windows Phone.
- pjmlp 8y ago
  Note that Android's emulator suffers from the same issues due to HAXM requirement changes. WP died due to multiple reboots on the whole toolchain. Silverligh/XAML => WP 8 model => WP 8.1 UAP model => WP 10 UWP model After a while we got fed up of rewriting, hence .NET Standard and the UWP Windows compatibility package, UWP Windows Toolkit. The emulator had very little to do with it, as many of us would deploy to real devices anyway.
  - vetinari 8y ago
    Android emulator originally came as qemu emulating arm CPU. The Intel build with HAXM, was added later, as the accelerated option. HAXM has another downside: it doesn't run on AMD CPUs. If you wanted accelerated emulator on AMD CPU, you could use the Linux version with KVM or Mac version with Hypervisor.framework up until few months ago, when the emulator started to support the Microsoft Hypervisor Framework.
    - pjmlp 8y ago
      Yep and it sucked much more than WP ever did, only after everyone started ignoring it while making use of Genymotion or Microsoft's own implementation, did Google care to actually improve it. So bad emulator support wasn't an issue regarding Android's adoption.
      - scarface74 8y ago
        But it may have some affect on app development. Even today most apps are iOS first. Using the iOS simulator compared to the Android emulator is like night and day. When you run your app on the iOS simulator, your app is compiled to x86 code and linked against an x86 build of the iOS frameworks - no emulation involved. The code —> build -> test cycle is so much faster with iOS. With classic Windows Mobile with the .Net compact framework, you could do a lot of your testing just running your app on your desktop without ever using the emulator.
        8y ago

garganzol 8y ago

Hyper-V was indeed designed to work presumably on servers. But the story does not end there. Let me continue the story. Windows Phone 8 came out in 2012. It was the version that signified the shift from Silverlight-based runtime to so called WinRT. How on Earth Virtual PC could be related to Windows Phone? Here is the thing. Windows Phone Emulator required a working Hyper-V setup. Say, you had no real Windows Phone device, but wanted to take a look at this new shiny thing. Run an emulator! But wait. Emulator was based on Hyper-V, and Hyper-V required a CPU with SLAT feature. To give you a context, if you had an Intel Core i3 CPU, you were out of luck. You could not run the Windows Phone emulator! The same applied to a lot of other widespread CPU models. I guess only 8% of developers world-wide were lucky enough to have a CPU with a SLAT at that time. So Microsoft ended in an intricate situation when Hyper-V was originally designed for server use only, but ended up as a critical dependency for an important desktop component (Windows Phone Emulator). I guess you know where that headed. Just a few developers could take a grasp on Windows Phone Emulator, while the majority of them were out of luck. This factor undermined Windows Phone development. It was essentially a time bomb that led to Windows Phone app starvation in upcoming years, among other factors. Combined with a Moore law slowdown, SLAT requirement turned out to be a weapon of mass destruction for Windows Phone. People who bought Core i3 in 2012 usually didn't bother to upgrade. So Windows Phone Emulator was much of a dead horse from the start. -------------------------------------------------- Regarding those fancy CPU features for virtualization assistance. One may think that SLAT was an absolute requirement for Hyper-V, but here is a funny point of anecdata. In order to workaround that nasty SLAT requirement, some developers resorted to the following scheme on CPUs that din't support SLAT: they installed VMware, installed a guest Windows OS. Then, they enabled nested virtualization in VMware machine settings. Then, they were able to set up Hyper-V in guest OS. Imagine that, VMware actually emulated SLAT guest CPU on SLAT-less host CPU. And only then, after all those hoops and wiggles those poor souls were able to run Windows Phone Emulator. What an experience. Interestingly enough, Windows Phone Emulator was pretty snappy in that double virtualization setup. But the whole experience was ruined. In a hindsight, that was a writing on the wall for Windows Phone.

pjmlp 8y ago
Note that Android's emulator suffers from the same issues due to HAXM requirement changes. WP died due to multiple reboots on the whole toolchain. Silverligh/XAML => WP 8 model => WP 8.1 UAP model => WP 10 UWP model After a while we got fed up of rewriting, hence .NET Standard and the UWP Windows compatibility package, UWP Windows Toolkit. The emulator had very little to do with it, as many of us would deploy to real devices anyway.
- vetinari 8y ago
  Android emulator originally came as qemu emulating arm CPU. The Intel build with HAXM, was added later, as the accelerated option. HAXM has another downside: it doesn't run on AMD CPUs. If you wanted accelerated emulator on AMD CPU, you could use the Linux version with KVM or Mac version with Hypervisor.framework up until few months ago, when the emulator started to support the Microsoft Hypervisor Framework.
  - pjmlp 8y ago
    Yep and it sucked much more than WP ever did, only after everyone started ignoring it while making use of Genymotion or Microsoft's own implementation, did Google care to actually improve it. So bad emulator support wasn't an issue regarding Android's adoption.
    - scarface74 8y ago
      But it may have some affect on app development. Even today most apps are iOS first. Using the iOS simulator compared to the Android emulator is like night and day. When you run your app on the iOS simulator, your app is compiled to x86 code and linked against an x86 build of the iOS frameworks - no emulation involved. The code —> build -> test cycle is so much faster with iOS. With classic Windows Mobile with the .Net compact framework, you could do a lot of your testing just running your app on your desktop without ever using the emulator.
      - 8y ago