On Mon, 9 May 2016 at 17:59 Andrew Robinson <[email protected]> wrote:
> On 5/9/2016 at 5:19 AM, Peter Hull <[email protected]> wrote: > > No, not a new link, but a different link: > https://sourceforge.net/projects/orwelldevcpp/files/Portable%20Releases/ > > Interesting, looks like 'orwelldevcpp' is a fork of the original Bloodshed one. I'd never heard of that, I thought development had ceased. > > Neither the ISO nor ANSI C standard specify a runtime. A runtime is only a > requirement if your application requires one. In Microsoft's case, you can > compile your C code to P-code, and since the P-code requires an > interpreter, that interpreter is the runtime engine. Otherwise, C > programs by definition have no runtime. > > 'Runtime' possibly is an overused term. I (and I think most people) would consider 'the C runtime' to be the implementation of the stuff in the standard headers (stdlib etc.) plus the initial startup code (crt0.o in unix-speak). That is mandated, see section 4 - Compliance in ISO/IEC 9899:201x. Unfortunately Microsoft also used Runtime as in Common Language Runtime which, I agree, is nothing to do with C. > I've seen both, although if the APIs are written in 32-bit, the OS will > have to switch processor states everything it switches from 64-bit to > 32-bit mode and vice versa. That would slow things down considerably so if > the APIs are written in 32-bit, it would be better for performance to > create the entire app as a 32-bit app. > > As I understand it, mixing 32 and 64 bit in one process is not possible; the only way is to use forwarding libraries and IPC which would be madness. But I also think the penalty for using a 32 bit process on win64 is not too bad. I'm not an expert on that so am prepared to be wrong. Cheers, Pete
_______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers
