トップページ⇒tech
536コメント150KB

Kylix3

■ このスレッドは過去ログ倉庫に格納されています
0001KylixNGNG
http://www.borland.co.jp/kylix/

LinuxでビジュアルにC++開発ができるKylix3ｷﾀ。
04824802005/10/01(土) 12:00:14
>>481
レスありがとうございます
どっちもどっちという感じですね
やっぱりC++に移植したほうがいいのかしらん
0483デフォルトの名無しさん2005/10/01(土) 12:35:24
Java に移植するとか。

それはそれで嫌がる人が多そうだけど、
すくなくとも Kylix のように放置されることは当分なかろう。
0484デフォルトの名無しさん2005/10/06(木) 01:00:12
C++にしたとしてもGUIライブラリどうするか迷うよね。
Delphiからの移植だとQtがいいかな、と思うんだけど、QtってIM周りとか仕様が弱かったりするし。
そもそもGPLでいいかどうかも判断に迷う。

そう考えるとJavaって悪くないかも。パフォーマンスはあれだけど、配布時のライセンスも自由に
決めれるし、対応環境も広いし。
0485デフォルトの名無しさん2005/10/06(木) 01:18:38
Kylix自体はもう今更って感じではあるが、
Borland製C++コマンドラインコンパイラだけでもメンテしていて欲しいな…。
gcc/iccに続く選択肢になるし、__closureとか__propertyとかあるし。
0486デフォルトの名無しさん2005/10/06(木) 01:19:50
Delphi.NETに移植してmono…
0487デフォルトの名無しさん2005/10/06(木) 18:15:05
C# がいまだ未知数な以上 mono もどうなることやら、って感じだな。
mono で GUI となると、5 年後に存在してるのかどうかすら怪しい。

頑張ってる人は頑張ってるんだろうけど。
0488デフォルトの名無しさん2005/10/07(金) 00:19:23
>>485
それもそうだけど、Borland PascalコンパイラもLinux版メンテしてほしい。
FPCは遅い。Lazarusの最大の問題点はVCLとの互換性じゃなくコンパイラの遅さ。
速くないならPascalつかうメリットない。
0489デフォルトの名無しさん2005/10/08(土) 00:16:48
そうなんか？ Pascal 好きな人って文法とかを偏愛してるのかと思ってた。
04904802005/10/08(土) 00:58:39
>>483
javaだとパフォーマンスがとか思う私は旧人類でしょうか･･･

>>484
そう、そうなんです。
GUIをどうするか。
はたまたIDEはということになるし･･･

>>486
正直それは追いかけていませんorz

ああ、そろそろ決めなければいかんな･･･
どうせどうころんでも私の責任にされるだろうし･･･
会社やめようかな･･･
0491デフォルトの名無しさん2005/10/08(土) 03:24:40
>>489
文法を偏愛している人はModulaを(ry
0492デフォルトの名無しさん2005/10/08(土) 23:55:23
>>490
Javaのパフォーマンスは昔ほど気にならない。最初にロードする時間さえ
我慢すればその後の動きは割と快適。GCで引っかかったような動きになる
のはあるけどね。

でも俺はQt4を狙ってる。まだ出たばかりなのであまり詳しく見てないけど
Qt3よりはだいぶ進化してる。やっとWinでもフリーになったし。
0493デフォルトの名無しさん2005/10/11(火) 23:21:31
このスレで聞くのがいいかわからないんですが、他に適当なスレがない
のでここで質問します。

Delphi5で構築したC/Sシステムがあります。DBはFirebirdです。
10プロジェクト(exe)、200ユニットで、ストアドやビューよりは
TQuery（実際はIBO）にSQLを直に書く方法を主にとっています。

が、今度クライアントマシンがLinuxになるということになりました。
最短、最小限の労力で上記システムを移植したいのですが、
みなさんならどうしますか？　現在のところ考えている選択肢は

・Kylix3
・Lazarus
・JBuilder

です。ちなみに当方は2年まえにKylix3でのC/Sシステムが１プロジェクト
だけ経験があります。LazarusはWindowsで入れてみてちょっと弄った程度、
JBuilderはServlet/JSPはよくやっていますが、クライアントアプリはDBを
使わない簡単なツール程度しか経験ありません。

Qtなどでやるのが完成度は高いのは想像できますが、工数がかかりすぎる
のではないかと思い、上記３案を考えています。他の案も含めアイデアが
あればご教授ください。
0494デフォルトの名無しさん2005/10/26(水) 19:13:24
>>493

・Wine

Wineがついにベータ段階へ。Ver.0.9リリース
ttp://slashdot.jp/articles/05/10/26/0735259.shtml
0495デフォルトの名無しさん2005/10/27(木) 01:01:26
Wineは厳しいだろうなあ。Delphiで作った単体アプリがWineで動く可能性は高いけど、
DB系はどうかな。Windows用のFirebirdクライアントもWineで動かす必要があるんだよな。
0496デフォルトの名無しさん2005/10/27(木) 09:19:02
じゃ、クライアントがWin以外になるわけだから、
ウェブブラウザアプリじゃね？
04979782005/10/27(木) 09:21:25
ウェブアプリなら、Delphiでも作れるから工数削減じゃん。
本当にDelphiのまんまだとHTMLを文字列処理だからイマイチだけどね。

IntraWebだとポトペタかなぁ？
0498デフォルトの名無しさん2005/10/27(木) 21:22:24
>>496
それじゃC/Sじゃないじゃんｗ
0499デフォルトの名無しさん2005/10/28(金) 08:49:38
Delphiのソース（DBアクセス）をそのままJNIにコンパイルできるよ。
で、Javaから呼び出す事も可能。
0500デフォルトの名無しさん2005/10/28(金) 09:18:09
>>499
そのコンパイルされたネイティブコードがLinuxで動くと思う？
0501デフォルトの名無しさん2005/10/28(金) 09:31:15
サーバーで動かして、サーバーJavaからクライアントに結果表を渡してみてはどうでしょう？
ただ、DB部分のソースが生きるだけで、残念ながら開発が楽じゃあないな。
0502デフォルトの名無しさん2005/10/28(金) 13:27:27
そりゃあKylixでやるのが一番楽そうだけど実際に使用する
Linuxのカーネルやライブラリのバージョンでの動作検証を綿密に行う必要ありそうだあな。

あと、帳票をどうするか。Delphi5だとまだRaveReportじゃないだろうからそこは最低作り直しだな。
05034932005/10/28(金) 15:54:49
>>502
RaveReportへの書き直し程度は覚悟しています。要はトータルでの工数が
ある程度削減できればいいんです。Kylixで作ったバイナリ、最近のLinuxでも
問題なく動いてますか？
0504デフォルトの名無しさん2005/10/28(金) 16:47:20
それはこのスレのログを見ればわかると思うが。
特に>>475のリンク先の情報は重要だろう。
0505デフォルトの名無しさん2005/11/07(月) 11:56:21
Kylix3を使用して，フォーム上で複数のフレームをnewで生成しようとしてい
ます．
しかし，TFrameから派生させたフレームTFrame1を1つのフォーム上で複数生成
するとランタイムエラーが発生してしまいます。 下記のプログラムですと、1
つめのフレーム生成は成功するのですが、2つめのフレームframe2の生成がで
きません。 
TForm1のコンストラクタ{
    TFrame1 *frame1,*frame2;
    frame1 = new TFrame1(this);
    frame2 = new TFrame1(this);
}


実行すると
Systemファイルが表示され「->」の位置で実行が止まっているようです。
    procedure _DbgExcNotify(
    NotificationKind: Integer;
    ExceptionObject: Pointer;
    ExceptionName: PShortString;
    ExceptionLocation: Pointer;
    HandlerAddr: Pointer); cdecl; export;
->  begin

解決方法をご存知の方がおられましたら，ご教授ください．
0506デフォルトの名無しさん2005/11/07(月) 20:45:15
Kylixは知らないけど、Nameプロパティを変えていかないと、
設計時のNameプロパティがそのままロードされてて、
衝突してるとかじゃなくて？
0507デフォルトの名無しさん2005/11/13(日) 19:39:58
kylixで作ったプログラムってLinux上で動くの？？
0508デフォルトの名無しさん2005/11/17(木) 00:39:40
>>507
むしろLinux以外では動かないと思うけど。
0509デフォルトの名無しさん2005/11/17(木) 21:01:43
Linux でも動かない事例が増えてんじゃないの？カーネル違いやらライブラリのバージョンやらで。

そもそも使っている人を見かけないから情報が少なすぎる。
0510デフォルトの名無しさん2005/11/23(水) 03:24:03
IDEが動かなくなった。たぶん、qtとかのバージョンのせいだと思うのだが………
かくなる上はchroot環境で古い環境を再現して、Xを飛ばすという裏技しかないかなぁ
0511デフォルトの名無しさん2005/11/23(水) 10:51:18
Kylix on Eclipseが噂されてるけど、

CLX
-----------------------
OS依存レイヤ(SWTのDLL, so)

で再構成してくれんかなあ。
0512デフォルトの名無しさん2005/11/23(水) 12:52:48
SWTのdll,doって、JNI用に作られてるんじゃないのか？
その構成だとJVMが常にロードされてしまいそうな…
05135112005/11/23(水) 17:09:12
>>512
QtがTrollTechという１企業でメンテされてるのに対して少しは将来的不安がなくなりそうなので。
Qtも最近少しはライセンス緩くなったけどね。
0514デフォルトの名無しさん2005/11/23(水) 17:11:56
将来的不安って、そもそも Kylix に将来はあるのだろうか
05155112005/11/23(水) 17:28:28
Kylix自体じゃなくってKylixで作ったアプリがOSのバージョンが上がって動かなくなるといった意味ね。
0516デフォルトの名無しさん2005/12/03(土) 10:44:23
ところで、オマイらkylixをどんな環境で動かしてる？
最新の環境にすると挙動が怪しくなるのだが。
0517デフォルトの名無しさん2005/12/03(土) 10:51:58
駄目じゃん、ちゃんと RedHat 7.2 で動かさなきゃ。
0518デフォルトの名無しさん2005/12/03(土) 11:52:15
>>513
> QtがTrollTechという１企業でメンテされてるのに対して少しは将来的不安がなくなりそうなので。
> Qtも最近少しはライセンス緩くなったけどね。
ボーランド1社がクローズドソースで管理しているKylixを使うぐらいだったら
Qtの将来を心配する必要はないね。

つか、QtはTroll以外でもメンテされているし。
0519塩水 ◆1FrMT.vzQQ 2005/12/24(土) 08:31:14
x86_64対応マダー？
0520デフォルトの名無しさん2006/02/09(木) 09:04:32
忘れない為に貼っておく。

How To run Kylix on a 2.6.x Linux kernel ? KLX3
http://support.borland.com/entry.jspa?externalID=16983&categoryID=102
0521デフォルトの名無しさん2006/02/18(土) 21:45:35
Kylix を買ってくれるような奇特な企業はあるんかいな
Qt 作ってる Trolltech とかが買えばよさそうだけど、そんな体力ないか
0522デフォルトの名無しさん2006/03/08(水) 20:34:20
http://japan.zdnet.com/column/interview/story/0,2000053136,20098072,00.htm

現在、ボーランドのIDE製品にかかわっているメンバー、開発担当者、サポートエンジニア部隊、そして私自身も、引き続き製品にかかわっていきます。 Delphi、C++ Builder、C# Builder、JBuilder、InterBaseなどの将来については、安心していただきたいと思っています。

Kylixは？…orz
0523デフォルトの名無しさん2006/03/30(木) 16:37:18
Ｋｙｌｉｘがダメになった原因って難だろう？

復活は無いのかなぁ？
0524デフォルトの名無しさん2006/03/30(木) 17:27:20
様々な環境に対応させるためにQTが必要だったから｡
それにｌｉｎｕｘ使うならソースで配布する方が利用者にとってはなじみが深いから｡
Windowsべったりを避けるなら今はＰＣ−ＵＮＩＸとなったＭａｃに行った方がいいと思う｡
ここならソース配布しなくても受け入れられるし､
とりあえずＯＳのバージョンごとにＧＵＩも単一で互換性を考えなくても良いと思う｡

個人的には復活して欲しいなぁ｡
0525デフォルトの名無しさん2006/03/30(木) 17:55:12
>>524
CocoaもC++用のラッパー作れそうだしな。
0526デフォルトの名無しさん2006/03/30(木) 22:25:53
またマカーか！
0527デフォルトの名無しさん2006/03/31(金) 00:04:10
>>524
ダメだった理由だよね。
> 様々な環境に対応させるためにQTが必要だったから｡
これはどういう意味だろうか。Qtが必要だったらからダメってことはないよね。
KDEはQtを使っているけれど、おそらくKylixで作ったソフトウェアより多く使われている。

> それにｌｉｎｕｘ使うならソースで配布する方が利用者にとってはなじみが深いから｡
これもちょっと違う。たとえば、Linuxのアプリを使っている人がどれぐらい自分で
日常的にコンパイルしているかというと、ま、ほとんどしていないね。
Linuxそのものが多くの環境で動作しているとはいえ、大半がx86といって差し支えない
と思う。だからうまく作れば、FirefoxやOOoと同じようにバイナリで配布することも可能
だったはずだ。要はKylixの出来が悪かったのが最大の問題じゃないかと思う。

> Windowsべったりを避けるなら今はＰＣ−ＵＮＩＸとなったＭａｃに行った方がいいと思う｡
> ここならソース配布しなくても受け入れられるし､
有償版Kylixならソース配布は必要ないからこれもズレている。
あえて言うなら、「Mac環境ならLinuxとよりも有償ソフトが受け入れられるし」だろうな。

> とりあえずＯＳのバージョンごとにＧＵＩも単一で互換性を考えなくても良いと思う｡
QtがOSのバージョン間でトラブルを多発したことを考えれば、Macだから互換性を
考えなくても良いってことはないだろうな。
0528デフォルトの名無しさん2006/03/31(金) 00:27:31
こっちをがんばりましょう

【Delphi互換!?】FreePascal【GPL】
http://pc8.2ch.net/test/read.cgi/tech/1137051510/
0529デフォルトの名無しさん2006/03/31(金) 00:33:40
Linux で Kylix (C++ の部分) する人すらほとんどいなかったのに、
Linux でわざわざ Pascal する人はさらに少ないのでは。
さらに言えば Linux では C++ 人口も少なくて未だに生 C 好きが多いんだよな。
0530デフォルトの名無しさん2006/03/31(金) 11:12:04
＞Linux で Kylix (C++ の部分) する人すらほとんどいなかったのに、

デスクトップアプリが少ないんだお。
それをポトペタで解消しる！

Ｋｙｌｉｘ復活お願いします。
0531デフォルトの名無しさん2006/03/31(金) 12:25:14
生Cはエロイ
0532デフォルトの名無しさん2006/03/31(金) 12:40:39
>>527
Qtのライセンスがらみでのゴタゴタはあったよ。商用Qtを使用しているにもかかわらず
Qt単体ライセンスより低額であることで制限を受けることになった。

あとソース配布じゃないというよりソース公開じゃないことが普及の妨げにはなった。
FirefoxやOOoはバイナリー配布されてようとオープンソースじゃん。いろんなディストリ
いろんな環境で動作させるにはユーザによるパッチとフィードバックが必要だったのに
オープンソースじゃないからユーザは手を出せなくて、ベンダーがそれを負わざるを得なく
なったが実際はそれを怠った。

Mac云々は問題外だな。企業でも個人でもUNIXとしてMacを使うメリットが全くない。
0533デフォルトの名無しさん2006/05/12(金) 22:17:21
kylix・・・
すっかり廃れたな
0534デフォルトの名無しさん2006/05/13(土) 02:29:41
そんなことない。みんなの心の中には永遠に刻まれてるさ。
0535デフォルトの名無しさん2006/05/24(水) 14:09:06
昨日、Kylix 3をDebian Sargeにインストールしてみたけれど、ライブラリの
シンボリックリンクをいくつも作らないと行けない。ちょっと面倒だね。
0536デフォルトの名無しさん2006/05/26(金) 11:58:18
そりゃそうだ。ユーザ環境で動かすのも大変。
■ このスレッドは過去ログ倉庫に格納されています