From: marcov@stack.nl   
      
   On 2005-02-10, RadSurfer  wrote:   
      
   > It seems silly that apparently ALL of a TPU/Unit is incorporated into   
   > a Pascal Application; unlike lets say how a 'C/C++' program does it:   
   >   
   > A 'C/C++' library links in only those object modules (ie.sub- units)   
   > that   
   > it requires, and IGNORES all others;   
      
   There is no 'C/C++' library. It is compiler dependant.   
      
   And most C/C++ compilers actually do it worse than TP, they do deadcode   
   elimination (aka smartlinking) on whole compilation units only, while TP   
   does it on per symbol basis.   
      
   gcc only improved on this in the last 2 (!) years.   
      
   > apparently with TP/BP one gets the ENTIRE TPU package...   
      
   Nope. Afaik TP does do dead code elminiation on symbol errors.   
      
   > remove   Crt   and  TP/BP  programs stop crashing because of apparent   
   > video card issues and the like, but then you LOSE out on other functions   
   > extremely useful to your TPascal project!  It's all really kinda nuts so   
   > far.   
      
   That's again because you are using 15 year products on an OS   
   that wasn't even on the design table when this product came out.   
      
   At least I don't assume you are using Windows 3.0 ?   
      
   > Even with all the "sophisticated" OOP going on for TP/BP its literally   
   > trapped inside a rather foolishly archaic implementation of the Pascal   
   > concept that most people like me are not very impressed.   
      
   Which concept are you talking about?   
      
   > Even with that said, for the time being, nothing gained by complaining.   
   > Best to keep studying this phenonema and try to make do.  I noticed some   
   > so-called Win 2.0/3.1 functions apparently unique to WinProc, etc, what   
   > good that would do the DOS user, but those functions appeared to have the   
   > more "modern" functionality and flexibility of 'C'   
      
   C is (c) 1973. In my definitions that is considered "old". The above paragraph   
   is totally gibberish. It seems you seem to say that some stuff in winprocs   
   would be usable from plain dos too? THat is quite possible, but that is the   
   main reason why winprocs has "win" in it.   
      
   > from day one -- even   
   > for DOS-only environments.  DOS is still very important in some areas.   
      
   Dos programs can't access Windows. C or not is irrelevant. Either it is   
   a dos program, or not. Even when they glued together in one binary, only one   
   will execute.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)