Sanchit's Blog

I wanted to post this a few years back but I just didn’t have the time.

This is something really interesting and it seems that nobody else has come across this little secret.

Many members from dreamincode.net Forums asked me how I could make my signature show videos running in the background and I’ve finally found time to explain how.

This is how my Forum Signature looks like (or looked like when I was writing this post) :

To see how this works, follow these steps:

1. Open your favourite media player and play any video file.
2. Ensure that the media player window is covering the image above.
3. Now, minimize the media player.
4. You should now see a portion of the video being played on the image as if the image itself were a media player.

Awesome, isn’t it?

I figured this out while I was experimenting with an application of mine which tried to modify Media Player Classic on-the-fly.

It seems that in Windows XP (might also be true for other windows OSes and other OSes), Video files can only be displayed on a portion of the screen that has a particular colour. The video can only be displayed on a portion of the screen which is currently displaying a specific colour.

That specific colour is RGB(16,0,16).

Try it out for yourself. Create an image with a background colour of RGB(16,0,16) like this:

Now play any video over this image and minimize the video player. The video should now be visible on the image.

My guess as to why this works is that Windows (or other OSes) needs to be able to figure out where a video should be displayed when a media player requests for playback. According to me, this has been intentionally included in the video playback design.

If the media player just provided co-ordinates of a rectangle to the OS for displaying the video, that would mean that if any other application was placed on top of the media player window, the video would be displayed over the application’s interface which would not allow the user to see the application’s user interface (forms, controls etc.)

Here’s what I think they did to fix the problem.

The principle behind this design could have been that “if a video could be displayed only within a rectangle that displayed only a specific colour, no overlapping application would be affected.”

But which colour would be best suitable for this purpose? Black is the first colour that comes to my mind for obvious reasons but black is a common colour and is used frequently in desktop wallpapers or in user interface elements.

Hence they chose a colour that’s technically not black but would look just like black and hence they must have come up with the colour RGB(16,0,16)

My reasoning probably isn’t correct but I’m pretty sure that the real reason is based somewhere along the lines.

I just find it ironic that something that behaves just like a green screen doesn’t even have a hint of green in its colour code (its 16,0,16 in RGB) 😉

As I’m still not sure if this works on other operating systems, I’d appreciate it if you could test this on your operating system and post the result as a comment to this post. Thanks.

VB6 calls control events in a very specific way. It’s impressive but the design of event handling results in losing a certain number of guaranteed bytes per control used. By losing bytes, I am referring to the addition of redundant bytes in the executable code.

I studied the entire structure with Disassemblers and debuggers and found out that the total number of redundant bytes is  governed by the following formula:

Total Redundant Bytes = SUMMATION OF (4 x (Number_Of_Events + 6 – Events_Used) ) FROM 1 TO N

where:
N = Total Number of Controls Used
Number_Of_Events = Total Number Events Supported by a Control (Different for each control)
Events_Used = Number of Events Used for each control.

So Imagine a simple form having two text boxes and 1 command button for a simple login box, considering that only the following events are used:
Form_Load()
Command1_Click()
The Total number of Redundant Bytes is:
(4*(31+6-1)) + 2*(4*(24+6)) + (4*(17+6-1)) = 472
1 FORM + 2 TEXT BOXES + 1 CMD BTN

That’s 472 unnecessary bytes just for a simple login box using absolutely no user-written code.

Many people refer to VB6 as Visual Bloatware, and you now know why 😉

I’ve come across a few people who believe that minesweeper lays down only half the number of bombs and only adds the other half on the board as the game progresses.

I debugged the game myself and have found that it is completely false. However, the game ensures that you don’t click a bomb on the first click. Hence, if the first click is a bomb, it is removed from the grid and placed at the first empty location from the coordinate (0,0) i.e. the top-left location.

Hence, if you clicked on (3,2) which originally had a bomb, it would be removed from (3,2) and placed at (0,0) if that location were empty.

This can also be verified without using a debugger. Use the xyzzy cheat to enable the white pixel at the top-left corner of the screen. Then, find a location which contains a bomb (ie. black pixel at top-left corner of the screen) but don’t click it. Now, move your cursor to the top-left corner of the screen and check if it has a bomb.

Now click on the previous location which had a bomb and you’ll notice that there isn’t a bomb once you click it. Then move your cursor to the top-left corner of the board and you’ll notice that the bomb has been shifted to the top-left location.

Minesweeper cheats FOR you and not against you to ensure that you can start the game without clicking a bomb everytime.

A while back I was studying the Len() function of VB6 and I came across something interesting.

Contrary to our belief that this function counts the number of characters in a string and returns it, it actually does something totally different.

Here’s how it works.

When any string is stored in VB, it is automatically stored in this format (in unicode):

Suppose the String is “ABC”:

06 00 00 00 41 00 42 00 43 00

The 41 to 43 part is a typical unicode style of storing strings, but 2 unicode characters before that, the number of bytes occupied by the string (including zeros) is stored (which is similar to Pascal style strings).
Hence 06 stands for 6 bytes occupied by “ABC” (since it’s stored as A,0,B,0,C,0)

So all that the Len() does is read 4 bytes before the beginning of the string and return that value itself, instead of calculating the length of the string.

So actually, the Len Function does nothing except read the length from the string format and return it.
Want to see how they do it?
Here’s the Disassembled Listing of the Len() Function MSVBVM60.DLL DLL File.

__vbaLenBstr proc near
   string = dword ptr 4

   mov eax, [esp+string] ; eax points to string
   test eax, eax ; ZF,SF,PF = EAX and EAX
   jz short break ; If String is Null then break from loop
   mov eax, [eax-4] ; Gets Unicode Length stored before string.

   ; Here’s how Text from textbox is stored internally:
   ; If text is born2c0de then in memory:
   ; (0×12 0×00) 0×00 0×00 (0×62 0×00 …)
   ; ie. length of string in bytes(unicode) (here 18 bytes)
   ; followed by a Unicode 0 (0×00 0×00)
   ; followed by the actual string in unicode
   ; (’b’ 00 ‘o’ 00 … ‘e’ 00)
   ; So [eax-4] just gets the unicode length of
   ; string which already is stored when a
   ; string is taken as input from keyboard.

   ; The Len() function doesn’t even calculate length!!!
   shr eax, 1 ; Divides Length by 2 to get Actual Length.
   ; Uses eax so it can be used as a return value.

break:
   retn 4
__vbaLenBstr endp