On 5/9/2016 at 5:19 AM, Peter Hull <[email protected]> wrote: 
Hi Andrew,

A few points have been raised here. I've not used Dev-C++ since probably about
2002 so I can't answer everything, but I will jump in and hopefully someone
else can address the rest.

1. I looked on http://www.bloodshed.net/ and I can't see any versions newer
than 2005's 4.9.9.2. Is there a newer link?
No, not a new link, but a different link:
https://sourceforge.net/projects/orwelldevcpp/files/Portable%20Releases/
2. GCC's command line option -lXYZ means 'look for a file called libXYZ.ext in
the library directories' - so if you want  liballegro-4.2.2-monolith-mt then
-lallegro-4.2.2-monolith-mt is correct. The extension .a is a static library,
I think MinGW can also link direct to a .dll.
The problem here is with Dev-Cpp. Using an older version works with DevPaks
while the latest 5.x versions do not.
3. All C programs need to link to a runtime library, Microsoft's is called
msvcrt-something (or at least has been called that, they changed it recently
IIRC). The point of MinGW was that it could use Microsoft's runtime, compared
to something like Cygwin which has to implement its own runtime. So seeing
references to msvc are not unexpected.
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.
4. Not sure about the error with the code you posted, I'll have a think.
Don't worry about it. Like I said, it was a problem with the newest release of
the Dev-Cpp compiler not working.
5. Allegro 4 predates 64-bit anything so I'm not surprised there's only a
32-bit version. I don't see why it couldn't be compiled as 64-bit though.
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.
Overall it looks to me like the Allegro devpaks have gone a bit stale and,
indeed, that Dev C++ has gone a bit stale. I don't know who the package
maintainer is (mpxd  live  com ), does anyone else?
Well the DevPaks work just fine with the 4.x versions of Dev-Cpp, it's the
websites that aren't being maintained ... well that and there doesn't seem to
be much user participation anymore.
I would echo SL's comment and recommend using Visual Studio Community and the
Nuget packages; they are bang up to date and I'd say easier to work with than
anything we have for Mac or Linux.
I try to avoid anything by Microsoft. MSVC seems to be the developer's version
of dependancy hell. I don't know how many projects I've come across now that
can only use the 2010, 2012, or 2013 version of MSVC. I've even seen projects
that can only use MSVC 6! I don't want to use a compiler I can never update
unless I want to re-create my whole entire project so it can work with the
newest release of the compiler. I don't want a project that is dependent on
one and only one version of MSVC. And Microsoft uses MSVC to force you to add
things to your computer, things like the latest version of their browser.
_______________________________________________
Allegro-developers mailing list
[email protected]
https://mail.gna.org/listinfo/allegro-developers

Reply via email to