Comments on: Microsoft Employee in Dodgy Picture Shocker http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/ Thoughts from, and the lives of a Canadian and a Brit living in Southern England. Sat, 27 Feb 2010 16:04:06 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Richard http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/comment-page-1/#comment-9331 Richard Sun, 04 Feb 2007 17:23:38 +0000 http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/#comment-9331 No problem - I've been on the presenting side where something that has worked flawlessly in rehearsal goes horribly wrong on the day! Indeed the biggest disaster I've had on stage was, as with yours yesterday, caused by someone else doing something that seemed innocuous, but has unforeseen results. In my case they borrowed a piece of equipment, and reconnected the cables incorrectly when they put it back. I think from my point of view, one of the reasons I commented on what happened, and was slightly cheesed off was the 'Oh it's a Mac' comment that came from, if I remember correctly, Dave, the guy who plugged in his USB key in the first place. From the description of what occurred over on <a href="http://differentthings.wordpress.com/2007/02/04/webdd-vista-saves-the-day-from-hell/" rel="nofollow">your blog</a>, it certainly seems that it was a driver issue, and had he done the same with the machine running it MacOS X there probably wouldn't have been the same problem. This fundamentally is the real problem with Boot Camp on the Mac at the moment - the Mac may be a lot more similar now to a PC with the Intel processors, but the Mac is still built on a custom design, it's close, but it isn't a true PC. As a result there are going to be hiccups like this because things just don't work quite the same. What would be interesting would be whether running with something like <a href="http://en.wikipedia.org/wiki/Parallels_Desktop_for_Mac" rel="nofollow">Parallels</a> instead of Boot Camp would be a better combination? No problem – I’ve been on the presenting side where something that has worked flawlessly in rehearsal goes horribly wrong on the day! Indeed the biggest disaster I’ve had on stage was, as with yours yesterday, caused by someone else doing something that seemed innocuous, but has unforeseen results. In my case they borrowed a piece of equipment, and reconnected the cables incorrectly when they put it back.

I think from my point of view, one of the reasons I commented on what happened, and was slightly cheesed off was the ‘Oh it’s a Mac’ comment that came from, if I remember correctly, Dave, the guy who plugged in his USB key in the first place. From the description of what occurred over on your blog, it certainly seems that it was a driver issue, and had he done the same with the machine running it MacOS X there probably wouldn’t have been the same problem.

This fundamentally is the real problem with Boot Camp on the Mac at the moment – the Mac may be a lot more similar now to a PC with the Intel processors, but the Mac is still built on a custom design, it’s close, but it isn’t a true PC. As a result there are going to be hiccups like this because things just don’t work quite the same.

What would be interesting would be whether running with something like Parallels instead of Boot Camp would be a better combination?

]]> By: Jon Harris http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/comment-page-1/#comment-9327 Jon Harris Sun, 04 Feb 2007 16:38:02 +0000 http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/#comment-9327 Of course the curse of Memphis - I should have realised! You are of course correct that the MacBook/Vista combination is an unsupported configuration, but to give this configuration it's due, it has run faultlessly for over 6 months from Beta 2 onwards. I've blogged about the day from hell, and the whole sequence of events was a pretty painful experience from my side as well as yours. I'm praying to the demo gods on an hour basis to make sure it doesn't happen again. I just hope our technical issues didn't spoil your enjoyment of the WebDD event. Being a 15 year Mac user is more down to the fact that I'm even older than I look and back then (mid 80s) designers used a Mac for design... simple and straight forward. Interestingly the corporate policy at Macromedia was PC not Mac. Of course the curse of Memphis – I should have realised!

You are of course correct that the MacBook/Vista combination is an unsupported configuration, but to give this configuration it’s due, it has run faultlessly for over 6 months from Beta 2 onwards.

I’ve blogged about the day from hell, and the whole sequence of events was a pretty painful experience from my side as well as yours.

I’m praying to the demo gods on an hour basis to make sure it doesn’t happen again. I just hope our technical issues didn’t spoil your enjoyment of the WebDD event.

Being a 15 year Mac user is more down to the fact that I’m even older than I look and back then (mid 80s) designers used a Mac for design… simple and straight forward. Interestingly the corporate policy at Macromedia was PC not Mac.

]]> By: Richard http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/comment-page-1/#comment-9293 Richard Sat, 03 Feb 2007 22:13:55 +0000 http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/#comment-9293 That is precisely the same reason that our core product is still in VS6 - heavily COM based. Our core product team has had a go at updating the C to VS2005, but effectively we'd have to rewrite the whole thing from scratch, so for a small company it is just impractical. That is precisely the same reason that our core product is still in VS6 – heavily COM based. Our core product team has had a go at updating the C to VS2005, but effectively we’d have to rewrite the whole thing from scratch, so for a small company it is just impractical.

]]> By: Mike Dimmick http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/comment-page-1/#comment-9292 Mike Dimmick Sat, 03 Feb 2007 20:46:46 +0000 http://www.peat.me.uk/2007/02/03/microsoft-employee-in-dodgy-picture-shocker/#comment-9292 The perennial problems for moving to newer versions of Visual Studio are down to deploying the runtimes. For Visual Studio 6.0 you can guarantee that both the VB and VC runtimes are already present on Windows 2000, XP and Server 2003 systems, since they're actually part of the OS. Meanwhile, for VS2003 and 2005, you're either targetting .NET, in which case it's a 20MB runtime, or the C++ runtimes which are tricky to deploy due to being Win32 Side-By-Side Assemblies. Add to that the fact that at least some VB 6.0 applications are unportable to VB.NET (such as our heavily COM-based application server) and that fixing the code when porting from VC++ 6.0 to a more standards-compliant compiler like v8.0 (VS 2005), and it's not hard to see why people stick with a known working solution in Visual Studio 6.0. We have an extra problem with our COM-based application server in that only one version of .NET can be loaded into a process, which by default (if loaded through COM Interop) is the latest version present on the system. This can potentially have undesirable results if you've developed your solution with .NET 1.1 and install on a system with .NET 2.0 installed, or if .NET 2.0 is subsequently installed, and you happen to have relied on some behaviour in 1.1 that's changed in 2.0. The perennial problems for moving to newer versions of Visual Studio are down to deploying the runtimes. For Visual Studio 6.0 you can guarantee that both the VB and VC runtimes are already present on Windows 2000, XP and Server 2003 systems, since they’re actually part of the OS. Meanwhile, for VS2003 and 2005, you’re either targetting .NET, in which case it’s a 20MB runtime, or the C++ runtimes which are tricky to deploy due to being Win32 Side-By-Side Assemblies.

Add to that the fact that at least some VB 6.0 applications are unportable to VB.NET (such as our heavily COM-based application server) and that fixing the code when porting from VC++ 6.0 to a more standards-compliant compiler like v8.0 (VS 2005), and it’s not hard to see why people stick with a known working solution in Visual Studio 6.0.

We have an extra problem with our COM-based application server in that only one version of .NET can be loaded into a process, which by default (if loaded through COM Interop) is the latest version present on the system. This can potentially have undesirable results if you’ve developed your solution with .NET 1.1 and install on a system with .NET 2.0 installed, or if .NET 2.0 is subsequently installed, and you happen to have relied on some behaviour in 1.1 that’s changed in 2.0.

]]>