两周前更新的新版本CrossKylix。

甚至 Kylix 早就停止了，但它似乎仍然被一些 Delphi 开发人员使用。

有没有人成功地将它用于 Windows 和 Linux 的跨平台开发？

我最近一直在阅读有关 CrossKylix 的文章，但对于大多数用途，必须考虑第 3 方组件。所以我想知道哪些积极开发的组件仍然支持 Kylix。

许多人在当天添加了部分或完整的 Kylix 支持，但我担心有些人从未保持更新，并且使用 Kylix 编译的 IFDEF ed 部分可能没有经过测试。

所以，理想情况下，我想要一份来自那些拥有真实应用和实践经验的人的报告。

这对于期待已宣布的 Delphi 未来跨平台版本的用户以及当前的 Kylix/CrossKylix 用户可能会感兴趣。

Sourceforge 的 Synmemo似乎是非常好的 txt 编辑器和代码荧光笔。可惜很久没有升级了。这是一个纯粹的vcl。我想知道它的最大长度是多少。它可以加载的最大 txt 文件是多少？

谢谢

这两个控制台应用程序包括一个使用 bmThreadBlocking 模式的 TTcpServer 的套接字服务器和一个使用 bmBlocking 模式的 TTcpClient 的套接字客户端。TTcpClient 旨在连接到服务器，发送一条线路，然后断开连接。TTcpServer 旨在侦听传入的连接，并回显在其 OnAccept 事件处理程序中收到的行。

这两个控制台应用程序在 Windows（XP 和 7）中运行良好。但是，当我直接使用 CrossKylix 或 Kylix 编译它时，应用程序无法在 Linux（SuSE 10.0 和 CentOs 5u7）中按预期运行。只要一个客户端连接，即在 TTcpServer 的 OnAccept 事件处理程序之内/之后，服务器应用程序就会立即获得“[1]+ Stopped ./TestSocketServer_1_Console_Native”。你能帮忙评论一下这个问题吗？任何帮助将不胜感激！

这两个控制台应用程序可以在http://www.multiupload.com/9HIIG61W93下载

为方便起见，源代码也粘贴在这里。（端口号 98765 或 1876 或其他数字没有帮助。）

TestSocketServer_1_Console_Native

TestSocketServer_1_Console_Native.dpr

uServerDataModule.pas

TestSocketClient_1_Console_Native

TestSocketClient_1_Console_Native.dpr

uClientDataModule.pas

这个简单的 CLX 应用程序尝试将 TMemo 的字体系列设置为固定宽度字体：

1. 使用在本地 Linux 机器上运行的 Kylix 3 编译的应用程序可以正确对齐。

2. 使用在本地 Windows 框中运行的 Delphi 7 编译的应用程序给出了正确的对齐方式。

3. 使用运行在远程 Linux 和 Windows XServer 上的 Kylix 3 编译的应用程序没有正确对齐。

4. 使用运行在远程 Linux 和 Mac Lion XServer 上的 Kylix 3 编译的应用程序没有正确对齐。

你能帮忙评论一下如何解决这个问题吗？任何评论将不胜感激！

uMainForm.pas

uMainForm.xfm

我继承了一个有许多问题的程序。最新的一个是太多实际参数警告：

粗体部分是错误突出显示的地方。

注意：该程序有效，只是不在我的机器上。它是使用相同版本的 Delphi (7) 开发的，但在 clx (kylix) 环境中。我想我（可能）已经解决了 clx 和 vcl （我当前的环境）之间的所有不兼容问题，但可能是我缺少一个生成此错误的组件。我会尽力澄清任何问题，但请记住，我开发 Delphi 才几个月。

我在 Delphi 7 应用程序（CLX）中遇到了内存泄漏问题，代码如下：

fsPrinter即使在主窗体（TForm）关闭时释放对象结果也会泄漏：

这是 FastMM4 的泄漏报告：

在这里，您可以下载代表问题的项目的完整SSCCE示例（单击按钮运行示例并关闭表单）。

为什么fsPrinter对象泄漏？我怎样才能避免泄漏？

我在 Delphi 7 中维护了一个应用程序，它有一个可以用 CrossKylix 编译的服务器部分。对于性能问题，我正在测试多线程和关键部分的使用。

我制作了一个控制台应用程序，它创建了 100 个 TThread，每个 TThread 计算一个斐波那契。然后我添加了一个临界区，以便一次只有一个线程计算斐波那契。正如预期的那样，如果没有关键部分，应用程序会更快。

然后我制作了一个控制台应用程序，它创建了 100 个 TThread，每个 TThread 在本地 TStringList 中添加单词并对该 TStringList 进行排序。然后我添加了一个关键部分，以便一次只执行一个线程。在 Windows 上，正如预期的那样，应用程序在没有关键部分的情况下运行得更快。在 Linux 上，CriticalSection 版本的运行速度比没有 CriticalSection 的版本快 2 倍。

Linux 上的 CPU 是具有 6 个内核的 AMD Opteron，因此应用程序应该受益于多线程。

有人可以解释为什么带有关键部分的版本更快吗？

编辑（添加一些代码）

线程创建和等待

TThread 和临界区使用

编辑 2

我读了这个为什么使用更多线程使得它比使用更少线程慢，所以据我了解，Linux 和 Kylix 编译的上下文切换比 win32 的上下文切换花费更多的 CPU 资源。

我们有一个基于 Borland Kylix C++ 构建的应用程序。该应用程序仍在使用中，我们维护了一个安装了 Kylix IDE 的 Red Hat 9 虚拟机以继续其开发。我们知道它已经很老了，但有一段时间这是我们的选择。

在 Fedora 21 之前，我们可以毫无问题地运行这个应用程序，但是在这个新版本中，我们的库无法加载，导致分段错误错误。

那是简单地加载库的测试程序：

libX.so 是用 Kylix C++ 构建的。执行时发生错误dlopen。我们不需要加载方法或执行方法来获取错误。使用 strace 分析错误，我们得到：

这libborunwind.so是一个 Kylix 运行时库，所以我们没有源代码来查看发生了什么。似乎旧的 Kylix 库与 Fedora 21（libc 等）的新库不兼容。

有没有办法在最近的 Linux 发行版中运行旧的编译代码？

以下程序尝试使用 AnsiCompareStr/Text：

当用 Kylix 编译时，它在 CentOS 5/6 x64 上输出错误的结果：

我想知道为什么 AnsiCompareStr/Text 给出错误的结果？

PS：根据http://www.delphibasics.co.uk/RTL.asp?Name=CompareStr，CompareStr被认为是过时的。根据http://www.delphibasics.co.uk/RTL.asp?Name=AnsiCompareStr，AnsiCompareStr被认为是现代的、区域设置安全的 CompareStr 形式。

PS：语言环境是 en_US.iso885915 和/或 en_US.UTF8

PS：Kylix 3（作为带有 CrossKylix 的 Delphi 7）