Tag Archives: Windows

From Windows to OS X

Posted on by
3

A couple weeks ago, I bought a Macbook Air with the intention of carrying it to school and using it as a daily laptop, replacing my Asus N82JQ, was a brick and consumed battery power like crazed, starved addict. On the whole, I am pleased with it, and it’s probably one of the best piece of tech I’ve ever bought, even though there are some issues. Perhaps the biggest hurdle to overcome was getting used to OS X after having lived and breathed Windows as a power user for most of my tech life.

Most of the transition has gone well, but perhaps I should talk about my pet peeve with OS X. When sorting by name in Finder, files and folders are sorted together, instead of sorting folders first, and then files, like in virtually every other OS out there. This feels like one of those insane Steve Jobs going against convention moments.

As a programmer, the the UNIX underpinnings of OS X really shines. Having tools like grep and diff right out of the box is really convenient, and the Bash shell is a lot more programmable in a sane way compared the command prompt and its VB idiosyncrasies.

As a portable machine, the tight integration between software and hardware lets really shines in its ability to sleep and wake instantaneously. There’s hardly any battery drain in sleep, making shutting down the system really unessential. This is a true ‘always ready to use’ system that PC makers have been striving to obtain for years with its hybrid HDD+SSD and alternative OSes have not been able to accomplish.

Despite the tight hardware and software integration, there are issues which you’d think shouldn’t happen and should have been caught in easily in a QA test that crops up. One frustrating issue is that when using a mini-DP to HDMI dongle, the colours on the external monitor appears washed out. Even more frustratingly, this issue happens only on OS X, and not when running Windows through the use of bootcamp. This whole issue deserves a post on its own, and I’ll save it for that.

Rants and praises aside, there is a significant hidden cost when moving from Windows to OS X. It might not be obvious at first, but you’re going to have to purchase new OS X specific licenses for the commercial software that you use. Even if you have one of those ‘per individual’ or ‘family packs’ licenses, they usually either cover only Windows or OS X, not both. This can be an expensive proposition if you’re going to be running a mixed environment of OS X and Windows at home. At the very least, you’re going to have to spend on MS Office for Mac.

Compatibility between Windows and Mac also adds to the cost. There’s no single file system that works across both OS X and Windows. Windows using NTFS and OS X uses HFS+, and it’s dilemma when it comes to formatting external hard drives. FAT32 is not a viable option if you have files larger than 4 GB. NTFS is the better compromise here, because NTFS is well documented due to its popularity, and if you had to connect the external HDD to another non-Mac device, chances are much higher that it has NTFS support instead of HFS+. In order to get NTFS on OS X functioning, you can either deal with the free ntfs3g and the performance penalties of running a file system in user mode, or pay for commercial drivers.

Transitioning between Windows and OS X is something that is going to take patience, and a wad of cash, but it’s something that can be done. It is probably easier for a Windows layman than a professional because there’s a lot less to unlearn. The best place to start would probably be getting used to the keyboard shortcuts and using Spotlight (like Windows Vista/7 start menu quick search) to launch apps. Things get a lot easier from there on.

Teaching an old dog new tricks

Posted on by
4

My Dell Inspirion 6000 is an aging laptop dating back about 4 years. It runs on an Intel Pentium 1.6 GHz processor with 2 GB of DDR2-667 RAM, an ATI Radeon Mobility X300 and a 5400RPM 80 GB hard drive. Windows 7 x86 went on it today, replacing the old Windows XP that it has been running. It was very usable, even more so than Windows XP, I dare say.

The installation took about 20 minutes, with the slow timing attributed to the slow hard drive. Graphics and WLAN drivers were obtained from Windows Update right after the installation completed and hit the desktop. Within 45 minutes from inserting the Windows 7 DVD into my drive, I had Office 2007, FoxIt Reader, Windows Live Messenger, FileZilla, KeePass, Wireshark and Eraser installed, almost a fully functional system for the stuff I do on my laptop. Since Windows 7 has a build in a firewall that supports both incoming and outgoing filtering, I didn’t need to install a 3rd party firewall, which are notorious for having a huge negative impact on system performance.

My old notebook is comparable to a modern day netbook, and if the netbook market is what Microsoft has in mind with it’s release of Windows 7, it would definitely find acceptance in it.

Test-Signing Drivers

Posted on by
Reply

Previously, I wrote about how not having signed drivers can be quite a pain on a 64-bit Windows system. I remedied that and made it less of a pain today.

Microsoft provides a set of tools in it’s Windows Driver Kit for the test-signing of drivers to be used for development purposes. What this means in simple terms is that it provides a way for the self-signing of drivers, and thus, getting the system to accept it as though it were digital signed by MS. This would avoid having to disable driver signature enforcement on start-up each time.

To begin with, download the Windows Driver Kit, and install the build environment and tools. Once that is done, launch the x64 Free Build Environment shortcut from the shortcuts created in the start menu with administrative rights. In my case, I made a folder consisting of my extracted raid drivers which look like this:

rr174x.cat
rr174x.inf
rr174x.sys

Now, to create the test certificate, we run the following:

makecert -r - pe -ss PrivateCertStore -n CN=mythokia.net(Test) TestCert.cer

Where mythokia.net(Test) can be replaced by any name. ‘Suceeded’ would be echoed upon successful execution of the above. That being done, we proceed to install the certificate on the machine as a Trusted Root Certificate Authority and Trusted Publishers so that items signed by this particular certificate would be recognized.

certmgr /add TestCert.cer /s /r localMachine root
certmgr /add TestCert.cer /s /r localMachine trustedpublisher

‘CertMgr Succeeded’ should be echoed for each. Now to sign the drivers with our certificate. This can be done either by signing the catalog file (one with the .cat extension), and/or the embedding the signature directly into the binary. From Microsoft’s explanation, drivers loaded at boot time are required to have their signatures embedded in the driver’s binary file itself. Unsure if signing just the binary is sufficient, I went ahead and did both.

signtool sign /v /s PrivateCertStore /n mythokia.net(Test) /t http://timestamp.verisign.com/scripts/timestamp.dll rr174x.cat
signtool sign /v /s PrivateCertStore /n mythokia.net(Test) /t http://timestamp.verisign.com/scripts/timestamp.dll rr174x.sys

Watch the output to see if both were successful. We’re almost ready to install the driver now, but one last twist. The bootloader has to be configured to allow for the running of test drivers. We issue this:

bcdedit -set TestSigning on

This adds an unobtrusive watermark to the bottom right of the screen that says ‘Test Mode’ that I can live with. Besides, I run my server headless anyway, except for the occasion RDP into it.

Now all that is done, we can finally install our self-signed driver like you would a normal driver. No more manually disabling the enforcement of digitally signed drivers every boot up.

Once again, these steps are detailed, and a lot more thoroughly so on MSDN, but here’s the rough guide to the self-signing of drivers for use on Windows x64 systems. I can finally remove that keyboard from my server.

Win 2008 R2 and signed drivers

Posted on by
1

After replacing yet another failed disk in my raid array this weekend, I replaced the Windows Vista installation on it with Windows Server 2008 R2, released last week.

I overlooked one important factor before installing Server 2008 R2 on it – I did not have signed drivers for my HighPoint 1740 raid controller. I had assumed, and wrongly so, that the drivers which had worked on Vista x64 would continue to do so in Server 2008 R2 (Win 2008 R2 is only available in x64 flavors), which is only partially the case.

On all x64 versions of Windows, drivers have to be digitally signed. I guess the logic behind this is for reasons and stability and compatibility. You could however, still force an install of a non-signed driver. The result however, could be some annoyance.

Afte the installation of the raid drivers, Windows refused to start and instead, booted into a recovery state. It was only then that I discover that although most drivers that worked under Vista/Server 2008 will work on Windows 7/Server 2008 R2, the signature is only valid for the particular version of the operating system they’re signed for.

To get around this, driver signature enforcement would have be disabled at each start up. The way this is done is to hit F5 right after the BIOS POST screen and before Windows start, and then hit F8 to bring up the advance options, and select disable driver signature enforcement. Troublesome.

There is yet another alternative, which I have not explored. The Windows Driver Kit provides a way to self-sign drivers for testing purposes. The MSDN article on how to go about doing this is here. I’ll have to look into it when I more time at my disposal.

Windows 7 initial impressions

Posted on by
2

There’s no denying that I’m a geek. I took leave today just so I could be there to install Windows 7 when it is released on TechNet.

Windows 7′s installation is largely similar to Vista’s. It has been ages since I last did an installation of Vista, so I can’t say for sure if it was any faster. Things went without a hitch until I reached desktop and tried to copy over my Everquest 2 installation off a network share. Windows locked up right away. I did a hard reset and tried a couple of times but fail was still the result. Unsure if it was an issue with the network transfer or writing to disk itself, I tried copying for another source. Thumbdrive and DVD copies went through okay, it had to be the network.

The NIC that I’m using is an Atheros Gbe onboard controller. I had the driver for it downloaded, but it wouldn’t install probably due a version check. To my knowledge, Windows Vista drivers are forward compatible with Windows 7. At this point, I thought I’d give Windows Update a shot. Despite Windows 7 being so new, maybe Microsoft did already start addressing issues that slipped through the earlier RC.

Looks like my faith wasn’t misplaced, an updated driver was there which rectified the issue. It would have been nicer if it had been included with the Windows install itself, which would have made for a better out-of-the-box experience. Overall, I was still pretty pleased.

Asides from the network driver, I have not run across any other issues yet. The UI changes would take me awhile to get used to, but it’s definitely a nice touch. I’ve already begun using some of the new features, such as aggregating multiple folders using libraries. More on that later. Right now, I’m gaming away in EQ2, doing Kurn’s Tower x1 on my new Windows 7 installation.

I am such a Microsoft fanboy

Posted on by
1

Windows 7 was officially RTM’d and released to OEM’s on July 24, but consumers won’t get their hands on it until October 22. However, certain other special groups are able to eat it earlier, such as MSDN and Technet subscribers, who will get it on August 6.

I couldn’t wait, so I forked out cash for a TechNet subscription, which ended up costing me in the area of SGD$500 after a 15% discount. All in all, it isn’t a bad deal, considering I’ll have access to numerous other Microsoft products to play with, such as Windows Server 2008. Being an aspiring system administrator (once I finish my army term), it works out great to have a bundle of software to tinker around during my (admittedly) free time.

Oh, I posted this from Internet Explorer just to top it off.

Windows and removable or remote media

Posted on by
Reply

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?

Posted on by
1

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

Transfer rate with a real file, in this case, an image of the Windows Vista WAIK


Test file created with fsutil

Test file created with fsutil


Transfer rate with a test file of the exact same size created by fsutil

The Path to x64

Posted on by
Reply

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 FilesSonyStationLaunchPad 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.