Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I just tried switching to using STLport for an app that must run on Windows 95. It ran fine on other Windows OSs, but it immediately crashed on Windows 95. I did some debugging and discovered that the crash occurs during static initialization. At that time, a _Locale_impl is constructed with a call to _Locale_impl::Init. That function seems to be checking a static reference count to see if it is 1, to call _Locale_impl::_S_initialize() only once. On Windows, the reference counter uses the functions InterlockedIncrement and InterlockedDecrement (_threads.h). These functions actually have different behavior on Windows 95 than on all later versions of Windows. On Windows 95, instead of returning the actual reference count, they only return -1, 0, or 1, depending on whether the result is negative, zero, or positive. So incrementing the reference count was always returning 1, so _Locale_impl::_S_initialize() would always be called. Inside of _Locale_impl::_S_initialize(), another _Locale_impl is constructed, leading to infinite recursion and a stack overflow. Is Windows 95 a supported platform for STLport? If not, is there an official list of supported platforms?
To have an idea about supported platform you should take a look to build/test/unit/STATUS. There is no status about Windows 95 in it...
This difference in behavior is surprising and not documented in MSDN. Are you interested in a fix ?
Older versions of MSDN have a note about this behavior, but it looks like Microsoft removed it. There is a good description of the issue at http://blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx. I'm very interested in a fix, and would be able to test it and give feedback. I am also willing to propose/submit a fix if that would be helpful.
I also found information about this Windows 95 limitation, maybe it is the same source as yours as it is directly accessible with a simple google research.
I have already committed a fix in SVN trunk. If you validate this version fast enough I will integrate it to STLport 5.1 branch so that it is part of next 5.1.1 version. You should certainly already know but just in case, do not forget to define _WIN32_WINDOWS or WINVER macro to 0x0400 value so that STLport know that you are building for Windows 95.
Thanks for getting in a fix so quickly. I just finished running the unit tests and they pass on Windows 95. When will the next release be out?
I expect to release 5.1.1 at beginning of february. I hope you will have time to make some tests.
As I stated before, the unit tests built from the trunk pass on Windows 95. It looks like these changes haven't been ported to the 5.1 release branch. Is this still possible?
Yes it is possible, I will.