This is all very interesting. And it could illustrate why a Microsoft language is not a good place for a newbie to start out.
At first, the Microsoft Basic implementations were quite attractive. But then as the operating system changed, Microsoft decided to make even more changes to Visual Basic. More than perhaps needed to be a Basic language..
A student language has a strong structure and can do what it needs to do without the need to implement something different or deviant from the original design of that language.
Besides, there is usually some type of trapdoor available in most implementations to break out from the structure and do something in another language. In the older versions of BASIC you could peek and poke and then call machine code and outperform some oddball thing.
Thank you all for your input. 
you can still use ASM with VB6-
in fact I use it to subclass windows without crashing.
The trick is in the API call- you are "supposed" to pass in a pointer to a procedure that windows will call- but if you instead point it
to a string variable with assembled ASM then it will actually execute the machine code that is present in the string variable.
But why the slimy hack? VB has an "AddressOf" operator, after all. The idea is to make it possible for class instances to subclass window messages, rather then require a Module to contain the WindowProc() and route the message to the proper Class instance based on the hwnd or something. Additionally it prevents the VB6 IDE from crashing during testing, since the ASM code remains in memory and is thus a valid JMP location throughout; before this "hack" the addressOf method was unstable during debugging, since pushing the stop button would mean that the module containing the windowproc is unloaded- but windows still calls it for messages on the window, such as the WM_CLOSE message; it calls nonexistent code and crashes.
HARD...
As far as "outperforming" the standard routines- this is generally quite easy via API routines. For example, instead of using DIR$, one can use the FindFirstFile(),FindNextFile() and FindClose() functions. This has the benefit of allowing recursive calls which aren't directly possible with DIR$() without cacheing folder names and recursing on them at the end of the procedure.
After dabbling with ASM for the subclassing code... well I think any future ASM work will avoid the windows platform...
