Writing FreeBSD memstick.img to a USB drive in Windows

I’ve received some hits on my blog of people looking how to write the FreeBSD memstick.img image to a USB flash drive under Windows. The official FreeBSD procedure works great, but only applies if you already have access to a FreeBSD box. Accomplishing the same under Windows is more of a hassle, but not too much.

The solution: download John’s Newbigin’s dd for Windows. This is an enhanced version of dd which also lets you list off raw devices in Windows — including USB sticks.

In the below example, I have a 4GB USB flash drive (HP, model v100w) connected on a USB port, under Windows XP SP3. This is the drive I want 8.0-RC2-amd64-memstick.img written to. Bolded text is used for denoting commands I’ve typed, as well as the device strings associated with the USB flash drive:

C:\>dd --list
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL.  See copying.txt for details
Win32 Available Volume Information
\\.\Volume{1ff1b266-ab71-11de-b1e8-806d6172696f}\
  link to \\?\Device\HarddiskVolume1
  fixed media
  Mounted on \\.\c:

\\.\Volume{808faa36-bdbc-11de-a116-806d6172696f}\
  link to \\?\Device\HarddiskVolume2
  fixed media
  Mounted on \\.\d:

\\.\Volume{1ff1b262-ab71-11de-b1e8-806d6172696f}\
  link to \\?\Device\CdRom0
  CD-ROM
  Mounted on \\.\e:

\\.\Volume{3794d0ff-abb4-11de-9377-00221578190a}\
  link to \\?\Device\CdRom1
  CD-ROM
  Mounted on \\.\f:

\\.\Volume{ec4923e1-c907-11de-a118-00221578190a}\
  link to \\?\Device\Harddisk1\DP(1)0-0+12
  removeable media
  Mounted on \\.\g:

NT Block Device Objects
\\?\Device\CdRom0
  size is 2147483647 bytes
\\?\Device\CdRom1
  size is 2147483647 bytes
\\?\Device\Harddisk0\Partition0
  link to \\?\Device\Harddisk0\DR0
  Fixed hard disk media. Block size = 512
  size is 300069052416 bytes
\\?\Device\Harddisk0\Partition1
  link to \\?\Device\HarddiskVolume1
\\?\Device\Harddisk0\Partition2
  link to \\?\Device\HarddiskVolume2
\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR17
  Removable media other than floppy. Block size = 512
  size is 4009754624 bytes
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\Harddisk1\DP(1)0-0+12
  Removable media other than floppy. Block size = 512
  size is 4009730048 bytes
...

The device string we want is the NT Block Device, not the Win32 Volume, and we’re interested in the Partition0 entry. Now that we know the device path, we can write memstick.img directly to that, using the exact same block size as what the official FreeBSD procedure recommends.

Note that the conv=sync parameter has been removed (not needed here, and this version of dd doesn’t understand it anyway), and I’ve added the --progress flag which indicates how many bytes have been written in real-time (useful).

Finally: please be sure you pick the correct device string! I won’t be held accountable if you screw this up and destroy your Windows machines’ hard disk. :-)

C:\>dd if=8.0-RC2-amd64-memstick.img of=\\?\Device\Harddisk1\Partition0 bs=10240 --progress
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL.  See copying.txt for details
1,044,858,880
102037+0 records in
102037+0 records out

Voilà.

How to install and use SCFH DSF

Many people over the past year have written to me or mailed me asking how to install and use SCFH DSF, since the site and the installation instructions are in Japanese. Today, I decided to write up such instructions for English-speaking individuals, and also document the features that I use.

Keep one thing in mind: all of this applies to Windows XP. I have no experience with using SCFH DSF on Vista, but according to the author it should work fine. I just don’t have any experience using it under that OS. Also, there’s no mention of it working or not on Windows 7, so I would be very wary running it there — but if someone feels ballsy enough to try it, go for it and let me know.

1. Download SCFH DSF, and unpack it into its own directory somewhere of your choice.

2. Close and fully exit any applications you have which can utilise video capture capabilities. I’m talking about things like MSN Messenger, Windows Live Messenger, etc. — basically anything that might be able to capture video from a device (think: webcam).

3. If using a 32-bit OS: download and install the Microsoft Visual C++ 2008 Redistributable Package (x86) here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf

   If using a 64-bit OS: download and install the Microsoft Visual C++ 2008 Redistributable Package (x64) here: http://www.microsoft.com/Downloads/details.aspx?displaylang=en&FamilyID=bd2a6171-e2d6-4230-b809-9a8d7548c1b6

4. If using a 32-bit OS: go into the SCFH directory you unpacked things in, and double-click the install.bat file. (NOTE: To uninstall SCFH DSF, follow Step #2, and run uninstall.bat)

   If using a 64-bit OS: go into the SCFH directory you unpacked things in, and double-click the install64.bat file. (NOTE: To uninstall SCFH DSF, follow Step #2, and run uninstall64.bat)

5. You’ll get a cmd.exe window and a pop-up dialog box that should say DllRegisterServer in scfh.ax succeeded (or scfh64.ax if you’re using a 64-bit OS). If not, something else is wrong and I can’t help past that point (I’ve never seen this step fail). Click OK to close both the dialog and the cmd.exe window.

6. In the same directory there’s a program called SCFH.exe. Make a shortcut to this somewhere for convenience, e.g. on your desktop. This is the main SCFH DSF control program. Once you run it (hold off on that for a moment), you should leave it open while capturing.

7. Launch any of the capturing utilities you want, such as Windows Live Messenger or Firefox/Internet Explorer with Flash which can capture from a webcam, etc… Ustream is a good example.

8. Run SCFH.exe or the shortcut you made. You’ll be given a window that says Select process. Pick the process name of the program which you wish to control SCFH in and click OK. For example, if you want to let someone watch your webcam (SCFH DSF that is, e.g. stream a copy of your desktop) in Windows Live Messenger, pick msnmsgr.exe. If you’re using Ustream or something similar, pick your browser process instance. Unlike VHScrCap, the process instances here make a lot more sense, and there aren’t multiples of the same name to confuse you.

   If the process in question isn’t listed, you probably need to set up said program (or Flash) to note that you have a new capture device available — the device is literally called SCFH DSF.

9. You’ll now be in the main SCFH DSF control program.

I’ll document the features the SCFH DSF control program that I’m familiar with or have a pretty good idea about. And whenever changing any of these features, be sure to click the Apply button!

• Drag here — used to select a portion of a window or a dialog/model by clicking the left mouse button + holding it down and “dragging” the selection window/border around. You’ll have to try it to understand what I mean. Note that the one beautiful thing about the Drag here feature is that once you select part of a window, you can move that window around and not have to re-adjust SCFH to tell it where the X/Y coordinates are.
• Area Selection — used to select a specific region of your desktop that you want to capture. Left click it once, and you’ll be shown a green translucent box that has the text Double-click to Apply in it. You can drag this box around and resize it (like you would a normal window), and when you’ve selected an area of your desktop you want to capture, double-left-click in the green translucent box.
• X/Y and Size input boxes — define what X/Y coordinate you want SCFH to capture (upper left corner) and what width/height. Any changes you make here should show up in the capture window of the program (Flash, Windows Live Messenger, etc.) in real-time. If there are common X/Y coordinates or sizes, you can click the Add button next to the respective item and they’re stored for future use. More on that at the end of this write-up.
• Show Mouse Cursor — defines whether or not SCFH DSF should capture your mouse cursor or not.
• Show Layered Window — allows you to capture things like Tooltips and other things that aren’t technically a window.
• Keep Aspect Ratio — should speak for itself. This option works significantly better than VHScrCap, in my opinion, and more reliably. This is quite possibly the main reason I stopped using VHScrCap given the described bug in my blog entries circa 2008.
• Enable Enlargement — only works when Keep Aspect Ratio is enabled. Say the program which is using SCFH DSF as a capture driver is capturing at 640×480, but the area/window you have selected to capture in SCFH DSF is only 200×160. When Enable Enlargement is disabled, what you’ll see in your program is the 200×160 capture region, centred, surrounded by a black box to fill in the remaining 440×320 pixels. When enabled, it would stretch the 200×160 contents to fit the size of the capture area.
• Over-Sampling — adds somewhat of a blur between two frames during animation/movement. Look up what oversampling means on Google, and some example sites/videos, and you’ll then understand it, or just play around with it.
• Thread Num — not entirely sure on this one, but based on how the program works, my guess is that it probably defines the number of threads SCFH DSF should use for internal operations. If you have multiple CPUs or a dual/quad core system, you might benefit from increasing this to 2 or 4. I myself have a quad core system and I’ve never had to adjust this; I always leave it at 1.
• Resize Method — allows you to pick how resizing functions and looks, and not just for Enable Enlargement but for any kind of resizing. They all look slightly different, and it’s especially noticeable on small resolution capture areas. I tend to use DirectDraw (1Pass) mostly because it’s incredibly fast and looks great. Note that you may want to adjust this if you’re capturing an area that has text. Try them all out, see which one looks best to you and to the person you’re streaming to. Keep in mind that most online streaming uses compression of some sort, so some of these resize methods might look better or worse once compressed by the streaming software.
• Capture: XXX fps — should be obvious. This defaults to 30fps, which is more than sufficient. I’m pretty sure it’s adjustable, I just can’t remember where…
• Performance — gives you an idea of how SCFH DSF is performing.  The author chose a unit type of frames per second, which is a little odd but understandable given the role of the program. The value shown here is highly dependent upon 4 things: 1) CPU speed, 2) video card speed (since many DirectX functions are offloaded on to the GPU), 3) Resize Method selected, and 4) size of the capture region. For example, the performance is going to be much higher for a 200×200 window than it is for a 1920×1200 desktop that has to be resized/scaled down to fit into a 640×480 capture region. :)

Finally, SCFH DSF does not store any data in the registry — instead, it stores configurations per application (e.g. firefox.exe, msnmsgr.exe, etc.) in INI files in the directory where SCFH DSF is located. The files will be named things like SCFH.msnmsgr.exe.ini, SCFH.firefox.exe.ini, and so on — you get the idea. The SCFH DSF capture driver itself does not use these, only the SCFH DSF control program, so be sure you exit the control program before deleting any of them.

Hope this helps get folks started with SCFH DSF.

VHScrCap bugs — part 5.

After much chaos (see my previous blog entries about this subject), I’ve recorded a 15 minute video showing the “cropping bug” in VHScrCap 2.1.4.0. It also includes a new bug, where VHScrCap suddenly stops working altogether (until I switch video sources, where it suddenly comes back to life); this bug could actually be with Flash, but I’ve never seen this happen with SCFH DSF or my webcam.

The fact that the “cropping bug” doesn’t happen until you’ve run/used VHScrCap the first time is a bit disconcerting. Near the end of the video, I also show that deleting the VHScrCap registry keys restores proper functionality (no more “cropping bug”).

The entire thing was recorded using VirtualDub (video and audio). Thankfully VirtualDub has screen and audio capture support, making recording this video incredibly easy. The quality is quite high, and very crisp; you should be able to see everything. And yes, my voice is fairly annoying, sorry. :-)

The video codec used is FM Screen Capture Codec (~100KBytes). I would have gone with Vladimir’s own VH Screen Codec, but it’s a DirectShow filter, and VirtualDub doesn’t work with those. The audio is MPEG Layer-3 (MP3), which should work for everyone. One bad thing about the video codec, however: it has no true keyframe support, so fast forwarding and rewinding doesn’t work. :-(

The video is available here (47MBytes):

http://www.malkavian.com/~jdc/vhscrcap/20080614_cropping_bug.rar

I don’t know what else I can say about this problem. The video speaks for itself.

VHScrCap bugs — part 4.

EDIT: This just in.  I just managed to reproduce (in full) the “cropping bug” in 1.5.0.  I really don’t know what just made it start happening, since 30 minutes ago it wasn’t occurring.  This might have to do with the well-known issue where VHScrCap’s configuration utility leaves itself lingering in memory (which is actually fixed in the 2.1.x series), so possibly the registry entries never got updated.

Additionally, Vladimir has stated he can reproduce the “cropping bug”, but with webcams or other hardware.  I’ve never seen that happen, ever — only with VHScrCap.

I’m going to try recording a video switching between the two DirectShow filters (VHScrCap vs. SCFH DSF), showing the problem.  I’ll include audio as well, assuming it doesn’t make the file too big.

This morning I decided to download VHScrCap 2.1.4.0 (according to the website, although the actual VHScrCap driver, once installed, is 2.1.5.0) and attempt to reproduce the bugs. Despite the incredibly annoying VHMultiCam feature (which is new to me) getting in my way, I was only able to reproduce (partially; it’s hard to explain) the “cropping bug”, but not in a way that would affect the video capture region itself. I could only partially reproduce it with the “Keep aspect ratio” option disabled. The “mosaic bug” was completely gone.

I uninstalled VHScrCap 2.1.4.0, deleted the leftover registry entries, and ensured that all the .ax files were unregistered/deleted from my hard disk. Then I installed VHScrCap 1.5.0, which is “old”, but labeled stable. Version 1.5.0 was what I originally was using when I found these bugs. Amazingly, I was not able to reproduce either bug using version 1.5.0 (though I’m under the impression 1.5.0 acts like 2.1.4.0 with “Keep aspect ratio” disabled).

Three major changes have occurred since late 2007 and now:

1) I’m using Windows XP SP3, versus Windows SP XP2,

2) I’m using DirectX 9 end-user runtimes dated June 2008, versus November 2007,

3) I’m using Adobe Flash Player 9.0 revision 124, versus a significantly older version.

This seems to indicate the core of the problem was in XP SP3, DirectX (which includes DirectShow), or Adobe Flash. None of these programs include ChangeLogs, so finding the true source of the fix will prove very difficult. VMware Workstation would come in handy (for installing XP SP2, an older DirectX runtime, and old Adobe Flash), but one thing is for certain:

Presently, I cannot reproduce the problems I originally stated were in VHScrCap.

I’ll be spending the next few days fiddling around with my workstation, seeing if there’s something I’m missing from before. Reproducing these bugs was incredibly easy, and I haven’t forgotten the procedure.

Vladimir, I apologise for stating the bugs are in your software, but I’m still not 100% sure VHScrCap is out of the clear yet. Surely you can see where I’m coming from: if the problems weren’t in VHScrCap, why did switching to another DirectShow filter solve them? That’s the part I can’t figure out.

VHScrCap bugs — part 3

The author of VHScrCap has again responded to my blog, consisting of the following:

1) Claims SCFH DSF doesn’t store settings — false. Each application you bind it to (e.g. explorer.exe, msnmsgr.exe, etc.) causes SCFH DSF to store the settings in <processname>.ini in the directory where the scfh.ax filter was installed from. SCFH, on the other hand, does not store settings, which makes me wonder which program (SCFH DSF vs. SCFH) he’s actually using.

2) Continually ignores the fact, despite long walk-throughs and step-by-step explanations, that VHScrCap works perfectly fine (read: every DirectShow filter has the “cropping bug” and “mosaic bug”). The bugs I have described only happen after VHScrCap is shut down and restarted/re-initialised (and continue subsequently). You can delete VHScrCap registry keys to work around the problem, but you’ll have to remember to delete them every time you exit the application.

3) Suggests that I “re-write all of my blog posts” to inform the world that “these aren’t bugs in VHScrCap”.

4) Implies that by me stating there’s bugs in VHScrCap, that I am executing slander.

I’m not sure what to make of this, and I find it interesting. The definition of slander is defined as comments or actions which would injure a person’s reputation, or defame said person. Calling the author of VHScrCap a thief/murderer/etc. would be slander; mentioning bugs (or “features”) in a piece of software is not slander, regardless of those comments being posted in a blog fashion, in Email, or spoken.

And just to cover my ass, there’s nothing libellous about my comments either. There is absolutely no effort on my part to discredit the author or VHScrCap. There is nothing vindicative here. I am simply reporting problems I have found in VHScrCap, and recommending that if people encounter said problems, there are alternative softwares available (SCFH DSF). Let’s not forget that I did approach Vladimir privately (way before I even had this blog), and reported the problems I found, offering to help in my spare time test debug builds or work towards finding a solution — a slanderous or libellous individual would not do such a thing.

5) As a result of my “slander”, he will possibly contact the WordPress admins and ask them to either close my blog entirely, or posts specific to VHScrCap (I’m not sure which). He apparently hasn’t read the WordPress TOS, applicable sections of which are Section 2 subsection vi (which redirects you to a definition of defamation, which basically repeats what I said above, re: nothing that would destroy his character, as I have no issues with the author personally), Section 5 (Automattic is not responsible for any content posted on a blog, and states “The Website may contain content that … contains technical inaccuracies”), and Section 12 (Automattic is not liable for any content on the site).

6) Indirectly threatens to turn VHScrCap into a solely commercial piece of software if “users do not respect and help developers”. This is sad. I hope such doesn’t happen, because for most peoples’ needs, VHScrCap is fantastic. It is indeed faster than SCFH DSF, and offers the ability to integrate with your own software, which SCFH DSF cannot. But people need to make the decision of what program suits their needs best, on their own. So there are pros and cons to both programs.

On the flip side, he offers the following positive commentary:

1) Recommends that I describe bugs in Adobe Flash in verbose detail, offering to help with the technical descriptions, so that users or programmers in the future may benefit from said descriptions.

2) States that he has put a lot of man-hours into developing VHScrCap, and is happy to make it free, as long as users respect and help developers of free software.

Vladimir seems to be completely unaware that I’m heavily involved in the FreeBSD Project, which is an open-source/community-developed UNIX operating system, and have been involved in open-source projects since 1993. On the other hand, unlike other open-source contributors, I do not play the “you have the source, fix it yourself” or “it’s free, so stop complaining” defence cards. I believe users should have the right to say anything they wish about anything, and that if you release software publicly (which I have), you have a personal responsibility to maintain it.

Vladimir definitely maintains his software, and appears to enjoy maintaining it (why else would he take the time to defend his software here?). I have absolutely no personal qualms with Vladimir, and in fact I appreciate his passion. But his personal character is not what my VHScrCap-related blog posts are about. A person can only go so far with bug reports before saying “I’m out of options. Your program has issues that affect me. You’re claiming they’re not issues. I’m going to switch to another piece of software that doesn’t exhibit those issues”.

That is all I have to say on the matter. Users should read my blog posts, the user comments from Vladimir, download the videos (his and mine), and conclude whatever they wish.

VHScrCap bugs — part 2

Yesterday, the author of VHScrCap dropped by my blog and decided to post a statement, arguing that what I’m showing is not a VHScrCap bug. I thought about refuting his claims via another comment, but then I thought, “Why not just blog about it?”

So here it is, a step-by-step walk-through of the video showing the bugs in question, with notations of what’s happening when in the video. Follow along and enjoy the bugs the author insists are not.

00:00 to 00:10 — I launch VHScrCap with a fresh/empty registry, and set it up to capture the full screen. Looks perfect!

00:11 — I choose Track Window, to track the Windows Media Player window of the Japanese parrot fish. Again — looks perfect! The video is “stretched”, but that’s not a bug — it’s expected.

00:12 to 00:44 — I move some windows around, showing the border of the capture region is correct/working properly. Still no bug at this point.

00:45 — I close Windows Media Player.

00:48 — I close the Flash application, which is what’s using VHScrCap. The VHScrCap configuration window also closes.

00:51 — I close the IE window, which is responsible for loading the Flash applet. I do this “just in case”.

00:56 — I launch the IE window.

01:01 — I log in to Ustream.

01:06 — I click “Broadcast Now” in Ustream, which brings up the Flash applet.

01:10 to 01:35 — Here is the first sign of the bug I call the “mosaic bug”. As you can see, the capture window contains what appears to be a heavily mosaic’d version of a portion of the entire screen (my desktop). This makes absolutely no sense what so ever. Now, I assume this bug happens because VHScrCap is still (somehow) trying to refer to the old window capture region of WMP, which is now closed. However, why is it mosaic’d? I also believe this bug to be possibly what leads to the next problem…

01:35 to 01:45 — I launch VHScrCap’s configuration program, and choose the first instance of Internet Explorer.

01:47 — I confirm that Track Screen is selected, confirming my above comment (re: mosaic’d version of my entire desktop).

01:48 to 01:52 — I close the VHScrCap configuration program, and relaunch it.

01:53 to 02:06 — I choose the Internet Explorer window once again, but this time a 2nd instance of it (since there were two instances shown earlier).

02:06 to 02:19 — I close VHScrCap and Internet Explorer, wanting to show that relaunching EVERYTHING (including Flash) to prove that nothing changes.

02:20 to 02:31 — I launch Ustream, log in, and click Broadcast Now, which launches the Ustream Flash applet.

02:32 — Oh look! All I did was relaunch everything, and now VHScrCap isn’t “mosaic’ing” anything — it’s capturing my entire desktop, like it should have done the previous time! This ABSOLUTELY confirms a bug. But wait, there’s more!

02:33 to 02:42 — I launch the VHScrCap configuration program.

02:42 to 02:52 — I move my mouse around the border of the captured region being shown in the Ustream application, and move some windows around. The reason I do this is to indicate my desktop is suddenly cropped incorrectly.

Do you see any sign of my desktop icons on the far left? Nope. Do you see any on the far right? Nope. What about when I drag a window to the left? You can see the left side of that window is no where NEAR the edge of my desktop, yet in the captured region inside of Ustream (VHScrCap!), it’s hitting the border of the captured region. VHScrCap somehow thinks my screen isn’t 1920×1200 any longer. ANOTHER bug, which I often refer to as the “cropping bug”.

02:53 to 02:55 — I select Track Window in the VHScrCap configuration.

02:56 to 03:06 — I go into Explorer (not IE) and launch WMP by double-clicking the video of the Japanese parrot fish. WMP launches.

03:06 to 03:14 — I tell VHScrCap to capture the WMP window, using the Select Window pulldown.

03:15 onwards — Look very closely at the captured region in Ustream. Again, you can see that VHScrCap is incorrectly cropping off the left and right sides of the WMP window — the same thing it was doing before when capturing the entire screen.  This proves the “cropping bug” happens with both Track Screen and with Track Window.

The fact of the matter is these are bugs.  There is absolutely no other way to see it.  The only solution for them is to clear the VHScrCap registry area, which fixes the problem until the next time you launch/utilise VHScrCap.  That, to me, confirms there is a bug.

On the other hand, VHScrCap does in fact capture regions faster than SCFH DSF, though the magnitude is not very substantial enough to justify putting up with such bugs.  I would rather have a capture filter work correctly, albeit 4-5 fps slower (but this doesn’t matter since Ustream limits you to ~20fps anyways!).

VHScrCap bugs

Many months ago, I found an incredibly annoying bug in a DirectShow filter/capture driver called VHScrCap, both in the older 1.x versions, as well as the newer 2.x versions.

Before I go into the bug, I’ll explain what VHScrCap is and what purpose it serves. It’s a very popular application used for capturing portions of one’s desktop (or any application window) and retransmitting it to any WDM-compliant (thus DirectShow) capturing application. For example, if you’re on Windows Live Messenger and want to show your friend a portion of your Firefox window, you can use VHScrCap for that purpose. The VHScrCap driver shows up as a webcam device in applications which support DirectShow — including Adobe Flash. VHScrCap is also quite fast, including some optimisation features which make it significantly fast even with large regions (1920×1200 for example).

For a few years I’d been using VHScrCap for one purpose: capturing the video portion of a Windows Media Player or Media Player Classic window, and re-streaming the video to a friend of mine in Michigan via Ustream. We watch bi-weekly episodes of Game Center CX, the Angry Video Game Nerd, island survival adventures involving members of Yoiko, or even us playing video games. Ustream uses Adobe Flash as a client (on both the sender and receiver side).

The bug was simple to reproduce: launch Ustream, launch VHScrCap’s configuration utility, set things up, and stream something as usual. Once finished, exit the browser, then go through the same routine again. The capture region/aspect ratio was completely wrong, and in some cases the capture region was capturing something like an 8×8 pixel region on my screen (and was heavily blurred at that!). I’ll add that the issue was not specific to Ustream: I could use Windows Live Messenger, or any DirectShow-friendly application to reproduce the bug.

I found that deleting the registry key HKLM\Software\HmelyoffLabs\VHScrCap before launching Ustream would fix the problem every time. Actually, to be more specific, deleting HKLM\Software\HmelyoffLabs\VHScrCap\params is what would fix it. I ended up writing a batch file and a replacement .reg file to work around the problem. See below for the link to those.

In December I contacted VHScrCap’s author and informed him of said bug, attaching screenshots of the problem. At first the author blamed Adobe Flash for the problem, and insisted I send him mini memory dumps when the problem happened (which required me to install extra Microsoft software). So I did. Then the author insisted there were no bugs in his code, and asked me to capture video of said problem. So I did. The author continued to blame Adobe Flash for something that is quite specific to his driver. I offered to completely format and reinstall Windows XP on my workstation as a form of troubleshooting — it made no difference. I eventually gave up communicating with the author, as it became obvious from the tone of his mails that he had zero interest in fixing this bug.

In case you want the workaround batch + .reg file, or to see the videos of the problem, they’re available below. Keep in mind that the .reg file is specific to VHScrCap 2.1.2 and will not work with earlier versions or later versions.

http://www.malkavian.com/~jdc/vhscrcap/

And then something happened yesterday…

I came across a Japanese application called SCFH DSF (which is a DirectShow Filter version of the SCFH program). You see, a few months back, the same friend and I translated SCFH and made an English version of the binary for personal use (I can’t/won’t post it out of respect for the author — I need to get in contact with him so there can be an official English release!). But a few weeks ago, the author released a DirectShow Filter version of his program, which means it more or less does the same thing VHScrCap does!

I promptly uninstalled VHScrCap and installed SCFH DSF. The client is in Japanese (I’m working on an English version), but it works wonderfully. Does it have the same bug as VHScrCap? Nope! Which further proves that the problem is with VHScrCap…

So for any visitors which use VHScrCap, reconsider using a DirectShow filter that actually works. :-)

Keyboard repeat rate and MSTSC/Remote Desktop

I’ve managed to find an interesting “flaw” of some kind with MSTSC and Windows, specifically in regards to keyboard repeat rate.

At work, I have my Keyboard repeat rate set via the Keyboard control panel as “Fast” (30-31 characters per second). This corresponds with the registry entry HKCU\Control Panel\Keyboard\KeyboardSpeed. At home, I have the same value set. I like a keyboard that has a very short delay (250ms is perfect), and a fast repeat rate.

I’ve noticed that at work, the repeat rate is slightly faster than at home (the delays are identical).  A friend of mine wrote a simple Win32 program which timed characters per second on a keyboard, and sure enough, my home machine outputs 20-21 characters per second.  Both my home and work workstations run Windows XP SP2.

Here’s the kicker — If I use Remote Desktop to connect from my work machine to my home machine, the keyboard repeat rate is that of my work workstation — makes sense, since I’m remotely connected. But after I’ve disconnected/logged out, the repeat rate of the remote workstation is retained on my machine at home. Well, that is until I reboot it. :-)

The bug itself is bizarre, but (for me) it’s actually useful. I like having a higher repeat rate. The repeat rate of my workstation at work is perfect.

So my question is: how exactly do I figure out what Remote Desktop is doing to set the keyboard rate, so that after a reboot I can restore that same rate?

Additionally, there’s a third-party program called Keyboard King which lets you adjust all of this stuff, but I’ve read a few forum posts saying that it can make a mess of certain keyboard input characters, and I’d rather not have some program sitting around in the systray running actively when, based on the above experience, I know there’s something internal to Windows which can allow me to have a higher repeat rate w/out third-party software.

GDI bugs with 2K/XP’s East Asian Languages option

For many (at least 7) years, there has been a bug which has driven me absolutely crazy when it comes to Windows 2000 and Windows XP. It’s very easy to explain: when the East Asian Languages check box is enabled in the Regional and Language Options, the GDI layer in Windows 2000 and Windows XP stops redrawing underlying windows properly when a window is dragged across another, or resized. The visual result is quite noticeable: leftover white lines all over the underlying window.

It honestly looks like an off-by-one bug of some kind, and is only induced when EAL is enabled. If you disable EAL and reboot, the problem goes away. The issue has kept me from enabling EAL for some time now. I’ve been able to confirm it on virtually every Windows XP Professional installation I’ve seen or done. However, on most of our workstations at work (Microsoft!), EAL is enabled and the problem does not occur.

When I brought it to the attention of some peers of mine who are more in-tune with the underlying workings of Windows, they were baffled. It’s well-known (and documented) that enabling EAL does “magical stuff” to GDI underneath, which leads me to believe the problem lies there.

done

The only workaround I know of is to avoid checking the EAL box, and instead extract individual Asian fonts from your Windows CD (they should be in \I386\LANG), decompress them, and copy them using Windows Explorer to your fonts folder. For example, copying MSGOTHIC.TTC and BATANG.TTC to your font folder would get you the ability to view Japanese Hiragana, Katakana, many Kanji, and with the 2nd font, Korean Hangul. Japanese or Korean input (IME) will not work, however.