Yes clearly dated. For example, there is no 'screen buffer' in Windows. That would really violate the concept of Windows. And although I access the buffers in the video card, I do this via the Windows API. Anything else would violate Windows integrity. But, it is possible to develop extremely fast code without compromising the operating environment.

Speed should not be the top priority in development anyhow. With CVData, my top priority was 'debugability.' Second, flexibility and ability to add new features extremely quickly. To that end I use a modern architecture that definitely impacts speed. The main program and the simulation engines (there are currently three with two more planned) are separately compiled objects. Communication is by object methods and properties. Up to 120,000 values must be passed, one at a time, via an object interface every sim cycle. Obviously this adds overhead. But, it truly does enormously improve the development process. The user interface obviously also adds significant overhead. Clearly it is much faster to present a DOS box with 80 columns and 25 rows of unformatted characters. Adding a GUI, internationalized, proportional number formatting, scrollable grids, Windows tool bars, balloon help, etc. all operating during the sim uses CPU cycles. But guess what. It can still be done while simming 2,000,000 hands each second.

Pardon my ramble, this doesn't answer the question. I am not familiar with RealBASIC and TrueBASIC. If they are normal BASIC languages, they are probably much easier for someone not used to VB. To start with, VB is an event-oriented language and this takes people used to normal procedural languages a bit of time to get accustomed to. You also need to get used to the VB development environment. It is quite good; but takes some study. The Help is voluminous and poorly organized. It's hard to figure out where to start. So, if you're throwing something together for your own use and don't already know VB, it'll take a fair time investment to get started. If you are creating something commercial and general purpose, there is no better language in existence for most tasks. Exceptions that would require a language like C++ would be word processors or compilers. I wouldn't want to have to write VB in VB. (Could be worse. The IBM Fortran H compiler was written in Fortran.)

regards,
norm