delphi的ARM架构支持与System.Win.WinRT库
目录
delphi的ARM架构支持与System.Win.WinRT库
2.3、所以使用默认库而未经转化的服务端应用并不支持ARM架构服务器
2.4、对默认库的调用经System.Win.WinRT类型转化后服务端应用应该可以支持ARM
2.5、服务端应用若不使用默认GUI图形用户界面应该也可以支持ARM服务器
喜欢的，就收藏并点个赞，鼓励我继续技术的原创写作及经验分享：
随着ARM架构云服务器的愈加火爆，delphi和C++ Builder在MSWindows平台下，有无简单实用的技术借鉴，值得研究。
一、WinRT
是微软在win8时代，开始研发的专门用来支持ARM架构芯片的独立的操作系统(不单独售卖，只提供OEM或在自己的surface平板、移动设备等中分发)。2023年1月10日起结束支持。
二、delphi的System.Win.WinRT库
WinRT虽然是微软的一个失败项目，但其技术，仍然值得使用和借鉴。
2.1、支持ARM芯片指令
通过调用WinApi.WinRT提供对基于WinRT的ARM芯片指令的支持。
2.2、基于WinRT技术的特点
检索微软官网，会发现：
不直接走“Win32”的API ，而是与Win32、.Net“并列”的一个架构，但“内核”同样是Winapi.Windows：
通讯：
- 整数统一用HString类型的序数范围
- Win32（0..4294967295）:THandle = NativeUInt; //(0..2^32-1)
- Win64（0..18446744073709551615）:THandle = NativeUInt;//(0..2^64-1)
- 字符串需要通过TWindowsString结构体和HString整数之间进行转化
- 字节序列化范围支持：s1,s2,s3,s4,s5,s6,s7,s8,s9,s10及其子集
- WinRT类有其独立的签名，进行类的属性存储：WinRTClassNameAttribute.Signature;
- 签名不同，数据包的SizeOf内存空间就会是不同数值的字节
- {$IF defined(LINUX) or defined(MACOS) or defined(ANDROID)}
- Syetem.ModuleCacheID()得到的模块缓存的签名不同。因而不转化类型信息，跨ARM架构就一定出问题。
- 所有WinRT运行时的类型信息及其上下文Context的导入基类及其帮助类：TWinRTImport、TWinRTImportHelper
- RO指令支持单线程和多线程
- WinRT依赖的相关API：Winapi.WinrtMetadata（WinRT元数据RO指令）、Winapi.CorHdr（定义运行时结构、需要使用的元数据）、Winapi.CorError、Winapi.Cor（Windows内核）、Winapi.CommonNames（Windows API的通用命名）
- WinRT的全部注册表位置：Software\Microsoft\.NETFramework
- 由此可见，它在设置时，就被定义为.NETFramework下的子集；后续技术延续，取决于.NETFramework的技术延续。
var
RoInitType: RO_INIT_TYPE = RO_INIT_MULTITHREADED;
type
RO_INIT_TYPE = (RO_INIT_SINGLETHREADED, RO_INIT_MULTITHREADED);
/// <summary>Base Delphi object needed for Windows Runtime classes. Implements IInspectable interface</summary>
//Windows运行时类所需的基本Delphi对象。实现IInspectable接口：
TInspectableObject = class(TInterfacedObject, IInspectable)
protected
FIIDS: array of TGUID;
public
/// <summary>Gets the interfaces that are implemented by the current Windows Runtime class</summary>
//获取由当前Windows运行时类实现的接口：
function GetIids(out iidCount: Cardinal; out iids: PGUID): HRESULT; stdcall;
/// <summary>Gets the fully qualified name of the current Windows Runtime object</summary>
//获取当前Windows运行时对象的规范命名空间：
function GetRuntimeClassName(out className: HSTRING): HRESULT; stdcall;
/// <summary>Gets the trust level of the current Windows Runtime object</summary>
//获取当前Windows运行时对象的信任级别：
function GetTrustLevel(out trust: TrustLevel): HRESULT; stdcall;
end;
/// <summary>Helper needed to automate life cycle of HSTRING type and conversions from/to string</summary>
//自动化HSTRING类型的生命周期和（从/到）字符串的转换所需的助手
TWindowsString = record
strict private
type
TWindowsStringNexus = class(TInterfacedObject)
private
FString: HSTRING;
public
constructor Create(AString: HSTRING);
destructor Destroy; override;
end;
PWindowsString = ^TWindowsString;
private
FNexus: IInterface;
FHandle: HSTRING;
FValid: Boolean;
public
constructor Create(const S: string); overload;
/// <summary>Checks that the internal HSTRING was created successfully</summary>
//检查内部HSTRING是否已成功创建：
property Valid: Boolean read FValid;
class operator Implicit(const S: TWindowsString): HSTRING; inline;
class operator Explicit(const S: string): TWindowsString;
/// <summary>Gets the string representation of the given HSTRING</summary>
//获取给定HSTRING对应的字符串：
class function HStringToString(const hs: HSTRING): string; static;
end;
2.3、所以使用默认库而未经转化的服务端应用并不支持ARM架构服务器
2.4、对默认库的调用经System.Win.WinRT类型转化后服务端应用应该可以支持ARM
就类似FMX和VCL在相应的跨客户机平台上的受支持一样。
2.5、服务端应用若不使用默认GUI图形用户界面应该也可以支持ARM服务器
三、服务端跨ARM
从上述分析，服务端的应用支持ARM架构芯片设备，基本可以得到的如下启发：
- 只要服务器设备及其ARM芯片提供商，公开了指令集RO；RW、ZI
一个ARM程序包括三个段：RO，RW，ZI。
RO是指程序中的指令和常量：eg：指令如if else等，常量如 const char a = 0，#define AA 10等；
RW是程序中的已初始化的变量：eg：int a = 10；
ZI是程序中未初始化的变量：eg：int a；这三点可以理解为：
RO就是read only；
RW就是read/write；
ZI就是zero initial；
- 借鉴System.Win.WinRT库的处理方法成功导入指令集
- 实现对整数和字符串类型的I/O的上述转化（参考System.Win.WinRT库的处理方法）
理论上讲，就应该能够成功跨ARM，完成服务端应用的迁升，这种方法应该是“通用”的、不依赖任何三方库、语言版本的差异的。
喜欢的，就收藏并点个赞，鼓励我继续技术的原创写作及经验分享：
window及DOS专栏：
https://blog.csdn.net/pulledup/category_9605480.html
window专栏：
https://blog.csdn.net/pulledup/category_9299987.html