Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Quietust]

I just did a bit of tracing through this crash-on-exit, and I've narrowed it down to the destructor for one of the globals - it appears to be calling a function through a pointer (where said pointer points into the data segment, causing the crash) and then closing 3 file handles, which are almost definitely STDIN, STDOUT, and STDERR.

enabler.cpp contains the following new code, which I can't help but suspect may be related to the crash:

Code: [Select]

#ifdef WIN32
//NOTE: TO FIX SDL LINKER ERROR THAT CAME UP WITH VISUAL STUDIO 2015
extern "C" { FILE __iob_func[3] = { *stdin,*stdout,*stderr }; }
#endif

[edit] Just did some more research, and I can 100% confirm that this is the cause of the crash - __iob_func is supposed to be a function which returns the array, not the array itself.

This should fix the problem:

Code: [Select]

#ifdef WIN32
FILE _iob[] = {*stdin, *stdout, *stderr};
extern "C" FILE * __cdecl __iob_func(void)
{
    return _iob;
}
#endif

The "proper" solution would be to recompile SDL using MSVC 2015.

[NCommander]

I just did a bit of tracing through this crash-on-exit, and I've narrowed it down to the destructor for one of the globals - it appears to be calling a function through a pointer (where said pointer points into the data segment, causing the crash) and then closing 3 file handles, which are almost definitely STDIN, STDOUT, and STDERR.

enabler.cpp contains the following new code, which I can't help but suspect may be related to the crash:

Code: [Select]

#ifdef WIN32
//NOTE: TO FIX SDL LINKER ERROR THAT CAME UP WITH VISUAL STUDIO 2015
extern "C" { FILE __iob_func[3] = { *stdin,*stdout,*stderr }; }
#endif


^- that linker error should be resolvable by rebuilding SDL and SDLmain static library with VS2015. __iob_func refers to symbols in the CRT that went away with VS2015. Reference: https://groups.google.com/forum/#!topic/dislin-users/kagVl9LVFJA

So I'm guessing remove the SDL linker line from enabler, rebuild SDL/SDLmain, rebuild DF?

[Max™]

Quietust and NCommander wizarding it up.

Spoiler (click to show/hide)

32 bit users are going to have to be cut off eventually. Or does everyone really imagine they'll be playing DF 1.0 on a 30-40 year old computer?

It depends on how much management it needs, but if it's enough to impact the schedule it'd be insane to keep ensuring 32 bit compatibility for the next 20 years. Why bother going 64 bit in the first place if there's no plans to ever take advantage of it?

Well, hopefully someone will eventually hack up a 64 bit XP clone for those insistent that it can't be beaten.

I put together a version of linux mint on the computer downstairs for the in-laws since they're longtime windows users, and mint has an XP skin that only confused them when they noticed it wasn't actually windows.

The biggest issue with sticking to 32 bit isn't performance, it's security, there are significant improvements from using WOW64, 64 bit registers, and various 64 bit architecture based security features whether you're using a 32 bit program or not. Clinging to an OS/hardware combo which is so old that it can't be updated to 64 bit means you're waaaaaay out in "I've got literally no security beyond obscurity" land, and it's unfortunate but that isn't a large portion of the user base, nor is it one which a developer should feel obligated to continue supporting. I can fully appreciate being broke as a joke, but you could probably find a computer being tossed out somewhere that would run 64 bit OS/software combos. It isn't like this is a looming thing, it was 10.. 11 12 years ago.

[Random_Dragon]

So, what's Toady's opinion on this "let's ditch 32-bit" idea? D:

[Max™]

Given that he provides the legacy version, probably less vehement than some of us, lord knows I'm an advocate for the "all 64 bit all the time everywhere" side, while he just wants to have it updated and get that ready for the future I think.

[Random_Dragon]

Yay. Personally I wouldn't mind either version, just the issue of what my current systems have as a consequence of irritating circumstances. :V

[Toady One]

[edit] Just did some more research, and I can 100% confirm that this is the cause of the crash - __iob_func is supposed to be a function which returns the array, not the array itself.

Ha ha, yeah, I just used the first thing I found which made it compile and not obviously crash (I still have no visible crash symptoms).  I can switch it over with the next set of linker tests as I try to sort out this memory problem.  I could try rebuilding SDL instead, but I'll probably find a way to screw that up.

[Random_Dragon]

Ha ha, yeah, I just used the first thing I found which made it compile and not obviously crash (I still have no visible crash symptoms).  I can switch it over with the next set of linker tests as I try to sort out this memory problem.  I could try rebuilding SDL instead, but I'll probably find a way to screw that up.

You're reminding me far too much of any time I'd try to mess with the source code in CDDA. XP

[NCommander]

[edit] Just did some more research, and I can 100% confirm that this is the cause of the crash - __iob_func is supposed to be a function which returns the array, not the array itself.

Ha ha, yeah, I just used the first thing I found which made it compile and not obviously crash (I still have no visible crash symptoms).  I can switch it over with the next set of linker tests as I try to sort out this memory problem.  I could try rebuilding SDL instead, but I'll probably find a way to screw that up.

Rebuilding SDL is straight-forward. Download the source, upgrade the project file in VisualC/, and bake one release build. I have a build environment sitting here ready to go, and if you'd like, I can rebuild all of DF's dependencies against 32-bit and 64-bit for a quick and easy to go dev environment if you like.

[breadman]

On Windows 8.1, I saw errors for msvcp140.dll before downloading it, then vcruntime140.dll, and now api-ms-win-crt-runtime-l1-1-0.dll, so I'd guess they'll all need to be included unless we're expected to install something.

Also, on the topic of the runtime, here's what will probably fix it permamently: Go to "C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86", copy and paste everything, and throw it into the DF folder. I can't test it easily, but that's all the files for the VC15 runtime. I'll post a zip in a moment.

EDIT: For anyone who wants to test or has runtime errors, grab http://dffd.bay12games.com/file.php?id=12184, and extract that zip into the same folder that you have DF 0.43.04 in.

EDIT 2: Here's the license from Microsoft on redistributing the DLLs in the runtime: http://go.microsoft.com/fwlink/?LinkId=524842

Yes, that set of libraries allows me to run DF.  I'm not seeing an error message on exit, but it does return exit code 5.

[Toady One]

Rebuilt SDL and everything still works as far as I can tell over here.  Fell back to old FMOD, turned off the fast incremental link option and managed to get SDL 64 bit working as well!  Shared saves between SDL64 and legacy32 back and forth without a problem.

Current plan:
(1) get rid of several platform-independent warnings/issues
(2) bundle up some windows test zips for people to mess with in here, while:
(3) the linux journey
(4) the osx journey

[LordBaal]

(5)Profit??

I for one, humbly volunteer to test it for Windows 10 Pro 64 bits.

[cesarjunior233]

I am getting the error : The program can't start because you not have api-ms-win-crt-runtime-l1-1-0.dll in your computer.

[Quietust]

I am getting the error : The program can't start because you not have api-ms-win-crt-runtime-l1-1-0.dll in your computer.

Install the Visual C++ Redistributable for Visual Studio 2015 for x86 (not x64).

[Toady One]

Here are the test zips for SDL Windows:

http://bay12games.com/dwarves/redist/df_sdl_32_wintest.zip
http://bay12games.com/dwarves/redist/df_sdl_64_wintest.zip

If you use the 64 bit one, it would probably be best to stay away from the bug tracker and just post strange problems in here.