Valhalla Legends Archive

Programming => General Programming => Assembly Language (any cpu) => Topic started by: Telos on February 11, 2004, 03:11 PM

Title: Disassembling VB Programs
Post by: Telos on February 11, 2004, 03:11 PM
TheMinistered and I have been documenting some of the functions inside of VB programs to understand exactly what is going on.  The first thing we noticed is that if you write VB programs with strict type checking and use type specific functions like Mid$, Left$, Right$ instead of variant accepting functions like Mid, Left, and Right, there is a serious decrease in the amount of code that VB generates.  It may seem fairly obvious but its a good reminder to use type specific functions whenever possible.  Lastly for people interested in working with VB disassembly the documentation on the functions we have done is available at http://www.freewebs.com/telosx (http://www.freewebs.com/telosx)
Title: Re:Disassembling VB Programs
Post by: Grok on February 11, 2004, 05:04 PM
That's a well documented fact, which you could have deduced without disassembly.

When using the Variant type functions Mid(), Left(), Right(), Trim(), etc, VB must first determine the vartype of the operands.

In fact it is one of the first things you learn when reading about VB code optimization.
Title: Re:Disassembling VB Programs
Post by: Telos on February 11, 2004, 05:21 PM
Hence the statement:

Quote
It may seem fairly obvious but its a good reminder to user type specific functions whenever possible.

It should be common sense that when using indetermine forms of variables that extra code will be required to determine the data type.  The disassembly simply allows you to see the sheer volume of extra code that Visual Basic has to execute to do this.
Title: Re:Disassembling VB Programs
Post by: Grok on February 11, 2004, 05:52 PM
By the way, why are you two disassembling a dead language?
Title: Re:Disassembling VB Programs
Post by: Newby on February 11, 2004, 06:10 PM
Quote from: Grok on February 11, 2004, 05:52 PM
By the way, why are you two disassembling a dead language?

/me looks at how many posts in the Visual basic section there are compared to any other programming sections (Besides General =P)

/me laughs :P

It's not dead for Battle.net :P
Title: Re:Disassembling VB Programs
Post by: Adron on February 11, 2004, 07:23 PM
Quote from: Grok on February 11, 2004, 05:04 PM
That's a well documented fact, which you could have deduced without disassembly.

When using the Variant type functions Mid(), Left(), Right(), Trim(), etc, VB must first determine the vartype of the operands.

In fact it is one of the first things you learn when reading about VB code optimization.

That is strange. I see VB functions getting turned into other calls when compiling to native code. VB should be able to do static selections of what function to use when you call Mid, Left, etc, if they are passed string variable arguments.
Title: Re:Disassembling VB Programs
Post by: Maddox on February 29, 2004, 08:32 PM
Should be
BSTR __fastcall __vbaStrCopy(BSTR destination, BSTR source);

This isn't like like strcpy. It copies source and destination to a new buffer which it returns.