Dear Allegro Users,
Just short notice:
If someone needs Allegro 4 working with 64bit applications for Windows (unfortunately just for Windows at the very moment), please let me know.
The story is, I tried to migrate to Allegro 5 with my project, actually with some effort I did, but I got stuck with the lack of "infrastructure" in Allegro 5 to get what I need, especially direct drawing on the screen, XOR mode and in general - problems with primitives. I'm not creating games, I'm doing CAD, and that's the main problem. So I came back to Allegro 4, and with some changes what I needed to do, I got it working in 64bit, however just on Windows, and with (for my project most important) GDI architecture, what is mostly useful for me, and is really fast, thanks to some hardware support made by Microsoft for that.
Here is a link to the project, so if someone has some similar needs, please let me know, I will be happy to help.

alfacad.net

In the same time I'm searching for similar solution for another platform, what is Mac OSX, which seems to be much more tricky, due to changes in Apple system, especially migrating from Intel to M1. But maybe one day it will be possible, if not only me would care about such a good API as Allegro 4 really is.
I slightly modified version 4.4.3 to get it working with 64bit application.
I would be happy to share my experience.

Regards,
Marek

Edit:
Here is a link:

https://github.com/markremark1/Allegro-4.4.3.1-64bit-MSVC.git

Marek, that's awesome that you got Allegro to build in a 64 bit environment. It was never made compatible with 64 bit, as it was back in 32 bit days, but I'm glad you got it working.

It would be nice if you could submit a Pull Request with your changes to github.

Yes, please share your changes if you can! I'm sure there are more old allegro 4 games that could benefit from this

Awesome work. It may please some users who prefer A4.
As Edgar said, PR so maybe other people are going to help / test / port.

Here is a link:

https://github.com/markremark1/Allegro-4.4.3.1-64bit-MSVC.git

Marek, how extensive are your changes? Can you fork allegro, repeat your changes, and make a pull request on github? Your changes are based off of Allegro 4.4.3.1 git, correct? Perhaps we can just make a big diff and see if the patch works.

Edgar,
There are not substantial changes, just couple of files. Maybe also important part is setup of MSVC project to get it 64bit, but maybe not that hard to setup another compiler.
I'm not a hero in GitHub, so let me learn first how to do that what you request for. That's correct, it's based on 4.4.3.1 git what I downloaded not long time ago (however 32 bit version i have done with 4.4.4 but there are not really big changes). Simply, 4.4.3.1 worked better form me with MSVC. So I'm trying to use all my "talents" to fork and amend 4.4.3.1 version.
By the way, if PNG is loaded and displayed, there is also necessary to compile libpng (lpng1637) and zlib in 64 bit, loadpng I just included in source to my project and compiled all together.

Marek

Hi Marek,

does it compile with MingW64? Could I get it working with code::blocks?

William,
I didn't try with MingW64, but I believe that if it works with MSVC, it works with everything
Seriously, just take it and try it.
As long as we are talking about Windows GDI, and reading here: https://docs.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN this:
"64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit)...."
GDI seems to be relatively easy.
Unfortunately, I believe the migration won't be so easy on OSX, probably impossible without substantial changes. If Allegro 5 would get XOR mode, I would use it, I already migrated to Allegro 5, but I had to move back. I do not know how to do vector graphic in A5 without primitives infrastructure what I got in Allegro 4 API. I can modify GUI, to draw in memory first then swap displays (drawing directly on screen is extremely slow in DirectX), but the lack of XOR mode restrains my hands and thoughts.

Okay. Thanks very much for the help

I took the liberty of forking your project and comparing it to allegro 4.4.4. I used 'git diff > patch.txt' after copying all of your changed files to the existing Allegro 444 from GIT.

I attached the patch file to this post.

If you read it, you will see that these changes can't be merged directly with 4.4.4, which is the development branch, without breaking a lot of the versioning. To contribute the changes, it would be best to 1) Fork the liballeg allegro5 master from github and do git checkout 4.4 then 2) apply your changes directly, 3) commit them, and 4) make a pull request.

1) Go to http://github.com/liballeg/allegro5 and hit the FORK button.

Clone the repository using the directions and using GIT after installing it.

git clone http://github.com/yourname/allegro5.git Allegro443
git checkout 4.4

2) Apply your changes, and whatever else you need to get it to compile in MSVC. Leave the versioning out. Also, try to make one commit for the 64 bit stuff, and one commit each for any other changes you make.

git add [file | directory]
...

3)
git commit -m "Commit message"

4) Go to your repository on github and select pull request. Make sure to compare the remote allegro 4.4 branch with your github changes branch.

Happy hunting.

Ok, I made an attempt to work this patch.

Edgar, I believe you took your diff against the wrong base. Your patch file has a lot of changes like this:

-set(ALLEGRO_VERSION 4.4.4)
+set(ALLEGRO_VERSION 4.4.3)

Which makes it hard to apply cleanly. I instead took the diff between the 4.4.3.1 tag and Marek's code

diff -r -Zu allegro4.4.3.1/ allegro4-64bit-MSVC/

Which leads to a much smaller patch (attached)

 demos/shooter/demo.c                           |    2 +-
 src/file.c                                     |    4 ++--
 src/fsel.c                                     |    2 +-
 src/glyph.c                                    |    4 ++--
 src/gsprite.c                                  |    2 +-
 src/gui.c                                      |    4 ++--
 src/guiproc.c                                  |    8 ++++----
 src/unicode.c                                  |   12 ++++++------
 src/win/gdi.c                                  |    2 +-
 src/win/wddlock.c                              |    4 ++--
 src/win/wgdi.c                                 |    2 +-
 src/win/wmidi.c                                |    4 ++--
 src/win/wsndwo.c                               |    4 ++--
 41 files changed, 27 insertions(+), 27 deletions(-)

It's so small it seems like I'm missing something. Marek added a bunch of files too, but it seems to be mostly some generated documentation and build files, I didn't find any significant added files.

This new patch applies cleanly to allegro 4.4. Here are the changes on my own fork of allegro:

https://github.com/amarillion/allegro5/commit/fc8cb8e0846a397fcd1990a5aa92fa3a18e722f8

All I need now is somebody to actually test this. I'm not set up for that.

Amarillion,
You are right, there are not many changes, and in fact I copied whole folder so also build files were included, what probably led to big troubles to generate differences.
But those files which were amended / changed, are easy to find by date (last update), because all that work I've done around Xmas, so between 26.12.2020 and 27.12.2020. Some of those changes are marked by "//64bit ... " comment, but unfortunately I forgot to do that in each file I changed. But it is also easy to detect them by searching string "long long" which for 64 bit version replaced simply "long" because of length of addresses, however, is not necessary well done, it should be instead some "long_long" declared as long or long long depending of the desired machine, or x86 or x64. It should be actually corrected in the code.
So it's right, it's so small, but not necessary you are missing something. Actually that was a reason why I included whole folder to make it easier at least to compile with MSVC (the project is created in MSVC 2017), to get it working quickly, as a starting point for other compilers, which I didn't test.
I just can say, since I compiled that version, as an "engine" for my CAD, which is compiled in 32bit with 4.4.4 fork and 64bit with my version of 4.4.3.1, with obviously necessary changes in my code (but this time made better in my code, as long_long rather than long or long long, to use the same source for bot 32bit and 64bit), all is running well, as pure 64bit application (there are also MFC included), with fully functioning Allegro for both vector (primitives) and bitmap operations (I do not use Allegro GUI, I created my own one), however, as I underlined before, I'm using GDI driver, which is the only fast enough for direct drawing, what is necessary in my project, especially XOR mode for drawing vectors.
Regards.

Not so surprising - the Linux builds of Allegro 4 always supported 64 bit and the Macos port was fixed for 64-bit when the Intel macs appeared. Just DOS/Windows remained 32-bit throughout the entire lifetime of Allegro 4. But yeah, it means 64-bit Windows specific code is the only place that requires changes.

Elias,
You wrote: "and the Macos port was fixed for 64-bit when the Intel macs appeared."

Looks like I've missed something. As I know the only Mac OS graphic driver in Allegro 4 was and is QuickDraw in a Cocoa window, which was never supporting 64bit target. Was it replaced by something what supports 64bit ? I would love it, at least waiting until Allegro 5 will support XOR mode, and some other "legacy" features (like DRAW_MODE_COPY_PATTERN for example) that I can't live without.

Hm, I may be misremembering. I definitely used the 64-bit Linux version though. (But never used Windows or Mac myself.)

I'm working on a patch and pull request now. Marek, are you on Github?

Edgar,
I will appreciate if you would do all necessary patches, as should be done. I made those small changes and I'm proud of it, but I cannot say I'm really familiar with GitHub requests. I'm pretty sure whole community will be more happy whe you will do that, if you are doing anyway. Many thanks.

I'm working from a fork of amarillion's patch against 4.4.3.1. Any word on anyone about using int64_t?

First of all, Marek Ratajczak, what an awesome move!!!! Congratulations on that!!! I have a project that uses all4 that is on hold(deadish) for quiet a while now, but would be good to compile it on 64, just because hehehe. Since my day to day work is not related to programming I can't say I will to it stat, but I'm definitely trying your(and other fellows that are merging it) solution anytime soon!!! Once again, congrats on the job!

I had a quick check yesterday evening; the code as it is won't compile on Linux now, due to ULONG_PTR. There are also some line-ending problems (stray ^M). I hope to have some time over the weekend to go over it more thoroughly. I believe we can and should use the stdint types, they are actually the ones used in the header files.

[edit] I did look and started trying to fix all the warnings but with MSVC set to /W3, as it is in our CMake script, there's a huge number of them. Most of them are of dubious value. So I think I'll back-track and just make sure it'll compile on Windows (MSVC) and Linux, assuming MinGW will also be OK. That's only a couple of changes to Marek's PR.

Thank you Peter. Let's not let this thread get buried in the sands of time just yet. Progress? Anything you want me to do?

Despite appearances to the contrary I'm not dead, either.
But I am just struggling with building using MSVC; it's not able to link in the allegrogl part. Also the built-in CMake support in Visual Studio seems a bit flaky and gives inconsistent errors which don't appear in the 'standalone' cmake.

If anyone knows about this, please chip in!
Pete

Glad you're still with us Peter.

Is there a repo you're working with? Let me clone it and see what I can do about the CMake stuff. Which version of VS are you using?

Have you made all the changes necessary to use the stdint.h header's standard types?

I've fixed the cmake problem, plus all cases where the casts seemed unsound (i.e. casting a pointer to a long) and then a few bits and bats.
The branch is here:
https://github.com/pedro-w/allegro5/tree/64-bit-allegro4-ph
I will need to rebase to sort out the commits as they're all mixed up at the moment.

Peter, how can I help? If I clone your repo and checkout your 64 bit branch, is it ready to build and test with MinGW? I can try it with a x86_64 GCC 8.1 compiler.

Yes, it should work. There will be warnings I expect but nothing of real concern (at least on MSVC it uses warn level W3 which is very picky). Then as I said I will try and sort it out into more coherent commits.

I'm having trouble building a 64 bit ogg and vorbis for 64 bit allegro. I can't figure out how to verify that they are actually 64 bit libraries. MSYS' file command doesn't help. Windows Explorer properties doesn't help. My Ubuntu 20.04 in a VM won't let me access the shared drive so I can't test from there either.

Maybe I will see if your allegro builds without the addons first. I'll try that and report back.

UPDATE
64bit allegro builds fine (*cough* with about 1000 warnings) with jpgalleg and allegrogl. The examples seem to work fine. I didn't test the grabber. And those warnings look pretty scary, but I don't think any of them had anything to do with your code. I get those when building 32 bit allegro 4 as well.

Any clues how to make sure my libraries are 64 bit? I don't have a way to verify that atm. file doesn't help. explorer doesn't help. Dependency walker crashes and doesn't work in Windows 10. I'm all out of ideas.

I counted 32 commits in your repo from the time of the 4.4 branch. Does that sound about right?

Not that many

> git log --pretty=oneline upstream/4.4...origin/64-bit-allegro4-ph
8400ebc8b8a7f635cafe2f7679c5d36f7e9f1aba (origin/64-bit-allegro4-ph) Fix some types to match Win API
5f13fd2297968c2477e90dbfa66261e386623de1 Fix some casts from pointer to long
0dc3c1e12a52bb1b8bc5d43d20cb56e3eb7b316b Add Visual Studio's CMake support dirs
6a156e75278b645de6fa3fc8e3102729ed049478 Make conditional on SHARED build
f1c485dd0936ce829aa4f87db022f65cff76aa60 Also allow DLL building with MSVC
b2ab27c62857940b9f73e426c14bd71033b5f848 For MSVC, ensure DLL symbols are exported/imported
7172efad62cde97078b8ff9d6e6391b1ae26ff4f Fix a couple more warnings
bdf1f0b495dd4f90435e8369dc7ad7f6aadbde23 Visual Studio - fix some compiler warnings
706fafec9750d176ff88b03aa11cc0c69d5bc8f1 Fix misc warnings
689f3fb4bd4667234f9b7ca3f704ad6045329af9 Use stdint types where possible
fc8cb8e0846a397fcd1990a5aa92fa3a18e722f8 Marek Ratajczak's 64-bit patch

AFAICS the remaining ones are all spurious/unhelpful, e.g. expressions of the form s + (i + 1) * sizeof(T) where s is 64-bit and i is an int complain about doing 32-bit arithmetic and then casting to a larger type (even when we know i is never going to be big enough to overflow). The fix seems to be s + ((int64_t) i + (int64_t) 1) * sizeof(T), anything else won't satisfy it. And that seemed to be a bit over-the-top to me!

[edit]
dumpbin is the thing Windows uses to tell you if a library is 32 or 64 bit. I don't know if mingw has a version of it?

[edit2] I've merged together some commits to make it easier to see what's going on. If you've got time can you check if it's still working ok? If so, then that's done as far as I am concerned.
https://github.com/pedro-w/allegro5/tree/64-bit-allegro4-ph

I tested your patch and everything builds okay, sans the addons until I get the deps built.

EDIT
Here's the full build log including allegrogl (which has the most warnings of all) :

buildlog.txt