Vista

As much 'bad press' as Internet Explorer gets, I think this is a step in the right direction to get known bugs and issues logged and tracked from the public. Great news for IE 7 and future versions.

File your bugs/etc here:
https://connect.microsoft.com/site/sitehome.aspx?SiteID=136

I ended up having to remove this new MIX build from a few machines because it seems to have too many problems under XP. So far, from what I've found, history doesn't work, a lot of websites don't render correctly (not necessarily an IE problem), any Google toolbar or Google Desktop component seems to conflict, and re-enabling the 'advanced features' pane doesn't seem to work, at least for me.

So, unless you are a web developer or a bleeding edge kind of person, I'd stick with the older build for now or just wait until the next refresh.

I'd still like to see IE more 'modular' and not so ingrained into the OS components but I think pretty much after IE4 and IE5, that's not really an option anymore.

The feature list that has always typically required Citrix is getting shorter once Longhorn hits the streets.

Two new options in the Remote Desktop client is "/span" and "/public".

I believe "/public" is for sharing your desktop with multiple people at once, but I could be wrong - I'm still digging into the documentation.

'/span' allows your "virtual desktop" to span multiple monitors as long as the height is identical.

The hot item for me at least with RDP 6.0 is published applications - finally!

The biggest news, for me, from tonight's hardware device chat at MS is the above mentioned subject line. Not unexpected but might prevent some people from upgrading their OS if they want to use older devices like Gravis gamepads and the like.

HDCP support is going to be required to play HD DVD content, in video cards and monitors, unfortunately too.

On a good note, the Bluetooth stack is supposed to be a lot better than the one in XP SP2. I'm happy to hear that because as time goes on, I seem to be getting more and more Bluetooth devices.

My biggest complaint about SMB as a network protocol was how often it would need to do many (relatively) redundant transfers across the wire. You have to remember this protocol dates back to Windows for Workgroups and DOS, where latency and high overhead did not matter much because 99% of the operations were done on a local network.

People back then weren't trying to stuff files back and forth through a VPN over a DSL line. End result, nowadays, is a lot of blocking operations when "stuck" on a low bandwidth link and typically results with a non-responsive Explorer process for network operations. Another limitation, without resorting to using a WINS server or some type of Layer 2 bridge, was/is browsing for "nearby" computers. Again, this shows the age of the protocol. A lot of "Workgroups" or "Domains" now exist in diverse geographical locations, and not in the next cube over.

I'm looking forward to the redesign. Only bummer is that it looks like it will be Vista/Longhorn only, for the advanced features.

One thing in particular that caught my eye from the new blog entry from the SMB team is this:

SMB 2.0 supports an arbitrary, extensible way of compounding operations to reduce round trips. This makes the protocol less chatty as compared to SMB 1.0. Chattiness of SMB 1.0 has often been a major pain point.

Bingo. Pretty much what I described up above.

Read more about it here:
http://blogs.technet.com/filecab/archive/2006/03/10/421752.aspx

This Works-For-Me(tm) as of Build 5308 of Windows Vista/Longhorn aka Feb 2006 CTP.

Copy mstsc.exe and mstscax.dll from your Vista install's System32 directory (aka %SystemRoot%\System32) to your XP machine.

In the directory that you copied those files to, create a directory that matches your MUI language, for instance, for English (US), this would be a directory called "en-US".

Copy mstsc.exe.mui and mstscax.dll.mui from your Vista install's System32\en-US [replace en-US with your MUI] to your newly created MUI directory.

Why did I do this? It is an oddball situation I will admit. I have a VMWare install of Vista on my laptop that needs to access a few Novell fileshares. As far as I know, there isn't a Novell client made for Vista yet.

Next question is, how does this allow Vista access those drives? Well, I have the Novell client installed on my host OS (Windows XP), and I use the RDP client to connect to the virtual machine's "LAN" device. This allows me to avoid using VMWare's console for the most part, and I can get away with not installing most of the VMWare utilities on the Vista client, and of course, as long as I allow the RDP session access to my laptop drive shares, I can get to the Novell servers I need to get to. True, you can do this with the normal XP RDP client, but I wanted to use the RDP 6.0 protocol. Some might call it "thinking outside of the box", I call it "thinking outside of the VM box."

How did I figure this out? I have a bad habit of fooling with things until they either completely break or work. It seems that my youngest daughter has the same habit already at age 1. She has the TV remote control mastered and now she's figuring out X-Box games, which is a little bit mindblowing to me.