Re: [AD] Don't use Devpaks

["Andrew Robinson" <arobinson18@xxxxxxxxxx>]

On 5/9/2016 at 5:19 AM, Peter Hull <peterhull90@xxxxxxxxxx> 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.