2週間前に更新されたCrossKylixの新しいバージョン。

Kylixでさえずっと前に廃止されましたが、それでもDelphi開発者の何人かによって使用されているようです。

WindowsとLinuxのクロスプラットフォーム開発でうまく使用した人はいますか？

最近CrossKylixについて読んでいますが、ほとんどの場合、サードパーティのコンポーネントを検討する必要があります。ですから、活発に開発されているコンポーネントのうち、まだKylixをサポートしているものを知りたいと思います。

多くの人がその日に部分的または完全なKylixサポートを追加しましたが、更新を続けていない人もいるのではないかと心配しています。KylixでコンパイルされるIFDEF化された部分はテストされない可能性があります。

ですから、理想的には、実際のアプリと実際の経験を持っている人からのレポートが欲しいです。

これは、発表されたDelphiの将来のクロスプラットフォームリリースを楽しみにしているユーザーや、現在のKylix/CrossKylixユーザーにとって興味深いかもしれません。

SourceforgeのSynmemoは、非常に優れたtxtエディターおよびコードハイライターのようです。長くアップグレードしないのは残念です。それは純粋なvclです。最大長を知りたいのですが。ロードできる最大のtxtファイルは何ですか？

ありがとう

2 つのコンソール アプリケーションには、bmThreadBlocking モードの TTcpServer を使用する 1 つのソケット サーバーと、bmBlocking モードの TTcpClient を使用する 1 つのソケット クライアントが含まれます。TTcpClient は、サーバーに接続し、回線を送信してから切断することを目的としています。TTcpServer は、着信接続をリッスンし、OnAccept イベント ハンドラで受信した回線をエコーすることを目的としています。

これら 2 つのコンソール アプリケーションは、Windows (XP および 7) で正常に動作します。ただし、CrossKylix または Kylix を直接使用してコンパイルすると、アプリケーションは Linux (SuSE 10.0 および CentOs 5u7) で期待どおりに実行できません。1 つのクライアントが接続するとすぐに、サーバー アプリケーションは "[1]+ Stopped ./TestSocketServer_1_Console_Native" を取得します。つまり、TTcpServer の OnAccept イベント ハンドラー内/後です。この問題についてコメントしていただけませんか？どんな助けでも大歓迎です！

2 つのコンソール アプリケーションは、 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 の font-family を固定幅フォントに設定しようとします。

1. ローカルの Linux ボックスで実行されている Kylix 3 を使用してコンパイルされたアプリケーションは、正しいアライメントを提供します。

2. ローカルの Windows ボックスで実行されている Delphi 7 を使用してコンパイルされたアプリケーションは、正しいアライメントを提供します。

3. Windows XServer を備えたリモート Linux で実行されている Kylix 3 を使用してコンパイルされたアプリケーションは、正しいアライメントを提供しません。

4. Mac Lion XServer を搭載したリモート Linux で実行されている Kylix 3 を使用してコンパイルされたアプリケーションは、正しいアライメントを提供しません。

この問題を回避する方法をコメントしていただけませんか? どんなコメントでも大歓迎です！

uMainForm.pas

uMainForm.xfm

多くの問題があるプログラムを継承しました。最新のものは、実際のパラメータが多すぎるという警告です。

太字の部分は、エラーが強調表示されている場所です。

注：プログラムは動作しますが、私のマシンでは動作しません。同じバージョンのDelphi（7）を使用して開発されましたが、clx（kylix）環境で開発されました。clxとvcl（現在の環境）の間の非互換性の問題はすべて解決したと思いますが、このエラーを生成しているコンポーネントが欠落している可能性があります。質問を明確にするために最善を尽くしますが、Delphiを開発してから数か月しか経っていないことを忘れないでください。

次のようなコードで、Delphi 7 アプリケーション (CLX) でメモリ リークの問題が発生しました。

fsPrinterメインフォーム（TForm）が閉じた瞬間に解放されても、オブジェクトの結果がリークしました：

FastMM4 によるリークのレポートは次のとおりです。

ここで、問題を表すプロジェクトの完全なSSCCEサンプルをダウンロードできます(サンプルを実行するには、ボタンをクリックしてフォームを閉じます)。

fsPrinterオブジェクトがリークするのはなぜですか? どうすればリークを回避できますか?

CrossKylix でコンパイルできるサーバー部分を持つ Delphi 7 でアプリケーションを管理しています。パフォーマンスの問題については、マルチスレッドとクリティカル セクションの使用をベンチに置いています。

100 個の TThread を作成し、各 TThread がフィボナッチを計算するコンソール アプリケーションを作成しました。次に、クリティカル セクションを追加して、一度に 1 つのスレッドだけがフィボナッチを計算するようにします。予想どおり、クリティカル セクションを使用しない方がアプリケーションは高速です。

次に、100 個の TThread を作成し、各 TThread がローカルの TStringList に単語を追加し、その TStringList をソートするコンソール アプリケーションを作成しました。次に、クリティカル セクションを追加して、一度に 1 つのスレッドのみが実行されるようにします。Windows では、予想どおり、アプリケーションはクリティカル セクションがなくても高速に実行されます。Linux では、CriticalSection バージョンは Critical Section のないバージョンよりも 2 倍高速に実行されます。

Linux の CPU は 6 コアの AMD Opteron であるため、アプリはマルチスレッドの恩恵を受けるはずです。

クリティカル セクションを含むバージョンの方が速い理由を誰か説明できますか?

編集（コードを追加）

スレッドの作成と待機

TThread および Critical セクションの使用

編集 2

このWhy-using-more-threads-makes-it-it-slower-than-using-less-threadsを読んだので、これを理解しているように、コンテキスト切り替えは、win32でのコンテキスト切り替えよりも、LinuxとKylixコンパイルでより多くのCPUリソースを消費します。

次のプログラムは、AnsiCompareStr/Text の使用を試みます。

Kylix でコンパイルすると、CentOS 5/6 x64 で間違った結果が出力されます。

なぜ AnsiCompareStr/Text が間違った結果を出すのだろうか?

PS: http://www.delphibasics.co.uk/RTL.asp?Name=CompareStrによると、CompareStr は廃止されたと見なされます。AnsiCompareStr は、http://www.delphibasics.co.uk/RTL.asp?Name=AnsiCompareStr によると、CompareStr の最新の Locale safe 形式であると見なされます。

PS: ロケールは en_US.iso885915 および/または en_US.UTF8 です。

PS: Kylix 3 (CrossKylix を使用した Delphi 7 として)