*Actually*; starting with VB5 the VB compiler pre-processes the code, then hands it off to a C compiler; that does create windows
'native' executables. If you've ever programmed in C++ (I assume you haven't), you know how difficult form/control management is, so
VB still relies on the MSVBVMxx.DLL for form and control management, but the VB code does compile to near-C code, although C code is
still much less efficient than 'native' executables, which techinally would have to be in assembler to be 'native', but it's close enough.
In fact, for true VB speed (rivaling C applications), you have to follow a few simple rules:
1) Early bind all objects, never use 'As Object'; allowing the VB/C compiler to hard link entry points.
2) Use static memory throughout the application (if possible), VB's memory manager still runs garbage collection, the less garbage, the
faster your program.
3) Avoid using collections, and other inefficient storage mediums. Use arrays or API memory copy routines if possible.
4) - ... {your input here!}
I've used these practices in detailed real-world examples, with the greatest of success.
If you'd like to read a little more about the VB+C compiler, I had an old link saved to the VB5 announcement of the compiler:
http://www.zdnet.com/pcweek/archive/1406/pcwk0069.htmlOne of the most visible changes to the product is the option to create native-code executable files for distribution. To create these executables, the main Visual Basic application translates the source code to an intermediate format and then hands this parsed code to a back-end C compiler. This C compiler is the same compiler used in Visual C++ 5.0, although Visual Basic users do not have to install VB 5.0.
Previous versions of Visual Basic created only P-code, which was interpreted with the help of a run-time dynamic link library that resided on each desktop.
VB 5.0 still allows developers to compile in P-code, however, and P-code might sometimes be preferable, Flores said. Not only can debugging be easier with P-code, but the files are somewhat smaller than native-code executables, making them easier to send over the Internet.
>Yeah, and MS is being just sticking to their words. VB still can't compile to native code...
