Yup, FBSL has many built-in "layers" that would normally correspond to separate add-on DLL's in other laguages such as, say, thinBasic. Each of them has its own set of functions and also their aliases. This means a great number of relatively large keyword hash tables are used that eat up lots of binary space. Luckily, my zlib-compatible (but not zlib-based!) intrinsic layer can be used very efficiently to have the tables and other data uber-zipped with compression level 10 prior to FBSL source compilation in order to reduce the overall binary size. The tables and data are unzipped directly in memory on the fly at app start, in fact adding very little overhead to FBSL's overall launch time. The layer
per se provides the user with controllable compression level Inflate()/Deflate() functionality and also allows for codec-independent PNG image handling.
I'm at a constant grueling war against my own ideas and source code efficiency for every kilobyte of final binary's size. From that standpoint, I'm really looking forward to FBSL v4 that's going to be multi-platform, which means using some multi-platform windowing framework for its graphics and UI. They are all really huge these days and my own code contribution is going to be insignificant against their background.
And yes, I'm also using console for debugging some parts of the language although my experience has shown that there are cases when simple printf() may meddle with the debuggee to the extent of crashing it while MessageBox() is more reliable in this respect. The nature of this behavior is unknown to me. Perhaps it may be some internal glitch of GCC v4.3.3 that we use exclusively to compile FBSL v3.