* Lawrence Gordon writes to Rowan Crowe, on Sunday September 15 1996
   at 08:05:
 RC>> For me, seeing a massive executable is somewhat of a turnoff...
 RC>> being an ASM  programmer myself I am used to being able to
 RC>> squeeze a lot of equivalent  functionality into a much smaller
 RC>> executable.
 LG> When 64k code and data was all anyone had to work with, size was
 LG> critical. These days, size just isn't as important.  If you can write
 LG> "hello world" to a exe file in 255 bytes in ASM and it takes 10k in
More like 25 bytes..
 LG> PB, that doesn't mean that ASM is better or there is anything wrong
 LG> with PB; it may only mean that PB might be better suited for other
 LG> types of applications.
I still think size is important. For example, I've been playing with 
installing FreeBSD (a unix variant for PCs) recently. To do this I used KA9Q, 
which among other things, provides FTP (File Transfer Protocol) services. 
This way I could have KA9Q on a floppy, format the hard drive, and then copy 
everything back over from my other computer.
NET.EXE is approximately 190k in size; it offers telnet, finger, FTP, etc. 
Compare it to a monster like Netscape, which is *megs* in size.
Sometimes the smaller, simpler things are far more suited to the job.
I also think that the bloated size of QB's executables show laziness on the 
part of MicroSoft's programmers. I'm not sure if you know *why* they're so 
big. A LIB is a set of OBJs. Each OBJ holds one or more functions or 
procedures. If a procedure is called, the contents of the OBJ are pulled into 
the executable. Now, if an OBJ has 4 procedures in it, yet we only call one 
of those, that's 3 parts of code that are never used.
Some functions are somewhat interdependent, so it helps to have them in the 
same OBJ, but others are totally separate, and only share common variable 
space (which can be shared across OBJs, if you pull in another OBJ).
If you look at the library for say Borland C, you'll see that almost every 
OBJ is dedicated to a single procedure only.
 LG>> real performance issue in the compiled BASICs is in file i/o,
 LG>> where, admittedly, C kicks butt.
 RC>> Says who? You're generalising here, file I/O in any given
 RC>> compiler (regardless  of language) depends on the runtime
 RC>> library. Have you actually done any tests on this?
 LG> Yes. About 5 years ago, I did several file i/o comparisons in native
 LG> Turbo C v2.01 and PB v2.1 using the runtime libraries of each
 LG> compiler. I posted the results in the Intellec PowerBASIC conference.
 LG> Unfortunately, I no longer have the original data, nor the compilers,
 LG> to run the tests again.
Comparing one version of a C compiler, and one version of a BASIC compiler, 
and concluding that "C kicks butt over BASIC" is still generalising. A more 
accurate statement would be "Turbo C v2.01 kicks butt over PowerBASIC v2.1".
Times change, and those are very old versions. :-)
Cheers.
---
---------------