Linux 上的 Delphi 应用程序的最佳解决方案是什么 - Delphi+Wine 还是 Lazarus？
我需要在 Linux 上使用我的 Delphi 解决方案，并且我已经在 Wine 和 Lazarus 上测试了它们。 从长远来看，我应该考虑哪些技术因素（编程、部署、维护等），以避免陷入维护噩梦。 我保持我的 Windows 组件使用相当标准，以避免跨平台开发的复杂性。 我正在寻找一些超越主观的确凿事实。 我不想考虑 .Net/Mono，因为这会让我立即倒退（上市的巨大延迟），这是我无法承受的。
我可以想到一些：
- Lazaraus 可能需要一些（更改）编程才能使代码正常工作。
- 葡萄酒是一个更难以维持大量客户群的环境。
我们将非常感谢您对此做出的贡献。
I need to make my Delphi solutions available on Linux and I have tested them on both Wine and Lazarus. What are the technical considerations I should take into account (Programming, Deployment, Maintenance etc.) on the longer term in order to avoid landing in a maintenance nightmare. I keep my Windows components used pretty standard to avoid complexities that may develop on cross-platform. I am looking for some hard facts that should go beyond being subjective. I do not want to consider .Net/Mono because this will set me back immediately (Huge Delay to market) which I cannot afford.
I can think of some:
- Lazaraus may require some (changes) programming to make code work.
- Wine is a more difficult environment to maintain at a large base of customers.
You contribution on this would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我想说那里没有黄金法则。 这实际上取决于 Lazarus 支持您使用的组件的数量。
我会开始用 lazarus 进行测试，并保留 Wine 作为备份，以防万一你绝望了。
仍然非常模糊（他们只是“看看”，但同时他们将 64 位的推出抹去了两个完整版本，因此即使取得进展，也可能需要相当长的时间）
Codegear计划 让我觉得Apple版本将使用QT，而不是原生api。
更新：快4年了，仍然没有Linux支持。 树木长得更快。
I would say there is no golden rule there. It will really depend on how much of the components you use are supported with Lazarus.
I'd start testing with lazarus and keep Wine as a backup in case you get desperate.
The Codegear plans are still very vague (they are only "looking at it", but at the same time they smear the 64-bit rollout over two full versions, so even if this makes progress this could take quite a while)
The quick timeline makes me think that the Apple version will use QT, not native apis.
Update: nearly 4 years, and still no Linux support. Trees grow faster.
我不同意这里其他人的观点，并建议您使用 Wine。 Google 正在为 Picassa 提供 Wine 安装，您也可以做同样的事情。 它们不依赖于发行版安装的版本，而是在程序目录中拥有一个预配置的副本，并且具有您可以测试的已知版本。
基本上，您只需要询问本机端口可以提供哪些 Wine 包装器不能提供的功能。 对于大多数 Delphi 应用程序来说，答案可能就是主题，除此之外别无其他。 我们制作了一个本机端口，以便我们可以在较低级别访问文件系统，但在此之前，我们的产品在 Wine 上几乎完美运行了多年。
从经验来看，本地端口并不是在公园里散步：
I have to disagree with everyone else here and suggest that you use Wine. Google is shipping Picassa with a Wine install and you could do the same thing. Rather than relying on the version installed by the distro they have a copy in the program directory that's preconfigured and has a known version that you can test against.
Basically you just need to ask what a native port would provide that a Wine wrapper wouldn't. For most Delphi apps, the answer is probably themeing and very little else. We made a native port so we could access the filesystem at a lower level, but prior to that our product worked on Wine almost perfectly for years.
And speaking from experience, native ports aren't a walk in the park:
我通常推荐使用 Lazarus。 如果您依赖 WINE，那么您也会受到 WINE bug 的影响，这可能会影响您的产品质量。 在 Windows 环境中使用 Lazarus + FPC 甚至可能很有用。
另一种选择是使用虚拟化，但这取决于您正在编写的应用程序的类型。
I would generally recommend using Lazarus. If you depend on WINE, you are also at the mercy of WINE bugs, which may affect your product quality. It may even be useful to use Lazarus + FPC on the Windows environment.
An alternative would be to use virtualisation but this depends on the type of application you are writing.
看看 Codegear 的计划 - 在 DelphiLive 2009 上搜索一些路线图提示 - 在 Linux 和 Mac 上提供本机 Delphi，我现在会选择 Lazarus。 您无需再进行 Wine 管理，稍后就可以将您的应用程序移植到本机。 （正如有人所说：Delphi 将像一个大动物园，里面有企鹅、老虎、豹子和雪豹。）
当然，移植需要放弃一些工作。 但是，如果您仔细查看诸如 unicode 之类的问题并防止犯最常见的错误，那么这应该相当容易。
在 delphifeeds 上搜索 unicode 和路线图以获取更多提示。
Looking at the plans of Codegear - search for some of the roadmap hints at DelphiLive 2009 - to provide native Delphi on Linux and Mac, I would for now go with Lazarus. You spare yourself of the Wine administration and later can port your app to native. (As somebody put it: Delphi will be like big zoo with penguins, tigers, leopards and snow leopards.)
Of course, porting will envolve quit some work. But if you have a careful look on issues like unicode and prevent doing the most common faults, it should be rather easy.
Search on delphifeeds for unicode and roadmap for further hints.
我认为 Wine 或 Lazarus 可能适合你。 我已经用 wine 测试了一些相当大的 Delphi 应用程序（许多第 3 方控件），它们运行得很好。 有一些烦人的字体问题。 真正失败的两件事是我使用 TWebBrowser（看起来几乎可以工作，我认为它使用的是 gecko 渲染引擎而不是 IE）。 另一个是多层（Datasnap）服务器，它可以运行，但是我不知道如何连接。
我认为坚持 Mac/Linux 对 Delphi 的支持将是一个错误，事实上他们可以为 OS/X 编译一个控制台“hello world”应用程序令人印象深刻 - 但我认为移植 VCL 是一个不同的故事（除非你'已经编写了一个控制台应用程序）。
如果您已经有了一个可以运行的应用程序，那么就尝试一下 wine - 测试不会有什么坏处。
另一件需要考虑的事情是您的用户是谁（以及有多少）？ 如果他们是 Linux 极客，那么他们在配置和调整 wine 时不会遇到任何问题（尽管他们可能会发现使用本机 Windows 应用程序很冒犯）。 如果是一群祖母那就是另一回事了。
I think either Wine or Lazarus would probably work for you. I've tested some of our quite large Delphi Apps (Many 3rd party controls) with wine, and they have worked pretty well. There were a few annoying font issues. The two thing that really failed majorly was where I used TWebBrowser (which looked like it almost worked, I think it was using the gecko rendering engine instead of IE). The other was a muli-tier (Datasnap) server, which ran but, I couldn't work out how to connect to.
I think holding out for Mac/Linux support for Delphi would be a mistake, the fact that they can compile a console "hello world" application for OS/X is impressive - but I think porting the VCL is a different story (unless you've written a console app).
If you already have a working application, then give wine a go - testing can't hurt.
The other thing to consider is who your users are (and how many)? If they are Linux geeks then they are going to have no problems configuring and tweaking wine (although they might find it offensive to use a native windows app). If it's a bunch of grandmothers then that's a different story.
Free Pascal Compiler/Lazarus 与最新的 Delphi 功能并不接近，但它相当稳定，尽管仍然存在错误需要找出。
另外，生成的可执行文件看起来更大，但它肯定比使用 VM 或使用 Wine 本身进行部署要小。
但它做了 Delphi/Kylix 曾经尝试过的事情。 交叉构建！ 通过使用它，您可以从一个平台编译到另一个平台。
Free Pascal Compiler/Lazarus is not close to the latest Delphi features, but it is quite stable even though there are still bugs to find out.
Also, the executables produced seems larger, but it is definitely smaller than using a VM or deploying with Wine itself.
But it does something that Delphi/Kylix tried once. Cross build! By using it, you can compile from a platform to another.
首先，您应该尝试确保您的 GUI 代码和非 GUI 后端代码干净地分离到 GUI 应用程序和库中（如果尚未分离）。 这使得测试更容易，也更容易实现命令行界面、Web 界面等。大多数情况下，这些库（带有对象和过程的单元文件）应该可以在 FreePascal 上轻松编译，但是您应该检查和调试非 GUI 代码第一的。
一旦解决了这个问题，就该看看你的 GUI 了。 如果您使用大量闭源第三方商业组件，那么您可能无法轻松转换 GUI。 如果您主要使用库存组件和/或已移植到 Lazarus 的组件，那么您确实可以转换 GUI 并按原样使用它。
请注意，由于 Mac OS 和 Linux 程序通常应该看起来不同，因此您可能需要根据您的应用程序来考虑这一点。 可能的方法包括：
1. 即使在 Windows 上也可以使用 Lazarus，并在所有平台上使用相同的 GUI 代码。
2. 仅在 OS X 和 Linux 上使用 Lazarus，并将 GUI 自定义为转换后看起来有点原生。
3. 为 OS X 编写本机 GUI（使用 Cocoa 或 XCode），然后链接到 Pascal 代码以进行非 GUI 处理。 这种事情在 Linux 上不太必要，但是您可以选择用于 LCL (VCL) 后端的工具包。
每种方法都有强烈的支持者，但哪种方法正确取决于您的“情况”和您的目标。
如果您的主要兴趣是 OS X，请考虑加入 MacPascal 列表。
Wine 是一个巨大的杀伤力，除非你明天需要在几乎不做任何修改的情况下发布 Linux/OS X 应用程序。 （既然如此，为什么不直接使用VMWare呢？）
Firstly, you should try to make sure your GUI code and non-GUI back-end code are cleanly separated into the GUI app and libraries if they are not already. This makes for easier testing, and also easier implementation of command line interface, web interface, etc. These libraries (unit files with objects and procedures) should compile easily on FreePascal in most cases, however you should check and debug the non-GUI code first.
Once that's out of the way, it's time to take a look at your GUI. If you are using a lot of closed source 3rd party commercial components, then you may be out of luck with easily converting the GUI. If you are using mainly stock components and/or ones that have been ported to Lazarus, then you may indeed be able to convert the GUI and use it as-is.
Note that since Mac OS and Linux programs are often supposed to look different, you may want to consider that, depending on your application. Possible approaches include:
1. Use Lazarus even on Windows, and use the same GUI code for all platforms.
2. Use Lazarus only on OS X and Linux, and customize the GUI to be somewhat native looking after converting.
3. Code a native GUI for OS X (Using Cocoa and maybe XCode), and then link to your Pascal code for the non-GUI handling. This kind of thing is less necessary on Linux, but there you have a choice of toolkits for the LCL (VCL) back-end to make.
There are strong proponents of each approach, but which one is right depends on your "circumstances" and your goals.
If your main interest is OS X, consider joining the MacPascal list.
Wine is a huge overkill unless you need to get a Linux/OS X app out tomorrow with almost no modifications. (In that case, why not just use VMWare?)
实际上，我们在 ShareTeam 产品中使用 Wine...我们在 Lazarus 上有一个测试版本，这是一个很好的工具，有很多优点，但目前还不是很完整。
我认为如果工作不简单，目前最好使用 wine，将 Delphi 应用程序转换为 Lazarus/FreePascal 并不简单。
我个人希望Embarcadero能做一个跨平台的Delphi版本，而不是像Prism那样和Delphi有很大的区别。
Actually we use Wine for our ShareTeam product... We have an on-test version on Lazarus that is a good tool and have a lot of advantages but is not really complete at the moment.
I think at the moment is better use wine if the work is not simple, converting a Delphi application to Lazarus/FreePascal is not simple.
Personally i hope that Embarcadero make a cross-platform version of Delphi, not like Prism that have a lot of difference with Delphi.