I am trying to make my old and not so old Allegro 4 projects more compatible with
the newer operating systems (Vista/7) and newer hardware (Multi-Core).
Nothing special, but I just don't want it them to crash or malfunction like now.
Things already work better using acquire_screen().

One of the things I want to do is to compile them to Allegro version 4.4.2. I am now trying with Dev-C++ and allegro-4.4.2-1mpx.DevPak. But one of my projects needs to be portable and run without allegro-4.4.2-mt.dll.

Now I never managed to get Dev-C++ to compile something static ever before, and again I am failing. The devpack does not seem to contain a static version library. Please advise.

PS. Another option is to install MSVC 6.0 on my newer Windows XP PC, but that thing contains so much functionality and options which I never use anyway.

Use Code::Blocks as an IDE rather than Dev-C++ and save yourself a lot of hassle, imho.

Thanks for the tip on Code::Blocks, from their site it looks like an actively developed Dev-C++ Alternative. I will try it out soon.

It is just that wonsungi's post above mine is not very encouraging: "Allegro 4 + Codeblocks problem"

To be continued...

His problem has nothing to do with Code::Blocks. Code::Blocks is just an editor, and it's the compiler that builds the programs.

See which version of gcc you use.
Download the relevant binary archive here:
http://www.allegro.cc/files/?v=4.4
(One of the lines "MinGW x.y.z")
Look in the lib/ directory, and compare with what was installed by the devpak (a devpak is in ZIP format, if I remember correctly)
It is possible there was no static library, or that it didn't have the name you expected.

It's in .tar.gz format

Five things that can cause a problem then: The Programming Interface, The Compiler, Allegro, The Program, The end user System/OS. I would like the first three covered as conveniently as possible, so I can focus on the program and the System/OS issues.

For now MSVC for static linking is only setup on my old Pentium III, which I have just put by my desk just for this sole purpose. I fixed program crashes in windowed mode in a dual core environment by using acquire_screen(). I put in a crude CPU Idler system. Pending is a malfunctioning mouse in Windows 7 in Fullscreen mode. Also in need of fixing is the poor handling of task switching.

@Audric
Looking at allegro-4.4.2-mingw-3.4.5.zip, and I see the same thing as in the devpak:

And some OpenGL and file format specific libraries.
Nothing that looks like a general static lib like alleg_s in older releases and the static lib in the current MSVC builds.

I checked again the files provided by a.cc.
Up to mingw 4.4 (included) there are no static versions of the libraries, but the library for mingw 4.5.2 does have them:

• liballegro-4.4.2-monolith-static-md.a

• liballegro-4.4.2-monolith-static-md-debug.a

• liballegro-4.4.2-monolith-static-mt.a

• liballegro-4.4.2-monolith-static-mt-debug.a

If you're comfortable with dev-cpp, note that you can configure it to run a specific mingw-gcc compiler rather than the old one (from 2006?) that's included with it. It works well, I've always used dev-cpp with an installed version of MSYS + mingw.

If you continue developing, I would recommend upgrading to a recent version of mingw-gcc, however I have to warn that gcc 4 is slightly more strict than gcc 3, you may get quite a few errors/warnings to fix. Nothing critical, but still, it's a small time investment - and in any case, don't overwrite a mingw-gcc v3 compiler installation until you're sure you don't need it again.

Of course the laziest solution is open-source your works Your HeroQuest engine is popular enough that it's very likely to get volunteers to port it to more recent OSes / compilers.

I have Installed and configured Code::blocks 10.05. That went well.

Setting up the whole MinGW-4.5.2 compiler was less straightforward. But I found that it needs these packages to compile an allegro application:

I managed to statically link the allegro 4.4.2 libraries with the above. Static linking allegro adds 500kB to a tiny test program. The program is still Windows 98 compatible.

Next I setup the MSVC Express 2005/8.0 compiler too, with vcsetup.exe. Installing only the compiler itself. Next I Installed the libraries from the Windows SDK (Called Vista libraries, yuk), The DirectX70 lib package and allegro-4.4.2-msvc-8.0.
After adjusting some code it compiles my program, but sadly all MSVC allegro 4.4.2 packages have static libs that are broken, they refer to allegro.dll.

Currently the only binary allegro 4.4.2 package that can compile statically is allegro-4.4.2-mingw-4.5.2! All other packages, including the devpak, are either incomplete or broken in this regard. It would be nice if this situation is improved. Until then I suggest that a Warning is displayed in the allegro.cc files page.

My try with cmake did not go well...

If you want help with cmake, that is probably your easiest solution with MinGW and A4.4.2. What did you try and what didn't work?

Roughly, the commands to make Allegro 4 with cmake are something like :

cd allegro4/allegro (just to wherever your allegro stuff is)
mkdir build
cd build
cmake -G "MinGW Makefiles" -DWANT_ALLEGROGL=on -DWANT_LOADPNG=on -DWANT_LOGG=on -DWANT_JPGALLEG=on -DSHARED=on -DCMAKE_BUILD_TYPE=Release ..
mingw32-make
mingw32-make install

You can replace on with off for any of the options, and with SHARED off it builds the static version of allegro. CMAKE_BUILD_TYPE can be Debug Release or ReleaseWithDbg I think.

You have to have your compiler and cmake on the path and installed already.

I attached a log of a successful build - to get all the addons to build you have to have libpng and zlib installed for loadpng, along with libjpg for jpgalleg and libogg and libvorbis for logg. allegrogl doesn't have any dependencies except for allegro.

EDIT
Also, you can tell cmake to make solutions for MSVC to build allegro with. Call cmake --help for options for setting the -G <Generator Name> option.

Thank you. Using your log file I managed to build two libs for MinGW.
It is the base lib without addons requiring alleg44.dll, together with a static version, for MinGW-4.5.2. (attached)

Unfortunately, after changing -G <generator-name> to "Visual Studio 8 2005" or "NMake Makefiles" it keeps throwing errors at me:
CMAKE_MAKE_PROGRAM / CMAKE_C_COMPILER / CMAKE_CXX_COMPILER not set, even when I set them as environment variables. I don't know how to tell cmake what it needs to run. Is mingw32-make also replaced with nmake?

Are you using the latest version of cmake?

Actually, try running MSVC's batch file to set up a build environment, or it's command line shortcut, and then run cmake and such from there.

As far as I know, cmake will build solutions for MSVC, and then you go into MSVC and build the solution.

Don't know about nmake.

I used the latest version of cmake 2.8.10 -> "cl.exe -- broken ... could not compile test program"
Read about it being a bug with MSVC express, and about using an older version: 2.2.3 -> "cannot find modules path" (it ain't even trying)
Read about using an older version: 2.0.6 -> "could not create named generator" / "Unable to find 'Visual Studio 6'"

..This thing is just messing with me, I give up, and use MinGW until someone else manages to build allegro 4.4.2 statically with MSVC 8.0/2005.

Like with all compilers, it needs to be on your %PATH%. So try running cmake from the command line build environment that MSVC provides. It sets up the path to run the compiler, so cmake may work after you do that. IDK.

I just tried the exact same thing with an install of MSVC 2005 (not the free express edition) at a friends place: it works right away.

Edit1:
The resulting dll is not as reliable as the one I used earlier.
Also using the static lib I get errors like this "MSVCRT.lib(MSVCR80.dll)||error LNK2005: _atof already defined in LIBCMT.lib".
Using the /MD compiler directive it builds my program, but the program fails to read ini and text files!? The non-static executables does not have this problem. Both type of executable give an error when renamed and run.

Edit2:
I can now Build Allegro at home with the Express edition of MSVC 2005.
The problem was related to .\VC\BIN\ mspdb80.dll. I renamed it to mspdb80.dlx during the build, and that fixed it. The Issue in Edit1 is again present...

Edit3:
Build the allegro source again, but now with some differences:
-Applied "fix.bat MSVC8" to the source.
-Cmake generator "Visual Studio 8 2005" to create project files.
-Opened the project file with the MSVC 2005 interface, selecting /MT or /MD options, then "batch build".

The resulting linked and static /MT libs+dlls behave much better. (attached)