[Delphi:90948] 今後のプラットフォーム
dev
最近はちょっと開発から離れていて浦島状態なので、教えていただきたいのですが。
今後はWin32と.Netどちらが主流になると皆さんはお考えなのでしょうか？
というのも、ちょっとした案件があがりまして、どちらをプラットフォームに
しようかと、悩んでおります。
当然、会社的な要素が一番になるのはわかるのですが、逆にそういうしがらみが無ければ、
ここの皆さんが個人的にどちらを支持しているのか、また、そのプラットフォームを選択
したときのDelphiのバージョンを聞かせていただければければ幸いかと思っています。
その案件を簡単に言うと、
１．外部機器と何かで通信してデータを読み書きする。
２．そのデータを解析する。
３．２のデータユーザにわかりやすく表示する。
４．２のデータを元に外部機器に支持を与える。
みたいな感じのアプリになります。
よろしくお願いします。
--
dev mailto:d...@arb-kids.net
高木太郎
dev さん：
> 今後はWin32と.Netどちらが主流になると皆さんはお考えなのでしょうか？
>
> 当然、会社的な要素が一番になるのはわかるのですが、逆にそういう
> しがらみが無ければ、ここの皆さんが個人的にどちらを支持しているのか、
> また、そのプラットフォームを選択したときのDelphiのバージョンを
> 聞かせていただければければ幸いかと思っています。
私も非常に興味があるのですが、レスがありませんでしたね……
私の考えだけで申しますと、弊社はＨＰＣ（高速処理）みたいなことを
やっているもので、.NET への完全移行というのは難しい立場にあります。
設計・生産技術や医療技術関連では、パフォーマンス（データサイズに
対する処理時間の短縮）が絶対的に必要である用途が多く、その分野には
私と同様の思考をする方が多いのではないでしょうか。
> １．外部機器と何かで通信してデータを読み書きする。
> ２．そのデータを解析する。
> ３．２のデータユーザにわかりやすく表示する。
> ４．２のデータを元に外部機器に指示を与える。
> みたいな感じのアプリになります。
上記のお話を伺う限りですと、まさにそのような分野ではないかと想像
いたします。 ですのでネイティブであっても問題ないと思います。
ネイティブ開発には Delphi 5 や 7 といった古いバージョンや、最新の
2009 が使えます。 古いバージョンと 2009 の間には、文字列型に関して
互換性がない部分がある（新バージョンでは Unicode が主になる）ので、
現時点では古いバージョンで踏みとどまっている方も多いようです。 ただ
移行はそんなに大変ではないので、徐々に Unicode 主流に移行していく
だろうと私は見ています。
――――――――――――――――――――――――――――――――――――
株式会社イマジオム 代表取締役 高木太郎
〒３１６－００２４ 茨城県 日立市 水木町 １－１１－１０
電話：０２９４－２８－０１４７
ファクシミリ：０２９４－２８－０１４８
電子メール：tarou_...@imageom.co.jp
ホームページ：http://www.imageom.co.jp/
dev
> 私も非常に興味があるのですが、レスがありませんでしたね……
ちょっと漠然とした質問過ぎましたかね・・・(^^;
> 私の考えだけで申しますと、弊社はＨＰＣ（高速処理）みたいなことを
>やっているもので、.NET への完全移行というのは難しい立場にあります。
>設計・生産技術や医療技術関連では、パフォーマンス（データサイズに
>対する処理時間の短縮）が絶対的に必要である用途が多く、その分野には
>私と同様の思考をする方が多いのではないでしょうか。
> 上記のお話を伺う限りですと、まさにそのような分野ではないかと想像
>いたします。 ですのでネイティブであっても問題ないと思います。
やはりパフォーマンスは落ちてしまうんですね。
絶対的に処理時間を速くしなくては回らないというほどでもないのですが、
現在動かしてるソフトでも、結構CPUパワーを喰ってるので、.Netにした時の
パフォーマンスは気になるところではあります。(ロジックを見直せば結構変
わるかもしれませんが、いかんせん技術と時間が・・・)
仮にネイティブでGoとしたとして、Microsoftを含み、開発環境はある程度
サポートされるのかどうか気になりますね。
まぁ、Microsoftが.Netへの移行にどこまで本気なのかどうかの判断も付かないんですけど。
> ネイティブ開発には Delphi 5 や 7 といった古いバージョンや、最新の
>2009 が使えます。 古いバージョンと 2009 の間には、文字列型に関して
>互換性がない部分がある（新バージョンでは Unicode が主になる）ので、
>現時点では古いバージョンで踏みとどまっている方も多いようです。 ただ
>移行はそんなに大変ではないので、徐々に Unicode 主流に移行していく
>だろうと私は見ています。
今使ってるのがD6なので、2009のProでもとりあえず入手してみようかと思います。
そして、もう少し色々文献などなど入手して、最終判断しようかと思います。
大好きなDelphiで開発したいのはヤマヤマなんですけど、昔ほど活況でないのも
事実ですので、慎重に決定したいと思います。
ありがとうございました。
--
dev mailto:d...@arb-kids.net
大津修一
大津です。
私見で恐縮ですが、
> 今後はWin32と.Netどちらが主流になると皆さんはお考えなのでしょうか？
>
.Net Frameworkが主流になるのは間違いないと思います。これは普及マシンに依存する
部分が大きいと思います。WindowsXPやそれ以前のバージョンのWindowsマシンが徐々にVista
マシンに置き換わるにしたがって、ユーザが「当たり前」と考えるインターフェイスに
ベクターデータ制御や3Dがどんどん取り込まれてくると思います。たぶんこう申し上げると、
それはデザイナーの世界であって、プログラマにはあまり関係ないと反応される方もいらっしゃるのではないかと思いますが、
この思いを強くしたのは、Vistaから導入されたWPF(Windows Presentation Foundation)を利用したプログラムを見たときです。
一番印象的だったのは、複数のウインドウが開いている環境において、1つのウィンドウ領域で起動された3Dアニメーションが、
他のウィンドウ領域で動いているのを見たときです。
これって今まであり得たでしょうか。これはデータ形式自体が（ＯＳレベルで）、ビットマップデータから重ね合わせを可能にするベクターデータに移行しないとなかなか
難しいのではないでしょうか。
従来のアプリケーションの形式であるWindowsフォームアプリケーションは、徐々にですがWPFアプリケーションに移行していくと
思います。これはユーザにとっては、より直観的でわかりやすいアプリケーションへの移行ということになると思います。
これまでのメインメニュー→メニュー→サブメニューを表示・選択し、さらに必要な項目を選択ということが
当然というアプリケーションの世界が、iPodのように見ただけで、ユーザがその操作方法をイメージできるアプリケーションの世界に変わる予感があります。
ところで、そもそものWin32と.Net Frameworkの関係についてですが、これは別の空間ではなく、おおざっぱな言い方をさせていただきますと、ご承知のように
Win32に.Net Frameworkが「かぶさっている」という関係です。現実に、.Net FrameworkからWin32ベースのDLLを利用することはよくあります。
では、.Net FrameworkでOKかというと必ずしもそうではありません。私が普段感じている問題は、2つです。
1、文字コード
高木さんも触れられていらっしゃるように、文字コードの問題です。シフトJISベースでコーディングしたDLLは、うまく使えない場合が多々あります。
2、既存資産（コンポーネントなど）の活用
すでにWin32ベースで稼働しているプログラムなどを、あえて.Net Frameworkに移行する必要はほとんどないと思います。移行はかなり困難と思われます。逆に移行をする労力を考えますと、最初から
作り直した方が簡単と思われます。たとえば、Win32でマルチスレッドやプロセスを制御するプログラムは、複雑化する傾向にあると思いますが、
.Net Frameworkベースですと当初より簡単なクラス（コンポーネント）になっていますので、プログラム自体を最初から作り直した方がよりシンプルになる可能性があります。
したがって、私の意見としては、以下のとおりです。
○「既存の資産（コンポーネントなど）」を活用する割合が多いのであれば、Win32ベース。
○新たに開発するのであれば、.Net Frameworkベース
> その案件を簡単に言うと、
> １．外部機器と何かで通信してデータを読み書きする。
> ２．そのデータを解析する。
> ３．２のデータユーザにわかりやすく表示する。
> ４．２のデータを元に外部機器に支持を与える。
> みたいな感じのアプリになります。
私であれば、SmartClient + Webサービスサーバの構成で作ろうとしまうと思います。
*************************************
大津 修一
Shuichi Ohtsu
EMAIL: oh...@digipub-net.com
HP : http://www.digipub-net.com/
*************************************
Delphiに関するドキュメント補完サイト：
http://www.digipub.biz/11/ap/Book/DelphiSpace/pDelphiSpace.aspx
ECO(Enterprise Core Object)に関するドキュメント補完サイト：
http://www.digipub.biz/11/ap/Book/Eco/pEcoSpace.aspx
dev
大津さん。詳細にありがとうございます。勉強になります。
>したがって、私の意見としては、以下のとおりです。
>
>○「既存の資産（コンポーネントなど）」を活用する割合が多いのであれば、Win32ベー
>ス。
>○新たに開発するのであれば、.Net Frameworkベース
現在のシステム自体開発から10年弱の間、増築改築を繰り返してきており
全体的な見通しが悪すぎるのと、パフォーマンスが悪い事から、
1から作り直しをするつもりでおります。
と、するとやはり.Netベースで開発した方が、後々は有利なのでしょうね。
Delphiで開発するとなると、「Delphi Prism」になるのでしょうか？
Delphiじゃなくて、C#とかで開発した方が・・・と考えてしまうんですが。
>> その案件を簡単に言うと、
>> １．外部機器と何かで通信してデータを読み書きする。
>> ２．そのデータを解析する。
>> ３．２のデータユーザにわかりやすく表示する。
>> ４．２のデータを元に外部機器に支持を与える。
>> みたいな感じのアプリになります。
>
>私であれば、SmartClient + Webサービスサーバの構成で作ろうとしまうと思います。
SmartClientですか・・・
早速デモでも落としてみて、どんなものか見てみます。
Webベースではパフォーマンスが悪すぎるという固定観念がありましたので全然考えていませんでした。
以上。ありがとうございます。
--
dev mailto:d...@arb-kids.net
大津修一
> と、するとやはり.Netベースで開発した方が、後々は有利なのでしょうね。
> Delphiで開発するとなると、「Delphi Prism」になるのでしょうか？
> Delphiじゃなくて、C#とかで開発した方が・・・と考えてしまうんですが。
今回、Delphi Prismをインストールしてみて、はたしてこれはDelphiなのだろう
かという違和感を感じています。と言いますのは、Delphiといった場合、言語体
系（ObjectPascal --Delphi言語）と統合開発環境の双方を指していると思いま
す。Delphi Prismは、統合開発環境を完全にVisualStudio(2005 or 2008)に委ね
てしまっています。そしてさらに、言語体系もかなり根本的に変更されているよ
うです。たとえば、Delphiでは、戻り値の有無によって
function
procedure
の使い分けをしていましたが、（まだよく精査していないので、間違いかもしれ
ませんが）両者を統合し、
method
とネーミングしているようです（私自身はもともと区別する必要はなく合理的だ
と思っています）。要するに言語自体もかなり変更されています。これは
VisualStudio2008から見てみると明確になるのですが、同ツールにおいては、こ
の言語は、Delphi言語ではなくOxygeneとされています。
要するに実体的にはDelphi Prismとは、
(New Object Pascal) Oxygene for VisualStudio
です。
こうなるとDelphiの独自性はほとんどないと思います。私自身は、BDS2006で
..Net Frameworkベースのプログラムを作ってしまっていますので、Prismは使う
つもりですが、（情報が少ないこともあり）移植にかなり苦労すると思います。
さらにECOのサポートもないようです。
そこで、これから.Net Frameworkプログラムという方には、やはりC#の方がお勧
めです。これは情報の多寡というばかりでなく、以下のメリットもあります。
○XAMLの編集などに利用するBlendなどのソフトとVisualStudio(C#)がすでに一
体化している。
(Blendの言語設定には、C#とVB.NETしかない）
私自身は、.Net Frameworkの開発おけるDelphiとC#の利用比率は、4対1程度です。
Delphiにこだわる理由は、長年利用してきて愛着もあり、機能において裏切られ
た印象もあまりありません。何より、コンポーネントが豊富であり、アセンブリ
レベルから.Net Frameworkレベルまで1言語で統一できることに満足しているこ
とによります。
dev
>要するに実体的にはDelphi Prismとは、
>(New Object Pascal) Oxygene for VisualStudio
>です。
なんか、すごい事になってるんですね。BDS2006は持っていても、実際はD6で止まってる
私としては、理解の範疇をこえているというか・・・(^^;
>そこで、これから.Net Frameworkプログラムという方には、やはりC#の方がお勧
>めです。
でも、道筋は見えてきたというか、
.Netをベースにするべきかどうかをもう一度よく吟味してみて、
移行しないのであれば、使い慣れているDelphiの2009などで開発する。
移行する決心が付いたら、残念ですがDelphiから離れてC#で開発する事にする。
これを念頭において、もう少し.Netについて情報を仕入れてみます。
本当にありがとうございます。
--
dev mailto:d...@arb-kids.net
iwamatsu
Delphi2009を使用している者です。
Delphi1から使い続けてDelphi7で満足して
いたのですが、ユニコード対応に対する
（いつまでもSJISでいいのか？という）
危機感から、比較的移行しやすそうな
C#を検討していました。
やはり.NETだけではどうしようもなくて
Win32APIを呼ぶ必要性も残されています。
それでも何とか以降は可能かと思って
いましたが、
・現在の環境ではやはり.NETは遅い。
便利な機能はその分オーバーヘッドが
大きいように感じました。
・リバースエンジニアリングが容易。
商用とかで動きを知られたくないとか、
ちょっとした暗号化などを使用したい
とか思っても、簡単にリバースエンジニ
アリング出来てしまってはどうしようもない
様な気がします。
dotfuscatorの様なツールの存在自体に
ちょっとショックでした。
といった矢先にDelphi2009がユニコード対応
を謳って出てきたので、.NETは当面おあずけに
しました。
Knockwood
"iwamatsu" <ZAS0...@nifty.ne.jp> 様、
ちょっと話がずれますが、リバースエンジニアリングの話が出てきたので。
私は、この対策として、Themeidaというプロテクトツールを使っていますが、
なかなか使い勝手が良く、性能も良いのでもう３年くらい愛用しています。
http://www.oreans.com/
dotfuscatorって値段を調べたらビックリするほど高かったですが、こちら
は１１９ユーロです。.NET版も１５９ユーロ程度なので、導入しやすいですよ。
もし、.NETのプログラムでの逆コンパイルとか心配されている場合は、
こんなツールも悪くないのでは・・・と。
あ、私はWIN32版を使っているので、.NET版がどれだけのものかは未確認ですが
参考まで。
dev
>・現在の環境ではやはり.NETは遅い。
> 便利な機能はその分オーバーヘッドが大きいように感じました。
パフォーマンスの問題は大きそうですね。
ネイティブと.Netで同じような簡単なソフトを拵えて、パフォーマンスのチェックを
した方がよさそうですね。
>・リバースエンジニアリングが容易。
> 商用とかで動きを知られたくないとか、ちょっとした暗号化などを使用したい
> とか思っても、簡単にリバースエンジニアリング出来てしまってはどうしようもない
> 様な気がします。
こちらは当方としてはあまりプライオリティを置いていない部分ですが、
> dotfuscatorの様なツールの存在自体にちょっとショックでした。
このような物を使わないといけない背景があるんですね。
今後の事もありますし、ちょっと勉強してみます。
Takuo Nakamura
"[Delphi:90964] Re: 今後のプラットフォーム" において
dev <d...@arb-kids.net> さんは書きました
>>・現在の環境ではやはり.NETは遅い。
>> 便利な機能はその分オーバーヘッドが大きいように感じました。
>パフォーマンスの問題は大きそうですね。
>ネイティブと.Netで同じような簡単なソフトを拵えて、パフォーマンスのチェックを
>した方がよさそうですね。
ケースバイケースでしょうね。
純粋に大量のデータをメモリ上で処理するようなアプリでは、
.NETの分が悪そうですが、
ここ数年、.NET でいくつかの 準リアルタイム系のサーバアプリケーションを
作りましたが、結局速度を決めるのは、ネットワーク、DB、ファイルI/O
で、.NET そのものの遅さが問題になったことはありませんでした。
＃最初の一回目の処理のレスポンスが悪いとかはありましたけど．．．
+---------------------------------------------+
|Takuo Nakamura from Hino City, Tokyo JAPAN |
+---------------------------------------------+
mlus
> ちょっと話がずれますが、リバースエンジニアリングの話が出てきたので。
以前使っていた JBuilderには obfuscator がくっついていました。
NET開発IDEは持っていないのでわからないのですが、もしかすると、BorlandのIDEならば、今後
NET用のobfuscatorがくっついてくるのかもしれませんね。
ところで、NETって何のために作成されたんですかね？
６４bitしとUNICODE対応へのスムーズな橋渡しを行う為？
MACだと、できてもないのに狼少年のように騒いでいた Silver Dragon の為？
Linux対応（MONO）の為 ？
MONOで作りました的な話は、私の周りでは見あたりませんが、
皆さんは、結構作られているんですかね？
dev
中村様、いつもありがとうございます。
>>ネイティブと.Netで同じような簡単なソフトを拵えて、パフォーマンスのチェックを
>>した方がよさそうですね。
>
>ケースバイケースでしょうね。
>
>純粋に大量のデータをメモリ上で処理するようなアプリでは、
>.NETの分が悪そうですが、
>
>ここ数年、.NET でいくつかの 準リアルタイム系のサーバアプリケーションを
>作りましたが、結局速度を決めるのは、ネットワーク、DB、ファイルI/O
>で、.NET そのものの遅さが問題になったことはありませんでした。
情報ありがとうございます。
先のメールで、両者で同じようなソフトを作ってと書きましたが、
Delphiでならサクッと書けるようなものでも、C#で書くとなると
その書き方一つでパフォーマンスにも差が出てしまうだろうから
正当な評価が出来るものなのか？と思っていました。
そこで、ふと思ったのですが・・・
例えば、通信部分は.Netを使って、解析部分はネイティブで開発して、
両者の間で簡単にプロセス間通信というか、データの受け渡しなどは出来るものなのでしょうか？
(メモリマップドファイルみたいな感じで。)
それが、普通に出来るのであれば、どちらかに固執しなくても、細かくソフトを分割して
ケースバイケースでこれは.Net、これはネイティブで、ということも出来るのかなと
思ってきました。
ちょっと、そこらあたりの文献を探してみたいと思います。
iwamatsu
「いつかはWin32APIが無くなって.NETがネイティブになるかもしれない」
そうなった時、.NET対応しておけば移行が楽。ということかと
いいだしっぺがなんですが、速度は気にしなければどうということはありません。
ただ、Delphi7で作ったツールと同様なものをC#で作成したら体感的に遅いと感じ
ました（GetFilesは便利だけど、FindFirstの方が早い・・とか）
.NETで開発していてもWin32APIは呼べますし、臨機応変に対応する事は可能なので
大きな問題とは思っていません。
完全な.NET対応ではありませんが現時点では仕方が無いとも思います。
リバースエンジニアリングに関しては未だに信じられないというのが正直なところです。
.NETだと普通にソース公開しているのと変わらないのでは？と認識しているのですが
（間違いであればうれしいので、だれか間違いだといってください）
岩 松
高木太郎
小山さん：
> ところで、NETって何のために作成されたんですかね？
>
> ６４bitしとUNICODE対応へのスムーズな橋渡しを行う為？
>
> MACだと、できてもないのに狼少年のように騒いでいた Silver Dragon の為？
>
> Linux対応（MONO）の為 ？
私より詳しい方が多いと思いますが、回答がありませんので……
分散アプリケーションを実現する（あえて「作る」とは言わない）ためだと
思います。 地理的にも離れ、プラットホームや性能がバラバラな構成要素を
うまくまとめ、目的に合った動作を確実にさせるために、クラスライブラリ
(ＣＬＲ）の標準化、通信手順やサービス提供方法（Ｗ？Ｆ）の標準化、
コンパイルタイミングの自由化（ＪＩＴコンパイル）などの取り組みが
なされたものだと理解しています。
間違っていたら、どなたかご指摘ください。
＃最近 Delphi と直接関係ない話題にばかり投稿しています。
mlus
高木 さん ご返答ありがとうございます。
>> MACだと、できてもないのに狼少年のように騒いでいた Silver Dragon の為？
これ Silverlight の タイポです。すみません m(_ _)m
> 分散アプリケーションを実現する（あえて「作る」とは言わない）ためだと
> 思います。 地理的にも離れ、プラットホームや性能がバラバラな構成要素を
> うまくまとめ、目的に合った動作を確実にさせるために、クラスライブラリ
> (ＣＬＲ）の標準化、通信手順やサービス提供方法（Ｗ？Ｆ）の標準化、
> コンパイルタイミングの自由化（ＪＩＴコンパイル）などの取り組みが
> なされたものだと理解しています。
なるほど、 CORBA ＋ Java みたいな感じですかね・・・・・。
Google も Native Client というのを出したようで、
Java、 NET、 Native Client の三つの選択ができるのでちょっとうれしいです。
dev
>一番の危機感はやはり、
>「いつかはWin32APIが無くなって.NETがネイティブになるかもしれない」
>そうなった時、.NET対応しておけば移行が楽。ということかと
全く持って、私の不安もずばりそこなんですね。
せっかく作り直すなら、今使ってるものより長く使えるようにしたいというのが
根底にありましたので。
なんか、この3行でモヤモヤがなくなったというか、スッキリしました。
Delphi Prism/C#で.Netの方向をメインに考えていこうかと思います。
皆様、本当にありがとうございました。
--
dev mailto:d...@arb-kids.net
中村拓男
dev さんは書きました:
>そこで、ふと思ったのですが・・・
>例えば、通信部分は.Netを使って、解析部分はネイティブで開発して、
>両者の間で簡単にプロセス間通信というか、データの受け渡しなどは出来るものなのでしょうか？
>(メモリマップドファイルみたいな感じで。)
>
.NET は ネイティブコードのDLL を簡単に呼び出せるので、Win32 と .NET の
混在は簡単です。
ただ、JITコンパイラ もなかなか優秀なので、下手なコードを書くと
負けるかもしれません。
遅そうな部分をプロファイラで切り分けて対処することをお勧めします。
＃100の検討は1回のプロファイリングにしかず(^^;
----------
東京都 日野市 中村拓男
大津修一
On Fri, 12 Dec 2008 10:03:24 +0900
dev <d...@arb-kids.net> wrote:
> そこで、ふと思ったのですが・・・
> 例えば、通信部分は.Netを使って、解析部分はネイティブで開発して、
> 両者の間で簡単にプロセス間通信というか、データの受け渡しなどは出来るものなのでしょうか？
> (メモリマップドファイルみたいな感じで。)
中村さんもおっしゃっているようにWin32のDLLを.Net Frameworkから呼び出すこ
とはいたって簡単です。むしろWin32上よりも簡単な気がします。
まず、[DllImport('DLL名l')]で対象DLLを指定し、その次の行でそのＤＬＬ内で利用す
る関数などを定義します。後は通常の利用の仕方とあまり変わりありません。
以下はBDS2006で作成したプログラムの抜粋です（したがって動きません）。定
義の仕方はすぐお分かりになると思います。
1点unsafe云々がありますが、それは.Net Frameworkの関連書籍を参照してみて
ください。
/////////////////////////////////////////////////////////////////////////////////////
unit test;
interface
uses
System.Drawing, System.Collections, System.ComponentModel,
System.Windows.Forms, System.Data,System.IO, System.Diagnostics,
System.Resources,System.Reflection,
System.Runtime.InteropServices,
System.Threading,
System.Text,
Microsoft.Win32;
type
TWinForm2 = class(System.Windows.Forms.Form)
strict private
procedure InitializeComponent;
{$ENDREGION}
strict protected
procedure Dispose(Disposing: Boolean); override;
private
{ Private 宣言 }
public
constructor Create;
function GetConfirmDialogHandle: IntPtr;
end;
[assembly: RuntimeRequiredAttribute(TypeOf(TWinForm2))]
{プログラム/アセンブリ情報}
{$UNSAFECODE ON}
[DllImport('user32.dll')]
function FindWindow(lpClassName,lpWindowName:String):IntPtr;unsafe; external;
implementation
function TWinForm2.GetConfirmDialogHandle: IntPtr;
begin
Result :=FindWindow(FILE_CONFIRM_DIALOG_CLASS, nil);
end;
end.
/////////////////////////////////////////////////////////////////////////////////////
dev
お二人の返信にてWin32のDLLを.Netから呼ぶのは簡単だと理解できました。
ありがとうございます。
もう腹を決めて.Netで行こうと思います。
VisualStudioとDelphi Prismを用意して、突き進みます。
(株)ブレーン 中村拓男
簡単とはいいましたが、入出力に用いる構造体に
固定長配列が含まれる場合とか、コールバックを使うAPI
を使う場合、属性、マーシャリング、GC の知識が
必要になります。
必用な知識が得られれば簡単ですが、最初はちょっと手強い
ですのでご注意ください。
Quoting dev <d...@arb-kids.net>:
----------
(株)ブレーン 中村拓男