🚀 go-pugleaf

DB>I'm still not sure it's a feasible step.  There is normally a lot of
DB>extra stuff in any particular "C library" that may or may not
DB>translate among compilers.  You aren't always aware of it when writing
DB>programs, but it's one of the reasons you can't just link an Microsoft
DB>C object file with a Borland C library, for example.  And if we can't
DB>get normal library files that are interchangeable, what are the odds
DB>of doing it as a DLL?
DB>
DB>Then there's the calling convention issue - some of the newer
DB>compilers (or even older ones such as Watcom) do a lot of optimization
DB>of the calling convention of functions unless you explicitly ask for a
DB>standard C calling convention.  Since this can significantly improve
DB>performance, would you be willing to give that up to have a common C
DB>library DLL?  (I'm presuming that different vendors will want to, or
DB>already do, optimize calls differently)
DB>

Actually, I have to say that I think it is a great idea.  Of course you
would need a different DLL for each compiler, but that is better than
having a complete linked in library for each program!  Furthermore, if IBM
were to supply a C library DLL for their C/2 and include it with every
copy of OS/2, then they would have a leg up on their compiler competition.
That way, I would write my programs in C/2 instead of Watcom or whatever,
because I know my clients would have the C/2 DLL on their machine.  Great
Idea whoever though of it!

Peter


---
 þ WinQwk 2.0 #0 þ Unregistered Evaluation Copy


--- WM v1.01c [Unregistered]
 * Origin: Gateway/2 OS/2 * StL,MO * (86:8012/17)
--  
Peter Garner - via Toadnet/UUCP Gateway 86:86/200
UUCP: ....!wupost!8012!17!Peter.Garner
INTERNET: Peter.Garner@f17.n8012.z86.toadnet.org