[AD] Re: Allegro 4.1.18 (WINXP) [make error]

[Harsha <nharsha@xxxxxxxxxx>]

Hi
 I just compiled the src of 4.1.18 and I got the following error while
running make

/*********************************************************************************************/
src/win/wwnd.c(583) : error C2065: 'TITLEBARINFO' : undeclared identifier
src/win/wwnd.c(583) : error C2146: syntax error : missing ';' before identifier
'tb_info'
src/win/wwnd.c(583) : error C2065: 'tb_info' : undeclared identifier
src/win/wwnd.c(584) : error C2143: syntax error : missing ';' before 'type'
src/win/wwnd.c(585) : error C2143: syntax error : missing ';' before 'type'
src/win/wwnd.c(590) : error C2065: 'last_w' : undeclared identifier
src/win/wwnd.c(590) : error C2065: 'last_h' : undeclared identifier
src/win/wwnd.c(597) : error C2224: left of '.cbSize' must have struct/union type

src/win/wwnd.c(599) : error C2065: 'tb_height' : undeclared identifier
src/win/wwnd.c(601) : error C2224: left of '.rcTitleBar' must have struct/union
type
src/win/wwnd.c(601) : error C2224: left of '.rcTitleBar' must have struct/union
type
make: *** [obj/msvc/alleg/wwnd.obj] Error 2


[Comp Details]

windows XP Professional 2002
Computer Intel(R) Pentium(R) 4 CPU 1.50GHZ

[ GCC Details]

D:\Visual_Studio\allegro-4.1.18>gcc -v
Reading specs from D:/Dev-Cpp/bin/../lib/gcc-lib/mingw32/3.3.1/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz
ation
Thread model: win32
gcc version 3.3.1 (mingw special 20030804-1)

/*********************************************************************************************/
END_OF_MSG( );

On Mon, 24 Jan 2005 07:40:16 -0800,
alleg-developers-request@xxxxxxxxxx
<alleg-developers-request@xxxxxxxxxx> wrote:
> Send Alleg-developers mailing list submissions to
>        alleg-developers@xxxxxxxxxx
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/alleg-developers
> or, via email, send a message with subject or body 'help' to
>        alleg-developers-request@xxxxxxxxxx
> 
> You can reach the person managing the list at
>        alleg-developers-admin@xxxxxxxxxx
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Alleg-developers digest..."
> 
> Today's Topics:
> 
>   1. Re: Overloading Alert (Chris La Mantia)
>   2. Re: Allegro 4.1.18 WIP RC1 (aj)
>   3. Re: Allegro 4.1.18 WIP RC1 (aj)
>   4. Re: AMD64 patch (Eric Botcazou)
>   5. Re: Allegro 4.1.18 WIP RC1 (Evert Glebbeek)
>   6. Re: Allegro 4.1.18 WIP RC1 (Kirill Kryukov)
>   7. Re: AMD64 patch (Peter Wang)
>   8. Re: AMD64 patch (Eric Botcazou)
>   9. Re: Allegro 4.1.18 WIP RC1 (Marcio Afonso Arimura Fialho)
>  10. Re: AMD64 patch (Evert Glebbeek)
>  11. Re: Allegro 4.1.18 WIP RC1 (Marcio Afonso Arimura Fialho)
>  12. Re: AMD64 patch (Peter Wang)
>  13. Re: Allegro 4.1.18 WIP RC1 (Elias Pschernig)
>  14. Re: AMD64 patch (aj)
>  15. Re: Allegro 4.1.18 WIP RC1 (Michal Molhanec)
> 
> --__--__--
> 
> Message: 1
> From: "Chris La Mantia" <celamantia@xxxxxxxxxx>
> To: <alleg-developers@xxxxxxxxxx>
> Subject: Re: [AD] Overloading Alert
> Date: Sun, 23 Jan 2005 23:18:07 -0500
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> Just to throw a comment into this mix: I use alert almost exclusivley for
> error messages, so I usually want to show the status of one or more
> variables... thus, it may be worth considering a printf() style
> string/argument list for a new alert.
> 
> --Chris
> 
> --__--__--
> 
> Message: 2
> Date: Mon, 24 Jan 2005 15:39:13 +1100
> To: alleg-developers@xxxxxxxxxx
> From: aj <aj@xxxxxxxxxx>
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> >the 4.1.18 WIP release to http://
> >www.eglebbk.dds.nl/allegro-4.1.18/. Tested and work smoothly under Linux,
> >but not recently tested on other platforms. So if others can test
> 
> AMD 2400+
> MSVC 7.1
> WinXPsp1  DX9c
> 
> builds OK.
> spent 3 minutes  in    /tests/test.exe     all OK.
> 
> --__--__--
> 
> Message: 3
> Date: Mon, 24 Jan 2005 16:02:41 +1100
> To: alleg-developers@xxxxxxxxxx
> From: aj <aj@xxxxxxxxxx>
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> Reply-To: alleg-developers@xxxxxxxxxx
> 
>  the 4.1.18 WIP release to http://
> >www.eglebbk.dds.nl/allegro-4.1.18/. Tested and work smoothly under Linux,
> >but not recently tested on other platforms. So if others can test
> 
> AMD2400+
> WinXPsp1 dx9c
> mingw  (GCC) 3.2
> 
> spent 3 mins in  /tests/test.exe    all OK.
> 
> --__--__--
> 
> Message: 4
> From: Eric Botcazou <ebotcazou@xxxxxxxxxx>
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] AMD64 patch
> Date: Mon, 24 Jan 2005 07:58:48 +0100
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> > I also get X async errors more frequently than on x86, which tend to go
> > away if you run from gdb.  So I don't think the problem is with my
> > patch, but with the X port itself.
> 
> Agreed.
> 
> > Attached is another patch.  Many of my changes from `long' to `int'
> > (e.g. for holding pixel values) were not really necessary so reverted
> > those.
> 
> Why?
> 
> --
> Eric Botcazou
> 
> --__--__--
> 
> Message: 5
> Date: Mon, 24 Jan 2005 09:37:22 +0100
> From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> > Evert Glebbeek (by way of Evert Glebbeek <eglebbk@xxxxxxxxxx>) wrote:
> > > Attached are the 4.1.18 thanks and changelog diffs.
> >
> > You forgot Phil Shenk doc patch (it was not applied directly but I
> > integrated it into my patch).
> 
> Embarassingly enough, I also didn't mention the additions AJ made :X
> I'll correct that before uploading the final release.
> 
> Evert
> 
> --__--__--
> 
> Message: 6
> Date: Mon, 24 Jan 2005 21:43:52 +0900
> From: Kirill Kryukov <kkryukov@xxxxxxxxxx>
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> > I've uploaded the files for the 4.1.18 WIP release to http://
> > www.eglebbk.dds.nl/allegro-4.1.18/. Tested and work smoothly under Linux,
> > but not recently tested on other platforms. So if others can test and
> > conform that it works well, I will upload the files to SourceForge,
> > somewhere around fivish PM UT tomorrow.
> 
> Windows XP SP2, DJGPP (GCC 3.4.3) - It compiles OK.
> Some examples don't work, and some other show garbage, but I think it
> is expected on Windows, is it?
> I don't have DOS box at the moment, can't test fully.
> 
> --
> Best regards,
> Kirill                          mailto:kkryukov@xxxxxxxxxx
> 
> --__--__--
> 
> Message: 7
> Date: Mon, 24 Jan 2005 23:48:12 +1100
> From: Peter Wang <tjaden@xxxxxxxxxx>
> To:  alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] AMD64 patch
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> Eric Botcazou wrote:
> 
> >>Attached is another patch.  Many of my changes from `long' to `int'
> >>(e.g. for holding pixel values) were not really necessary so reverted
> >>those.
> >>
> >>
> >
> >Why?
> >
> >
> 
> In some places, the change from long to int would have changed the API
> unnecessarily (I'm thinking of the blender functions, but maybe there
> were more).
> 
> In other places where it didn't really matter either way, I thought it
> would be best just to leave them alone.  Then the assumption on the
> sizeof(int) can remain as it is now (somewhere between 16-bits and
> 32-bits) and long can continue to be used to hold values which need
> 32-bits.  Is there any reason to prefer a 32-bit integer over a 64-bit
> integer on a 64-bit machine, e.g. to hold single pixel values?
> 
> Peter
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005
> 
> --__--__--
> 
> Message: 8
> From: Eric Botcazou <ebotcazou@xxxxxxxxxx>
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] AMD64 patch
> Date: Mon, 24 Jan 2005 14:12:08 +0100
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> > In other places where it didn't really matter either way, I thought it
> > would be best just to leave them alone.  Then the assumption on the
> > sizeof(int) can remain as it is now (somewhere between 16-bits and
> > 32-bits) and long can continue to be used to hold values which need
> > 32-bits.  Is there any reason to prefer a 32-bit integer over a 64-bit
> > integer on a 64-bit machine, e.g. to hold single pixel values?
> 
> Alignment I'd say.  Every other 32-bit pixel value is not 64-bit aligned so
> you must be careful when you're dereferencing a pointer to a scanline,
> although this doesn't really matter on AMD64.
> 
> --
> Eric Botcazou
> 
> --__--__--
> 
> Message: 9
> Date: Mon, 24 Jan 2005 10:11:27 -0300 (ART)
> From: Marcio Afonso Arimura Fialho <maaf1980@xxxxxxxxxx>
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> To: alleg-developers@xxxxxxxxxx
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> --0-367625160-1106572287=:9175
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> Content-Id:
> Content-Disposition: inline
> 
> Evert Glebbeek wrote:
> >
> > I've uploaded the files for the 4.1.18 WIP release
> > to http://www.eglebbk.dds.nl/allegro-4.1.18/.
> > Tested and work smoothly under Linux,
> > but not recently tested on other platforms. So if
> > others can test and conform that it works well, I
> > will upload the files to SourceForge,
> > somewhere around fivish PM UT tomorrow.
> >
> 
> Builds fine with DJGPP 2.03 + GCC 3.4.1, with WARNMODE
> flag set. Builds OK regardless if user has run fix.bat
> or not.
> 
> There's however a minor issue when compiling with GCC
> 3.4.1.  It complains that the  '-mcpu=pentium'  flag
> is
> deprecated (see below):
> 
> gcc -DALLEGRO_LIB_BUILD -Wall -W -Wstrict-prototypes
> -Wno-unused -Werror -mcpu=pentium -O2 -funroll-loops
> -ffast-math -fomit-frame-pointer -I. -I./include -o
> obj/djgpp/alleg/exgui.o -c examples/exgui.c
> `-mcpu=' is deprecated. Use `-mtune=' or '-march='
> instead.
> 
> > This WIP does not yet include Peter's patch to make
> > Allegro more 64 bit friendly, but I see no reason to
> > not apply it (and similar patches) after this.
> 
> I might be wrong, but after applying them, I belive
> it's a good idea to rebuild the DJGPP port just to
> make sure.
> 
> >
> > Attached are the 4.1.18 thanks and changelog diffs.
> >
> 
> I've fixed a typo and improved formatting in
> 'authors.' The diff file is attached.
> 
> Marcio.
> 
> _______________________________________________________
> Yahoo! Acesso Grátis - Instale o discador do Yahoo! agora. http://br.acesso.yahoo.com/ - Internet rápida e grátis
> --0-367625160-1106572287=:9175
> Content-Type: application/octet-stream; name="authors.diff"
> Content-Transfer-Encoding: base64
> Content-Description: authors.diff
> Content-Disposition: attachment; filename="authors.diff"
> 
> LS0tIGF1dGhvcnMub3JpZwkyMDA1LTAxLTIzIDIzOjUzOjAyLjAwMDAwMDAw
> MCArMDAwMA0KKysrIGF1dGhvcnMuCTIwMDUtMDEtMjQgMDk6Mjc6MDYuMDAw
> MDAwMDAwICswMDAwDQpAQCAtNTQwLDggKzU0MCw4IEBADQogICAgbWFkZSB0
> aGUgc2hvd192aWRlb19iaXRtYXAoKSBtZXRob2Qgb2YgdGhlIFdpbmRvd3Mg
> d2luZG93ZWQgZHJpdmVyIHdhaXQNCiAgICBmb3IgYSB2c3luYy4NCiAgICAN
> Ci0gICBNYXJjaW8gRmlhbGhvKG1hYWYxOTgwIGF0IHlhaG9vIGRvdCBjb20g
> ZG90IGJyLg0KLSAgIEZpeGVkIHNldmVyYWwgaXNzdWVzIHdpdGggdGhlIERK
> R1BQIHBvcnQgYW5kIHRlaCBWQkUvQUYgZHJpdmVyLg0KKyAgIE1hcmNpbyBG
> aWFsaG8gKG1hYWYxOTgwIGF0IHlhaG9vIGRvdCBjb20gZG90IGJyKS4NCisg
> ICBGaXhlZCBzZXZlcmFsIGlzc3VlcyB3aXRoIHRoZSBESkdQUCBwb3J0IGFu
> ZCB0aGUgVkJFL0FGIGRyaXZlci4NCiANCiAgICBNYXJjbyBDYW1waW5vdGkg
> KG1hcmNvIGF0IGV0cnVzY2FuIGRvdCBsaSBkb3QgaXQpLg0KICAgIEFkZGVk
> IDE1IGFuZCAyNCBiaXQgc3VwcG9ydCB0byB0aGUgbmF0aXZlIFRzZW5nIEVU
> NDAwMCBkcml2ZXIgKG5vdw0K
> 
> --0-367625160-1106572287=:9175--
> 
> --__--__--
> 
> Message: 10
> Date: Mon, 24 Jan 2005 14:24:50 +0100
> From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] AMD64 patch
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> > >>Attached is another patch.  Many of my changes from `long' to `int'
> > >>(e.g. for holding pixel values) were not really necessary so reverted
> > >>those.
> > >>
> > >>
> > >
> > >Why?
> > >
> > >
> >
> > In some places, the change from long to int would have changed the API
> > unnecessarily (I'm thinking of the blender functions, but maybe there
> > were more).
> 
> True. I think a case could be made that those functions should really hav=
> e
> taken an int rather than a long, but that's beside the point since they
> didn't.
> Having int might be a good idea because compilers Allegro currently
> supports (in Windows) do not agree on the size of a long, but they do agr=
> ee
> on the size of an int. At least as far as I know.
> 
> > In other places where it didn't really matter either way, I thought it
> > would be best just to leave them alone.  Then the assumption on the
> > sizeof(int) can remain as it is now (somewhere between 16-bits and
> > 32-bits) and long can continue to be used to hold values which need
> > 32-bits.  Is there any reason to prefer a 32-bit integer over a 64-bit
> > integer on a 64-bit machine, e.g. to hold single pixel values?
> 
> I think there's performance reasons to prefer an int over any other integ=
> er
> type if there are no other constraints on the datatype.
> 
> Evert
> 
> --__--__--
> 
> Message: 11
> Date: Mon, 24 Jan 2005 10:31:18 -0300 (ART)
> From: Marcio Afonso Arimura Fialho <maaf1980@xxxxxxxxxx>
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> To: alleg-developers@xxxxxxxxxx
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> Builds OK also with DEVC++ 4.9.80.
> Demo program OK.
> Examples not tested.
> 
> Regarding the DJGPP release, probably I'll not have
> time to test the examples, but the demo program and a
> program I wrote (PTASE) works fine.
> 
> Evert, Elias,... and all other Allegro contributors,
> Great work!!!
> 
> Regards,
> Marcio.
> 
> __________________________________________________
> Converse com seus amigos em tempo real com o Yahoo! Messenger
> http://br.download.yahoo.com/messenger/
> 
> --__--__--
> 
> Message: 12
> Date: Tue, 25 Jan 2005 01:00:43 +1100
> From: Peter Wang <tjaden@xxxxxxxxxx>
> To:  alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] AMD64 patch
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> Eric Botcazou wrote:
> 
> >>In other places where it didn't really matter either way, I thought it
> >>would be best just to leave them alone.  Then the assumption on the
> >>sizeof(int) can remain as it is now (somewhere between 16-bits and
> >>32-bits) and long can continue to be used to hold values which need
> >>32-bits.  Is there any reason to prefer a 32-bit integer over a 64-bit
> >>integer on a 64-bit machine, e.g. to hold single pixel values?
> >>
> >>
> >
> >Alignment I'd say.  Every other 32-bit pixel value is not 64-bit aligned so
> >you must be careful when you're dereferencing a pointer to a scanline,
> >although this doesn't really matter on AMD64.
> >
> >
> 
> Hmm, then I guess we should use ints internally to hold single pixel
> values but retain unsigned longs wherever needed in the interface for
> API compatibility?  That can be done after the current patch is applied.
> 
> If you could explain your thinking about the alignment a bit more, that
> would be great.  To me it seems like there is not much difference
> between dereferencing a 32-bit quantity and (i) storing it into a 32-bit
> register, or (ii) storing it into a 64-bit register.  Surely the only
> difference is that in the latter case the upper 32-bits of the register
> need to be cleared (or sign-extended)?
> 
> Peter
> 
> --__--__--
> 
> Message: 13
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> From: Elias Pschernig <elias@xxxxxxxxxx>
> To: alleg-developers <alleg-developers@xxxxxxxxxx>
> Date: Mon, 24 Jan 2005 15:17:20 +0100
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> On Mon, 2005-01-24 at 00:42 +0100, Elias Pschernig wrote:
> 
> > I'll test the example programs tomorrow (in linux, maybe XP).
> >
> 
> Ok, discovered no problems in linux.
> 
> --
> Elias Pschernig
> 
> --__--__--
> 
> Message: 14
> Date: Tue, 25 Jan 2005 01:17:27 +1100
> To: alleg-developers@xxxxxxxxxx
> From: aj <aj@xxxxxxxxxx>
> Subject: Re: [AD] AMD64 patch
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> >Alignment I'd say.  Every other 32-bit pixel value is not 64-bit aligned so
> >you must be careful when you're dereferencing a pointer to a scanline,
> >although this doesn't really matter on AMD64.
> 
> i'd like to see alignment on 128bit boundarys  as i have been doing some
> SSE[2|3] programming on bitmap data directly.
> are the buffers created for the bitmap->dat  aligned to anything ?
> 
> --__--__--
> 
> Message: 15
> Date: Mon, 24 Jan 2005 16:39:15 +0100
> From: Michal Molhanec <michal@xxxxxxxxxx>
> To:  alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] Allegro 4.1.18 WIP RC1
> Reply-To: alleg-developers@xxxxxxxxxx
> 
> This is a multi-part message in MIME format.
> --------------000302070608080700070105
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
>    Hello,
> i did testing with more compilers to prevent problems like the one with
> 4.1.17 and djgpp was.
> 
> MinGW 3.3.1 dll+static
> VC++ 7.1 (.NET 2003) dll+static
> DJGPP 3.4.3
> Borland C++ 5.5.1 (free command line tools)
> Borland C++ 5.6.4 (CBuilderX)
> these five were without problem
> 
> Open Watcom 1.2
> attached patch, otherwise it compiles OK, it only does not generate
> documentation (we can probably ignore it)
> 
> VC++ 6.0 dll+static
> the new wwnd.c requires w98 so you need to tell vc60 about it, patch
> attached
> 
> --
> Regards,
>     Michal
> 
> --------------000302070608080700070105
> Content-Type: text/x-diff;
> name="alwatcom.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="alwatcom.diff"
> 
> --- alwatcom.orig.h     Fri Feb 14 14:24:40 2003
> +++ alwatcom.h  Mon Jan 24 03:34:10 2005
> @@ -179,3 +179,4 @@
> #define ALLEGRO_EXTRA_HEADER     "allegro/platform/aldos.h"
> #define ALLEGRO_INTERNAL_HEADER  "allegro/platform/aintdos.h"
> 
> +#define LONG_LONG       long long
> 
> --------------000302070608080700070105
> Content-Type: text/x-diff;
> name="winalleg.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="winalleg.diff"
> 
> --- winalleg.orig.h     Fri Sep 13 11:18:56 2002
> +++ winalleg.h  Mon Jan 24 15:20:42 2005
> @@ -36,6 +36,11 @@
> /* bodges to avoid conflicts between Allegro and Windows */
> #define BITMAP WINDOWS_BITMAP
> 
> +/* Windows 98 or Windows NT 4.0 Service Pack 6 required */
> +#ifndef WINVER
> +   #define WINVER 0x0500
> +#endif
> +
> #if (!defined SCAN_EXPORT) && (!defined SCAN_DEPEND)
>    #ifdef ALLEGRO_AND_MFC
>       #ifdef DEBUGMODE
> 
> --------------000302070608080700070105--
> 
> --__--__--
> 
> _______________________________________________
> Alleg-developers mailing list
> Alleg-developers@xxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 
> End of Alleg-developers Digest
>