Archive

Posts Tagged ‘visual basic’

Visual Basic 6 Internal Event Handling

January 16th, 2009 1 comment

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 ;)

Categories: Code Internals Tags: , ,

Microsoft does it differently

January 8th, 2009 1 comment

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