随着关于Delphi团队致力于跨平台开发的所有讨论，一种不断涌现的观点是，“我希望他们这次做得对，不像Kylix。”我没有真正注意到Kylix何时出现，因为当时Linux并不像现在那样成熟，而且它不是我感兴趣的操作系统。所以现在它又开始成为一个问题，我发现自己在想，Kylix做错了什么，这次CodeGear怎么做得更好呢？
答案 0 :(得分：9)
这次CodeGear能做些什么做得更好：
需要一种更抽象的方法来在对话框中布置控件，而不是VCL现在使用的基于像素的东西。这已经在具有高DPI设置或非标准字体的Windows上出现故障，对于多平台程序来说会更糟糕。以sizer classes in wxWidgets或GTK，Java或QT中的布局类/管理器为例 - 它们在更改字体或控件大小方面都做得更好。作为另一个优点，它可以透明地控制对象中的翻译文本更短或更长。
仅使库成为Unicode。理想情况下会有一个特殊的字符串类，在Windows内部使用UCS-16，但在Linux和Mac OS X上使用UTF-8。程序应该能够使用平台本机Unicode编码，而不是强制转换为每个文件系统访问或屏幕输出。但也许他们已经通过Delphi 2009的Unicode字符串更改将该球丢弃了。
GUI应该在所有平台上使用本机控件，以便正确看待和。那将是Windows上的标准控件，Mac上的Cocoa，以及Linux上理想情况下应该使用GTK或QT，具体取决于桌面是GNOME还是KDE。
远程调试器需要成为一流的工具，而不是现在的错误和半隐藏的东西。不同平台的开发经常发生在虚拟机中，有时只能远程访问机器。
答案 1 :(得分：8)
Kylix有两件事正在反对它：桌面上普遍接受的Linux还没有，而Kylix本身也非常昂贵。投入Kylix的质量问题（特别是第一版），你就得到了答案。
如果CodeGear想在Linux上做另一个版本的Delphi，他们应该只看Lazarus。
答案 2 :(得分：6)
我当时（现在仍然）在Free Pascal Unix RTL上工作，在Kylix之前在* nix上做了Pascal，我们从第一个测试版开始就密切关注它。所以可以说我对Kylix的兴衰有一个很好的独特观点。
一个主要的问题是它不适合服务器应用程序使用，当时人们在Linux上做的主要事情，但恕我直言，并没有解释失败。
虽然存在各种其他问题（Wine，部署，非常以Linux / x86为中心，因此难以移植到“下一个”* nix，Borland没有足够推动它），我仍然认为Kylix失败的事实更多当时Linux的困境证明了Kylix问题的直接结果。其中一些（如长期二进制API稳定性）尚未得到修复。
仍然应该有效恕我直言，因为它显然领先于其余部分，并且可行，如果需求确实在那里，人们会加强（有些人，我们仍然会在转换大型Kylix代码库的FPC列表上获得每月人员。）
面向服务器的版本可能受到了更大的打击，并且他们在单一来源的东西上做得太过强烈（这错误地提出了期望），但仍然是GUI原则，因为它应该有效，恕我直言，我责怪Linux和Linux市场。太快了，市场太炒作了，还没准备好在Windows模型之后实现商业化。
答案 3 :(得分：3)
在我看来，去跨平台本土＆amp; amp;托管（VM）对Delphi有好处;但是有一些问题需要在实施前仔细考虑。 （通常Turbo Pascal版本是，IMO ......虽然Delphi语言的一些补充不是;例如，你不能声明接口中的属性只能被读取和/或写入而不会声明什么属性的来源是一个必须在接口中声明的字段或方法.IE是一个好主意......但是他们忘了完全分离接口/实现。）
所以，IMO，我们需要的是：
1 - VCL- / TurboVision- / GeneralPurpose类库，旨在独立于平台。 （对于面向对象的层次结构，VCL确实是一个很好的例子;就像当时的turbo-vision一样......电视引入和使用流也很有趣。）所以，重申：
a）一个良好的面向对象的可见组件层次结构......也许还包含比当前像素更多的“百分比”/相对/矢量图形方案。 （从而补偿屏幕分辨率差异。）
b）“知道”如何初始化和释放其包含对象的对象（虽然指向对象的指针将被免除，因为我们希望能够“共享”对象），因此设置构造函数以初始化并且不需要用于释放所包含对象的析构函数。 {IE，优化常见案例。}
c）应该实现像TList，TStringList等非可视组件......尽管添加了ADT，例如Stack，Queue，PriorityQueue，Heap，Tree＆amp; B树。但是，作为个人要求，我们可以将它们设为1而不是0吗？我问这个问题是因为在搜索它们时，如果使用无符号数字，那么将0找到“未找到”并将正数作为索引就更好了，这与ShortStrings的风格非常相似。这也有一个好处，就是不要将最大允许大小限制的一半切断为使用带符号的数字。
d）对象应该能够在尽可能低的水平上发送和发送/删除自己到流中，以便在另一端重建。 {也许很难实施;但是TurboVision API通过其注册方案来实现它...使用RTTI它应该会更容易。}
e）前面提到的ADT还应该有一个镜像通用接口heirchy，这样像TStringList这样的东西会给你一个字符串列表，其匹配的对象属性是TIntergerObject类型的对象。
f）容器类型，如堆栈或StringList也应该知道它们包含的类型;以及它们是否是同质的。
g）非可视对象树上的一个解析器 - 对象子树，它是可继承和通用的（可能就是“吃掉”BNF并相应地解析输入......一个巨大的项目本身。
我知道这是一项艰巨的任务，而且还有很多工作要做。然而，收益也是巨大的。 JVM可以是一个Stack对象和一个解析器对象，它将源代码转换为要推送到堆栈的适当对象...... Forth编译器/解释器可以用几个堆栈和一个Forth解析器对象以相同的方式实现。您显然可以看到它的领先地位：在基础上拥有一个多功能和通用的ADT库，并在构建框架的基础上，RAD工作室的下一次迭代可以一举成为.NET的“任何语言”的竞争对手想法，但也为后端的多个archetectures。 （是的，有调整大小和字节序问题，但高级语言的想法是将程序员从这些问题中移除，除非他特别关注它们;通过保留Delphi的Byte，Integer，可以很好地解决这些问题， LongInt大小稳定，因为它当前是[当需要依赖于机器的类型/大小时可能使用NativeInteger，NativeLongInteger等]并且让文件的TStream-descendant对象处理存储和检索Delphi- / RAD-native应用程序数据并从格式需要特定字节序的那些派生出来。）
答案 4 :(得分：1)
我第一次出来时买了Kylix - 它跑得很慢，看上去很笨，实际上只支持几个特定版本的Linux。坦率地说，那里有更好的Linux工具。但我认为，任何人都可以越来越难以通过销售开发工具来赚钱，无论平台如何 - 免费替代品都非常好。
答案 5 :(得分：0)
试图为那些过去免费获得工具和软件的人收取600美元可能不是一个明智的决定！
答案 6 :(得分：0)
他们在许多不同的发行版品种上创建可靠的部署也遇到了很多麻烦。
答案 7 :(得分：0)
我讨厌Kylix和VCL for Web（Intraweb）的是它们的组件看起来像标准组件....
VCL本身非常通用（除了句柄）...所以我想拥有相同的源代码，相同的pas，dfm，dpr ....并通过选择编译器选项选择要构建的平台对于具有相同源文件的每个平台，或者甚至具有不同的dprs。
答案 8 :(得分：-1)
Linux尚未准备好处理商业级软件。最值得注意的问题是缺乏二进制兼容性。它应用了，它现在仍然适用。
Danny Thorpe，Delphi / Kylix R＆amp; D，在2001年写了一篇情绪化的文章：
Problem: Linux Libraries Can't Fail