On 17 Sep 96, Rowan Crowe wrote to Lawrence Gordon:
 RC> I still think size is important. For example, I've been playing with
 RC> installing FreeBSD (a unix variant for PCs) recently. To do this I
 RC> used KA9Q, which among other things, provides FTP (File Transfer
 RC> Protocol) services. This way I could have KA9Q on a floppy, format the
 RC> hard drive, and then copy everything back over from my other computer.
 RC> NET.EXE is approximately 190k in size; it offers telnet, finger, FTP,
 RC> etc. Compare it to a monster like Netscape, which is *megs* in size.
 RC> Sometimes the smaller, simpler things are far more suited to the job.
True, but that also depends on how much time you want to spend coding.
I'm not interested in spending hours or days coding a simple utility
when I can fire up PB and write it in a couple of minutes.  The difference
in size between your assembler utility and my PB utility may be quite
large, but my time is worth more to me than saving a few K on the hard
drive.
 RC> I also think that the bloated size of QB's executables show laziness
 RC> on the part of MicroSoft's programmers. I'm not sure if you know *why*
 RC> they're so big. A LIB is a set of OBJs. Each OBJ holds one or more
 RC> functions or procedures. If a procedure is called, the contents of the
 RC> OBJ are pulled into the executable. Now, if an OBJ has 4 procedures in
 RC> it, yet we only call one of those, that's 3 parts of code that are
 RC> never used.
I know why they are big. I also know why PB's executables are large.
And to me it's less a question of laziness than of functionality, unless
you consider BASIC and other high level language programmers "lazy".
But, you're right about unneeded functions getting linked in with the
rest of the program.  I've always been intrigued by the idea of an
ANSI standard for BASIC, along the lines of C, where header files would
be used and whatever functions are needed are autolinked in at compile-time,
either automatically or through compiler directives. So, for example, a
PRINT statement, that you are using only to print a string to the screen,
wouldn't require the library for output to a file, printer, or another
device.
 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.
 RC> Comparing one version of a C compiler, and one version of a BASIC
 RC> compiler, and concluding that "C kicks butt over BASIC" is still
 RC> generalising. A more accurate statement would be "Turbo C v2.01 kicks
 RC> butt over PowerBASIC v2.1".
 RC> Times change, and those are very old versions. :-)
I'd be interested in running some tests again, using PB and some of
the newer C compilers.  Anyone else out there interested in taking this
on?
--- PPoint 2.01
---------------