Compiled Code—Not a Panacea

P-code is good. Native code is good. Visual Basic has them both. That doesn’t mean you can mix and match at will (although Chapter 5 will suggest a strategy for doing just that). Sometimes you have to make trade-offs. So let’s take a closer look at some of the basic facts of life for program size and speed.

First, program speed is important—it’s just not equally important everywhere. To listen to certain marketing material for previous versions of Visual Basic, you might think speed didn’t really matter. In fact, I could paraphrase what has been said by certain people at Microsoft (who will remain nameless) who thought of a compiler as more of a marketing bullet than a real feature: “Visual Basic programmers (in their ignorance) think they want a compiler, so we’ll give it to them. But they’re going to be disappointed when their forms don’t load any faster with native code than with p-code.”

Well, that’s true. If forms load faster in version 5 (and I’m told that they do), it’s not because of the compiler. The Form Show method isn’t now, and never was, written in p-code. Neither are the Data Access Objects (DAOs) or the Remote Data Objects (RDOs). What’s different about the speed of native code is not that it makes what you used to do faster. The difference is that it makes new things possible. For example, nobody in their right mind tried to write action video games with Visual Basic version 4. I’m not saying it would be easy now, but you could at least consider it.

Between writing the first and second editions of this book, I planned to write a book on C++ for Visual Basic. I ran out of time before I could finish it, but part of that book is available as a series of articles on Microsoft Developer Network (MSDN) and on the companion CD for this book. When I told readers of the first edition of Hardcore Visual Basic that I was working on a C++ book, a frequent reaction was surprise and even anger—as if I were betraying Visual Basic by writing about C++. A typical comment: “The next version of Visual Basic is going to have a compiler, so why would you ever want to use C++ for anything?” Good question. This book will attempt to answer it, but I’m sorry to say that there are still some important and useful tasks that require C++ or some other low-level language.

Some of them include:

• You can’t write Declare statements for some API functions, and you don’t want to write them for others. For example, Visual Basic doesn’t do Unicode Declare statements. If you really want to prove a point, there’s not much you can’t do one way or another with a Declare state­ment, but it’s easier and more efficient to use a type library writ­-ten in Interface Description Language (IDL). This book won’t tell you how to write type libraries, but you will get the Windows API type library for free (described in Chapter 2). Furthermore, the companion CD contains the source code and an article describing how I wrote it.
  
  
• Visual Basic can’t use most standard COM interfaces that are implemented by Windows. Just try using IShellLink to create shortcuts. Or beat your head against a wall trying to use IStorage. There is a way to get past the limitations, but it requires mucking around with type libraries. We’ll do it in Chapter 10.
  
  
• Visual Basic can’t implement standard COM interfaces. The one you probably need the most is IEnumVARIANT. You can fake it in some cases by delegating from the Collection class, but in other cases your best option is C++. This book will provide a death-defying hack to enumerate variants, but it’s not something you’ll want to show your mother.
  
  
• Visual Basic can’t create a self-contained executable file. If you really can’t fit a setup program on a floppy disk or if you aren’t willing to require your web customers to download the Visual Basic run-time DLL over the Internet, you’ll need to develop programs and components in another language.
  
  
• Some things are easier to do in other languages. For the most part, Visual Basic’s lack of pointers is an advantage, but sometimes you really need them. Visual Basic also lacks some fundamental language features that are common in other languages, such as compile-time initialization of variables, procedures parameters, and easy bit manipulation. You can hack around these limitations in Visual Basic, or you can just write the code without hacks in another language. We’ll be hitting some of these walls in the rest of the book. Sometimes we’ll go over them. Sometimes we’ll go around.

I have been a tireless proponent (some Visual Basic developers and designers will say an obnoxious pest) of fixing these limitations so that Visual Basic really could do anything any other language could do (and I think it could be done without pointers). But alas, not this time. The compiler opens a lot of new doors, but I’m afraid that when Visual Basic programmers pass through those doors, they’ll find some language limits that never bothered them before.

According to my friend Joe Hacker, it takes at least one version after a major new feature is added before anybody (language user or language designer) fully understands the implications. So that means the next version of Visual Basic had better be a full-featured compiled language with no compromises (or at least not major ones). Unfortunately, that’s what I said last time.