Windows and removable or remote media
We’ve come a long way in the history of Windows since Windows 95 and despite the hostility of a huge number towards Vista, there has been remarkable improvements and innovations made. However, beneath the fresh coat of paint, some of the old cracks in the wall are still occasionally visible. I was reminded, just not too many minutes ago, that Windows Vista is not all that different from Windows 95. What on earth am I talking about?
Thirteen years into the evolution of Windows, attempting to access a damaged/dirty CD still has the chance to bring down the entire explorer.exe process. The same can happen when trying to access a network resource over Explorer that has an unstable link or loses connectivity halfway. It has been thirteen years, THIRTEEN YEARS for crying out loud! Why can’t we handle I/O errors gracefully?
To give Microsoft some credit, at least we are no longer thrown a blue screen when the floppy drive is inaccessible.
File transfer rate: What’s going on here?
I’m completely puzzled by this. Transferring a file across the network (GigE), a file that contains real data moves much slower (it’s almost a 10 MB/s difference!) than a test file created by fsutil. As far as I know, and I maybe wrong here, the content of a file shouldn’t matter when transferring across the network as the protocols involved (TCP and Samba) doesn’t do any compression on its own. Explanations anyone?
Transfer rate with a real file, in this case, an image of the Windows Vista WAIK
Test file created with fsutil
Transfer rate with a test file of the exact same size created by fsutil
The Path to x64
RAM prices are dirt cheap, and with the amount of work I’m doing on virtual machines lately, it would be silly to not get another stick of 2 GB to my existing 2 GB.
2 + 2 might make 5 if you were in the world of Big Brother, but in the 32-bit world, 2 + 2 is somewhere in the range of 3 ~ 3.5 GB. 32-bit systems are not always able to address up to the full 4 GB of available physical memory, the reason is a bit complicated and has to do with virtual addressing limits. I’ll save myself from rehashing what others have written on the topic and refer you to the excellent article here.
The transition from 32-bits to 64-bits was smoother than I expected. First of all, I’m running on an OEM version of Windows Vista Business 32-bit, and I needed a 64-bit copy of Windows. Luckily obtaining the installation media wasn’t an issue for me as I had a copy of Windows Ultimate lying around, which I won from a Microsoft talk last year. I admit I was a reluctant to open the shrink wrap at first, but I desperately needed the media.
It is worthwhile to note that serial keys for Windows Vista are tied to the edition (Home Premium, Business, Ultimate etc) but not to the bitness (32-bit or 64-bit). Therefore, using my old Business edition serial was perfectly fine and I can save my Ultimate edition license for another day.
There is no difference in the installation process between the two bitness. The only difference, and deal breaker for many is that 64-bit Vista requires 64-bit drivers, and the drivers have to be digitally signed. The only two drivers that I have trouble with were Sony Ericsson’s PC Suit, which was required to sync my phone and Adobe’s PDF printer. It seems that I’m out of luck for the former, but the latter got addressed with a patch.
The only issue I had was with poorly written applications which hardcode their installation paths. In Windows x64, program space is separated depending on if they’re 32 or 64 bit (with a few naming oddities I must say, but they’re all preserved for compatibility reasons). However, SOE’s launchpad absolutely insists on writing to C:\Program Files\Sony\Station\LaunchPad despite the fact that 32-bit applications are suppposed to be redirected to C:\Program Files (x86). The problem exists with only the launchpad itself though, it is able to patch EQ2 in its correct C:\Program Files (x86) path.
The other problem I have was with 64-bit Java; it didn’t provide a plugin for 32-bit Firefox. There exists a way to work around this on Linux, but as far as my Google skills go, I couldn’t find a solution on Windows. Therefore, I went back to 32-bit Java.
With a full 4 GB of addressable memory, there certainly has been some changes to my workflow. I’m gradually becoming a huge fan of keeping my system clean and moving my work onto virtual machines. I might be a terribly messy person in real life, but I almost have a certain OCD when it comes to organizing my system. I’d almost do all my work exclusively inside virtual machines if not for the fact that I’m a gamer, and that virtualized 3D hardware acceleration isn’t quite here yet, but it will be one day. Guaranteed its not much and it’ll take another year or two, or even longer, before the technology matures, but VMWare Fusion already has experimental Direct X 9 support, and its the road that we’re going to take.
There’s still a vacuum as far as 64-bit software is concerned. Let’s face it, there’s not that many applications that would benefit from a 32-bit to 64-bit transition. WoW64 does its job of running 32-bit applications on Windows x64 just fine without any performance degradation, despite all the rumors that fly around.
