Freeware Utilities Aren’t Worth the Cost

I feel like dropping my bike on rollers and doing some intervals. All I need is a timer. Google turns up a bunch of programs! One minute later: none of the programs with descriptions are what I want, and most don’t even have descriptions. Why am I even bothering to Google for this? I could write a script that does what I want in one second; back in a sec.

while true; do sleep 60; print \\a; done

Shoot, the cygwin alarm isn’t loud enough. How do I make it louder? Back to Google. Thirty seconds later: Great! A hundred different message board and mailing list posts, most of which have no replies. I could have written a program that would do what I want in the time I spent searching. Back in thirty seconds. Maybe forty, since I’m not really familiar with F# or .NET

let timer =

  let t = new System.Timers.Timer()

  t.Interval <- 60000.0

  t.Enabled <- true

  t.Elapsed.Add(fun _ -> System.Media.SystemSounds.Hand.Play())



  print_endline “Enter to kill”

  read_line() |> ignore

  t.Enabled <- false

O! It’s loud enough even if I don’t adjust the volume. I’m done! And it only took ten seconds, since I didn’t need any volume controls.

Now I want to be able to copy and paste this to Trillian, which is running on one of my other machines. At least Google only gives returns one result this time, and the linked program will even do what I want. But it costs $25. Are they kidding? Back in five minutes.

This has been happening more and more lately. Whenever I search for some trivial Windows utility, Google returns hundreds of irrelevant results and a few commercial programs which are relevant but cost $5/minute. I wonder why I don’t have this problem when I’m looking for Linux utilities, despite being a better Linux programmer. Ahh, well, time to hop on the bike. Back in a an hour . . .

Freeware Utilities Aren’t Worth the Cost

Mysterious Opcodes and Instruction Prefixes in Windows 98 and Windows Vista

I’ve been playing around with running Windows on top of a VM and it’s got some strange looking opcodes I can’t figure out.

Windows 98 has opcodes that have redundant prefixes. For those of you that don’t muck around in assembly, x86 has prefixes to do things like access the 16-bit version of an instruction instead of the 32-bit version of the instruction. It’s legal to tack on the same prefix multiple times (and every processor I’ve tried even does the same thing if you add contradictory prefixes). I doubt any Win98 era compiler generated redundant prefixes, so those prefixes must have been added on purpose. But why? It’s clearly not for alignment reasons in Windows, and it even mucks up the alignment in a few places. Even if alignment were an issue, adding redundant prefixes would have been bad way to go about it at the time – decoding extra prefixes was expensive prior to Athlon and Banias on Intel and AMD processors, respectively.

It’s at least possible that an assembly coder would add a new unsupported prefix manually, and then forget to remove the extra prefix when the assembler is updated, but Vista has me completely baffled: it issues 0x0F0D opcodes. That’s a NOP on my Conroe, but it’s a 3dNow! prefetch opcode on older AMD processors, and it causes an undefined opcode exception on Intel processors up to and including Prescott. As in the previous case, this doesn’t seem to be for alignment purposes. AMD supports Intel’s prefetch opcodes, so it’s not because you need to issue both AMD specific and Intel specific preftech opcodes. I can see why you’d want to NOPs in a debug build (since they let you place breakpoints in places you might not otherwise be able to) but surely the Vista release build isn’t a debug build.

Even if you want a NOP, why use 0x0F0D? 0x90 works fine, and won’t cause problems on older processors. If you want a longer NOP, you can always add prefixes (which are fast now). Is it only used in the Core2 codepath? I tried spoofing the CPUID to match Prescott, and I still saw this mysterious new NOP, but I was only spoofing family, model, and stepping. Maybe Windows looks at the feature flags to really determine which CPU is really being used, in which case it would have still gone down the Core2 codepath. Even if I spoofed those, who knows what else MS uses to identify a CPU? I’m tempted to buy an old Prescott system off ebay just to see if Vista takes the same codepath, causing the CPU to throw undefined opcode exceptions all the time.

Considering all of the effort that MS goes through to improve Windows performance, they must know they’re doing this. It’s unlikely that it’s an accidental last minute change

UPDATE: After experimenting with some cache tests, we can see that 0x0F0D is actually causes prefetches on Conroe (and newer) processors, even though the current version of the Intel Architecture Manual claims that the opcode doesn’t do anything. What other 3dNow! opcodes has Intel adopted?

UPDATE 2: Raymond Chen gives one reason you might want odd prefixes on things: to work around Intel CPU bugs. It turns out that work-around was pulled before the OS was released, but perhaps there’s a similar explanation for the odd opcodes I was seeing.

Mysterious Opcodes and Instruction Prefixes in Windows 98 and Windows Vista