Here I present version 1 . version 2 of the TINS windows binary packageAll 19 entries in a single convenient download.
Please let me know if something doesn't work (game crashes, dll not present, ...). I expect I will need to fix things, so keep an eye on this thread for updates.
I'll open the tins site for voting soon.
Everything worked for me except your entry (crashes on start up) and The hostages which wanted libpng13.dll
My entry is not working? Well stop the press!
Could you do me a favor and try this debug version here http://amarillion.bafsoft.net/download/eleven_monkeys_win_bin_dbg.zip, and if that one crashes too, run in through gdb and get a backtrace?
Never used GDB so before so um...
But good news! It didn't get very far at all....
C:\Downloads\eleven_monkeys_win_bin_dbg\eleven_monkeys>gdb tins07
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: C:\Downloads\eleven_monkeys_win_bin_dbg\eleven_monkeys/tins07.
exe
warning: al-main INFO: Allegro initialised (instance 1)
warning: al-gfx INFO: Called set_gfx_mode(2, 640, 480, 0, 0).
warning: al-gfx INFO: First call, remembering console state.
warning: al-gfx INFO: Autodetecting graphic driver.
warning: al-gfx INFO: The driver will wait for vsync.
warning: al-gfx INFO: set_gfx_card success for 640x480x16.
Program received signal SIGSEGV, Segmentation fault.
0x7c901010 in end_ ()
(gdb)
And that's where it dies. MSVC 8.0's Debuggers tells me it fails in find64.c
#endif /* _USE_INT64 */
{
WIN32_FIND_DATA wfd;
DWORD err;
_VALIDATE_RETURN( ((HANDLE)hFile != INVALID_HANDLE_VALUE), EINVAL, -1);
_VALIDATE_RETURN( (pfd != NULL), EINVAL, -1);
_VALIDATE_RETURN( (sizeof(pfd->name) <= sizeof(wfd.cFileName)), ENOMEM, -1);
if (!FindNextFile((HANDLE)hFile, &wfd)) {
err = GetLastError();
switch (err) {
case ERROR_NO_MORE_FILES:
case ERROR_FILE_NOT_FOUND:
case ERROR_PATH_NOT_FOUND:
errno = ENOENT;
break;
At the bolded line... now Since you probably compiled in MINGW I take it the info is pretty much useless.
Anyway looking at your dependencies I think I can just compile this and play around with the code until it works.
However I have an exam tomorrow and knowing my work habits it's probably in my best interest to fix this later 
I'll get around to it.. but just not yet.
All you needed to do in GDB was to type "bt" or "backtrace" and hit enter
Thanks I take it that's after it crashes?
New info:
| 1 | (gdb) bt |
| 2 | #0 0x7c901010 in _end__ () |
| 3 | #1 0x7c80ef6d in _end__ () |
| 4 | #2 0x10206fd8 in _end__ () |
| 5 | #3 0x100a6ca1 in _end__ () |
| 6 | #4 0x00413137 in glob(char const*, std::vector<std::string, std::allocator<std: |
| 7 | :string> >&) (pattern=0x469a85 "data/*.mod", result=@0x22f60c) |
| 8 | at src/resources.cpp:27 |
| 9 | #5 0x00413b74 in Resources::init() (this=0x22f6c0) at src/resources.cpp:108 |
| 10 | #6 0x0040b859 in Main::init(int, char const* const*) (this=0x22f6bc, argc=1, |
| 11 | argv=0xc42910) at src/main.cpp:102 |
| 12 | #7 0x0040c168 in _mangled_main(int, char const* const*) (argc=1, |
| 13 | argv=0xc42910) at src/main.cpp:268 |
| 14 | #8 0x100aded6 in _end__ () |
| 15 | #9 0x0040c242 in WinMain (hInst=0x400000, hPrev=0x0, Cmd=0x241f22 "", |
| 16 | nShow=10) at src/main.cpp:273 |
| 17 | #10 0x0045347a in main () |
Thanks, that is what I needed.
I haven't figured out what's going wrong yet. It's crashing on a call to al_findnext. Here is that part of code:
| 1 | // adds all filenames that match pattern to the vector |
| 2 | void glob(const char *pattern, vector<string> &result) |
| 3 | { |
| 4 | char buf[1024]; |
| 5 | |
| 6 | al_ffblk info; |
| 7 | |
| 8 | int temp = al_findfirst (pattern, &info, FA_RDONLY | FA_ARCH); |
| 9 | |
| 10 | while (temp == 0) |
| 11 | { |
| 12 | replace_filename(buf, pattern, info.name, sizeof(buf)); |
| 13 | result.push_back (std::string(buf)); |
| 14 | temp = al_findnext(&info); // <--- line 27, crash here |
| 15 | } |
| 16 | |
| 17 | al_findclose(&info); |
| 18 | } |
Your binary crashes for me (Vista), but when I build it with VS 2005 it runs fine.
Edit: Attached is my executable.
I can confirm that this version works.
[edit]
XP Home here.
[edit2]
Okay I got all entries working now. Found a copy of libpng13.dll, from last years tins entries .
This is the part I like the most about speedhack-like competitions. 
Works fine on windows 2000 though my copy of allegro42.dll seems to be out of date, couldn't play Amarillion's game till I used the dll from the debug version from above.
That would be it. I was using the allegro dll from this site for MSVC 8. When I took out the mingw version your original works. So it looks like it was a dll issue.
So are the MSVC dll and mingw dll incompatible? This doesn't look good, the whole point of having dll's is to be able to share 1 with multiple applications, but as it seems, it doesn't end up working that way.
I'd just like to point out the reason my game doesn't end is because on line 40 of CORRIDOR.cpp I have "==" when it should be "<=". It's as simple as that. 
Oh, and amarillion, you did get my source code, yes? It's not in the binary package above (I sent an email with the source code to ya).
Ok, I guess static linking allegro should fix the bug in my entry.
Version 2 of the package is now available (linked above), with
libpng13.dll included
static linked version of my entry "eleven monkeys"
Onewing: Yes, I got it, thanks. The source of your entry should now be available from the entries page on the TINS site.
"The procedure entry point _install_allegro_version_check could not be located in the dynamic link library allegro42.dll"
So much for not breaking ABI in 4.2 
The 4.2.0 DLL does not work with 4.2.1 games. It's not supposed to.
We will not be maintaining "forwards compatibility", meaning that programs compiled with a newer release of Allegro may not necessarily run on a target system which has an older release of Allegro installed. You would have to upgrade the Allegro DLL on the target system. While we will try to minimise these kinds of forced upgrades, it should give us more flexibility within the stable series.
i wanted to try some of them for the heck of it but couldnt, where can i get the dlls? IIRC there used to be an installer for this.