Windows support

[Piloalucard]

Summary of changes

This pull request includes following changes or fixes.

• Compatible code with Microsoft Visual C++ Compiler
• Support of Windows Server 2022
• Support of Windows Server 2025
• Support of Windows 11

Description

Code was updated to be compatible again with Windows platform. Microsoft mandates compilation with Microsoft tools to give support, with that said the code needed to be compatible with Microsoft Visual C++ Compiler for a new version to be built.
Macros we're added to comply with this and change the behavior depending on which platform the project is being built.

Type of change

• Refactoring
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have confirmed my fix is effective or that my feature works

[piste-jp]

I would like to notify this comment in advance before this PR goes to compilable...

I know you are working so hard on this PR and also I know you want to support windows again in the IBM storage archive product. But I must strongly disagree to this PR. Because this PR has no benefit to the normal open source users who are using the code in this repository. On the other hand code change is big and impact of the readability of codes are really big.

I have so many comments and complains but top-3 of my comments are

First, please don't introduce crossbuild directory easily. This kind of architecture specific code is handled under libltfs/arch directory. Please follow this as much as possible.

Second, please don't use SAFE_ prefix in the macros in commons.h. Frankly I cannot understand what does SAFE_ means. I believe they are "safe" only in windows environment for for Linux/Mac/BSDs env. I don't recommend that we use the C++11/C99 "Annex K" functions because of its history, they are optional and they are not supported in the glibc yet. What is the problem that LTFS uses current ANSI C standard functions on windows env? I strongly recommend that you need arch_ prefix and design glue layer carefully like thread handling in LTFS, see src/libltfs/ltfs_thread.h carefully.

For example, SAFE_FOPEN looks only safe for windows. And SAFE_WRITE cannot be understand what is "safe" at all.

Last, please write macros to keep the C language context. I believe macro feature can easily ruins the C language context and create new your own langage. But this project is clearly written by C please do not corrupt the readability for C developers. I strongly recommend that you need to use inline function as much possible, that is a reason taht we choose C99.

For example, this macro call confuses C developers in short period. They don't think conf_file is output of function (macro) at a glance. Of course, they can understand soon, but that small thinking time reduces the readability totally.

SAFE_FOPEN(path, "rb", conf_file);