So it turns out the binaries I have aren't loading the acodec dependencies. Too bad! No sound for you!

Having somehow avoided building Allegro from sources in Windows since at least as far back as 2015, and since having at some point reclaimed all the space doing so robbed from my paltry 250GB SSD, I'm not looking forward to the prospect of having to re-download and install all that's needed and build every single last dependency along with, just to make certain I don't have to dive into this territory again until the next time I have to upgrade to get the fix for a showstopping bug.

Could someone who's already generated Win32 binaries of the dependencies of 5.2.2.x kindly help me out? Binaries would be just fab. Or the simplest possible path to accomplishing my goal of building them as fast as possible and getting back to working on games and stuff...

Yes, everything is included. static and dynamic versions of everything (enet, flac, freetype2, libpng, zlib, physfs, turbo (libjpeg), ogg, theora, vorbis, dumb (static only)). As well, there are dynamic debugging executables, demos, and tests, as well as html and chm docs and all the includes and libs you need for everything.

Still not able to stream an ogg file in my project; I'm tearing my hair out, seems like this happens every time I upgrade. I even found a bug where somehow the file string was being clobbered. Will keep trying...

This is all Greek to me. Due to a distaste for / lack of aptitude for the C multiverse and a strong will I have managed to weasel past the complexity and I just use SwiftForth and DLL's. That's it. Will gdb work with any EXE, even if it's not in C? (Not that I hold out much hope.)

I managed to get Process Explorer to show me what DLL's are loaded by my process. Looks like everything is there. I am literally doing just (the equivalent of) this...

Looks like libvorbisfile-3.dll fails to load, due to PathFindOnPath failed... but I'm in the same directory as that file. Makes no sense.

I have updated my Allegro version number that I pass to al_init to 5.2.3, thinking that was it. No luck.

Another update: Just tried copying all dependencies to C:/windows, and it succeeds. The heck.

Update the third: Tried copying them to the folder where my actual IDE's EXE is located. That worked too. I'm starting to think that this is a Windows 10 security thing. Disallow loading of DLL's that seem to be not related to the current process.

When a DLL is loaded, the %PATH% is what is searched, starting with .\. That means the current working directory needs to be the same as the one with your exe and dlls. Do NOT put DLLs in system32 or SysWow64, or any other system directory unless they're never going to change or very infrequently.

I seem to recall it being possible to compile all the dependencies into the allegro DLL. I think I did this to clean up the install directory of The Lady, a few years back. Would it be easy for you to do? Seriously I would paypal you $20 to avoid having to do it myself.

The framework I've built (Bubble) is loaded into the IDE, which is an EXE in a different directory. The IDE is the compiler. We load and test application code interactively here, and sometimes spit out an application exe. The issue is that I had to put in a notice telling people to copy all DLL's to the IDE's bin folder if they want sound. Not a show stopper, but it is a weak point; a person can forget to do that when I release the framework with new versions of Allegro.

The other reason is just my sense of tidiness.

I leave it totally up to you if you feel like doing it. I wasn't kidding about paying!

Newp, no static linking, though in theory it could be done, at that point you're replicating GNU, haha.

I think the SwiftForth FFI just saves the Forth CPU state, creates a stack frame and calls DLL functions and then reverses the process to come back to Forth. Pretty straightforward. I do not have to load any dependencies of Allegro manually, I believe it is automatically done by Allegro's behind-the-scenes C stuff when I initialize. I just declare Allegro and SwiftForth takes care of loading it, in a similar fashion to C.

By "select the current working directory", what do you mean exactly? Like chdir? Or is there something else, like a WINAPI function I should call?

Yes, the following code will allow you to set the current working directory to the directory the executable is in. Use al_change_directory instead of _chdir or chdir. It takes care of the cross platform stuff for you.