-- Ben Armstrong, Hyper-V Program Manager
Talking about Virtual PC and Hyper-V at Microsoft
For those who do not know - Rogue is quite possibly the greatest 'old school' game of all time - and the predecessor of most modern 'dungeon exploration' games. Indeed - when the infamous 'Diablo' was released it felt very much like Rogue with modern graphics.
As well as this - Rogue has spawned an entire category of games which are usually referred to as 'Rogue-like'. The most popular of which is 'NetHack'. However I personally prefer the original Rogue - as I find most other 'Rogue-like' games to be far too complex.
You can find out more about Rogue at the following sites: http://www.wichman.org/roguehistory.html and http://home.wanadoo.nl/loche/rogue/index.html.
And as you can see - it runs perfectly under Virtual PC:
Well - it has taken several hours of 'research' in order to write this post - so if you don't mind, I have a turquoise potion that I need to quaff… Ugh… I feel very sick now…
Cheers,Ben
Virtual PC has a convenient feature called 'Shared Networking'. What this is is a small virtual NAT (network address translation) router - which is quite similar to the cheap hardware broadband routers that a lot of people use (myself included). The advantage of Shared Networking is that your virtual machine can access the external network with needing to be directly connected to it*. This is handy if you don't want to have to worry about whether your virtual machine has all the latest security patches, or if you regularly move your physical machine between different network configurations (e.g. moving a laptop from you work network to your home network).
Normally using Shared Networking is very simple. You just enable it and set the guest operating system to use DHCP - and everything works. This is not the case with a Windows Server 2003 guest though. The problem is that Shared Networking configures the guest operating system to use the same DNS servers as are used by the physical computer. However - all DNS packets are actually returned from '192.168.131.254' - which is the virtual gateway used by Shared Networking.
Windows Server 2003 looks at the DNS packet, sees that it is coming from a source other than the DNS server it requested the information from, and rejects it. A simple fix for this is to manually assign the DNS server inside the virtual machine to 192.168.131.254 - then everything will work just fine.
* The downsides of Shared Networking are that external computers cannot connect directly to the virtual machine (so it is not useful for server applications) and that Shared Networking only works for IP based networking.
Windows Server 2003 does not include drivers for the Sound Blaster 16 emulated by Virtual PC (nor is this card officially supported in Windows Server 2003). It is - however - possible to get sound working by loading the Windows XP drivers under Windows Server 2003. To do this you will need to:
Other requested files can be selected from the Windows Server 2003 product CD.
No, this is not a post about how to speed up performance under Virtual PC. Rather this is a post about how to enjoyably while away your Friday afternoon driving your race car in 'The Need For Speed' under Virtual PC. This is the original game which has since spawned a long line of sequels. You can download a playable demo from here: http://www.dosgamesarchive.com/download/game/48 And as you can see; it runs perfectly under Virtual PC:
Happy racing!
When the team moved up to Microsoft from Connectix one thing that was quickly evident was that there were a number of 'cultural' differences between the two companies. This was highlighted by the fact that when we started the entire program management and development teams were from Connectix while the majority of the test team was from Microsoft. We have spent a lot of time trying to resolve the differences and want to end up with the 'best from both worlds' - however we still have a number of areas that need work :-)
One 'Microsoftism' that I have enjoyed having as a program manager is the concept of a 'bug bar'. This is a list of requirements that a bug must meet in order to be fixed in a milestone or release. Examples for a service pack would include things like 'Customer reported problems', 'Application crashes' or 'Data loss bugs'. Then as bugs come in during the development cycle they are assessed against the 'bar' and a decision is made to fix the bug or to postpone it to a future release.
This is invaluable for a number of reasons. Firstly, it helps to ensure a consistent quality approach for a release as it stops us from ignoring major bugs, and from wasting time on trivial issues. Secondly, it helps to be able to give a precise answer as to why a certain bug did not get fixed in a given release. Finally, it is great to be able to review the fixed and postponed bugs before shipping a product and be confident that the right changes have been made to the product.
However the thing that sticks in my mind about the 'bug bar' is this:
At Microsoft there are regular bug triage meetings where bugs are reviewed and assigned to an appropriate person. From time to time a contentious bug will be reported - where people are divided as to whether this bug should be fixed, and if it should be fixed how it should be fixed, and what the potential impact of the fix is. Invariably a minute or two into the discussion someone will ask 'Does it meet the bar?' Answering this question will resolve all debate. If it meets the bar it should be fixed. If it does not meet the bar we will get it next time.
When I first started working at Connectix, one of my favorite past times was to tease the CTO, Eric Traut, about the fact that BeOS did not work under Virtual PC. Eric is a bit of a perfectionist, and liked BeOS, so it bothered him that it did not work. From time to time he would take a shot at trying to get BeOS to work - and fail. Eventually Eric declared that 'BeOS would never run stably under Virtual PC' because of assumptions that it made about the underlying hardware.
The problem was that BeOS would install okay but programs would randomly (and frequently) crash.
During the late development cycle of Microsoft Virtual PC 2004, I decided it was time to fire up my collection of 'odd' operating systems and confirm that we had not broken any of them. Much to my surprise BeOS ran perfectly - no crashes, perfectly stable. The weird thing is that no one is entirely sure why this is - we just know that it is the result of one of the core changes we made during the Microsoft security review of the product.
So here you are:
In order to install BeOS all you really need to know is to use the VESA driver instead of the S3 video driver - as the S3 driver is quite problematic (details on how to enable the VESA driver can be found here: http://www.betips.net/chunga.php?id=365).
You can download the personal edition of BeOS v5 from here: http://www.bebits.com/app/2680 but as noted on that webpage BeOS can't run on Athlon processors - and this holds true for inside of Virtual PC too.
'What Works and What Doesn't in Microsoft Virtual PC 2004' (http://vpc.visualwin.com/) is a great website that is maintained by Jonathan Maltz. It lists all reported operating systems that people have tried under Virtual PC. At this stage there are 715 operating systems listed, 571 of which have been reported to work.
I love this website - and usually visit it on Friday afternoons to look for a new OS to play with under Virtual PC. Much kudos to Jon for his work here - and I think that we can all rest a little bit easier knowing that the 'BEERnix 1.0 Beta' does indeed run under Virtual PC :-)
Well - my kids are both finally asleep - and 'Santa' has been to put presents in their stockings - so I have a little time to relax before heading to bed early (as I know that my children will wake up *Very* early). So what better to do than to post to my blog :-)
One not so well known feature of Virtual Server is that it allows for user customization of the website theme. All of the coloring, font and some of the graphics are actually defined in "C:\Program Files\Microsoft Virtual Server\WebSite\VirtualServer\scripts\VSStyles.css".
This file is relatively easy to modify - and was designed as such to allow companies to customize Virtual Server to fit in with their own corporate branding. Or - if you want - you can use it as a way to help celebrate Christmas. This is what Virtual Server usually looks like:
And here is the festive version: