Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for including SDL3 headers in older toolchains #11900

Merged
merged 3 commits into from
Jan 9, 2025

Conversation

madebr
Copy link
Contributor

@madebr madebr commented Jan 9, 2025

With these patches, I can successfully use the SDL3 headers with MSVC 6 (from 1998).

Description

Existing Issue(s)

@icculus icculus merged commit ebaa30d into libsdl-org:main Jan 9, 2025
40 checks passed
@icculus
Copy link
Collaborator

icculus commented Jan 9, 2025

Let's have the headers automatically define SDL_NOLONGLONG if _MSC_VER <= whatever Visual C++ 6.0 sets it to.

@sezero, I assume Watcom has "long long", right?

@sezero
Copy link
Contributor

sezero commented Jan 9, 2025

@sezero, I assume Watcom has "long long", right?

Versions of it that matter (e.g. >= 1.9, maybe even older) do.

@sezero
Copy link
Contributor

sezero commented Jan 9, 2025

@sezero, I assume Watcom has "long long", right?

Versions of it that matter (e.g. >= 1.9, maybe even older) do.

E.g.: The Makefile.w32 in sdl2-compat has been working since
the beginning using ow1.9

@madebr madebr deleted the use-SDL3-in-MSVC6 branch January 9, 2025 21:46
@madebr
Copy link
Contributor Author

madebr commented Jan 9, 2025

About the introduction of __debugbreak and _BitScanReverse, I asked ChatGPT about this.
I hope it was not hallucinating..

I also don't know what MSVC version introduced long long, ChatGPT thinks it was 2010 so SDL_NOLONGLONG should be defined for _MSC_VER < 1600

@sezero
Copy link
Contributor

sezero commented Jan 9, 2025

I also don't know what MSVC version introduced long long,

vs2005, at least, has it, if I recall correctly

@icculus
Copy link
Collaborator

icculus commented Jan 10, 2025

Random webpage I found said VS2013, but that seems way too late.

So now I'm bisecting it. :)

image

@icculus
Copy link
Collaborator

icculus commented Jan 10, 2025

Visual Studio.NET 2003 is the first to support it. _MSC_VER == 1310 (decimal, not hex).

icculus added a commit that referenced this pull request Jan 10, 2025
@madebr
Copy link
Contributor Author

madebr commented Jan 10, 2025

While you maybe still have the old toolchaibs set up, are the minimum versions I used for _BitScanReverse and __debugbreak correct?
Should we have an asm { int 3 } implementation for older x86 msvc?

@sezero
Copy link
Contributor

sezero commented Jan 10, 2025

About the introduction of __debugbreak

Maybe add the following for old MSVC versions? (not tested)

--- SDL_assert.h~
+++ SDL_assert.h
@@ -131,6 +131,8 @@
     /* Don't include intrin.h here because it contains C++ code */
     extern void __cdecl __debugbreak(void);
     #define SDL_TriggerBreakpoint() __debugbreak()
+#elif defined(_MSC_VER) && defined(_M_IX86)
+    #define SDL_TriggerBreakpoint() { _asm { int 0x03 } }
 #elif defined(ANDROID)
     #include <assert.h>
     #define SDL_TriggerBreakpoint() assert(0)

@icculus
Copy link
Collaborator

icculus commented Jan 10, 2025

Go ahead and commit it, if someone actually reports it failing on Visual C++ 6.0, we'll fix it as the highest priority. :)

@sezero
Copy link
Contributor

sezero commented Jan 10, 2025

Go ahead and commit it,

Done as 61f13b9

if someone actually reports it failing on Visual C++ 6.0, we'll fix it as the highest priority. :)

Yes, with very most highest priority :))

@madebr
Copy link
Contributor Author

madebr commented Jan 11, 2025

On unknown platforms, SDL_TriggerBreakpoint currently becomes a no-op.

#else
/* How do we trigger breakpoints on this platform? */
#define SDL_TriggerBreakpoint()
#endif

I think this might surprise people.
Would it be bad if SDL leaves SDL_TriggerBreakpoint undefined and trigger a compiler error?
This also allows users to define SDL_TriggerBreakpoint themselves.

@slouken
Copy link
Collaborator

slouken commented Jan 11, 2025

On unknown platforms, SDL_TriggerBreakpoint currently becomes a no-op.

#else
/* How do we trigger breakpoints on this platform? */
#define SDL_TriggerBreakpoint()
#endif

I think this might surprise people. Would it be bad if SDL leaves SDL_TriggerBreakpoint undefined and trigger a compiler error? This also allows users to define SDL_TriggerBreakpoint themselves.

Good point, let's remove that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants