The "main" is simply the entry point if the .APP gets called directly. In addition to this, functions and procedures in the "main" program file are visible through the DO ... IN .... For example, if we had MYLIB1.APP has MYLIB1.PRG as the "main", and you have the following:

* Contents of MYLIB1.PRG
RETURN "MYLIB1 - rev 2003.02.21" && Provide means to identify revision

PROCEDURE MyProc1
WAIT WINDOW "MyProc1"
ENDPROC

PROCEDURE MyProc2
WAIT WINDOW "MyProc2"
ENDPROC

FUNCTION MyFunc1
RETURN "This string returned MyFunc1"
ENDFUNC

Then you could do the following in an external program:

DO MyProc1 IN MYLIB1.APP

Or another thing you could do:

SET PROCEDURE TO MyLib.APP ADDITIVE
? MyFunc1()

What's more, if you define classes programmatically within the main .PRG and you SET PROCEDURE to the .APP, that class definition becomes available for use. This means you'll be able to use CREATEOBJECT() to create an instance. This feature is one way you can get around the problem about distributing programs using VCX files, as you'll either have to build them into each .APP that uses them (resulting in undesirable bloating), or distrubite the .VCX separately (no need to decompile -- it's directly readable if someone has VFP).