原因 TIdBytes $ c $在早期的Indy 10版本中，c>是 TBytes 的简单别名，主要是为了兼容 SysUtils.TEncoding ，它使用 TBytes 。 Indy的 TIdTextEncoding 类型曾经是D2009 +中的 SysUtils.TEncoding 的简单别名，所以 TIdBytes 需要是一个简单的别名， TBytes 才能匹配。

然而， TBytes 在XE3中对Indy造成了相当大的麻烦，主要是因为Genericics的RTTI问题（ TBytes 是一个简单的别名最近Delphi发行版中的 TArray< Byte> 所以，Indy 10.6重新设计了 TIdTextEncoding ，不再依赖于 SysUtils.TEncoding （还有其他原因这样做），然后允许 TIdBytes 更改为自己的数组类型，以避免XE3问题向前发展。

另一方面，您正在传递一个 TBytes ，其中一个 TIdBytes 是预期的，所以首先，您不遵循Indy定义的界面，您的部分编程不佳。所有Indy 10的基于字节的操作，包括 ReadBytes（），始终在 TIdBytes 上运行。 TIdBytes 默认映射到 TBytes 的事实是您不应该在代码中依赖的实现细节。 Indy 10期望 TIdBytes ，所以使用 TIdBytes ，那么你不会有不兼容类型的编译器错误。

Today I try to compile my XE3 project in XE4. First problem that I face is with Indy's FTCPClient.Socket.ReadBytes() method.

Before it was accepting TBytes type, now it insists on TidBytes.

Definitions: TIdBytes = array of Byte; TBytes, Im not sure I guess it is generics something like TArray which is array of Byte.

Question number 1: Why does compiler complain by saying that'[dcc32 Error] HistoricalStockData.pas(298): E2033 Types of actual and formal var parameters must be identical'. As I see they are already identical.

Question number 2: Should I modify my source code with the each new delphi version?

Thanks.

The reason TIdBytes was a simple alias for TBytes in earlier Indy 10 releases was primarily for compatibility with SysUtils.TEncoding, which uses TBytes. Indy's TIdTextEncoding type used to be a simple alias for SysUtils.TEncoding in D2009+, so TIdBytes needed to be a simple alias for TBytes to match.

However, TBytes caused quite a bit of trouble for Indy in XE3, mainly because of RTTI problems with Generics (TBytes is a simple alias for TArray<Byte> in recent Delphi releases). So, Indy 10.6 re-designed TIdTextEncoding to no longer rely on SysUtils.TEncoding at all (there were other reasons as well for doing so), which then allowed TIdBytes to change into its own array type in order to avoid the XE3 issues moving forward.

On the other hand, you were passing a TBytes where a TIdBytes was expected, so that is bad programming on your part for not following Indy's defined interface in the first place. All of Indy 10's byte-based operations, including ReadBytes(), have always operated on TIdBytes only. The fact that TIdBytes silently mapped to TBytes was an implementation detail that you should not have relied on in your code. Indy 10 expects TIdBytes, so use TIdBytes, then you would not have compiler errors about incompatible types.