added inline assembly to patch the problem

[lamosekm]

This pull request addresses a build issue with OpenSSL on Visual Studio versions prior to 1929 (VS2019). The problem was that older MSVC versions lacked inline assembly implementations for certain interlocked functions, namely InterlockedAdd64, InterlockedOr64, and InterlockedAnd64.

The proposed changes introduce:

• Inline assembly code to provide InterlockedAdd64, InterlockedOr64, and InterlockedAnd64 functions.
• A conditional preprocessor directive to check for MSVC versions prior to 1929 and define the inline keyword as __inline for compatibility.
• A definition for InterlockedOr to be _InterlockedOr, ensuring consistent function naming across different versions of MSVC.

These changes ensure that OpenSSL can be built using older versions of the MSVC compiler, thus maintaining backward compatibility, especially for systems that still rely on older development environments.

Testing:

The changes have been compiled and tested on Visual Studio 2017, confirming that the build succeeds without errors and the functions perform as expected. The inline assembly has been written to be compatible with the calling conventions and requirements of the older compilers.

By merging this PR, OpenSSL will gain improved compatibility with projects that must maintain legacy systems.

[lamosekm]

@bbbrumley hey professor, here is my first Software Engineering Assignment. I still need to do one more to make up for those 3 missed quizzes from that one week. I will begin working on that shortly. This was a first for me, so apologies if some of it isn't 100% correct. Thanks, Mitch.

[nhorman]

Is this going to work for 32 bit windows platforms? I feel like it might be safer for older platforms to use the fallback approach that pthreads uses (i.e. using an internal mutex)

[t8m]

We will need CLA submitted to be able to take this contribution. https://www.openssl.org/policies/cla.html

[bbbrumley]

This is somehow related to #24209 right?

[tom-cosgrove-arm]

Actually, I don't think we should accept this PR. It's not just that the commit message "added inline assembly to patch the problem" needs re-writing, but as @bbbrumley notes, the body of the commit (the assembly) is copied directly from #24209 without attribution to the original author @yjh-styx. Only whitespace and comments have been changed. Unless @lamosekm and @yjh-styx are the same person, this is not acceptable to my mind.

(Once a PR has been merged, the original author's name is associated with that code in git, and changes to comments and whitespace can be accepted separately. Offering up someone else's work ostensibly as one's own is definitely not acceptable, and the author of this PR makes no reference to the original PR where the assembly comes from.)

[t8m]

Closing this.