That's right: no beta, no Release Candidate. This is the real thing.

Grab it from the download page. Binary packages for Windows and MacOS X will be available in the course of the week.

Missing from the archive is the new demo game (the old 4.0 demo is in the archive). This will be available shortly as a seperate download and will replace the old one in 4.2.1.

Apart from the usual request that people start using it and report and help fixing problems (not too many, we hope), I think it would be nice if there was a short guide that goes over the differences (feature-wise) between 4.0 and 4.2. I can probably write one myself, but if someone wants to volunteer to do it that would be great.

Many thanks to all the people who have contributed to Allegro in one way or another. This would never have happened without any of you or the support from the a.cc community. Cheers people!

I got the Windows-friendly .zip archive. My develpoment environment is MinGW (GCC 3.4.2) + MSYS (1.0.10). Built with

./fix.sh --dtou
make
make chm-docs
make compress
make install

Built AllegroGL (0.2.4 CVS), played the Allegro demo game, recompiled one of my own Allegro projects. The result:
Everyhing works wonderfully!

I would like to thank everyone working on this great library for your hard work and time.

Now let's hope we'll see the new stable AllegroGL and OpenLayer 2.0 soon.

EDIT:

That is a good addition to the documentation, although its usefulness may be questionable since the most common beginner mistake seems to be the mistake #1: Ignoring this manual.

In section Creating bitmaps before loading. IMHO there should be a /* wrong */ comment on the second line of code to clarify that the code is wrong and to make the documentation more consistent.

SECOND EDIT:
Ohhhh! I think I found typos in the docs! In the section Community; should the last word be to instead of too? Also in the fifth paragraph: However, if it was nescessary that decisions were made...

Great news!

Well done everyone that's contributed to this. Thanks for all your efforts.

Neat! I knew there was a reason I did not go to work today... besides feeling like vomiting at anytime!

Now someone we all know will be forced to do some updates to the Files and Documentation sections ;-)

Congratulations everyone!

Seems to be working fine in FC4.

Congratz guys! Well done!

I'll download this immediately.

Finally a "stable" release and not something with a name which scares the newcomers...

Works perfectly for me! The downside is that now I need to get the precompiled versions of 4.2 for all platforms for OL 2.0...

Thank you all. Allegro rules.

Compiled and installed correctly under Ubuntu 5.10. Will check all the other builds later, installing a qemu with DSL to see if I can compile it there as well.

Compiled fine all the three versions on Windows XP SP2 with gcc 3.4.2
Thanks for the great work

Great! The strange thing is, that I found an info about 4.2 coming at some other site (warsztat.pac.pl to be specific) before allegro.cc. Isn't that strange?

EDIT: Too much "strange" here. Little advice: beer + posting = shame

Well, I uploaded the files two days ago and I think the release was unofficially announced on #allegro, so it's possible someone got the news before I posted it here.

Congratulations evert, elias, peter, peter, grzegorz, dennis, chris and all the others

Works fine for me in Gentoo.
Great work all!!

Compiled and "worked" under Qemu+DSL. Lack of X dev support forced it to work with VGA, but at least the demo worked "flawlessly".

Yay, I'm first one to report problems! Only with the make procedure so far... here's what I get, after building for MSVC6:

D:\allegro4_20>make install
misc\mdhelper.bat C:\PROGRA~1\MICROS~2\VC98\lib
process_begin: CreateProcess((null), miscmdhelper.bat C:PROGRA~1MICROS~2VC98lib,
...) failed.
make (e=2): The system cannot find the file specified.
make: *** [create-install-dirs] Error 2

D:\allegro4_20>make chm-docs
docs/makedoc.exe -chm docs/chm/allegro.html docs/src/allegro._tx
writing 'docs/chm/allegro.hhp'
writing 'docs/chm/allegro.hhc'
writing 'docs/chm/allegro.hhk'
hhc docs/chm/allegro.hhp
Microsoft HTML Help Compiler 4.74.8702

Compiling d:\allegro4_20\docs\chm\allegro.chm

make: [docs/chm/allegro.chm] Error -1073741819 (ignored)

...

For that last one, hhc.exe actually crashed. Didn't do this for the last 4.2 WIP. I was able to build the chm file via the Help Workshop GUY, however.

C:\Documents and Settings\student\Desktop\allegro>make install
make[3]: Entering directory `C:/Documents and Settings/student/Desktop/allegro'
misc/mdhelper.sh C:/dev-cpp/lib C:/dev-cpp/include C:/dev-cpp/include/allegro C
/dev-cpp/include/allegro/platform C:/dev-cpp/include/allegro/internal C:/dev-cp
/include/allegro/inline
sh: C:\Documents: No such file or directory
make[3]: *** [create-install-dirs] Error 127
make[3]: Leaving directory `C:/Documents and Settings/student/Desktop/allegro'

Maybe mdhelper.sh should get the files surrounded in quotes? Solution for now: move allegro to a directory that doesnt contain spaces.

Hmm... for Dustin problem, I guess Allegro should check if there are spaces in the current directory, and get the DOS directory name, or warn about spaces in the path and stop the build.

The problem for Paul is a bit more complex... note how all backslashes disappeared. That is, they weren't escaped? Can you run by hand misc\mdhelper.bat C:\PROGRA~1\MICROS~2\VC98\lib to see if that works?

Ahh, ReyBrujo... my brain slowly churned into action and recalled something about using "mingw32-make" to build instead of just "make". I'm doing this now, and have built the regular and debug libs... now working on the static-linked. Maybe this is documented somewhere, but I didn't see it during my casual perusal of the build docs anyway.

Hasn't that always been the case? That allegro can't be in a path with spaces?

These demos had a rather odd effect on this Win2k Pro Service pack 4 machine
Specs: Intel Pent 4 1.6 GHZ, 523,280KB RAM
The restrictions on this computer wont let me see what kind of GFX card it has... is there an allegro program that will tell you this? Its a LCD monitor.

excolmap
excustom
exfire
exdbuf
exflip
exfont
exhello
.. and maybe some more

ones that i tested and look ok:
exkeys (and all the ones that are earlier lexigraphicaly and aren't in the above list)

Problem description:
The screen is nudged up slightly with a small bar of black inbetween the bottom of allegro's 'screen' and the bottom edge of the screen. Below this bar there is what looks what should be at the top of the monitor. The screen also appears nudged to the left with a black bar appearing on the right and the left side of the screen getting cut off.

Hypothesis: Looks like something to that changes based on the resolution of the screen maybe? Maybe theres a flaw in win2k's direct x drivers?

Sounds like the video card's drivers are using improper hsync and vsync settings. Some monitors will let you adjust this on a per-resolution basis.

Edit:
It was my own fault it wasn't working, half my project was compiled with 4.0 and the other half 4.2

Well I thought that the "fix.bat msvc --msvcpaths" was supposed to take care of it...

Wouldn't that just take care of the paths to msvc?

That happens if there's a mis-match in DJGPP and MinGW programmes. You wouldn't be using DJGPP's make, or MinGW's make with a DJGPP-based bash, would you?

Hehehe.... crappy LFN support I guess... /me remembers the ugly workarounds djgpp uses...

Hi everybody,

Congratulations to all the people that made 4.2.0 a reality! Amazing job, guys!

Allegro builds fine on MingW32 for me, but unfortunately it doesn't on DJGPP (gcc.exe (GCC) 4.0.1), this is the message I get:

Compiling Allegro for djgpp, optimised. Please wait...
gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mtune=i586 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -
I./include -o obj/djgpp/alleg/graphics.o -c src/graphics.c
src/graphics.c: In function '_set_gfx_mode':
src/graphics.c:635: error: 'blit_end' undeclared (first use in this function)
src/graphics.c:635: error: (Each undeclared identifier is reported only once
src/graphics.c:635: error: for each function it appears in.)
make.exe: *** [obj/djgpp/alleg/graphics.o] Error 1

Am I doing something wrong ('fix djgpp', 'make')? Are the devs aware of this issue?

Kindest regards,

Ronald

Oops. Please add this line somewhere near the top of src/graphics.c. Thanks for pointing it out.

extern void blit_end(void);

Nice! Now we just need a new version of AllegroGL.

A small request, people: I only have Windows and GCC, so could you OS X, Linux and MSVC users attach your compiled library files?

Thanks for the help Peter,

Allegro compiles ok now, and the examples seem to work just fine.
Some final notes though.. I got a couple of warnings during the compilation:

src/dos/vesa.c: In function 'get_vesa_info':
src/dos/vesa.c:328: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness
src/dos/vesa.c: In function 'setup_vesa_desc':
src/dos/vesa.c:579: warning: pointer targets in passing argument 1 of 'uconvert' differ in signedness
tests/vesainfo.c: In function 'get_vesa_info':
tests/vesainfo.c:176: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness

and this is the output of 'make install':

C:\DJGPP\allegro>make install
misc\mdhelper.bat c:\djgpp\lib

C:\DJGPP\ALLEGRO>
Extended Error 183

misc\mdhelper.bat c:\djgpp\include

C:\DJGPP\ALLEGRO>
Extended Error 183

misc\mdhelper.bat c:\djgpp\include\allegro

C:\DJGPP\ALLEGRO>
Extended Error 183

misc\mdhelper.bat c:\djgpp\include\allegro\platform

C:\DJGPP\ALLEGRO>
Extended Error 183

misc\mdhelper.bat c:\djgpp\include\allegro\internal

C:\DJGPP\ALLEGRO>
Extended Error 183

misc\mdhelper.bat c:\djgpp\include\allegro\inline

C:\DJGPP\ALLEGRO>
Extended Error 183

copy lib\djgpp\liballeg.a c:\djgpp\lib
1 file(s) copied
copy docs\info\allegro.info c:\djgpp\info
File not found - DOCS\INFO\ALLEGRO.INFO
0 file(s) copied
install-info c:/djgpp/info/allegro.info c:/djgpp/info/dir
install-info: No such file or directory (ENOENT) for c:/djgpp/info/allegro.info
make.exe: [c:/djgpp/info/allegro.info] Error 1 (ignored)
copy include\allegro\platform\alplatf.h c:\djgpp\include\allegro\platform\alplat
f.h
1 file(s) copied
The optimised djgpp library has been installed.

I don't think that went entirely correct.. any idea what's wrong?

Regards,

Ronald

Compiled Allegro4.20 with MinGW3.1.0 and MSVC6.
Worked all flawlessly, no errors, no warnings with all of these possibilities: {STATICLINK=1,{}} x {PROFILEMODE=1,DEBUGMODE=1,{}}.

For my project, i only use MSVC6 to compile.

Problem:
I get two 'unresolved symbol' linker errors, when i try to compile my project with the 'alld.lib'.
One is referring to '__imp__hline' and the other to '__imp__vline'.
(I do not use the 'curses' library, so conflicting hline,vline is not an issue.)

Oddity:
With the standard MSVC6 'Release' configuration and 'alleg.lib', i do not get these errors and everything works fine.
The only way i managed to jump around this, was to replace all 'hline','vline' calls with equivalent 'line' calls.
I searched for '__imp__hline' in all files of the whole allegro directory, but indeed could not find it(not even in the .map files), so i guess something went wrong with building 'alld.lib', but what could be causing this?
((probably br0ken?)msvc6 alld.lib and alld42.dll is attached)

I have to admit to not really understanding the way libraries work on OS X yet. I have attached a bundle of everything from lib/macosx, but whether that is enough to install the framework and template that most OS X users will consider essential rather than just the BSD subsystem style libs I have no idea.

I used GCC 4.0 and all the latest libraries, so these are probably for OS X v10.4 Tiger only.

Ronald: did the header files get installed properly? Otherwise install-info failing is ignorable (though allegro.info should have been generated).

EDIT: attached a patch which should fix the warnings with src/dos/vesa.c

Dennis: the problem is that hline and vline are now inline functions which actually call _allegro_hline and _allegro_vline. The implementations are in include/allegro/inline/draw.inl. What happens if you use one of the older fixed-point functions in debug mode, say, fcos instead of fixcos? I'm not familiar with MSVC so I'm just hoping that the problem does not show up with fcos.

Evert, I have recently updated my mingw32 installation, and I don't have DJGPP set up on my machine currently. The "make.exe" in my mingw32/bin directory looks a little suspect though:

root 122880 Nov 7 1999 make.exe*
None 90624 Sep 21 2004 mingw32-c++.exe*
None 90624 Sep 21 2004 mingw32-g++.exe*
None 88064 Sep 21 2004 mingw32-gcc-3.4.2*
None 88064 Sep 21 2004 mingw32-gcc.exe*
None 1069568 Aug 11 18:52 mingw32-make.exe*

Shouldn't it be newer? Maybe I just didn't install mingw properly. Honestly, I don't remember, I did it one bored evening this past summer.

Anyway, everything is built, including the CHM docs, and running smoothly. Thanks to the Allegro team, the Earth is safe once again!

For all our sakes, please delete that thing or move it out of the way! Or just run "make -v" and see what it is.

Peter,

Both liballeg.a and the header files got installed successfully. I guess that's fine then, thanks again for the patch and your help.

Regards,

Ronald

Ronald, were you compiling and installing under a pure DOS environment? Or using Windows XP? Check if you got an allegro.inf file created, maybe it did not support the four letter extension and created a three letter one instead.

Hello again,

I'm compiling on a dos command prompt inside WinXP. Inside C:\DJGPP\allegro\docs\info, the file allegro.info gets created, but during make install, the copy command fails:

copy docs\info\allegro.info c:\djgpp\info
File not found - DOCS\INFO\ALLEGRO.INFO

Maybe the path in which the copy command is executed is not C:\DJGPP\allegro, because a manual copy inside that directory DOES work?! Or there might be a problem with the uppercasing of the file?

Ronald

Is it possible that you already had the directory created, which generated this error?

It was in the allegro directory, as it could copy the library but not the info. I am a bit lightheaded right now, so I cannot guess what happened.

Peter,

Huh, strange! Anyway yea, I'll get rid of it.

I've quickly tried to make an ebuild for the new Allegro version, there I found something: In the Allegro 4.1.18 ebuild (the most recent official one) there is a patch for Allegro, looking like this:

--- misc/allegro.m4
+++ misc/allegro.m4
@@ -11,7 +11,7 @@
 dnl AM_PATH_allegro([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]$
 dnl Test for allegro, and define allegro_CFLAGS and allegro_LIBS
 dnl
-AC_DEFUN(AM_PATH_ALLEGRO,[
+AC_DEFUN([AM_PATH_ALLEGRO],[
 AC_ARG_WITH(allegro-prefix,
             [  --with-allegro-prefix=PFX   Prefix where liballegro is installe$
             ALLEGRO_CONFIG_prefix="$withval", ALLEGRO_CONFIG_prefix="")

I plan to submit a new ebuild to Gentoo Portage, but before I do this I want to know if this patch is still necessary?

Oh, and btw, Allegro compiled fine (also without the patch).

EDIT: I just noticed that the new demo game wasn't included and the old demo game still showed the Allegro 4.0 movie ...

No, that fix was made a while back.

It would - the patch doesn't affect the build process of Allegro, it affects the allegro.m4 file that other people can use to test if Allegro is installed.

By the way, if you're also in charge of specifying on what hardware Allegro has been tested and is known to work, Allegro is 64 bit safe.

Thanks for your answer! I've already written a bug report on Bugzilla so that the new Ebuild will be included in Portage!

recognition:
Aaaah, i see, so the problem is that inline functions are disabled per default in MSVC6's 'Debug' configuration.

solution:
So i enabled them for 'Debug'(preprocessor symbol used by MSVC6 is actually _DEBUG), which then showed the error that 'inline' functions are incompatible with the debug-info-creation of the type 'programme-database for edit and continue'.
So i disabled debug-info-creation for 'edit and continue' and now it compiles fine in debug mode with 'alld.lib'.

conclusion:
So 'alld.lib' was not br0ken, it was just a matter of wrong MSVC6 settings, completely disallowing inline functions.
The drawback is that of losing the 'edit and continue' debug feature.
Is there a possibility to make Allegro fall back to non-inline alternatives, if generation of inline functions is prohibited by the compiler settings?

(recognition,solution,conclusion...the AK-47 robot from KnightsOfTheOldRepublic reprogrammed me to this funny type of answer-structuring:))

'fcos' works without any warnings or errors.

Hi everybody,

I decided to remove my djgpp directory entirely and rebuild from scratch.
Used bnu2161b.zip, djdev203.zip, fil41b.zip, gcc401b.zip, gpp401b.zip, mak3791b.zip, pat253b.zip, txi48b.zip and Peter Wang's fix for graphics.c and his vesa_sign patch.

Still, a minor, related, warning pops up during compilation:

tests/vesainfo.c: In function 'get_vesa_info':
tests/vesainfo.c:176: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness

Everything else is smooth. Then, 'make install' does its magic, until

Extended Error 183
copy docs\info\allegro.info c:\djgpp\info
0 file(s) copied
File not found - DOCS\INFO\ALLEGRO.INFO

install-info c:/djgpp/info/allegro.info c:/djgpp/info/dir
install-info: No such file or directory (ENOENT) for c:/djgpp/info/allegro.info
make.exe: [c:/djgpp/info/allegro.info] Error 1 (ignored)

After make finishes, I can do the copy and install-info commands manually myself without problems. All the other files are installed as far as I can tell, and the examples work fine. I've no idea what's the problem here, can you guys tell me where to look further?

Regards,

Ronald

I would ask you to do a small test: search in makefile.dj and makefile.all for the allegro.info rule, and rename allegro.info to allegro.inf, and try again. My bet is that, for who knows why, the four letter extension is breaking this build (similar to an old Watcom problem where compilation failed because a file had nine characters as name: datafiles.c).

I am at work right now, but may be able to check and modify the makefiles if you cannot.

Thank you ReyBrujo, that was it! I changed makefile.dj, line 42 from

INFO = info
to
INFO = inf

and that did the trick, make install works fine now. Thanks again, fellows!

Regards,

Ronald

Dennis: It's strange, because hline/vline are supposed to be using the same technique as fcos and friends. I can't see any difference between them. Please try to figure it out and let me know if you need some guidance around the Allegro source code.

Ronald, if you are still there, can you try make INFO=inf to see if it compiles without errors (except that warning, it is just a cast, a simple patch)? Do a make clean first. Also, can you check in the info directory of your djgpp to see if the files there have the .inf or .info extension? That would be a second patch if they only have the .inf extension.

I don't understand. If you're using a system of release candidates, shouldn't the last one actually be equal to the main release (modulo version values)?

You'd like to think so, but it doens't really work that well for allegro. Usually when a RC goes well, it is made into the next release, but I think thats happend, like once. Otherwise it gets into a perpetual RC release, it'll never end

Well, there was an RC3 that was only announced on [AD]. But actually, we're just not formal about the release process. "Beta" and "RC" are just WIPs in disguise to encourage more testing

I guess I must be doing something really silly, but... I've downloaded and installed mingw 4.1 package , opened up a vs2005 command window (that sets up the path, include/lib directories, etc), ran 'fix msvc8', and on typing 'mingw32-make' I get the following:

D:\DATA\allegro42>mingw32-make
Compiling Allegro for MSVC, optimised. Please wait...
gcc -O -Wall -Werror -o obj/msvc/runner.exe src/misc/runner.c
f:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -luser32
collect2: ld returned 1 exit status
mingw32-make: *** [obj/msvc/runner.exe] Error 1

D:\DATA\allegro42>

Neil.

I'm very sorry, it was all my own fault... some outdated header files from 4.20beta4 were somehow sitting in the 'include' directory of my MSVC installation and thus got used, instead of the true 4.20 headers to which i pointed with the additional include directory settings.
(I wonder how they got there, because normally i do NOT do 'make install' and prefer to set the needed 'include' and 'lib' directories manually in the MSVC configuration.)

It's working now, with full debug-info-creation('edit and continue' enabled) and 'inline' disabled.

I hope i did not waste too much of your time.:)
(I wasted two hours, combing through alconfig.h, almsvc.h, draw.inl, debug.h, base.h only to find nothing wrong with them. Then i clicked one of the allegro files in the MSVC 'external dependencies' tree of my project(because i was tired of reading them in 'notepad') and noticed that it showed a wrong drive letter. Then i immediately knew what was wrong.)

Hello,
Is this a mistake in the documentation:

If you don't have w32api you don't get user32 (amongst others) so you can't compile allegro. So it's not optional, it's mandatory

After installing w32api allegro 4.2 makes the libs and dlls like a dream. Took about 1 minute. Well done everyone involved!

My only problem now is I have a similar problem to paul pridham except my directories are 8.3. This is what I get. Anyone any ideas?

Neil.

Can you execute hhc docs/chm/allegro.hhp by hand?

Dennis: no problem.

Neil: for your own projects, you can embed the manifest via the properties at Configuration/Manifest Tool/Input and Output/Embed Manifest => yes. Whatever that does should be added to the Allegro makefile.

Has anyone else got the same problem as I have with MSVC 7.1 using pre-built binary?

What binary did you install?
There is no binary release (for MSVC) of 4.2 yet.

Ops! I am mixing things up I guess. I installed the binary release from here of Allegro 4.2.0 RC2.

Of course RC2 != final release, which this thread is about. Sorry for derailing the thread, I will come back and report when a binary release is available if the problem persists. Please ignore this and my previous post if this isn't contributing with anything on the topic.

Ok. Not embedding the manifest produces this:
/out:..\debug\test.exe.manifest

And producing it does this:
/out:.\debug\test.exe.embed.manifest /notify_update

But checking the manual I think you need the /ALLOWISOLATION:NO linker flag. The documentation states:

/ALLOWISOLATION:NO indicates DLLs are loaded as if there was no manifest and causes the linker to set the IMAGE_DLLCHARACTERISTICS_NO_ISOLATION bit in the optional header's DllCharacteristics field.

/ALLOWISOLATION causes the operating system to do manifest lookups and loads.

/ALLOWISOLATION is the default.

Which bit of the make file do I update to add this flag? I guess the problem is then I need to distribute msvcr80.dll with every build as most people won't have it. Maybe making allegro on vc6 or vc7 is the better option?
Neil.

Can you provide an English translation?

Line 207-ish of makefile.vc

The .manifest problem actually came up shortly before the release and there is a patch in to keep generated .manifest and .exe files together. But obviously, if we can get rid of the .manifest files that would be preferable.

[edit]I've tried loads of things and can't get them to work so I've build it using VC6 and all is well. It probably needs someone who knows more than me to fix this problem.

I did notice one bug that happened with both MSVC and MINGW32, when you try and build using PROFILEMODE=1 DEBUGMODE=1 it tells you there is nothing to build and it doesn't do anything. All other modes work fine.

Another bug (or is it a feature) I've noticed is when you compile using mingw32 it regenerates all the files even if they've been built, e.g. I made the system then did a STATICLINK=1 and it make static versions of all the examples, etc. MSVC build only redoes the lib files. You have to prefix mingw-make with lib (e.g. mingw32-make lib STATICLINK=1)

Neil.

With .NET MS tried to fix DLL hell by creating manifests and assemblies (i.e. embedding all detailing relating to what libraries, versions, etc) to allow simple XCOPY deployment.

Looks like they've done kind of a similar thing with VC8 (in this version they've included .NET support into the C++ language).

We need a way of getting rid of all this crap and I think the above flag(s) are the ones required as it says I don't need a manifest. I've posted a message to a MS forum to see exactly what is required.

My only worry is the VS2005 settings need tuning a lot as I've been reading about loads of performance issues as various security settings, etc. are turned on by default.

Neil.

Just had to ask about this, is there any binary release planned for this version?

Why don't you read the announcement and find out?

If it helps I now have two complete binary releases for both MSVC and MinGW for all modes (except static profile - see my message above about why not).

I'll stick these up on my website tonight if anyone wants them.

Neil.

Double doh!

I greatly appreciate it. But the static profile would be nice to have as well, so I think that I'll wait personally and see if that file will be included as well.

Your problem is you need to change to a Win32 Application (not console).

Binaries are up:

http://www.allegro.cc/files/4.2.0/allegro-msvc71-4.2.0.zip (or .7z/.exe)

The others are available @ http://www.allegro.cc/files/.

Got it through dev-c++ package manager. o_O
Haven't tested it though.

Thanks Matthew for the binary, and to everyone who contributed to this release. I got the mini example to compile now.

It still gets 10 warnings, should I ignore them?
The warnings

c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\internal\alconfig.h(378) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned char *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\internal\alconfig.h(385) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned char *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(421) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned char *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(435) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned char *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(446) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned short *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(460) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned short *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(471) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned short *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(485) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned short *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(521) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned int *' of greater size
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\allegro\inline\draw.inl(535) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned int *' of greater size
Linking...

If anyone wants another source of the msvc and mingw binaries I've got my own at:
http://retrospec.sgn.net/users/nwalker/allegro42_msvc_bin.rar
http://retrospec.sgn.net/users/nwalker/allegro42_mingw32.rar

In these is the full allegro release, minus the source code, so the setup, examples, demo, include/lib, tools, docs, etc. are there.

Matthew, how come your static release lib is bigger than your static debug lib?

it's there in mine and the offical allegro.cc one.

Neil.

Look for the project option to disable 64-bit compatibility warnings.

I'm doing nothing but standard builds. In MSVC >= 7, they are all bigger than debug versions for me.

How so? I built static profiles for MSVC 6/7.0/7.1/8.0.

I meant debugged profile.

but thinking about it, I guess that doesn't make sense

Neil.

Does this mean that Allegro has compatibility issues with 64-bit CPU's? Could something bad happen to 64-bit users, or is it just if you specifically compile for the 64-bit platform?

Not precisely. Allegro works fine in 64 bit mode in Linux, but the Windows port is 32 bit only for now. Part of the reason is lack of a 64 bit version of MinGW and disagreement between MSVC and GCC when it comes to the size of long integers. Lack of dedicated Windows developers also doesn't help, I'm sure.

Chances are some things do not work correctly if Allegro were compiled as a 64 bit library in Windows. Using the 32 bit library is fine.

That's bad, I would help out if I had the relevant knowledge, and some more time on my hands. I guess knowing Win32 API pretty well and especially DirectX is necessary though?

Not a good thing at all. Well Microsoft has never been about portable standards, I guess it's in their intrest to tie people with their OS as much as possible.

Fine with me!

Well, someone who is a regular Windows user would be the most important, I think. There are a few on the mailinglist, but it seems that we still don't have a `full-time' Windows maintainer.
As for W32 API and DirectX... well, I know nothing about either but managed to do some work on it anyway with the help of on-line references and a lot of trial and error so I wouldn't say it's really a requirement.

It isn't really Microsft's fault though. The C standard says almost nothing about the size of integer datatypes and it certainly doesn't say all compilers should have the same size for them.
Historically, an int in the Microsoft world was a 16 bit entity and longs were 32 bit. Since moving to 32 bit Windows, ints are 32 bit (which I think has always been common in the UNIX world) but they are still using long in many places where they probably should have used int. They can't easily switch to 64 bit longs without breaking their own API in some places and existing code.
The proper solution would be C99 integer types that do have a well-defined size. Guess who doesn't support them?

Anyway, we'll have to find a way to handle the problem eventually.

Lets hope that someone steps up and helps you out. I won't though as I would make a false promise almost certainly (to much going on right now).

The function reakey() is returning 0, when press alt-xxx (numeric pad), this was perfect in version 4.0.3

Platform: Windows
Compiler: gcc (2.95.3-6(mingw special))

This compiler I used to compiler Allegro 4.2.0 and the program with readkey() function.

Thanks.

Yes, seems this was an undocumented feature of 4.0.x. You might be able to simulate it with keyboard_callback.

Undocumented or not, we should probably document this change in the API differences section.

Will the deprecated functions be removed from the next release? If not, would you accept a patch, as yet unwritten, that replaced the current generic compiler warnings with something more useful (e.g. function A is deprecated in favour of function B)?

Absolutely.

Okay, but just one quick question - while the GCC builds generate their warnings in response to the _attribute_ ((deprecated)) stuff around line 130 in alconfig.h, where are MSVC, etc, getting their definitions of AL_FUNC_DEPRECATED, AL_PRINTFUNC_DEPRECATED and AL_INLINE_DEPRECATED? I can't seem to find anything in include/platform/* or anywhere else.

Further down in alconfig.h (around line 218) there are fallbacks for non-gcc.