On Sunday 03 May 2026 15:24:27 Jacek Caban wrote: > On 5/2/26 12:55, Pali Rohár wrote: > > On Saturday 21 March 2026 11:31 PM Jacek Caban wrote: > > > On 3/18/26 18:11, Pali Rohár wrote: > > > > > > > The point of those my changes was to provide the last missing time > > > > functions for x64 builds, so we would have all of them for all msvcrt > > > > builds on all windows versions. > > > > > > What is the value in it? > > For example running tests. > > > Those are synthetic tests and they do exactly what they are supposed to do: > fail for unsupported features, which is entirely expected. You can still run > them, you just don't seem to like the result ;-)
I mostly do not agree with this. mingw-w64 tests are useful, they are not "second category" synthetic code. We have tests to ensure that the mingw-w64 provides correct and consistent behavior. I think that tests have value and Kirill now tried to clean them too. Also tests are used to verify correct behavior for different Windows versions (even if there is no automated CI for older/different Windows version). > > > > > In my opinion those changes, including the documentation one, are rather > > > > small and isolated. > > > > > > The same can be said about hundreds of other functions. If we applied > > > that logic to all of them and accepted them, they would no longer be > > > small or isolated when taken together. > > There are not new hundreds functions in Win10 msvcrt.dll, just really > > few functions, and moreover without declarations in mingw-w64 header > > files. So I think that for those new functions cannot be used same logic. > > msvcrt.dll is just one of hundreds of system libraries. That claim does not > seem true even for msvcrt.dll alone. We already have a large number of > compatibility thunks, most of which have an actual reason to exist, or at > least had one at some point, that hide the difference. But I'm taking here about the msvcrt.dll which provides the C runtime API. Whole change is for CRT library, not for other system libraries. I agree that there are lot of other system libraries and those are bound with capability of the system. But msvcrt.dll is the core one which is not bound to the system as it has generic C API. > > > > So I think that it does not increase complexity of > > > > code compared with previous time function changes which were rather > > > > larger and I have not received from you negative feedback on it. > > > > > > Well, I would prefer to drop those changes as well, but I respect that > > > other maintainers have a different opinion. If you want my honest > > > opinion, I do not see any value in "improving" compatibility with > > > vintage OSes like this. I can understand the desire to have the basics > > > working so that someone doing software archaeology can use mingw-w64, > > > but we already have that. Going after every corner case to make it more > > > "compatible" with vintage OSes does not warrant any additional > > > complexity to me. > > > > > > > > > Jacek > > These functions are used in the mingw-w64 tests and without having > > symbols for them, it is not possible to run mingw-w64 test suite > > on XP x64 and therefore not possible to verify compatibility. > > > Well, maybe the test is the problem then. I could imagine having a macro > that specifies the minimum Windows version specifically for tests. Then > "fixing" the problem should be a simple #ifdef in tests. You could then just > pass an extra CFLAG when targeting a Windows version that is not supported > by the default test configuration. > > > Jacek > For example there are tests which are using mkstemp and mkdtemp functions which requires those symbols. These two functions are used also outside of tests by applications, just because they are useful and better than what is windows API providing. I have very simple changes which makes these functions working also on WinXPx64. So why not providing the required functionality to have them working and instead saying that it is a problem in a code which is using these functions. Why to complicate the whole testing environment and tests itself, which code should be compiled, which not, which to run, which not if the whole problem has simple solution, just provide the missing function and it will work everywhere? Also adding new and new thing with disabling code in the tests would lead to situation that the test would do nothing at the end. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
