Now something is amiss with the two last betas. Since the beta1 I've seen a ~100 fps reduction in a program of mine (with beta3 it is ~5-10fps slower than with beta2). What's more, since beta2 both debug and release versions operate at the same speed (whereas with beta1 the release was about 80fps faster). Results show up with both msvc2003 and mingw3.4.2 on WinXP SP2. What

The scene I'm using consists of a clear bitmap, two 'textprintf_ex's, a rotated, masked blit and key input. Is there something that's changed that could account for this slowdown? I'll make a simple demo and try to trace the slowdown, but it would help if possible causes for this where given first.

Here are a few details about compiling Allegro with the latest djgpp (with GCC 4.0) under Windows 2000 (yes, I know, don't use Windows 2000 with djgpp, but I cannot test it under plain DOS right now):

1. When compiled with WARNMODE=1, I get this warning (does not stop the processing, though):

gcc -fno-exceptions -DALLEGRO_LIB_BUILD -Wall -W -Wstrict-prototypes -Wno-unused
 -Werror -mtune=i586 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I.
/include -o obj/djgpp/alleg/cpptest.o -c tests/cpptest.cpp
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid for Ada
/C/ObjC but not for C++

2. When the directory is already created, mdhelper.bat throws this error under Windows 2000 (does not stop the building): Extended Error 183

3. Under Windows 2000, at least, the info is not installed:

copy docs\info\allegro.info d:\compiler\djgpp\info
File not found - DOCS\INFO\ALLEGRO.INFO
        0 file(s) copied

4. Attached the five patchs I got to get djgpp working correctly (except the -Wstrict-prototypes warning). I am not happy with the vbeafex.c patch (it is already reported in a previous post, replacing static int int_ds with int int_ds. I tried to make it local variable, but there are not a single free register to store it with "r".

The patches should work correctly in previous DJGPP versions, since they are casts. My 2.95.3 copy is broken (asks for txi, I use make all and it compiles one file and stops again. I can continue using make all to compile the next file, but it is just too stupid to continue).

Couldn't yet test your patch, will do later when I arrive home. At work, as promised, worked on the MinGW patch. Attached it is. The most interesting patch is:

Index: src/win/wgdi.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/win/wgdi.c,v
retrieving revision 1.35
diff -u -r1.35 wgdi.c
--- src/win/wgdi.c	14 May 2005 15:54:52 -0000	1.35
+++ src/win/wgdi.c	16 May 2005 20:00:37 -0000
@@ -114,7 +114,6 @@
 /* hardware mouse cursor emulation */
 static int mouse_on = FALSE;
 static int mouse_was_on = FALSE;
-static BITMAP *mouse_sprite = NULL;
 static BITMAP *mouse_frontbuffer = NULL;
 static BITMAP *mouse_backbuffer = NULL;
 static int mouse_xfocus, mouse_yfocus;

I am not sure if this was made on purpose, but this local variable was shadowing the global one defined in mouse.c. I removed this copy, and it worked fine. Maybe someone should compile with -Wshadow and check everything again?

Also, I casted the parameters to DWORD or BYTE if they were used in Win32 API functions. If you want, you can change them to unsigned long and unsigned char.

Note that this is a unofficial version of GCC 4.0 for MinGW, but I am confident solving these warnings will prepare Allegro to work flawlessly with the official branch.

(Edited on 2005-05-17: I tested your patch. Moving the static variable inside the function doesn't work, the compiler cannot find it. By the way, I cannot setup sound with DJGPP (no hardware detected). I hope someone can test this on a real W9x system. I will see if I can install Windows 95 on Qemu).