macOS could anyone on 10.15+ check the availability of this header in Xcode?

[broly]

hi,

debating upgrading to catalina or something even higher.

however the lack of 32 bit GUI apps has me concerned an important header is removed after mojave:

#include <architecture/i386/pio.h>

could someone create an xcode project and see if this header still exists on 10.15++?

it says (on mojave) that it should be in 10.15 but i'd like to know if it's in monterey or big sur too:

thanks

 

[Red Menace]

That particular header still exists at least up to SDK 12 (Monterey), but any OS beyond Catalina will only support 64-bit.

 

[broly]

That particular header still exists at least up to SDK 12 (Monterey), but any OS beyond Catalina will only support 64-bit.

thanks for this.

i still don't understand what they mean in catalina by "64-bit GUI apps only" (assuming i use opencore).

the header i am inquiring about is *technically* 32 bit (i386) though i concede it's critical for many x86_64 operations.

since it's in the catalina sdk and presumably available, what does apple truly mean by "no 32 bit apps"? are they talking about **** like cocoa and other mac-related UI APIs?

 

[Red Menace]

... are they talking about **** like cocoa and other mac-related UI APIs?

The entire OS from the kernel up only supports 64-bit.

 

[broly]

but people with opencore can apparently use catalina and 32-bit non-gui apps? so what is this distinction? it must be the removal of 32 bit gui stufff?

 

[Red Menace]

As long as you don’t use a 64-bit OS (at all), you can use whatever the processor supports. Anything that uses a current OS (or any pieces of it) needs to be 64-bit, as the 32-bit support has been removed.

 

[casperes1996]

but people with opencore can apparently use catalina and 32-bit non-gui apps? so what is this distinction? it must be the removal of 32 bit gui stufff?

It means that your programs must be compiled against the 64-bit ABI. This means things like function calls placing the first arguments in RDI, RSI, RDX (etc.) instead of on the stack. (More than 6 arguments are still placed on the stack). You will not find 32-bit versions of dylibs so 32-bit compiled applications will not be able to load libraries for functions supporting the 32-bit calling convention. You cannot simply load a 64-bit library from a 32-bit application due to the difference in calling convention. And even if you could and the calling conventions matched more, you'd run into problems where, when calling a library function from a 64-bit application, and the function was from a 32-bit library, the callee-saved registers would not include the upper-32 bits as it would try to push the 32-bit version of the register to the stack not the 64-bit version of the register.

The header is not 32-bit specific. It defines functions that are available. As long as they are compiled against a 64-bit calling convention it's fine. In this case the header contains some in-line assembly, but the assembly is also agnostic to 64/32-bit compilation.
Consider it more as an "i386 or newer" thing.