4 Ways to Disable Autoplay in Windows XP

Autoplay can helpfully automatically do things when you insert a disc, but it can get your computer rootkitted or just be plain annoying. If you want to turn it off, there are several ways of doing it.

  1. To disable autorun just temporarily, hold down the Shift key as you insert a CD.
  2. Go into Device Manager (Control Panel→System→Hardware→Device Manager), select your disc drive, go into its properties, and uncheck “Auto Insert Notification.”
  3. If the last step doesn’t work (you don’t see such a checkbox), try downloading Tweak UI, a useful tool from Microsoft for manipulating many Windows settings. In the disc drive settings (My Computer→Autoplay→Drives), uncheck the letters for which you do not want Autoplay on.
  4. If you don’t wish to download and install Tweak UI, you can use the Group Policy Editor on Windows XP Pro (this tool is slightly dangerous if used incorrectly).  Run “gpedit.msc” and navigate to the System templates folder (Computer Configuration→Administrative Templates→System) and open up the “Turn off Autoplay” template.  Change it from “Not Configured” to “Enabled,” which should turn off AutoPlay.

HP dv6605 dv6000 XP drivers

I got a new HP dv6605 Pavilion laptop, but it came with Vista. I reimaged it with XP MCE from an older Pavilion onto it, only to find out that none of my drivers worked.

HP doesn’t provide XP drivers for this laptop – only Vista drivers. There are three main things that need drivers: the video card (nVidia GeForce Go 7150M), the chipset (nForce 650M), and wireless adapter (Broadcom something-or-other). I’ve got all but the wireless working so far (I’ll try that next).
For the video card, theoretically any new ForceWare driver release should work because nVidia uses a unified driver architecture (UDA), but the ForceWare installers are picky about which cards they’ll install for. I used the 156.65 drivers from laptopvideo2go.com. Newer drivers will probably work if you get modified INFs.

Edit:  Newer video card drivers don’t work, at least for me.  I tried a couple drivers from the 16x.xx series and it only made Windows unbootable.
The nForce chipset, which includes Ethernet and stuff, was trickier. Somebody reported limited success with using Vista drivers from HP in XP, but Ethernet didn’t work. I found out that nForce drivers from Acer worked for my HP laptop, including ethernet.

For sound, the Conexant HD Audio is the same as HP’s other models. I was able to go into Device Manager and install the driver by choosing to select for a list. The Conexant HD Audio driver was under “Sound … controllers,” “Conexant,” “Conexant HD Audio.” It was in the list probably because it was leftover from my last laptop. You can also try downloading the driver from HP’s website – try searching for the “dv6110us” model and getting drivers from there. The audio instantly worked after installing the driver.
When I tackle the Broadcom wireless, I’ll update this.

Edit: I got my wi-fi working using the Broadcom drivers from the Acer website mentioned above (link again). They’ll be named “Broadcom Wireless LAN Driver” when you install it. There’s an interesting side effect to these drivers: the light by the wi-fi switch will be orange when it is off, slowly blink blue and orange when it’s on but not connected, and rapidly blink when data is transmitted.

Fixing fork and sshd in cygwin

I decided to go crazy and arm my computer with all I needed to access everything from any Internet-connected computer, including stuff like VNC.  Naturally, I wanted this to be secure, both to prevent unauthorized access and to maintain my privacy.

I figured the best way to do it would be to set up a SSH server on my computer.  This way, I could not only login remotely but also tunnel ports securely through the Internet.  Because my computer runs Windows, I had installed Cygwin so I had have a Unix environment at my disposal.  (My Mac already has the Unix stuff on there, and it’s somewhat analagous to Cygwin).  I followed the easy instructions on how to setup sshd on Cygwin.

However, when I tried to login with “ssh localhost”, it kept giving me the error:

ssh_exchange_identification: Connection closed by remote host

A Google search showed me that several people had the same error, but they didn’t have the same problem as I did.

I looked in /var/log/sshd.log and saw stuff like:

sshd 3844 fork: child -1 – died waiting for longjmp before initialization, retry 0, exit code 0xC0000022, errno 11

for every time that I tried to connect.  Apparently, sshd couldn’t fork new processes.  This pointed to some internal errors.

Rebaseall didn’t help.  Neither did disabling Windows Firewall.  Nor did downgrading openssh.

However, cygcheck showed me the problem.

Running “cygcheck -s | less”, it gave me a warning about having multiple cygwin1.dll’s in my PATHs.

Google Desktop showed me I had no less than 4 copies cygwin1.dll on my computer that were all different versions and were in my PATH (where the system looks for executibles).  Bad, bad, bad.  I either deleted or replaced the other cygwin1.dlls.

Fixed.  Just make sure you only have one cygwin1.dll.

Benchmark: Turion 64 X2 vs. Celeron 331

I got a new laptop (see previous post) with an AMD Turion 64 X2 Mobile TL-50, with a clock speed of 1.66 GHz per core.

Earlier, I got a new CPU to replace the broken one in a desktop computer. That one is an Intel Celeron 331, with a clock speed of 2.66 GHz.

I know clock speeds are more for marketing than for an indicator of performance, so I decided to try a benchmark. Each computer would try to optimize an approximately 6000×5000 pixel PNG image using OptiPNG.

This test is fairly simple and mostly geared towards CPU power. OptiPNG is not multi-threaded, so essentially I was comparing a single 1.66 GHz core with a 2.66 GHz CPU. No fancy processor instruction sets were used. Both processors are 64-bit, but both were running 32-bit Windows.

Minor factors:

  • Turion laptop’s hard drive is 5400 RPM. The other’s was 7200 RPM.
  • Background processes may have been shifted to the Turion’s other core, thereby allocating more cycles to the benchmark, as opposed to the single-core desktop computer.

The result:

  • Celeron 331: Finished the test in 1:06 min.
  • Turion TL-50: Finished the test in 1:30 min.

From these results:

  • If the Turion was running at 2.66 GHz per core like the Celeron, it would’ve finished in about 56 seconds, meaning it might be slightly more efficient (IPC) than the Celeron.
  • If both cores of the Turion were used, it would have finished in about 45 sec.
  • If the Celeron had a clock speed of 3.32 GHz (1.66 x 2), it would have finished in about 52 seconds.

This means, my Celeron is kinda slow. It also consumes more power (1.3 V vs. 1.1 V). However, it cost a whole lot less (partly because it’s for a desktop).