1 :
デフォルトの名無しさん :
2010/03/09(火) 17:13:46 HTABOXコアに関するご要望はこちらへお願いします
現在ウインドウスタイルを操作するAPIの定義を検討中です。 ご意見を伺えれば助かります。
3 :
デフォルトの名無しさん :2010/03/09(火) 18:11:41
exeと同じ名前のhta,htmlを読み込むって事だけど、index.htaとかを読み込む方が良いんじゃないでしょうか? 人によると思いますが、自分的に同じ名前を複数存在させるの嫌なんです・・・
start.iniみたいな定義ファイルを導入して、柔軟な起動ができるように するというアイディアはどうでしょう?
6 :
某330 :2010/03/09(火) 18:56:17
残念ながら状況変わらず。 あと、F5 を押すと MSHTA 同等になるざます。 (メニューとか右クリックとかはそのままですが)
えぇ〜!!
認識引数、絶対パス結果をMessageBoxで表示するバージョンを作りますので しばらくお待ちを。
URL上のLZHを置き換えました。 3回MessaeBoxが表示されると思うのですが、その結果を教えてください。
起動ファイルがないよ状態でhelpからビルド日時も確認してくださいね。
R:\ 直下に test.exe と test.html を置いた場合。 開始初期CommandLine "R:\test.exe" 第一引数認識文字列 空 絶対パス結果文字列 空 ビルド情報 HTABOX Mar 9 2010 19:16:08 リリース
起動はコマンドラインでしょうか?それともファイル名を指定でしょうか?
ファイル名を指定で実験したものですから、逆に通常起動で 引数を認識していませんね。明日までの宿題にさせてください。 ご迷惑をおかけします。
html->htlmのタイプミスがありました。LZHを入れ替えました。明日お暇な 時で結構ですから動作をご確認ください。
ファイラ (あふ) から起動した場合です。 エクスプローラからダブルクリックなどで起動した場合も同様。 コマンドプロンプトから実行した場合はメッセージボックスは一度だけ。 ファイル名を指定して実行の場合は r:\test r:\test.html 開始初期CommandLine "r:\test.exe" r:\test.html 第一引数認識文字列 r:\test.html 絶対パス結果文字列 r:\test.html で正常に起動しました。 引数を指定しない場合はファイラから起動した場合と同様です。
あー入れ違い。 だいたい正常に起動するようになりましたが、 コマンドプロンプトから引数指定の場合はうまく行きません。
このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
自分はhtmlからWIN32のGUIが呼び出しているというのに魅力を感じてて、それの機能追加を期待してる。 現状のメニューだけだとちょっとまだ使えないから何も出来ないけど、頑張って下さい。
ありがとうございます。 自分が使う為に作り始めて、こつこつ成長させてきたソフトなんですが、 書いてしまうと書く側のエゴが出てしまうんですね。ここでいろんなご意見 をうかがって、プログラムなんて書いたこと無い人が書いてみようかと思う 環境を作れたらいいなと思っております。
Windowスタイルなんですけど、動作途中で変更する必要はありませんよね。 だった起動時読み込みファイルという概念を導入して、 [STYLE_EX]hoge|hoge; [STYLE]hoge|hoge; で設定するだけというのが簡単でいいのではと、 あらゆるAPIは追加可能なんですが、 どっかの外人さんの書いたなんとかみたいに、 単にC++を遠まわしにやるだけっだら意味ないと思うのです。
起動時のスタイル設定の理由はもうひとつあって、 HTABOXコアの場合APIを使えるのは起動後なんです。軽量なHTMLの場合既に 表示された後になるかも知れません。たとえ一瞬でも表示されたスタイルが 変更されるのは美しくないだろうという理由もあります。
start.ini(仮称)を導入すれば、最初にその存在を確認し、宣言してあればその HTMLを実行するとか、さまざまなオプションを付けることもできます。私は この方向で行こうと思っているんですが、異論のある方いらっしゃいますか?
これ純粋にhtmlパースも独自なの? windowsのコンポーネントに依存しないのなら他のプラットフォームでも稼働するのかな?
実行ファイルの大きさから想像していただけると思いますが、独自パースは スクリプトのみです。HTMLも独自パースが理想ですが、IEと同じ大きさの 巨大なプロジェクトとなりますので個人では支えきれないと考えています。
>>25 速攻の回答ありがと
そうか、他のシステムには移植できないのか。
ieコンポーネントは化け物だからしょうがないかもね(つかffとかもコンポーネントベースになればいいのに)
>>27 そのIEコンポーネントを制限無く扱える手法が無いと感じたものですから
HTABOXコアが誕生したという経緯です。
総務省消防庁の提供する「救急オフラインシステム」が出力するXMLから 任意な事案項目、傷病者項目をデータとして取り出したり、国表統計 月報統計を出力するサービスの準備を開始します。 HTABOXコアをこういったピンポイントなサービスを提供する手段として 捕らえていただければより深いご理解がいただけると思います。
総務省が行政事務のクラウド化を推進するのは結構なことなのですが、自治体にはそれぞれのカラーがありますから、 単純にこの形式のデータを報告してくださいが行われた場合、2重にデータを作成し、突合するという本末転倒な状態 となります。かといって中央官庁が各自治体の御用聞きをおこなってシステムを設計するはずもありません。 私はこの隙間を埋めるソフトウエアサービスを提供することが自分に課せられた使命のひとつだと思っています。
通常ならそんなことは個人では不可能です。 大きな力に押しつぶされるでしょう。 しかしHTABOXシステムはそれを可能にするために書かれたソフトです。
皆さんもいろんな分野で活躍なさっていると思うのですが、その中で感じる矛盾 が、ソフトウエアで解決できるのであれば、どんどん開発して発表してください。 その業務のつらさを知っている人間だけがそこにフィットするソフトを書けるのです。 まだ生まれたばがりのHTABOXコアですが、そんなときの道具になれるよう努力してゆ きますのでご指導お願いします。
独白スレッドになっていますがお許しください。 「どうしてソース隠すことにこだわるのか?」についてお話します。 答えは「書いた人のアイディアがお金にならなければ人は育たない」と考える からです。どんなに優れた発想でソフトを作っても大手企業さんがその拡張版 をすぐ出すようでは書いた人の苦労って水の泡ですよね。 もちろん、ソースを公開し共同開発して人類共通の英知とするっていうのも素 晴らしいとは思いますが、それは片手間にそんなことをしても食べていける人 の場合で、少なくとも私にそんな余裕はありません。
アイディアを思いついたユーザーがネイティブコンパイラを扱える方なら何も いらないのですが、そうじゃないユーザーのアイディアをいかに簡単に具現化 して、保護するかというテーマで考えた結果が「HTML Applicationでソース隠 蔽」だったわけです。 でも旧HTABOXではMSHTA.EXEの壁を越えられず、最終的に名前パイプ経由とい う消極的な手法しかとれませんでした。これはデバッガでこそ見えないものの オブジェクトの単純GETで関数コードが見えてしまいます。 MSHTA.EXEを自分で書ければその問題を解決できるのは明白でしたが当時の私 にそのスキルはありませんでした。
旧HTABOXは、私にとって敗北の象徴となりました。最も目にしたくないもので あり、この世から消し去りたい事実となったのです。 HTABOXシステムとかHTABOXコアというネーミングはHTABOXという検索で旧HTABOX の事がヒットしないようにという単純な理由です。勿論、現状の隠蔽手法にも穴 が発見される可能性はありますが、だったらこうすればという対策を直ぐ発想で きるとこまで研究したつもりです。
誰でもプログラムを書き始めた当初はソースさえ難解なら見えたところで簡単 には流用できないだろうと思うものです。しかし、十分に経験を積むとアルゴ リズムは無視して、結局「どのCOMまたはどのAPIを使っているのか」を見るだ けで内容が推察できるようになります。 そいう観点から見た場合ソースが長大で難解に書かれていたとしても目くらま しにはなりません。また、ネイティブコンパイラの場合リリース前に配布EXE をメモ帳で眺め、要所となる手続きが推察不能であることを確認すべきです。
HTABOXコアのエンコード機能で実現したいことは 「書いた人の汗が報われる」 というごく当たり前でフェアなルールを導入しましょうということです。
HTABOXサーバーを使わなくてもHTABOXコアだけで今までの概念を打ち破るソ フトの配布形態、ビジネスモデルを実現できることを説明します。 HTABOXコアでフレームアプリケーションを作成し、子フレームをURL上のもの とします。サーバーには認証を設定せず、フルスペックなフリーソフトとして Vectorに投稿します。サーバーのログを監視すればユーザーの利用状況が判り ます。リリース当初はユーザーからの報告でバグフィクスが必要となりますが サーバー上のファイルを更新するだけで即座に対応することができます。 つまり、リリースしながら手元にあるという状態を作り出すことができます。
十分に広報活動が行われたと判断した場合、サーバー上の既存ファイルをスペ ックダウンさせ、フルスペックの機能が必要であれば別のソフトをダウンロー ドするように促します。別のソフトの内容は当初のフルスペックバージョンで あり、子フレームURLには認証を設定します。あとはアカウントを販売するだけ です。 従来の静的配布ではフルスペックを配布した後に制限を加えるなどということは できませんが、HTABOXコアならあたりまえのように実現できます。Vectorで何を 基準にソフトを審査しているのかは知りませんが、少なくとも一部をURL上の子 フレームとしている私のHTABOXエンコーダーが承認されていることは事実です。
寝る前に一言書かせてください。 HTABOXコアはMSHTA.EXEとは比べ物にならないくらい自由度が高い環境です。 逆な観点から言えばそれを使用する側の強い倫理観が求められます。もし、 この技術が悪用されるなら個々のHTABOXコアにシリアルを埋め込んで名前を 固定し申請がなければ使用できない状態にせざるを得ないでしょう。 私は決してそんな日は来ないと信じています。
長々と書いてしまいましたが、私がHTABOXコアに興味を持っていただいた方に
是非知っていただきたい事は書かせていただきました。
今一番重要なのは、実際にこの環境を使ったサービスが成功するのか否かです
から、しばらくはHTABOXコアを使った具体的サービスプログラムの作成に重心
を置きたいと考えています。このスレッドに直ぐレスポンスできないかも知れ
ませんがお許しください。
もっと荒れるかと思ったのですが、つまらないつぶやきにお付き合いいただい
てありがとうございました。
ttp://kuroda.bglb.jp/
42 :
デフォルトの名無しさん :2010/03/12(金) 16:34:03
プログラムの事は、殆どよくわからないのですが、hidebouさんの思い、 言葉を目にし、HTABOXコアがいかに魅力的なソフトであるかが伝わって きました。 HTABOXコアの誕生によって、多くのプログラマーの汗が報われる事を願って やみません。hidebouさんのサービスプログラムの成功を、心から期待して おります。
>>42 もう50才になろうとする爺ですが、爺になると開き直りの境地の達します。
万人からアホ呼ばわりされたとしても、たった一人の方の心に残る何かを
残せたらそれでいいじゃないかと...
ですから少し泣かせてください。ありがとう!。
今書いている「救急オフラインユーティリティー」に気が入らないのですこし つぶやかせてください。テーマは「C++とスクリプト」になるでしょうか。 バイナリの再利用というと響きはいいですが、要は他人の褌でいかに相撲をと るかの工夫なわけです。C++が一般的になる前は「関数」がライブラリを形成 していたわけですが、「クラス」という概念を導入し単一アドレスへの問い合 わせで他言語からもバイナリモジュールをコールできるようにしたのがCOMだと 理解しています。
ですからIDispatchのようなクラスをコールする動作でプログラムが形成され ていた場合、その実行速度はどんな言語でもほぼ同一となります。これは Microsoft Office系のオブジェクトをC++で操作したところで早くならないこ とから理解できると思います。こういう動作は主にスクリプトで書くべきです。
ただし、APIコールがループで繰り返されるようなケースでは個々のAPIがCOM でラップされていた場合「そういう名前あります?」「ああIDはこれですよ」 「じゃそのIDでInvokeしますね」が繰り返されるわけですから、膨大な時間 リソースを消費します。それはC++で書くべきでしょうとなるわけです。
話は変わりますが、スクリプトよりC++の方がバグの発生率は少なくなります。 スクリプトではVARIANTのvtしか型を限定する要素がありませんが、C++では明 確な型宣言が必要ですので、勘違いがおこりにくいのです。久しぶりに目にす るソースファイルにたいしたコメントが無くても即座に修正作業に入れます。 C++でWIN32アプリを書くと痛感するのですがGUIの形成は地獄絵図になります。 「メインウインドウにボタンを一個置いてクリックしたらダイアログを表示し ましょう」というプログラムを書きながら「onclick="hoge()"」で済む世界が 天上の世界に思えるのです。
一番楽なプログラミング環境はC++です。だけどGUI形成はDHTMLでささっと 済ませてしまいたい。という発想でHTABOXコアを眺めていただければ、狂気 乱舞する方がいらっしゃると思うんですが、だめですかね。
寝てる時にふと思ったんですが、C++向けには Microsoft Script Control msscript.ocx:{0E59F1D2-1FBE-11D0-8FF2-00A0D10038BC} の機能にプラスしてHTML解釈によりGUIが形成できるCOMDLLを提供すると 喜んでもらえるんでしょうか? HTABOXコアがやってる事の順番変えるだけで供給できるんですが。
Microsoft純正プログラム眺めていると、GUIはリソースのHTMLでささっと済ま せている場合が見受けられますよね。要はそれと同じ事をWIN32環境でできる ようにすれば.....ということはCOMDLLよりスタティックリンクできるライブ ラリの方がいいかも知れませんね。 今のところ余裕が無いのですぐ設計するわけにはいきませんが。
話題が変わりますが、私が何よりも重大な問題だと考えていることについてお 話します。「プログラミング新規参入者の減少」についてです。 私の住んでいる田舎の場合、どこの書店でも売れない本は置きません。ここ数 年で開発言語系の書籍は激減しました。プログラミングしたいという人はWWW 経由で調べてるからという理由ならいいでしょうが、現実は違うと思います。
私はシャープのポケコンでプログラミングに興味を持って現在に至るのですが 当時はそこでちょっとしたゲームとかを書くと、それは誰も見たことがない最 先端テクノロジーですので「凄い!」になるわけです。その後業務用OSである PTOSでBASICをいじり、MS-DOS、Windows、とプラットフォームが変化してゆく 歴史を目撃しているわけですが、今までいかに不自由だったかという理由を踏 まえると納得できる規格の変化も、いきなり新たな規格を突きつけられた人間 には理解できないという現象が生じています。
Windows以前、ひとつのプログラムはコンピューターを占有しました。つまり 他のプログラムは今動いているプログラムを停止しない限り起動できませんで した。その代わり、ディスプレイもキーボードも自分が好きなようにコントロ ールできますから、今のようにWindowsから肩を叩かれて動く配慮は必要なか ったのです。プログラム特に業務で使うものは現場で作るものという風潮が まだ残っていたと思います。事実私のような人間でもちょっと本を読めば実用 的なプログラムが書けたのです。
同時に複数のプログラムを動かして、アクティブなタスクを切り替えたい。と いう欲求はごく自然な流れです。今までキーボードは直接のハードウェア割り 込みだったものが、そうは行かなくなります。CPUは結局ひとつのストーリー しか理解しませんから、常駐する親プログラムがキーボードを監視して、どの プログラム向けに入力されたものかを子プログラムへ通知する必要が生じるの です。これがWindowsメッセージです。
CとC++についても全く同じような事が言えます。Cは言語というよりもアセン ブラをもっと使いやすくしましょうという規格として存在しました。重要なの はこの時主導権を持っていたのはANSIという営利とは関係の無い協会であった ことです。規格が定まればバイナリのライブラリは共有できる資源となります ので、結果的にプログラマーはハードウェアを意識せず標準関数を使いプログ ラムが書けるのです。
Cの誕生は劇的に生産効率を向上させましたが、大規模なプロジェクトの場合 名前の衝突が頻繁に発生します。Cでの名前は最終的にただのアドレスに変換 されるマークなのですが、リンク中に名前の衝突が起これば致命的な破綻と なります。複数の人間がひとつのプロジェクトに関わる場合、自分が使える 名前の範囲をペーパーで確認するといった作業が必要になるわけです。 C++のクラス、名前空間はそれを解決する素晴らしい英知なわけですが、その 苦労を知っていない、若しくは想像できない人間にとって、これほど煩わしい ものは無いわけです。
javaの誕生は新たなステージの幕開けでした。仮想マシンという規格層を設け そこに向かって動的なバイナリモジュール呼び出しをしようとするものです。 実行時の名前解決ですので、ソースコードに名前情報が含まれ、ソースが暴か れるという欠点はあるのですが、人間も賢くなったものだなぁーと思いました。 Java裁判がおこるまでは...
結局どんな理屈をこねようが、企業間の抗争の根底にあるのはマネーです。 Microsoft社のJava仮想マシンはSUNのそれを完全に凌駕していました。当然 Windowsには同社しか知りえない情報があるわけですから当然です。 悲劇は起こりました。正統な英知の集積であるJ++は息の根を絶たれることに なってしまいました。高速なJavaという夢はこれで終わったのです。
その後のWndowsにおけるプログラミング環境のグダグダはご存知のとおりです。 Microsoft社は所詮メインの開発プラットホームにはなり得ない仮想マシンを 意地になって開発し続けます。それにかかるコストを回収しようとあたかも 最高のものであるかのようにコマーシャルし続けます。結果的にユーザーは プログラミングそのものに失望し、現状に至っているというのが私的分析です。
誰でも最初はプログラミングなんて何のことだか解りません。大切なのは私 がポケコンでゲームを書いた時のように、ちょっとした自作プログラムに自身 が感動できるか、友人が「凄い!」と言ってくれるかだと思います。 私の息子達もそうなのですが、プログラミング=ビデオゲームだと思ってい ます。また、WWWの発達によって何でも目にできますから地味なアプリケーシ ョンを見せても「何これ?」になるわけです。開発環境に対する情報はめちゃ くちゃ、苦労して書いても誰も見向きもしない。開発環境を誤ればソースコード は丸見え。これで「さあプログラミングしましょう」と声高に叫んでも、 若い人がついてくるわけありません。
確かにWindows上でネイティブアプリ並に高速な Java VMが存在していたらならば かなり歴史は変わっていたでしょうねぇ .NET Frameworkが産まれなかったかも
HTABOXコアはそんな現状に対する私にとって精一杯の抵抗なんです。 大げさに聞こえるかも知れませんが、この国は若者たちの英知無しでは滅び ます。 どんな些細なプログラムでも自分が使って便利だと思えるツールは誰かが喜んで くれます。「ありがとう」という声は必ず作り手のパワーとなります。 いかにそれが虚しく空を切ろうが、私は死ぬまで叫び続けようと思います。 「さあプログラミングしましょう」
>>61 こんなスレに目をとめてくれてありがとう。
>>63 いえいえ、手軽にGUIを構築できるHTABOXには期待しています
ソースもバグだらけなら日本語も不自由なんですが、明らかに間違っているので 訂正させてください。 57:ソースコードに名前情報が含まれ->クラスファイルに名前情報が含まれ
寝苦しくて起きてしまったので爺さんの戯言にお付き合いください。 「私が抱いている具体的な構想」についてです。 こんな環境を提供したところで、みんなが急にプログラム書き始めるとは思っ ていません。プログラムを発表できる場を提供することが絶対必要だろうと 考えています。今までの私の断片的な書き込みから想像できると思いますが、 「プログラムの100円ショップ」を実現したいんです。
変な話ですけど皆さんの時給っていくらですか? 単純に労力が金額に換算できるとすれば、本来1時間かかる面倒な作業をその プログラムで回避できればその時給分の価値があるはずですよね。実際にオー ダーメイドの業務アプリケーションなら結果的にコストダウンだと判断されれ ば導入されるはずです。 日常のツールでそれを主張しても受け入れられないでしょうから「100円」が いいのではないかと考えています。
本当にちょっとしたツール例えば「HTMLタグ名だけを全部小文字に統一」みた いなのが沢山あって、手作業じゃ面倒だし、安かったらお金で解決しちゃおう というニーズに答えるシステム作りをしたいんです。 HTABOXシステムは実行時のプログラム配布を実現できますので、場合によって は「使っただけ課金」というシステムにすることもできます。
私はクラウドがもたらす本当の恩恵ってそういう事じゃないのかなって思うん です。従来は静的に配布される高機能なエディタの正規表現機能を使って小文 字に変換するしかなく、結局お金も時間もかかったわけですが、そういった用 途のためのツール群がオンライン上にあって必要な時にチョイスできる状態。 プログラムを投稿する側もエディタ全体を設計して競い合う必要はなく、自分 が得意とする分野のアクションで個性を発揮し、確実に収益が上がる状態。 私がおぼろげながらも、目指しているのはそんな未来なんです。
そこで才能を開花させる若者が出てきて、レクサスの一番高いのに乗って 「プログラム書くってステータスの高い仕事なんだ」と世間が気づけば 後に続く人も出て、私の仕事も一段落なのかなぁっと思っています。
話がすごくあっちこっちに飛躍しちゃいましたが、このスレッド本来の目的 であることろの「HTABOXコアに対するご意見ご要望」を気兼ねなくお寄せく ださい。 「プログラムは書いたことがないんですが」という方のご意見ほど貴重な ものはないと考えております。そういう方をメインターゲットに書いたツ ールなんですから。
72 :
デフォルトの名無しさん :2010/03/17(水) 01:54:05
プログラムはちょっとかじった程度なんやけどなんかすごいことしているようで まーなにはともあれ体壊さんようにがんばったってや〜
>>72 私は3年間このことだけ考えて、このことだけ見つめてきたわけですので、
どこか感覚がズレてないかをここで確かめたいという気がしてるんです。
暖かいお言葉ありがとう!
ちょっとだけスレ違いな話をさせてください。 テーマは「ソースコードの美しさとは」になるでしょうか。 私にとって至福な時間というのは、自身が書いたソースコードに見惚れてい るときです。決して動作にホレボレするのではなく、ソースコードなのです。 ただし、その美しさは「機能美」でなければなりません。美術彫刻は確かに 美しいわけですが、機能が存在しないという点で物足りなさを感じます。
例えば「レーサー」とか「航空機」とか、ある目的のために研ぎ澄まされて 結果的に美しいという形の方に心を奪われます。プログラムで言えば「速度」 です。 世の中には「アーティスティックな美しいコード」のために存在する言語も あるそうですが、そういうことは「美術」か「文学」の世界で論じるべきこ とであって、最終的に情報処理の手段にすぎないプログラミングコードに 速度を犠牲にした美しさを求めるなどナンセンスです。 今夜は庄内平野も久しぶりに雪景色です。
スタート時にウインドウを最大化する場合のサンプルです。「救急オフラインユーティリティー」 の部分は各自のアプリケーションタイトルに置き換えてくださいね。 <script language=javascript onreadystatechange=""> window.onCreate = function() { var WM_SYSCOMMAND = 0x0112; var SC_MAXIMIZE = 0xF030; var Hwnd = WIN32.FindWindow("HTML Application Host Window Class", "救急オフラインユーティリティー"); if(Hwnd != 0) WIN32.SendMessage(Hwnd, WM_SYSCOMMAND, SC_MAXIMIZE, 0); } </script>
今までスクリプトしか書かなかった方はWM_SYSCOMMANDやSC_MAXIMIZEの定数が どこから出てきたのか不思議に思うかも知れませんが、WINUSER.Hにこの辺の 定数はずらりと書いてあります。ということは、無料版のVC++をダウンロード してWIN32SDKのヘッダを眺めているだけでもずいぶんと賢くなれることを意味 します。
例えばこういう動作をwindow.Maximize()にして最初から実装すれば?という 意見が生じるのはごもっともなんですが、一旦決めた「規格」は動かしがた いものになります。 不親切に感じるかも知れませんが、できるだけWIN32APIのイメージのまま実装し、 各ユーザーの好みで、関数としてくくってもらう方が望ましいと考えています。
なぜJScriptしかサポートしないのかという理由は、C++のコードへ移植しやす いからです。アルゴリズムをスクリプトで考えてそのままVC++のソースへ貼り 付け、型宣言を変えることはよくやります。勿論その逆もありです。 なんでVBScriptはサポートしないの?っていう声があれば技術的には何の問題 もなくサポートできるんですが、VBScriptじゃないと書けないという方はいら っしゃるのでしょうか?
プログラム初心者です、プログラマー目指すまでの情熱はないですが エクセルVBAから入って、vb、vbscriptなどほんの少しかじりました 結構そういう方は多いのかなと思いますがどうなんでしょ? 最初にvb系から入ってしまうと、{}や行の最後の;などの表記のある言語に違和感を 覚えてしまいます
>>80 了解しました。改良点としてVBScriptでのエンコードを課題とします。
現状で改善すべき課題と考えていることをまとめておきます。 「旧HTABOXのようにファイルを単一EXEにできること(リソース格納)」 「メインウインドウのスタイルをコントロールできるようにすること」 「VBScriptのスクリプトブロックでもエンコードできること」
IEにはDHTML Behaviorというのがあってあまり需要はないかも知れませんが GDIで単純な図形をスクリプトから描けたらいいかなぁと思っています。 LineTo(x, y)みたいな関数があって、描画結果をバッファリングで保持。 小学生なんかが喜んでくれるんじゃないかなぁっと思うんです。
IEにはVMLがあるのを忘れてました。あれをスクリプトで操作しやすいように ブリッジするものを作ればいいわけですよね。
知っている人は知っているから今更なんですが、私がHTML Applicationを書く 手法を紹介します。「MSE7.EXEの活用法」です。 Microsoft Office2000以降にはスクリプトエディタが存在します。2000の場合 は確かMSE.EXEでそれ以降はMSE7.EXEですよね。ただし標準ではインストール されないので、完全インストールしてofficeがインストールされたフォルダを 眺めると必ずいらっしゃいます。
これは単独で起動できますので、ディスクトップにショートカットを作成しま す。また、WORDやEXCELのEXEがあるフォルダの親を見るとMseNewFileItemsと いうフォルダがありますが、ここにはMSE7がファイルを新規作成する場合の テンプレートが存在し、デフォルトではcharset=UTF-8のHTMLとなっています。
MSE7.EXEを起動します。新規作成->ファイル->HTMLページを行います。 HTML Page1.htmがメモリ上に作成されます。編集画面を右クリックすると ページのプロパティーを変更するダイアログが表示されますので、私の場合 HTML3.2 -> HTML 4.0、UTF-8 -> shift-jis、VBScript -> JavaScript に変更して先ほどのテンプレートファイルHTMLPAGE.HTMを上書きします。 一旦MSE7.EXEを終了して再度起動します。
もう一度新規作成->ファイル->HTMLページを行います。今度は先ほどテンプレ ートを置き換えましたので、自分の望むキャラクタセットのHTMLなはずです。 HTMLの適当な位置にカーソルを置き、編集->スクリプトブロックの挿入->クライアント を行うとスクリプトブロックが挿入されます。作成されたスクリプトブロック 内にカーソルを置きCTRL + jを押してください。知らなかった人は感動の涙 にむせぶと思います。
適当なスクリプトを書いて、ブレークポイント(停止したい位置)でF9を押し 行の左に赤丸が付いた状態とします。デバッグ->開始やF5でHTMLを開始します。 MSE7の場合は未保存だから保存しますか?ときかれるのでyesと答えます。 ソースコードはブレークポイントで停止しますので、デバッグ、クイックウォッチ 等で変数の状態や場合によってはdocumentと入力して全体の状態を確認します。 この画面を見て知らなかった人はもう一度涙を流すはずです。
忘れてましたが、IEメニューからツール->インターネットオプション->詳細設定 ->スクリプトのデバッグを使用しない がデフォルトではオンですので、チェック をオフにしないと停止しませんから事前にオフにしておいてください。
また、デバッグで停止しているソースは基本的に変更できず、デバッグを停止 又は最後まで実行しないと、他のアプリが動かないほどリソースを消費する事 に注意してください。これでwindowやdocumentから芋ずる式に全てのオブジェ クトの状態を眺めているのと、手探りでコーディングしているのとではハイテ ク兵器と竹やりほどの差が生まれると思います。
HTABOXコアはTABLEのIDがMENUならWIN32メニューを生成しますが、この編集 画面上ではテーブルがそのまま行列に見えるので、メニューのイメージどお りなわけです。onclickが設定してWIN32APIを使わなければMSE7の状態でデバ ッグできます。 実はここでHTABOXコアをActiveXObjectするとWIN32APIが使えるのですが、 当然EXECOMサーバーとしてHTABOXコアをレジストリ登録しなければなりま せんので今のところ非公開機能としています。
IE8には標準でデバッガがついているようでしたが、自分の会社のMSDNも見れ ないブラウザでしたので、私はIE8そのものを使った事がありません。
MSE7.EXEはHTMLをデバッグする目的で存在しますので、ADSI関連のスクリプ トだったりするとインスタンスの生成そのものがエラーとなりますが、スク リプトをHTML中のブロックではなく単独JSとして作成し、開けばコードヘル パーが効いた状態となります。ブレークポイントはCSCRIPT.EXEの規則に則る 必要があるのですが、面倒なときはわざとエラー行を書くとMSE7.EXEがデバ ッガとして起動します。
MSE7.EXEは同じofficeのバージョンでもOSやIEのバージョンで振る舞いがすこ し違うことにも注意が必要ですから、ご自身の環境でファイルの拡張子をhta にしてみたりして動作を確認してください。 私が「HTML Applicationは生産性が高い」と考える最大の理由はこのMSE7.EXE が存在することなのです。「救急オフラインユーティリティー」は250Kほどの ファイルですが、MSE7.EXEが無かったらC++で全部書いた方がメンテナンスしや すいという判断をしたでしょう。
誤解がないように「単一EXE」手法について報告します。HTABOXコアはCD等の 書き込み不能媒体で配布されても動作することをガイドラインとしています。 したがって単一EXE格納はすべてリソース格納したres://経由とする予定です。 また、この機能はエンコードを同時に行われると考えています。
どうも書き込んだあとに日本語不自由なことに気づいてすいません。 ですから旧HTABOXのように何でもかんでも格納できるものにはなりません。 SRCでパスを指定するものなら格納してリソース参照に置き換えられると考 えています。
現時点での構想では エンコード動作時にソースHTML、画像等、アイコンをリソース格納し、 エンコード済みのHTABOXコアは著作保護の為に再利用できないという ルールがいいのではないかと考えています。
ホームページのリニュアールおめでとうございます。興味深く読ませていただき ました。昨今、書店ではプログラムに関する書籍も減り、為になる書籍を手にす ることが少なくなりました。hidebouさんのホ-ムページは、とても参考になりました。
>>100 ありがとうございます。
VMLで思い出したのですが現状ではエンコードすると<html>タグをHTABOXコア
で生成するためVML無効になってますね。
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns="
http://www.w3.org/TR/REC-html40 ">
は決まり文句みたいなので出来るだけ早く対応したいと思います。
こんな小さなモジュールでもリリースした時は、私のPCの上だけで幻を見ていて 「動かないよ!」「エラー後にPCが不調だよ!」「こんなん使えないよ!」の 嵐になるんじゃないかとうなされていたのですが、暖かく見守っていただいて ありがとうございます。 前職では若くしてお亡くなりになる方を多く見たものですから、この年まで生 きることができ、しかも私の書いたものに興味を持っていただける幸運に感謝 しております。
VMLはIEの独自規格のグラフィック描画規格ですが、HTML Applicationの場合 IE以外のエンジンで動かすことは無いわけですので積極的に使用すべきです。 FrontPageやMSWORDでHTMLをデザインすればワードアートやオートシェイプを 画像ファイル無しに使用することができます。
ん〜ん。せっかくFrontPageでワードアートのあるページを作成してもMSE7が 余計な変換を自動的に行うものですから痛し痒しのジレンマに陥りますね。 FronPage内のMSE7ならそれは起こらないのですが、今度はActiveXできない。 逆にMSE7でベースを作成し、最後の装飾としてワードアートを追加するのは ありかもしれません。
バージョン1.20ではHTMLタグのinnerHTMLだけをエンコードしていたのですが、 1.30ではソースコード全体をエンコードし<html encode='true'></html>の中 に保存しています。したがってVML等HTMLタグのアトリビュートが必要な場合 でも破綻しないことになります。また、HTMLタグの外に何かが書いてあった 場合もそのまま反映されます。
いよいよ兵糧が底をついたので、しばらくビジネスに専念します。
「救急オフラインユーティリティー」はあまりにベタな名称なので
「Medical information analysis system for ambulances」の頭文字をとって
MIASAサービスと名づけました。HTABOXシステムはクライアントCPUで動く
オンラインサービスを実現できますので20K程のGETにレスポンスするだけで
250Kを超えるスクリプトを認証付きでコントロールできるはずです。
ttp://kuroda.bglb.jp/miasa/index.htm
疑問なのですが、どうして html タグをエンコード時に残しているのでしょうか。 そもそも、なぜテキストベースでバイナリデータではないのでしょうか。
>>108 「html タグをエンコード時に残している」のは<html xmlns:v="....をそのま
ま再現する必要からです。
「バイナリデータではない」のはHTTP経由で破綻しないこと、HTML中のコメン
トとしても破綻しないが要求されるからです。
大変素晴らしい質問に、不自由な日本語でお答えしてすいません。 回答が的を得ていない場合は気兼ねなく質問してください。
結局VMLがらみで私のとった選択は MSWORDにVMLを置きPNG代替オプションオンでフィルター後HTMLを出力し、 生成された画像フォルダからPNGをコピーしMSE7で<IMG>参照するという 先祖がえりした手法になりました。静的なVMLはこれが一番確実ですね。
HTABOXシステムは非力なネットワーク環境、非力なサーバーを有効活用しよう
という思想の元に開発したのですが、
>>38 で説明したようにHTABOXコアだけで
も自宅サーバーでビジネスができます。
私なりの小規模サーバーに対する考え方を説明します。参考になる部分もある
かも知れません。
前職では通信関係つまり119番通報を受ける部署にいたこともあるのですが、 絶対に中断が許されない業務の場合「現有」「予備」という二重体制をしき ます。この場合「予備」は非常用ですのでやや能力が劣ってもかまいません。
自宅でサーバーを運用する場合もビジネスであるなら必ず「現有」「予備」 の体制をしくべきです。私の場合はNECが投売りした14kのサーバーを迷わず 2台購入しました。若干のオプションを加えても50kにおつりがありました。 現在は実験機と本番機という扱いですが、将来は両者を定期的に同期し、 障害がなくとも切り替えて、有事に備えることになります。
回線も二つ契約しています。ひとつは家庭用でひとつは業務用ですが、ルータ はNTT純正のものとし、プロバイダ、回線、ルータに障害が発生した場合は 単純につなぎ変えて80番を開ければ対応できるようにしています。こういった 柔軟な対応が可能なのはダイナミックDNSを選択しているからです。
サーバーでネットワークサービスを提供する場合、障害が発生した場合の シュミレーションは大変重要ですし、復旧にかかる時間を短縮する最も単 純で確実な手法が「安いのもを2つ用意する」ことだと考えています。
蛇足になりますが、私は古い人間なので枯れたソフトしか使いません。 具体的には非.NETであることをガイドラインとしています。 オークションでWindows2000ServerやSQL2000Serverがあったら是非確保して 情報が存在するうちにその取り扱いを研究することをお勧めします。
ついでですから、私がなぜサーバーサイドからの動的なプログラムの配布にこ だわるのかについてお話します。テーマは「実行権は誰のものか?」です。 従来の静的に配布されたなアプリケーションの認証は、認証前と認証後のバイ ナリを比較検討されてしまえば、必ずクラックされる運命にあります。しかも WWWの普及によって、たった一人のクラッカーがそれを発見すれば、瞬く間に その手法は周知の事実となってしまいます。
私が思うに、これを解決する方法は「サーバーのレスポンスがなければ完全な 実行体とならないプログラムを配布すること」だと考えます。 今までもソフトウエアの多くは「販売」ではなく「ライセンスの供与」だった わけですが、実際にその契約形態は絵に書いた餅でライセンスを供与した側が 「今日から使っちゃだめ!」と言ったところで意味を成さなかったわけです。
「実行を許可」する権利を製作者が保持できなければ、本当の意味でのライセ ンス契約は成立しませんから、今後のソフトウエア配布は総てHTABOXコアのよ うなものになって行くと考えます。使う側からしてみれば息苦しく感じるかも 知れませんが、結局、いくばくかの収益が上がらなければソフトウエアは生ま れませんし、しつこいようですが、それを目指す「人」も育ちません。
やがてコンピューターにキーボードが付いていたという事が昔話になるでしょ う。そのこと自体は必然でしょうが、そのプログラミング環境規格は単に企業 の利害で決定されてしまうでしょう。中間言語やスクリプトでどんなに優れた アプリケーションを書いても、直ぐにそのエッセンスを横取りされるでしょう。 私がどんなにあがいてもそんな未来がそこまで来ています。
Scripting.txtを見てもらえば解りますが、IDispatchインターフェースの継承 クラスには、GetTypeInfo(UINT as itinfo, UI4 as lcid, VOID as pptinfo) return VOID が存在します。スクリプトからこれを呼び出すことはできませんが、C++なら ITypeInfoポインターからこの情報を引き出すことができます。
この2つのタイプライブラリはほとんど総てのアプリケーションに必須な存在 だと思います。特にXMLは劇的にスクリプトを設計しやすくします。 単純な例として自分のPCの全ファイル情報を一旦取得し、あるアプリケーショ ンがインストールされた後と比較するプログラムを書くとしましょう。
通常は情報を構造体に保持して再帰的に検索したりするわけですが、作成途中 で、構造体が正しく情報を保持しているのかを確認したくなります。 この時設計の段階から構造体ではなくXMLDOMにデータを保存すれば、saveする だけで全情報を確認できますし、データの永続化にもなります。また、特定の 条件のファイルを検索する場合もXPathを指定した柔軟な条件設定ができます。
この辺の考え方やテクニックをこれからHTML Applicationを書き始める人向け に解説して公開することは重要だろうと考えています。正直そういった解説が なかったので、HTML Applicationは書きやすいはずなのに、情報が無くて使え ない手法。悪い言い方をすればアンダーグラウンドな手法と思われているのだ と思います。
>>128 貴重な情報をありがとうございました。参考にさせていただきます。
それぞれの分野で突き詰めた研究をしている方もいるものだと改めて感心しま
した。いつか子供たちがプログラミングに興味を持つきっかけとなるような簡
単なグラフィック命令系を追加できればと夢見ております。
小学校の図書室にプログラミング入門みたいな本があったのですが、子供たち が数値演算や文字列置き換えなんかに興味を示すはずがありませんから、グラ フィック系の単純なプログラムを解説していました。しかしそれは既に絶滅した N88-BASICでのプログラミングだったのです。
私はその事実を知っていろいろな事を考えさせられました。 教員に開発言語の推移を理解する能力があるのか?必要なのか? プログラミングという概念を理解するだけならその本は有益なのか? しかし、どう考えても実践不可能なサンプルを目を輝かせた子供たちが見るか と思うと、胸が痛みました。IEがあるかぎり有効な、単純なグラフィック命令 を作って子供たちに提供したいという想いはそんな動機なのです。
私は辛辣な言葉で小学校におけるコンピューター教育の現状を批判する文字列 を書いて、投稿せず削除しました。理由は投稿しても意味が無いからです。 いつか子供たちが自分で作った落ちゲーやシューティングを友達とワイワイ 言いながら書き換えている姿を見たいと思いますし、それを可能にする環境 作りも私の使命だと考えています。
>>133 貴重な情報をありがとうございました。
いろんなアプローチがあることは大変いいことだと思います。
HTABOXコアは初心者がとっつきやすくという事と、玄人が使えるということを
両立させたいという方向性で考えています。これは難しいことなんですけれど
小窓からWIN32APIやCOMの仕組みが見える状態がいいのかなぁっと思います。
>>135 とても興味深いサイトですね。
「言語から」という発想は魅力的ですが、最後はC++やってもらいたいなぁっと
いうのが私のスタンスになるでしょうか。HTABOXコアの特色はWEBプログラミン
グとローカルなプログラミングを融合させようという試みでもあります。
HTMLとJavaScriptを習得すればWEBページも書けますよね。最もずるい方法が
これじゃないかなぁっと思うんです。
HTML Applicationは「ずるい」よりも「反則技」という表現が適当かも知れ ません。初期XPの「アプリケーションの追加と削除」はこれで書かれていた ほどOS機能の一部だったわけですが、書きやすく強力なものですから悪用さ れて今日に至っているわけです。
HTABOXコアはEXEの起動を基点としますが、「書きやすく強力」が再び「悪用」 につながる可能性が無いとは言い切れません。その場合Windows環境全体に及 ぼす被害は甚大なものになるだろうと予測されます。その意味からエンコード 動作は私のサーバーで制御できる状態としていますし、今後はアカウント登録 したユーザーのみが利用できるサービスとなる予定です。
また話題が変わってしまいますが、多くの書籍でC++を紹介する場合iostream を使ったプログラミングを行うわけですが、あれは入門者に混乱をもたらすだ けで、むしろ入門者を蹴落とすトラップに思えてしまいます。 C++は演算子を再定義して自分が使いやすい言語を作れる言語と表現すること ができると思います。iostreamの構造は確かに対称的で美しいのですが、私は 必要だと思った事はありません。誰かが作った一つの例とて眺めるだけです。
オブジェクト指向の解説に至っては殆どの書籍が間違っています。入門者が 抽象クラスを最初から設計できるはずがありません。まず「猫」というクラス を書き、次に「犬」というクラスを書きます。そこで同じ事を二度書いている 部分に気づくはずです。つまり複数の具象クラスを書いて、そのメンテナンス が容易ではないことを理解できれば、共通点である「哺乳類」クラスの必要性 を感じるはずです。
抽象化とは単に同じ事を何度も書かない工夫と捕らえて差し支えないと思い ます。「哺乳類」クラスがあれば新たな「虎」クラスは最小限のコーディング で済みますし、すべての具象クラスに新たなメソッドを追加する場合でも基底 クラスが知りえる情報で処理可能ならば「哺乳類」クラスに追加するだけで 済むからです。
今は貧乏暇無しで、そんな余裕はないのですが、仮称「逆説C/C++解説」みた いなサイトを書いてみたいと思っています。ちょっとした言い回しの違いで 本来労力やミスを軽減するために存在するC++の規格が難解で使いにくいもの と誤解されているケースがあるように思うからです。
どうも読み返すと意味が変なこと書いちゃってますね。 140:は「オブジェクト指向の解説」->「クラス継承の解説」です。 お詫びして訂正いたします。
話のついでですから「オブジェクト指向」についてなんですが、これは難しく 考える必要は全く無くて「単にコピペしやすから」と考えれば素直に受け入れ られると思うんです。 個人のプロジェクトでクラス定義をヘッダファイルにして本体と分ける必要は ありませんからclass hoge{};の中に全部を書けば貼り付けることが容易です。
JScriptの場合、例えばファイル入出力オブジェクトを作れば、こまごまとし た関数を選んで貼り付けるよりもオブジェクトをコピペしてReadとかWriteな んていう直感的な名前のメソッドを呼んだ方が可読性が向上しますし、 オブジェクトのバグが発覚して修正を行った場合も、それを使用する他のプロ ジェクトへ貼り付け易いわけです。
プログラマーは「どれだけ横着ができるか」という事に貪欲でなければなら ないと思うんです。そうでないとコーディングテクニックは向上しませんし、 結局、長大なプロジェクトになった時、自分が作ったスパゲッティーで具合 が悪くなってしまいます。(多分に自戒の意味を込めて)
HTMLダイアログの表示でダイアログ自体の生成に時間がかかる場合、IEアイ コンがそのまま表示されてしまう現象を認識しました。サンプルにあるよう なそっけないダイアログでは発生しないようです。これはちょっと原因の 究明に時間がかかるかもしれませんが次のマイナーアップデートで対応した いと考えています。
C++はさぁ、一番最初に #include ... #include ... // この辺は簡単に理解できる using namespace std; // まったく理解不能 int main() // Cで関数の知識が無いと理解不能 { cout << "Hello World!" << endl; // いきなり行儀の悪い演算子オーバーロード、まったく理解不能。 // しかもまともな説明なしであっさり通り過ぎる } 初心者は拒絶反応起こすって
jsから入ったからmainとかはわかる includeも、そこにそのファイルの中身を挿入するんだろ? でもusing namespace std;はさっぱりわからんわ。
test
いつもの接続プロバイダがアクセス禁止対象となっていたので面食らってし まいました。 using namespaceは文字通り「名前空間を使いますよ」なわけですが、私は本 番ソースコードでこれを使いません。例えばstd::stringと書いた方が読みや すいからです。名前の衝突が起こらなければそもそも名前空間を使う必要も ないわけですが、Cで大きなプロジェクトを書くと変数や関数に直感的な名前 を付けたつもりが、既に使われていて、新たな名前を作ることが可読性を低 下させる場合は便利な規格です。
>>150 私の欠点は自分が興味を持った事へはとことんダイブするんですが、他の方が
何を書いているのかを全く知らないことです。ここでこういう貴重な情報を教
えていただけると大変助かります。ありがとうございました。
NILScriptについてはこれから勉強させていただきます。
HTABOXコアのスタートはMSHTA.EXEの置き換えな訳ですが、歴代のMSHTA.EXE
はそのサイズから想像できるように「Hello World」程度のことしかしていま
せん。ならば「Hello World」プラスアルファ程度のコードでHTML Application
をより自由なものにできるという実に横着な発想なわけです。
この横着には私なりの戦略がこめられていて、OSが変移しようがIEが存在すれ ば動くことを意味します。プログラムをリリースして、それがミドルウエアで ある場合、サポートする総てのOSを手元においてテストする必要があるわけで すが、MSHTA.EXEの為に用意されている環境プラスアルファなら枕を高くして 眠れるだろうという安直さで書かれています。
今回はbiglobe山形がアク禁になった代わりにASAHIがアク禁解除になったので こうして書き込みできていますが、両方アウトならダンマリになってしまいま すね。私は携帯電話という物が大嫌いですから息子にでも頼んでここに事情を 報告するしかないでしょうね。 でもこうして他人のサーバーに好き勝手なことを書いて、多くの方が目を通し ていただけること自体には感謝しています。2chって素敵な文化だと思います。
これからWindows上でプログラミングを書こうと思っていらっしゃる方向けに 私が思う最短経路を説明したいと思います。勿論、遠回りがいけない事である とは思いません。私自身何年も遠回りをしたのでこういう意見を持つことがで きたのは事実ですから、いろいろな手法を体験し早期にその長所、短所を見抜 く事が理想ですが、老いぼれの独り言とお許しください。
アプリケーションはユーザーの操作を認識する手段を持たなければなりません。 そうでない物も存在しますが、多くの場合操作対象のファイルパスやURLや処理 におけるオプション等を実行前に指定してもらうためのユーザーインターフェ ースが必要です。これは皆さんが見慣れているメニューやボタンです。 これは多くの開発環境で見た目通りに部品をドラッグして作成できますが、一旦 作成したデータを再利用しようとすると、使いにくい事に気づきます。最悪の 場合、自動的に生成された位置情報データがクラッシュし、最初から作り直さ なければならない状況に陥ります。
かと言って、総てのコントロールをソフトウエア的にソースで生成しようとす ると一旦実行して見た目を確認し、数値を変化させてまた見た目を確認すると いう作業を総てのコントロールについて行わなければならず、これも非効率的 です。 HTMLエディタでWEBページとしてユーザーインターフェースを設計すればこの 問題をスマートに解決できます。
HTMLに関する知識は貴方が世界に向かって何かを発信する時に必ず必要になる 知識でもあります。なぜなら、貴方の作ったプログラムを実行する前にそれを 紹介する貴方のWEBページが評価されるからです。 HTMLに関する情報を収集する場合、情報の発信用に他のブラウザを対象とする のかアプリケーション用にIEのみを対象とするのかの判別をすることは重要で す。officeが完全インストールしてあれば\1041\HTMLREF.CHMが存在しますから ディスクトップにショートカットを作成して常に参照できるようにすべきです。
アプリケーションの動作を記述するのは多くの場合スクリプトで足ります。 「scd56jp.exe」で検索しWindows Script V5.6 ドキュメントを入手してく ださい。これも即座に参照できるようディスクトップにショートカットを 作成すべきです。 スクリプトに関する情報を収集する場合、HTTP経由の制約されたセキュリ ティー環境なのか、HTAやHTABOXコアのように自由にファイル入出力が許 されている環境なのかを認識することは重要です。
スクリプトはWindowsに存在するCOMコンポーネントを呼び出す事によって多く の複雑な処理を簡潔な記述で行う事ができます。ファイル入出力、XML、HTTP データベース、ADSI、メール送受信....etc この時、是非COMのタイプライブラ リを俯瞰してください。その情報を提供する努力を私も行います。
最後に既存のCOMコンポーネントでは実現できない機能を必要とした場合、 オリジナルなCOMDLLをC++で作成してください。HTABOXコアの場合はレジス トリに登録する必要のないプライベートコンポーネントのDLLでも機能します。 C++のソースコードを不安なく書けるようになるには確かに時間が必要かも 知れませんが、速度や柔軟性の面において最良のパフォーマンスを発揮する ことができます。既存のCOMでは逆に考えれば「こういう機能が必要」と予測 されている領域から出ることができませんが、WIN32APIを探検すれば誰も 見たことの無いマジックを披露することもできるでしょう。
最後に今後はアプリケーションをリリースする場合、サーバーをコントロール するテクニックが問われる時代となります。従来は一旦リリースしてしまえば 駟馬も追う能わずで製作者側が不利なものでも取り消しは効きませんでしたが サーバーに紐を付けた状態でリリースすれば、リアルタイムでコントロール可 能です。
毎度の事ですが読み返すと不自由な日本語ですいません。 私ごとですが、スランプに陥っています。ただただ休みたいというのが本心で すが、それでは干上がってしまいますのでエンコード後のデバッグという辛い 作業をしなければなりません。何か私が考える以上にエンコード後には制約が 存在するようです。解りしだいご報告します。
まず、エンコード後にdocument.charsetがunicodeになってしまう問題の解決 策ですが、非エンコードスクリプトブロックで明示的にshift_jisを指定して ください。 <script language="javascript" onreadystatechange=""> document.charset = "shift_jis"; </script>
このタイプライブラリにおける 「MSHTML.HTMLDocument」がdocumentのディスパッチです。ここに PROPERTYPUT HTMLDocument.charset return BSTR PROPERTYGET HTMLDocument.charset return BSTR が存在するので読み書き可能な文字列プロパティーとしてcharsetが存在する ことがわかります。
エンコードスクリプトのデコード完了をソースでどう認識するかについて考 えました。onreadystatechangeで非同期にデコードしていますので内部から イベントを発生させるには荷が重いので、デコード完了の証としてonreadystatechange に空文字がセットされる規則としたいと思います。結果的に以下のソースで デコードの完了を認識できる事になります。 <script language=javascript onreadystatechange=""> document.charset = "shift_jis"; window.onload = function() { //いずれかのスクリプトタグのonreadystatechangeにSYSTEM文字列が存在すれば0.5秒後に再検定 for(var c = 0; c < document.scripts.length; c++) { if(new String(document.scripts.item(c).onreadystatechange).indexOf("SYSTEM") != -1) { setTimeout("window.onload()", 500); return; } } alert("ok"); } </script>
現バージョンではデコード前にonreadystatechange=""を実施していますので デコード後に実施するように変更します。上記ソースのalert("ok");の部分を エンコードスクリプトブロック中の任意関数呼び出しに置き換える事ができる わけです。これによりユーザーの操作を待たずともグローバルに参照するオブ ジェクトを無警告でActiveXObject生成することができます。
現状のエンコード規則は生成されたオブジェクトのvtが9の場合関数呼び出し 以外のInvokeを禁止しているのですが、これだと自由度がなくてコーディング しにくいですね。typeofでfunctionが返された場合のみ厳格にして全体に緩い 規則に変更しようと思います。 ところでVBScriptはmainという関数があってもalert(main)とできませんから もともとソース見えにくいという認識でよろしいのでしょうか?
>>160 WSHの最新バージョンは5.8なのにドキュメントが更新されてないって変だよなぁ
>>171 まったく個人的な推測ですが強力すぎるからWSHを使って欲しくないと考えて
いるんだと思います。もっとおとなしい方法を使ってほしいんでしょうね。
ですからcscript.exe、wscript.exe、mshta.exeがWindowsに付属しなくなる日 が来てもおかしくないと考えています。HTABOXコアはその日に備えた対策という 意味もこめられています。
隠蔽コード関数中にwindow.showModalDialogという表現をするとエラーとなり windowを省略したshowModalDialogという表現だとエラーとなりません。 美しくない仕様ですが、今のところ許容していただくしか無いようです。
ダイアログのスクリプトをエンコードした場合dialogArgumentsの扱いにミス がありました。再構築時に読み取り専用であるdialogArgumentsを退避させて 別名参照させる時に同名大文字変数としていましたが、この局面では大小の 文字は区別されていないので読み取り専用への書き込みと判断されて致命的 なエラーで停止します。ちゃんと別名にすることで解決できたようです。
ダイアログに関してもうひとつ注意点ですが、メインウインドウが非アクティブ になった原因がHTMLダイアログの表示であった場合HWNDを捕捉して制御すると いうアルゴリズムですから、ダイアログ中のActiveXで警告ダイアログが表示さ れた場合は非アクティブになった原因が警告ダイアログとなるので制御しません。 現時点でこれは仕様ということにします。
174:の問題はIDispatchExのまま制御することで解決できそうです。 関数をIDispatchExのまま制御すればオブジェクト内の関数も同じ扱いで制御 できるので、従来オブジェクトの参照や列挙まで制限していたものを緩め、 関数コードのみを保護できそうです。
隠蔽スクリプトブロックは隠蔽という目的以外にもActiveX警告ダイアログ を表示させない目的でも使えます。例えばエンコードスクリプトグローバル var FSO = new ActiveXObject("Scripting.FileSystemObject"); が評価されても警告ダイアログは表示されず、初期化された変数FSOへの参照 はあらゆるスコープから有効です。 ただし、button等のHTMLエレメントonclickで直接代入を行う変数は遅延出現 する前に解決されるので非エンコードブロックで宣言しなければなりません。 関数呼び出しの場合こういった配慮は必要ありません。
VBScriptはJavaやC++と同時に眺めるとめまいがするので一切書かない人だっ たのですが、改めて言語仕様を眺めてみるとなかなか興味深いですね。 特にClassのTerminateイベントは魅力的です。JScriptではデストラクタが書 けないのでこれは羨ましい。VBScriptにはソースを暴露するtoString()も無い わけですから私自身VBScriptを再評価すべきかもと思っています。
VBScriptのクラスはプライベートメンバーが使えるのもいいよね 継承をサポートしてないのが糞だけど元になったVBにも無いから仕方ない (VB.NETなら継承使える) JScriptは delete Function.prototype.toString; を最初に入れとけばソース表示されないよ
>>180 「継承できない」なるほど気づきませんでした。
delete Function.prototype.toString;も大変賢い方法だと思います。
別インスタンスからtoStringを復元されないかを実験したいと思います。
delete Function.prototype.toStringは宣言したHTML中では有効ですが攻撃者 がダイアログを追加し、有効なtoStringを追加するとソースを見ることができ るようです。実験に使用した用本体側HTMLとダイアログ側HTMLを書き込みます。
<html> <head> <meta name="vs_targetSchema" content="HTML 4.0"> <meta name="vs_defaultClientScript" content="JavaScript"> <title></title> <meta NAME="GENERATOR" Content="Microsoft Visual Studio"> <meta HTTP-EQUIV="Content-Type" content="text/html; charset=shift_jis"> </head> <body> <INPUT type="button" value="main" ID=Button1 onclick="main()"> <INPUT type="button" value="crack" ID=Button2 onclick="crack()"> <script language=javascript> delete Function.prototype.toString; function test() { alert("naisho"); } function main() { alert(test); } function crack() { window.showModalDialog("crack.htm", test); } </script> </body> </html>
<html> <head> <meta name="vs_targetSchema" content="HTML 4.0"> <meta name="vs_defaultClientScript" content="JavaScript"> <title></title> <meta NAME="GENERATOR" Content="Microsoft Visual Studio"> <meta HTTP-EQUIV="Content-Type" content="text/html; charset=shift_jis"> </head> <body> <script language=javascript> var func = dialogArguments; func.toString = Function.prototype.toString; alert(func); </script> </body> </html>
それって本体側HTMLも改変しなきゃいけないんじゃ? そんなことができるならdelete文を削除したほうが速そう 関係ないけど.htaってなんでコンテキストメニューに編集が無いの? うっかり項目を追加するスクリプトを作っちまった new ActiveXObject("WScript.Shell").RegWrite("HKCU\\Software\\Classes\\htafile\\shell\\edit\\command\\", "Notepad.exe %1", "REG_EXPAND_SZ");
ここでのポイントはダイアログ側での func.toString = Function.prototype.toString; な訳ですが、これをできなくしているのがHTABOXコアの隠蔽原理です。 toStringを踏み潰した後にDISPATCH_METHOD以外は無視するよう言い聞かせて おけばプロパティーの追加は不可能になるからです。
>>185 確かに実際には「delete文を削除」は有効ですが、エンコードされた後にと
いうイメージで実験させてもらいました。ダイアログの追加は改編というよ
り単なる追加で可能だからです。
>>185 HTABOXコアでは右クリックを無視していますが、右クリック動作を書いて
メニューを表示させるというアイディアは思いつきませんでした。今後の
課題としたいと思います。
これってプロセスをサスペンドして全メモリ領域からスクリプトっぽい文字列を検索すればソースが読めちゃったりしないの?
>>189 とてもいい質問だと思いますが、詳しくお答えできないという立場をご理解
ください。
>>190 HTML5ならIE9で可能となるのかも知れませんね。私の眠っているVISTAを復活
させる必要があります。
エンコードスクリプトからダイアログを呼び出す場合、引数に具体的オブジェ クトを渡すよりもdocument全体を渡した方が安全のようです。 ダイアログ側で引数オブジェクトを変数格納する場合非エンコードブロックで var OBJ = dialogArguments.Script.OBJ; とScriptを介した参照で変数を作成し以降は当該変数への操作とするとエラー となりません。
プログラムのことはさっぱり分かりませんが、旧HTABOXを以前から見ていた者です。 スレが伸びているのを機に、HTAをゼロから覚えたいと思います。
エンコーダー以外の実践的アプリケーションを書いていなかったものですから 実際にダイアログを使ったり、ソース内にオブジェクトがあったりするケース での煮詰めが甘かった事を痛感する日々でしたが、ここに呟いた留意点をドキ ュメントに追加してバージョン1.40をリリースする予定です。 1.40は「実践的なエンコードルールの確立」と位置づけています。
ダイアログのスクリプトグローバルに var SYSTEM_MENUE = true; が宣言されていた場合、最大化最小化ボタンを付加することとさせてください。 これをダイアログのスクリプトスコープから行おうとすると複数のWIN32関数 を追加しなければならず、取り扱いが煩雑になるという理由からです。
タイプミスがありました。 SYSTEM_MENUE -> SYSTEM_MENU です。いつもよく確認もせず書き込んですいません。
実は今日の午前中はtdc.ocxが特定のパターンの時だけハングする現象に悩ま されました。原因はCharSetプロパティーはデフォルトで空であり適確な設定 例えば"shift_jis"が設定されていないと不安定であるという事実でした。 MSE7.EXEでコードをドラッグ生成するとデフォルト値を確認できますので原因 の究明がスムーズだったというわけです。
本日中には1.40のドキュメントを書き上げてリリースしたいと思います。 モードレスダイアログをアプリケーションウインドウのように扱えますから よりプログラミングの自由度が増すのではないかと考えています。 しかし、毎回思うのですがプログラミングは楽しいのに説明を書くのは苦手 です。くどい説明がいらないようなプログラムを書くというのは理想ですが なかなかそうもいきません。解りにくかったらどんどんダメダシしてください。
>>200 仕様をあれこれ考えてる時も楽しいけど
実装する時にはいろいろ妥協が必要なこともあったり
>>202 自分のためのツールだったらとことん尖がっていてもいいんですが、リリース
して使っていただくとなるとその妥協点を見出すことの連続になりますね。
こういったツールって「独りよがり」が一番の敵だと思っています。
XPのIE7環境で実験してるんですが、親のキャプションにモードレスを重ねて ダイアログをクローズすると親のキャプションの色が抜けてしまいますね。 WM_CLOSEで親へ再描画を促す処理を加えてみたいと思います。
逆ですね。ダイアログが表示されても親がアクティブなのでおかしくなるとい う解釈が正しいようです。解決のためにすこし実験プログラムを書く必要があ りそうです。
ダイアログの加工が終わるまで一旦SW_HIDEしてSW_SHOWしていた事が原因でし た。気づいてみれば本来アクティブなダイアログを非表示としてしまえば親が アクティブになるという単純なミスでした。まもなくファイルを更新します。
ファイルを更新しました。結果としてダイアログの構築がもたつくと若干ちら つく事になりますが、その対策についてはまた考えたいと思います。
再度ファイルを更新しました。ダイアログは構築後に表示されます。 一時的にWS_VISIBLEを剥奪するという手法が円満解決のポイントでした。
ダイアログにシステムメニューを付けるということはメニューも付ける可能性 があるわけで、WS_EX_CLIENTEDGEを付加しないとメニューとクライアント領域 がのっぺりしてしまいますね。将来は自由にウインドウスタイルを設定可能に したいとは思いますがダイアログのSYSTEM_MENUが宣言されていた場合に関し ては自動的にWS_EX_CLIENTEDGEを有効とさせてください。
ファイルを更新しました。SYSTEM_MENUが宣言されたダイアログはアプリケー ションウインドウとほぼ同じ3Dで窪んだ外観となります。アプリケーションの ように扱えますが、HTA用ウインドウではなくHTML Dialogですのでセキュリテ ィーの取り扱いに若干の制約があったと記憶しています。
呼び出されたダイアログでのActiveX生成時の警告ダイアログについて実験し ていて気づいたのですが、フレーム構成でないアプリケーションはHTA扱いで すから、そこから呼ばれたダイアログもHTA扱いなんですね。 ただしフレーム構成とした場合は子がHTMLでなければなりませんから、そこ から呼ばれるダイアログもHTML扱いになりエンコードしないと警告が出ると いうごく自然な展開なわけです。
もしHTAが子フレームで構成されていて、子もHTA扱いとさせることができれば さらに自由度が上がることは明白ですが、今後の課題としたいと思います。
>>213 <HTA:APPLICATIONという書き方でエラーとはなりませんがMSHTA.EXEと同様の
機能しか提供できません。作った本人も残念なのですがHTA:APPLICATION中で
使用する機能があれば実装しますので気兼ねなく書き込んでください。
いや、frameタグのセキュリティ属性のほうです。 <FRAME SRC="SUBFRAME.HTML" APPLICATION=YES >
>>215 すいません別の意味でしたね。恐らく
The APPLICATION attribute can be used only in HTAs.
という記述からすると同じ扱いになろうかと思いますが、初めて見る書き方
なので調べてみます。
理解できました。有効ですね。子フレーム宣言を <frame name="top" src="page1.htm" APPLICATION="yes"> でセキュリティーがHTA扱いとなるのですね。こんな便利な機能を私はまった く知りませんでした。教えていただいてありがとうございました。
極めて今更なんですが、HTA扱いだと何やっても警告出ないんですね。 実は長い間HTMLダイアログベースで同じ事をやろうと研究していた時期があっ たものですから頭こんがらがっていました。結局一人で出来ること、気づくこ とには限界がありますし、私は特にその容量が小さいので今回のようなご指摘 は値千金です。今後ともよろしくお願いします。
HTABOXコアのダウンロードファイルを更新しました。 exeはそのままですが、ドキュメントとサンプルの誤りを訂正しました。 お礼に差し上げるものも無いのでウインドウスタイル変更についてプロトを 作成したいと思います。HTML系のウインドウはFrameとDocumentにそれぞれ HWNDを持っていますので使いようによっては斬新なことができると思います。
まずHWNDの取得ですがダイアログの場合取得しにくいので一律に window.FRA_HWND、window.DOC_HWNDで常に参照できるものとします。 GetWindowLong、SetWindowLong、GetSystemMenu、SetWindowPos をWIN32名前空間に出現させればスタイルの変更が可能になるはずです。
補足ですが、当初window.FRA_HWNDとしていましたが、単にグローバル変数 FRA_HWND、DOC_HWNDとしています。 GetWindowLong、SetWindowLong、GetSystemMenu、SetWindowPos の各引数は本物と同じです。ただしスクリプトからのプロシージャ取得設定 は危険なのでWindowLong系のGWL_WNDPROCは無視しています。
ShowWindow関数を追加しその定数もサンプルスクリプトに加えました。
SetLayeredWindowAttributes もクレクレ
自分はスキルが無いから、身体に気をつけて頑張って!という感謝の言葉しか思いつかない・・・
p2でも無理なの?
ブログでやればいいのに
書き過ぎでアク禁食らったんじゃないかな。 もうちょっと抑えて書くといいね。 待ってます。
過疎板だからといって、200レス/月でアク禁になるのかよw
test
ご迷惑おかけしました。片方の回線で書けるようになったようです。
ttp://www5a.biglobe.ne.jp/~javajava/ari/style_test.lzh のプロトタイプでは以下のAPIが使用可能です。
GetWindowLong、SetWindowLong、GetSystemMenu、SetWindowPos、ShowWindow
SetLayeredWindowAttributes、AnimateWindow
また、右クリックでのポップアップメニュー機能も追加してみました。特に
このメニューの仕様についていいアイディアがありましたら助かります。
通常メニューについてもポップアップメニューについても将来は構造化した 定義をスクリプトから行えるようにする予定ですが、HTMLタグによる宣言の 場合は単純で使いやすい仕様が望ましいと考えています。 プロトでは新たにTDのinnerTextが-(マイナス記号)だった場合セパレータと する規則を導入しましたが、これでいいのかな?と迷っています。
HTABOXコアという器も改良を続けて行くでしょうが、器の中の料理の作り方 を紹介する事にも力を入れていかなければと思っています。今のところHTML Applicationは知る人ぞ知るという情報であって、肝心のこれからプログラム を学習しようという人へ情報をいかに広報してゆくか、導けるかが課題にな ろうかと思います。
>>230 同一IPから連続で書くと、一日でアウトになるよ
本来なれば私のサイトで意見交換するというのが本筋なのですが、私として も何かと目に留まりやすい2chをあてにしてしまっていることろが悪いのです。 昨日、今日とFrontPageやASPとにらめっこして気軽にご意見をいただけるシス テム作りを行っております。書いた本人は直後にコメントを消せるルールなら 書き込みやすいかなぁーとか思っています。
もっと本質的な問題を言うとSEOに優れている2chのような場では逆に失言が未 来永劫残る危険性があって発言にブレーキがかかる気がするんです。かと言っ てメーリングリストのように閉鎖的なのは前時代的ですし、ブログやtwitter もいいでしょうけれど話題がプログラミングだけにソースをきれいに表示でき ることを考えると自分でそいう目的のシステムを作った方がいいかなぁっと考 えています。
従来HTAやWSHは個人的に使うツールだった訳からとても趣味性の高い奥まっ た情報の交換が主だったと思うんです。「過去ログ見てから物を言え」的 ムードが参入者にとって障壁となっているのではと。これからという人が気 兼ねなく発言できる場が絶対に必要ですし、私自身その中で気づいてゆくこ とが多いと思っています。
とりあえずFrontPageのスレッド形式掲示板を使いやすく改良してそういった ニーズに答えられる努力をしていますが、HTABOXコアは特化されたブラウザと して使用することも出来るわけですから、twitterのように緩い結びつきで、 コミュニティーが形成されてゆく情報交換ルールを作ることも夢ではないと 思います。
>>241 まさしく情報の範囲として実に広範なものになりますから、細部までとなると
一人がどうこうしても追いつかない情報量になろうかと思います。
それぞれの分野で興味を共有しあって助け合える仕組みが必要だと思います。
>>245 C++で利用するならおっしゃる方法も素敵ですし、私は#importした後に生成
される.tlhや.tliファイルを直接眺めたりもします。要はスクリプトにコメ
ントとして貼り付けて必要な部分をコピペしやすい形式のファイルとしてい
るだけです。
またCOMの全体像を把握したい場合も整形されたタイプライブラリが便利です。 FileSystemObject.CreateTextFile(.......) return ITextStream ですから 今度は後方からITextStream.で検索をかけITextStreamのメソッドやプロパテ ィーを確認するといった具合です。
HTML Applicationという手法の最大のメリットは「省力化」だと思っています。 生涯のテーマとして少数のアプリケーションを維持するだけなら全部C++で書く のが正解ですが、行きずりのテーマをささっと短時間でアプリケーションに 仕上げてしまうような状況でこそ本領を発揮するはずです。それを可能にして いるのが他人の褌であるCOMの利用なわけですから、その構造を短時間で理解 する工夫がなければHTML Applicationのメリットが削がれてしまうと感じてい ます。
個人的には1週間で1本のアプリケーションをリリースする体制を目標にしています。 つまり年間で52本をリリースするわけです。「下手な鉄砲数打ちゃ当たる」を実践 するためにHTABOXコアを書きましたし、HTABOXコアを知らない人も短時間にどんど んリリースしてくる不思議な人間がいることに気づいてHTABOXコアの存在に気づく という展開になるんじゃないかと思います。
>>250 ジョイスティック系のAPIがあることすら知りませんでした。
今後勉強して喜んでいただけるよう努力します。
>>250 ちらりとMSDN見たんですが、いよいよ構造体がらみになりそうですね。
いつかは構造体をスクリプトで定義、参照できる規格を決めなければと思っ
ていましたので良いきっかけをいただいたと思います。JScriptならイメージ
が沸くのですがVBSriptのclassインスタンスがC++からIDispatchExに見える
のかというような実験を繰り返す必要がありますので、お時間をいただくこと
になります。
全くゼロから覚える場合、何をやったら良いか教えていただけますか? とりあえず、教育用言語とアルゴリズムは学生時代に習いました。 HTMLはスタイルシート以外は分かります。
>>254 HTMLでユーザーインターフェースを作ることを理解されていらっしゃるので
したら自分の興味がある機能を提供してくれるCOMを使ったスクリプトを書い
てみてはいかがでしょうか?私の知識の範疇にあれば使えそうなCOMを紹介し
て簡単な導入部を書けるかも知れません。
HTML、Script、COM、C++と広範な技術を活用できますが、最も重要なのは書い
てて得してる気分とか、楽しいとかだと思います。
>>254 私の経験で恐縮ですが、HTMLは単に表示されるだけと思っていた時に、結果を
ファイルに書き出せるだけでとっても感動した記憶があります。scrrun.dllに
存在する"Scripting.FileSystemObject"はテキストファイル入出力機能を提供
してくれるCOMです。クォート内のワードで検索すれば数十万件ヒットしますの
でサンプルは沢山あるはずです。
>>253 スクリプトを書くときにJScriptかVBScriptかで悩むかもしれませんが、HTML
中には両方書いてそれぞれグローバルな要素を参照できますので、両方を齧っ
て自分のスタイルに合った方を使えばいいと思います。
JScriptはJavaScriptの拡張ですので、他のブラウザ用にHTMLを書くときにも
知識が生かせます。VBScriptはIE限定ですがoffice系のVBAをスクリプトへ移
植する際には僅かの書き換えで済みますから便利だと感じています。
HTML Application用いてMSWORDやEXCELを操作するメリットはマクロのセキュ リティー設定に関わりなくマクロと同等の動作を実行できることです。一見 回りくどいように思われるかも知れませんが、VBAをVBScriptでの外部呼出し に替えることは簡単ですし慣れればJScriptへの翻訳も問題ありません。
ひとつ面倒な点があるとすればMSWORDやEXCEL固有の定数をスクリプト環境で 定義しなければならない事ですが、この問題を解決する目的でタイプライブ ラリ解析システムが生まれたと言っても過言ではありません。 //WdNewDocumentType type enum var wdNewBlankDocument = 0; var wdNewWebPage = 1; var wdNewEmailMessage = 2; var wdNewFrameset = 3; と宣言しておけばVBAでの定数名を書き換えることなくスクリプトへ移植でき るからです。
HTABOXコアはまだVBScriptを使用したスクリプトブロックのエンコードに対 応していませんが、対応後はマクロの記録でVBAを自動生成させ、少ない労力 でスクリプトへ移植し、1本のアプリケーションとしてリリースできる事をご 理解いただけると思います。これぞ究極の他人の褌でとる相撲だと思います。
>>262 C++側から見た場合、スクリプトから呼び出されたCOMの引数はVARIANTですが
JScriptのObjectの場合はIDispatchExポインターを保持しています。VBSript
のclassインスタンスもそうなら....という話です。
もしそうならC++側で要素を列挙できますから構造体の代わりに使えます。
「柔軟に扱える」の方が適切な表現かも知れません。うまくいけば必要な要 素のみを宣言した「省略構造体」を引数として渡せばC++側が要素を追加して 「完全構造体」を返すというルールが作れるかも知れません。
従来スクリプトから呼ばれるCOMを作成するためにはレジストリに登録する パブリックコンポーネントを作成しなければなりませんでした。全くのスク ラッチでこれを書くこともできますが事実上VC++のATLがないと困難でした。 HTABOXコアはその面倒を内部で処理し単純なDLLでもスクリプトから呼び出さ れるルールを実現しています。ATLなしでも書けるということは無料の2008で 十分だということです。
最近ASPばかり眺めててHTABOXコアに手を付けられずせっかく作ったプロトも リリースしていなくてすいません。ASPを眺めていて不思議な現象を発見した ので話の種にさせてください。#include virtualで別WEBにあるASPを参照し 被参照側のグローバル変数を呼び出し側で<%=HOGE%>すると見えないんです。
いろいろ設定を変えてもだめでIIS5.0でもIIS5.1でも同じ状態なのです。 でも、ひょんな事からその対策を発見しました。両方同じ言語な場合のみこの 現象が発生しているのです。JSとVB又はVBとJSならこの問題は発生しません。 引き換えにユーザー定義系クラスは参照できませんが、改めてVBScriptの 存在に感謝したしだいです。
という訳でMSE7.EXE(Microsoft Script Editor)でVBScriptを書く機会が多く なっているのですが、複数行を一度にコメントアウトする場合面倒だったり します。VBA環境の場合はその機能があるのですがMSE7.EXEにはありません。 これは検索置き換えで正規表現を使えば簡単に解決できます。コメントアウト したい範囲を選択して行頭「^」を「'」に置き換えればいいのです。
正規表現という手法はとっつきにくくて、各環境で微妙な差異があったりし ますが、使ってみると劇的に作業が楽だったり、ソースコードが簡潔になっ たりします。特にJScriptのreplaceでは置き換え文字列生成に関数を指定で きますので柔軟な置き換え結果を生成できます。
HTABOXコアではなくHTABOXサーバーの話題なのですが、IISで独自認証システ ムを構築する場合ISAPIフィルタDLLが必須となります。ASPは画像等のGET要 求を知り得ないからです。しかしISAPIフィルタDLLとASPはASPがIISインプロ セスで動作していない限り交信できません。つまりISAPIフィルタDLLはASPの セッション情報にアクセスできないというのが通説です。
HTABOXサーバーのアドバンテージはそれを実現している事です。IISプロセス とASPプロセスでそれぞれCOMをインスタンス化し、IISの保護されたプロセス 境界を突破する通信手段をCOM内に構築することでDLLとASPは連携できます。 勿論ASPは勝手気ままに消滅するかも知れませんから、DLL側のXMLインスタン スへ動作を報告し、DLL側は必要に応じてXMLを読むというからくりです。
ネットでプログラミング系の情報を見ている時に 「○○では○○したくてもできない」 というフレーズを見つけた時はチャンスだと思うんです。なぜならそれを実 現すれば確実にアドバンテージを得ることができると教えてくれているから です。
プログラミング業界の格言に「人のやっていないことはやるな」というのが あります。これは「万人がチャレンジしてだめな手法へチャレンジするな」 という意味です。決まった納期に仕様どおりの製品を納める仕事なら当然の ことですが、フリーランスプログラマーの場合は逆だと思います「人ができ ないからチャレンジする」でなければ新しいものは生まれません。
なんとかHTABOXサーバー側のシステムも営業稼動できる状態に漕ぎ着けたよ うです。技術的に可能か?が判明すると興味を失って実装部を煮詰めないの が私の欠点なのですが、霞を食って生きてはゆけないので睡眠時間の少ない 日々をすごしました。最終的に販売動作はサーバーが自動的に行い、私はコ ンテンツの充実のみに集中できるはずです。
プログラミングに限って言えばスキルとは頭の良さと無関係なものです。 要は「知っている」か「知らない」かの違いだけだと痛感しています。 私の家族に霞ではなくお米を食べさせなければならないので総てを無料閲覧 可能にはできませんが、実践的で理解しやすい情報を提供してゆく予定です。
朝4時からですから24時間耐久になりましたがFrontPage Server Extensionsが 管理するDBと独自認証系DBとの良好な位置関係に結論をだすことができました。 これによって書きかけだった救急隊用医療情報分析システムをサーバーに組み 込む作業も終了し一般公開へ大きく前進できたと思います。
こいつはソースで250Kくらいになる退屈な構造のプログラムなのですが、HTA BOXコアがきちんと大きなボリュームに耐えられるのかのテストでもありました。 勿論パース中は若干もたつきますが、サーバーからの認証ダイアログに答える 必要があるので、それに気をとられてあまり気にならないという素敵な誤算も あるようです。
いまだサーバー側の独自認証システムコードから抜け出せずにいます。 FrontPageが生成するVBScriptコードを再利用するという発想がいやらしすぎ るらしく、最後に蹴られるという展開を何度も繰り返してしまいました。 まさに「策士策に溺れる」の展開なので、初心に帰って朴訥なコードを書き HTABOXコアのほうに手をつけれるようにしたいと思っています。
<script language="VBScript"> Class HelloWorld Sub Print document.write "Hello, World" End Sub Function toString toString = "見せられないよ☆" End Function End Class Set hello = New HelloWorld </script> <script language="JScript"> alert(hello instanceof Object); //=> false alert(typeof HelloWorld); //=> "undefined" alert(typeof hello); //=> "object" alert(typeof hello.Print); //=> "unknwon" alert(typeof hello.toString); //=> "unknwon" alert(hello); //=> "[object]" alert(hello.toString()); //=> "見せられないよ☆" </script> VBScriptは難しすぎ
282 :
281 :2010/05/14(金) 18:55:11
間違えた ×unknwon → ○unknown
>>281 私も同じような実験コードを何度か書きました。
Class HelloWorldが直接JScriptから参照できればもっと有機的な絡み方がで
きるんですが、あくまでもNewしたインスタンスしか見えないようでした。
JScriptにVBという名前空間を、逆にVBScriptにJSという名前空間を出現させ
異なる言語の標準関数を使えるようにしたら面白いかも?という構想を持って
います。
VBSは撲滅すべき
>>284 私はVBS初心者なんですが、どうも一旦ばかばかしいミスのコードを実行する
と、その後正しいコードを書いてもエラーとなる気がしています。ひょっと
するとVBSはJSよりWindowsシステムに近いところで動くのかも知れません。
だとすればJSよりちょっと高速に動くという推理をしています。
本番サーバーの最終調整とセットアップドキュメント作成をやっています。 ひとつの目標として、私が書いたものでないHTABOXコアプラットホームの アプリケーションを販売できる体制作りを掲げています。そのためには認証 や登録を軽量でありながらも堅牢なものにしなければなりません。
私のような年になると、未来への沸き立つ希望などは消えうせて、何かを次 の世代へ伝えられればという想いだけになります。これからこの世界を担う 方たちが希望をもって生きてゆける材料をひとつでも作っておければと、し ょぼくれた目をこすりながらIISと格闘しております。
>>288 情報ありがとうございます。
今後は単純にZIPにしようと思います。
サーバーリニューアルの前に足元を固める意味でCOMについて再学習しました。 従来は他人様のレジストリに触りたくないのでサイドバイサイドにこだわって きましたが、エンコードを必要としないスクリプトの場合HTABOXコアが提供 するプライベートCOMの生成を待つのが面倒だと自分でも感じています。
従来パブリックCOMを書く場合はVC++のATLを使っていたのですが、いわゆる操作 手順でのプログラミングになるものですから、何かのきっかけでプロジェクトが クラッシュした場合のことを考えると大胆なチャレンジができませんでした。 本来はどんな事が起こっても単純にソースをコピーしてビルドすれば新しいプロ ジェクトが完成するべきなのですが、手順に頼った分複雑になるのです。
改めて完全なスクラッチでパブリックCOMDLLとパブリックCOMEXEのスケルトンを 書いてみて、今まで思っていたより簡潔な記述ができることに気づきました。 さすがに50行で1画面とはゆきませんが、150行で3画面くらいあればレジストリ への登録部分も含めた全体を記述することができます。どうもCOMの解説にはC++ 以前の情報がちらりと見えて学習者を混乱させているように思えます。
特にEXECOMサーバーの場合、プロセス境界を超えてポインターを認識する仕組み が必要になりますが、IClassFactoryとIDispatchで構成されるモジュールなら ole2disp.dll {00020424-0000-0000-C000-000000000046}に任せるだけという あっけない展開に拍子抜けしてしまったくらいです。サイトを新しくしたらCOMの セクションを設けて詳しい解説ができればと考えております。
近い将来のバージョンアップ時に開発者がそれを望めばHTABOXコアをレジストリに 登録し、冒頭から拡張機能を利用できるオプションをつけたいと思います。また、 GUIを持たないツールとしてのスクリプト用に同等の機能を持つCOMDLLを提供できる と思います。VC++の操作手順から完全に離れた形でCOMを記述することによって COMそのもののポータビリティーを向上させることができたからです。
自分なりに突き詰めてディスパッチ機構を見直した結果。ActiveScriptにしても HTML中のScriptにしてもルートにある(若しくはグローバルな)スクリプトディ スパッチは極めて軽量にラップすることができるという結論に達しました。 このラップ層にWIN32による低水準関数を置くことで本来はActiveXObject要求 である部分をHTABOXコアからのディスパッチ提供にすりかえることができます。
で何がどう変わるかというと。開発者はHTABOXコアをEXE形式のCOMモジュールと してレジストリに登録します。開発中のスクリプトには通常のCOMのように var WIN32 = new ActiveXObject("HTABOX.Application"); と記述して普通にデバッグできるわけです。
完成したスクリプトはHTABOXコアの内部リソースとして格納し配布します。 HTABOXコアは内部リソースを実行する際 new ActiveXObject("HTABOX.Application");という要求を見つけた場合 GetHtabox();という単純な関数呼び出しに置き換え、Invoke要求で当該 ディスパッチを返します。これにより配布形式ではレジストリ登録せずとも 同一の動作を実現できるわけです。
従来はもっと込み入った手法なので生成タイミングがどうたらこうたらという制約 があり、自分自身この規格でばりばり開発したいかというと???だったのですが 今回の研究で本当に足元をしっかり固めることができ、すっきりとしたルールを 確立することができそうです。
蛇足ですが、私がCOM開発する場合の環境についてお話します。多分これからCOM プログラミングにチャレンジする方には参考になると思います。これが明確になっ ていないのでCOMは敷居が高い分野だと誤解されている気がします。要は何が起こっ ているかを逐次確認できる環境こそ最も大切なのです。
まず、EXE形式なWIN32アプリケーションで徹底的にIDispatch若しくはEx継承 クラスをテストします。ウインドウは作成せず、AllocConsole();でコンソール を生成し必要な情報がすべて表示されるようにします。また全体をcatch(...)で 捕捉しどんなに軽微な異常も見逃さないようにします。
呼び出し側として同一EXE内にActiveScriptを生成し、試験するディスパッチを AddNamedItemで追加、スクリプトをパースしてディスパッチの挙動を監視します。 具体的にはAddRefやReleaseによるrefカウンターの推移等をコンソールへ出力 するのです。この段階でスレッドモデル、デバッグビルド、リリースビルド、 あらゆるチャレンジを行い、仕様を決定してゆきます。
十分な検証が行われたとしてもディスパッチ冒頭の関数は単にMessageBoxを表示 するような単純なものとします。これは実際にIClassFactoryを実装しCOMとして 外部からの呼び出し行った結果が期待通りでない場合、問題の切り分けを容易に する目的です。あらゆるプログラミング環境で共通な事ですが、特にCOMの場合 動かない原因をいかにすばやく特定できるかが鍵になると思います。
今日は新たなHTABOXコアのロジックを試験していたのですが、今まで勘違いして いた部分に気づきました。documentの構築直前のタイミングで独自ディスパッチ をScriptへ送りつけることはできないと認識していたのですが、何の問題も無く 可能であることがわかりました。なんか得したような損したような複雑な気分です。
HTABOXコア2.0(仮称)はスクリプトを起動起点とすることができます。つまり WIN32.CreateWindow(html);で任意のHTMLコードをHTA実行できます。これは 最初に生成したWindowを破棄し、新たなWindowを生成できることを意味します。
また、実行関数はすべて起動スクリプト側に記述し生成されたHTAインスタンスへ 転送する形で実行可能です。結果的にHTMLコードはボタンやメニューなど外観に 関する事柄のみとなり、ビューとドキュメントの分離が可能です。また、ソース 隠蔽は起動側スクリプト全体というルールを設ければ、より堅牢な隠蔽ができます。
自分でこのHTABOXコア2.0用スクリプトを書いて笑ってしまったのですが、 HTMLからコールされる関数を2,3宣言しwhile(IsWindow(hwnd))で待機する スクリプトの構造はWIN32APIで書いたWindowsプログラミングのミニチュア版 のようでとても愛らしいものになります。近日中に実験器を公開したいと思います。
<html> <script language="javascript"> window.close(); </script> </html> 何かこのようにウインドゥを閉じるとエラーダイアログが出るのですが
>>307 貴重なご指摘ありがとうございます。直後にcloseすることは想定しておりません
でした。現状では操作すべきウインドウが無いのでウインドウクラスのアドレスを
登録できないという内部エラーメッセージが表示されます。次期更新時にはウイン
ドウ実体が存在するかのチェックルーチンを追加しますので今後ともご指導お願い
いたします。
mhtafile
ttp://www.vector.co.jp/soft/winnt/util/se408592.html > HTMLは、HTMLファイルと埋め込みコンポーネントを「Web アーカイブ、単一のファイル」のMHTMLファイルにできますが、
> HTAには、そういうファイル形式がありません。
> なので、HTAファイルと埋め込みコンポーネントがばらばらで持ち運びや管理が面倒です。
> そこで、HTAもMHTMLファイルのように単一のファイルにして実行する方法です。
HTABOXコアでもmhtmlドキュメントを実行ファイルとして扱えると有難いです。
↑自体はレジストリの操作が必要なので……
>>309 手元のMSWORDでmhtを作ってみたところ画像等がメールの様にBASE64エンコード
されているのがmhtであると認識しました。技術的には可能だと思いますし、今後
総てをリソース格納するさいに個別のリソースとせずこの形式を利用すればとても
スマートな処理が可能だと考えます。大変貴重なご意見ありがとうございます。
HTABOXコア2の基礎検証が終了しました。デモ版を明日公開できるかと思います。 起動はJS又はVBSファイルとなります。従来のWIN32にHTAを生成する機能を付加 しましたので、何度でもdocument.writeしてHTAを更新する事ができます。 HTABOX2.EXEをレジストリ登録すればwscript.exeで実行可能ですから//Dでデ バッグできますし、HTABOX2.EXEへのドロップ実行ではレジストリ登録無しに実行 可能です。
これでひとつ自分の考えていた理想が実現できた気がします。最も高級な言語と最 も小回りの利くC++の連携で従来のアプリケーション構築に対する概念を根底から 変革する提案ができると思います。これもひとえに愚かな私を暖かく見守ってくだ さる皆様のおかげと感謝しております。まだまだ改善すべき点が発見されると思い ますので気兼ねなくご指摘ください。
HTABOX2.0のデモンストレーションバージョンを公開します。
ttp://kuroda.bglb.jp/htabox/demo.zip 含まれるファイルはdemo.js、demo.vbs、HTABOX2.EXEです。
デモの手順はHTABOX2.EXEを起動しヘルプからご覧になれます。
スクリプトからHTMLオブジェクトを扱う感覚は慣れないうちは戸惑いを感じるかも
知れませんが、HTMLは外観の構成に専念し演算部分を隠蔽しながら起動側スクリプト
に置けることをご理解いただけると思います。
demo.jsのソースについて説明をさせていただきます。 var WIN32; //#define WIN32 // WIN32 = new ActiveXObject("HTABOX.Application"); WIN32.ScriptFullName = WSH.ScriptFullName; //#undef WIN32 WSH環境では当然ActiveXObject生成が必要ですが、HTABOX2環境ではエラーとなりま す。そこでプリプロセッサー命令を追加しました。#define op1 op2 はHTABOX環境で 単純にオペランド1文字列をオペランド2文字列に置き換えます。したがって#undefまで の2行先頭はコメントアウトされます。JSには条件コンパイルにより処理できる問題です がVBSとの統一した扱いを目的に追加しました。
var HTA = WIN32.CreateHtaWindow(); var DOC = HTA.document; var WIN = HTA.window; var SCR = HTA.Script; var HWND = HTA.FraHwnd; CreateHtaWindow()関数は非表示な空のHTAインスタンスを生成し、HTAへの操作を 提供するディスパッチを返します。スクリプトを毎回HTA.Scriptと記述しても間違い ではありませんが、そのつどDISPATCH_PROPERTYGETによるInvokeが発生するわけで すから変数でインスタンスを握った方が得策です。
var html = WIN32.FindSourceMark("#" + "BEGIN_HTML" , "#" + "END_HTML"); HTA.Open(); HTA.Write(html); HTA.Close(); HTA.Show(); FindSourceMark(op1, op2)関数はソースコード中にop1文字列を検索しop2文字列 との中間文字列を返します。スクリプトソース中にHTMLを書いた場合クォーテーション 問題が発生します。コメント中であればHTMLをそのまま貼り付けても文法的に破綻 しませんから、/*.....*/のコメント中に開始マークと終了マークを置いて抽出する わけです。関数の引数が"#" + "BEGIN_HTML"なのは"#BEGIN_HTML"と書くとこの位置 が開始と認識されることを防ぐためです。
function ButtonFunc() {WIN.alert("ButtonMsg");} SCR.ButtonFunc = WIN32.HideFunc(ButtonFunc); JSの場合 SCR.ButtonFunc = function(){.....}と直接追加も可能ですが、ここではtoString() を拒否する加工を行ってからHTAのスクリプトインスタンスへ関数を追加しています。 もし、HTML構築時に必要な関数である場合はHTA.Open(); とHTA.Write(html);の 間にこの追加を行うことで対応可能です。尚、alert()のようにHTA側コンテキストに しか存在しない関数呼び出しには配慮が必要な事に注意してください。
WIN32.WiteForWindow(HWND); 現在の仕様ではWiteForWindow(op1)関数はop1を引数にIsWindowVisibleが真である 条件で待機します。この待機が無く母艦スクリプトが終了した場合、生成した関数 実体を提供するスレッドが無くなりますのでHTA側からの呼び出しは失敗します。
今回公開するデモはHTABOX2.EXEをレジストリ登録してdemo.js,demo.vbsを wscript.exeで実行後、HTABOX2.EXEをレジストリ登録解除してアイコンへの ドロップ起動を行う訳ですが、実際のリリースバージョンでは旧HTABOXと同様 にドロップされたスクリプトは暗号化してEXE内に格納される予定です。
蛇足なのですが同じ動作のJSとVBSを書いて「なぜVBSの方がクイックに動くのか」 について納得できる要素を見出すことができました。JSと同じ感覚で set SCR.ButtonFunc = GetRef("ButtonFunc") と書いてもVBSではエラーです。ということはVBSは左辺へIDispatchExのQueryInterface を行わないという推理ができます。あくまでもIDispatchを基本ルールとして動作 しているとすれば「速いのはあたりまえ」という事になります。
従来HTA:APPLICATIONは私の生成手法では禁忌と考えていたのですがHTABOX2では 普通に使えるという実験結果でした。さらに考えてゆくと起動起点をスクリプトに した場合HTAにこだわる必要はまったく無く、むしろセキュリティー制限がHTAと 同等のHTMLインスタンスを生成した方が自由度が高いという結論に達しました。 HTABOX2.EXEを強引にメモ帳で眺めるとヘルプウインドウをCreateDlgWindow(); で生成している部分が見えるとおもいますが、HTAがプロセスと同じ寿命を持つの に対しこのウインドウは何度でも生成消滅できますし、複数が同時に存在しても 問題とはなりません。
HTABOX2は外から見ると何も新しい技術ではなくHTML系ウインドウを操作できるCOM なわけですが、内部は結構チェレンジングな構成となっています。まずODL、MIDLを 使用せず動的にTypeInfoを生成して引数チェック付きのDispatchとしています。 したがって関数名や引数の変更、ディスパッチ相互の関係等はソースコードを変更 してビルドするだけで完結します。このごくあたりまえに思える操作がATLに依存 するとMIDLがらみで大変気の重い作業になります。
また、ディスパッチを構成する段階でスクリプトディスパッチとWIN32APIによる 低水準ディスパッチの有機的な関係を実現していますから、ここは正規表現で楽 をしたいという局面でパース済みのスクリプトディスパッチを高速に利用すること ができますし、逆にスクリプトをパースする時点で低水準ディスパッチを呼ぶこと も可能です。
new ActiveXObject("HTABOX.Application"); で生成されるルートディスパッチ にはMotherという愛称がついていて彼女だけはIDispatchExです。この母なる存在 は子ディスパッチを乗せるコンテナとして機能しています。ですからJSなら WIN32.hoge = ..... で新たな機能を追加することもを可能です。
以前からの宿題であったVBSのclassはIDispatchExなのか?について検証して みました。結果はIDispatchExなんですがGetDispIDで新たな要素のDISPIDを 要求しても知らんぷりする頑固者です。ですから構造体代わりに使うためには 全メンバーが既存でなければならないということになります。まぁそれでも JOYINFOEX構造体の代わりに引数が13個ある関数を作るよりはましでしょう。
確かにスクリプトとHTMLを別記するのには戸惑いが…… BEGIN_HTMLからEND_HTML中に従来のHTA文法で記述したスクリプトも作動するようですが、 自分の書き方だとたまにInvoke〜ダイアログが出たりしたので、 正式版リリースの際にはエラーメッセージのリファレンスが欲しいところです。 それとHP掲示板にスパムが溜まっているようです
>>326 実に本質をついたご意見です。HTABOX2では単純にHTMLをドロップ格納するモード
があって、その場合ソースは隠蔽されず、JSやVBSを使ったスクリプトがドロップ
された場合隠蔽というルールがいいかもと考えています。
格納後(デモではドロップ)でエラーが発生した場合どこまでランタイムエラー情報
を表示すべきかで若干の悩みを持っています。隠したいという目的ならこのソースの
ここがエラーですという表示はおせっかいになるわけです。
HTMLドロップの場合は旧HTABOXと同じく名前つきパイプでexecScriptでもデバッガ でプロセスを捕捉する部類のカジュアルクラックには対抗できると思われまますから 皆さんのご意見を十分うかがってHTMLドロップとスクリプトドロップの使い分け、 その仕様については練り上げていかなければならないと考えています。そのために どんな小さな事でも結構ですので、「こういうルールがいい」というご意見をお待ち しております。 サーバーについてはご指摘のとおり「放置したらどうなるのか」の実験を行っている 状態となっておりまして近日中に全リニューアルを計画しております。
頭の中を整理してみると旧HTABOX手法+IHTMLDocument系参照拒否は十分な隠蔽に なりえるかも知れません。今だから話せますが旧HTABOXの最大の弱点はmshta.exe という名前のダミーを作られた場合、本物かの判断が難しいことでした。今はその mshta.exeを使わずに自プロセス内に同等のインスタンスを生成できているわけで すからそのアドバンテージを活用しない手はないかも知れません。
HTABOXコア用に書かれたC++ソースコードは正直言って成り行きで書かれていまし たので、この手の機能追加はストレスによる食欲不振を伴ったでしょうが、HTABOX2 用のC++ソースコードは内部もCOMで形成されていますので、まるでスクリプトを書く 感覚で動作を拡張できます。つまりAクラスはBクラスより前で宣言されていなければ ならないというスパゲッティーの要因から開放されているからです。
話があっちこっちになってしまいますが、スクリプト起動には大きなメリットがあ ると推察しているんです。アプリケーションにとって起動時のレスポンスは全体の 印象を決める大きな要因ですが、全部をHTMLパーサーに任せた場合もっさりした印 象をぬぐえないんです。実際にサイズの大きなアプリケーションでテストは行って いなのですが、ボタンやメニューでの操作を起点に必要とされる関数ならHTML構築 とは別スレッドのスクリプトエンジンでパースすればクイッキーな初期ウインドウ 構築が可能なのではないかという意味合いもあります。
JSまたはVBSをリソースとした場合の利点については上で述べられているのでさて置くとして
(個人的にはミニWIN32APIの将来的な拡張に期待。エラーメッセージもここで操作するとか)、
HTML(またはmshta.exe用のHTA)をリソースとする利点はプログラミング初心者向けに、
HTABOXコアの敷居を下げることに尽きるかと愚考。
JS・VBSリソース時の隠蔽はHTABOXコアの新手法、HTMLリソース時の隠蔽は
>>329 の旧HTABOX手法+IHTMLDocument系参照拒否というのは充分に有用だと思います。
>>332 ご意見ありがとうございます。HTMLドロップとスクリプトドロップの使い分けとい
う方向性で考えてゆこうと思っております。スクリプトドロップは細かな制御を必
要とする場合、単にHTMLの場合は細かな事を考えずにすむというのが理想ですよね。
今日は早速HTMLドロップで何が起こるかを検証していたのですが、ちょっと壁にぶ
つかりました。about:blankで生成して後からdocument.writeする手法に統一した
いというのが大きな方向性なんですが、HTMLドロップの場合逆に実ファイルを生成
して読ませないとデバッガが後付けのexecScriptの内容まで追跡してくるんです。
旧HTABOXの場合はスクリプト抜きのHTMLファイルを瞬間的にHDに書き込んでいたの で、デバッガはそのファイルに気をとられexecScriptを追跡できないという微妙な バランスの上に成り立っていたことに気づきました。当初は単純に考えていたので すが、もう一ひねり必要なようです。
HTMLドロップの対応を決定しました。単にスクリプトタグに hide="true"を検出 した場合当該スクリプトブロックコードは内部エンジンでパースされ外見的には WIN32.ScriptParse("{C8357EDC-0303-44E7-BC27-8332D5D4810E}", document.Script); というソースしか見えないということになりそうです。改めてスクリプトブロッ ク単位の内部パースを見直してみると構築タイミングがどうのこうのという件は 私の考えすぎで、スクリプトエレメントのイベントではなく直にパースしなさい と書くことでwindow.onloadより前にパースは完了するようです。
ですから何も考えずに「これはちょっと見せるのもったいない」と感じた部分を 隠すことができます。ただし現時点では内部パースする部分に window.onload = function(){....}自体を書いてもスルーされるようです。 内部パースブロックで関数を定義し、その後の通常パースブロックのグローバル スコープで直に関数を呼んでも関数の構築は完了しているという望ましい結果で したので、window.onloadを書いて関数を呼ぶことに問題はありません。
デモのファイルそのものを差し替えるのは説明文等を整理してからになりますので すこしだけ時間をいただきます。ただ勘違いが無いようにお願いしたいのはHTMLや HTAファイルをHTABOX以外で実行した場合メニューはただのテーブルに見えます。 例えば外部実行用にMSHTA.EXEをDLLでフックしてWM_COMMAND拾ってメニューを 動かすことはできるのですが、そこまではご容赦願いたいということです。
HTML中のスクリプト独自パースはVBSだと失敗しますね。JSの関数はそれだけで単独 ディスパッチですから搬送できるんですが、VBSの関数は本当に関数なんでそれだけ 引き剥がすわけにいかないんですね。クラスを作ってインスタンス化してもらえば 搬送可能でしょうが、VBSにはガベージ・コレクションが無いので誰がReleaseする の?ということになってしまいます。
この壁は崩せないと思いますのでVBS使いでソース見せたくない派の方はスクリプト 起動を使用していただくことになると思います。勿論隠蔽の必要が無いならばHTML にVBSを書いても問題ありませんし、両言語を混在させて隠蔽部分だけJSでもいいと 思います。どうしてもという要望があれば昔のHTMLのみ一時ファイル出力後名前付 パイプでスクリプト転送というモードを付け加えることはできますが、ファイルの 生成を必要としないというガイドラインを守りたいと考えますのでご了承ください。
HTABOX2.EXEを強引にメモ帳で眺めると内部で使用しているスクリプトのコードが いといろ見えると思うんですが、C++クラスの中でスクリプトコードをパースして いつでも利用できるディスパッチメソッドを形成しているんです。これだとWIN32 で書いた低水準メソッドとの混在が自然に記述できて生産性が劇的に向上します。 ただJSを採用した場合単なる関数もディスパッチを形成しますからそこでオーバー ヘッドが生じます。VBSを採用すればオーバーヘッドが生じない高速なものとなる はずです。ただVBSで唯一痛いのが名前の大文字小文字を区別できないことです。 Dispatchという機構そのものがそうなのでしかたがないのでしょうが、VBSの場合 コードを考えているより衝突しない名前を考えている時間の方が長いという笑えな い状況が生まれがちです。
ttp://kuroda.bglb.jp/htabox/demo.zipを更新しました 。demo.htaを追加しました。
HTABOX2.EXEがレジストリ登録されていればmshta.exeで実行できます。拡張子を
htmにすればMSE7.EXEでいつもの様にデバッグできるわけです。
HTABOX2.EXEへドロップした実行の場合メニュー構築、スクリプトブロック隠蔽が
有効となります。demo.htaでは<script language="jscript" hide="true">で
隠蔽を指定していますから、スクリプトのソースは
WIN32.ScriptParse("{2692E0BE-08C4-4FDE-9B61-7F7107EF18BD}", document.Script);
というような関数呼び出しにしか見えなくなります。GUID風の文字列はCoCreateGuid
に生成させていて単に予測不能で再現性のない文字列という意味で使っています。
デモではwindow.onloadに隠蔽関数が間に合うことを証明するためにHTMLウインドウ 生成前にMsgBox表示を行っています。その関係上暫定的にウインドウをHWND_TOPMOST 指定で表示し裏に隠れないようにしていますが、これはあくまで暫定的な措置です HTABOX2.EXE全般にいえることですが、動的document.writeですから画像等を相対 参照する場合のベースパスはありません。これはカレントディレクトリの参照規格 を明確にした後に個々で処理していただくことになると考えています。
どんな分野でもそうでしょうが、既存の物を壊さないと新しい物は創造できません。 C/C++でのプログラミングもしかり、どんなに巧妙に書いたつもりでも3日も経てば 改善すべき点が見えてきて全部をぶち壊したくなります。考えてみれば私の3年半 はその繰り返しでした。C++とは自分なりの言語仕様を作る言語なわけで、自分が 納得できる仕様を確立することができなかった時間と表現できます。
今回自分がたどり着いた結論は単純です。冒頭のコメントにこう書くだけです。 //クラスは原則としてIDispatch継承とし、IDsipatchExのコンテナに乗せること このルールによりコンテナのポインターさえ入手できればプログラムの全域で 総ての関数を自由に呼ぶことができるというごく当たり前なものでした。
結果としてIClassFactory継承クラスをひとつ用意すればそのままパブリックCOM サーバーとして機能するという副産物を生み出します。特にEXEの状態でCOMサーバ ーを形成すれば、DLLとは違い主体的に動作をコントロールできます。自身がスタン ドアロンの状態で起動された場合は内部実行メモリ空間へレジストリとは無関係に COMインスタンスを提供できることをHTABOX2.EXEは利用しているわけです。
自身のサーバーをチェックする気がおきないほど熱狂し、失望し、疲弊した1ヶ月 でしたが、私は私の問いに回答を見出せたと安堵しております。ちょうど1ヶ月前 我が家に来てくれた子猫は私の傍らの椅子で寝そべりながらその愛らしいしぐさ で私を慰めつづけてくれました。今回の仕事はその子猫に捧げたいと思います。
JSがまるでだめなVBS初心者としては、mshta.exe用HTA→HTABOXコア用VBSへの整形を補助する
スクリプトを書きつつ正式版リリースに備えるべきですかね
デモ版で試させていただいた結果では、まず
dim Document: set Document = HTA.document
dim Window: set Window = HTA.window
としておいてHTAのスクリプトには行末に:を追加、
FunctionまたはSubのプロシージャを抜き出して関数の定義に押し込んでGetRefでイベントと接続、
残ったHTAは行頭に'を追加して'#BEGIN_HTMLと'#END_HTML間に送れば
なんとなく動きました(省略しすぎ)。
それと一仕事終えたところの要望で申し訳ないですが、今回のデモ版で使われているHWND_TOPMOSTを
<body topmost="true">のような感じで呼び出せると有難いです。まあ他にも、
独自コンテキストメニュー
ttp://www.kiku-net.com/webcraft/TIPS/TIPS-003.html を使いたいのでHTAタグのcontextmenu="yes"復活とかきりがないんですが……
>>347 うちわのC++ルールがひと段落なだけでHTABOXについてはこれから本腰をいれさせ
ていただきます。力不足でファイルを出力しない形式でHTMLがドロップされた場合
VBSを隠蔽できていませんが、引き続き努力しようと考えております。
TOPMOSTについてはSetWindowPosをスクリプトスコープへ提供することでの対応に
なる予定です。HTAタグのcontextmenuは知りませんでした。現状では右クリック
イベントをメッセージループで独占していますから、余計なお世話になってしまっ
ているわけですよね。今後の課題とさせていただきます。
概ね技術的なチャレンジも終了し、方向性も決まってきたので、できれば複数のオフ
ィシャルユーザーで中枢部分を合議しなから開発してゆくという手法がとれないか
と考えています。今後ともご指導お願いいたします。
HTML中のVBS隠蔽なんですが、dim, sub, function 宣言されたものについては 隠蔽転送に成功しました。単にDISPATCH_PROPERTYGETが失敗したらGetRefという ロジックです。ただしclass宣言はNGです。はたしてclass宣言だけで実体の無い 状態が何者なのか今のところつかみかねています。
ttp://kuroda.bglb.jp/htabox/demo.zipを更新しました 。
DEMO.HTAには隠蔽VBSブロックが存在しHTABOX2.EXEへのドロップ実行ではソース
がJS同様に隠されることを確認できると思います。私は活きたVBSコードを書けない
のでVBS使いの方にこのスクリプトブロックへさまざまなコードを書いていただいて
不具合をあぶり出せれば大変助かります。classには未対応ということをご理解いた
だいたうえで。
VBSの隠蔽ブロック内でclassを定義しそのインスタンスも同一ブロックで生成すれ ば隠蔽可能というルールにはできそうです。今のところ set Obj = New Hoge で何が起こっているかを推察した場合class定義部分のコードを再評価してディス パッチを形成しているとしか思えません。現実的に定義だけを隠蔽して非隠蔽ブロ ックで実体を宣言することは無いと思いますので十分実用に耐えるのではと考えま す。
VBSは速度の点で魅了的なのですが、大文字小文字の件と翻訳単位が「行」という 概念に縛られているのが気になります。でも文句があるならvbscriptのインター フェースをラップしてParseに前処理を加えることでカスタマイズできるかも知れ ませんね。99%他人の仕事で1%だけの労力なのに自分で作ったふりができるところ がCOMの恐ろしさでもあります。
スクリプト起動とHTML起動の違いについてまとめます。 スクリプト起動のメリットは ...HTAの表示タイミングそのものをコントロールできる。 ...必要によっては何度でもdocument.writeで内容を置き換えられる。 ...デバッグ時のメニュー外観がリリース時と同じである。 HTML起動のメリットは ...通常のHTMLアプリケーションをそのまま実行可能である。 ...ディスパッチ転送を意識することなくコードの隠蔽が可能である。 思ったより後者の出来が良かったのでコンパクトなものなら後者で書きたいですね。 ちなみにHTMLドロップ時にC++内部で行われていることはスクリプト起動動作の手 順とまったく同じです。HTA生成後は"WiteForWindow"で待機しています。
<html>
<script language="vbscript">
Set xmlHttp = CreateObject("Microsoft.XMLHTTP")
xmlHttp.open "GET", "
http://headlines.yahoo.co.jp/hl?c=flash ", False
xmlHttp.setRequestHeader "If-Modified-Since", "Thu, 01 Jun 1970 00:00:00 GMT"
xmlHttp.send
Set DataFile = CreateObject("Scripting.FileSystemObject").CreateTextFile("./Res.txt")
DataFile.Write xmlHttp.responseText
DataFile.Close
CreateObject("WScript.Shell").Popup "OK"
Set xmlHttp = Nothing
Set DataFile = Nothing
Window.Close
</script>
</html>
デモ版全てのバージョンで上記コードでは4行目、
xmlHttp.open "GET", "
http://headlines.yahoo.co.jp/hl?c=flash ", False
のようなXMLHTTPオブジェクトのopenメソッドがHTAとWSHのどちらからの起動でも
IEスクリプトエラーとなるのを確認しましたので、ご報告いたします。
……ソース隠蔽を検証する能力はないんです済みません
356 :
355 :2010/07/29(木) 18:29:15
あ、デモ版の機能制限によるものという可能性を失念していました。
もしそうでしたら
>>355 はスルーしてくださると幸いです
357 :
355 :2010/07/29(木) 21:18:35
XMLHTTPオブジェクトをMsxml2.XMLHTTPまたはMsxml2.ServerXMLHTTPの4.0以降にすると
エラーはでないのですが、
>>342 のカレントディレクトリ絡みからかRes.txtが同一フォルダに保存されないですね
>>357 詳細な動作報告をしていただいてありがとうございます。まずはっきりしているの
は、あらゆるパスは絶対パスで処理していただく事になります。これはabout;blank
で生成後document.writeする事が要因なのですが、拡張機能が遅延構築される従来
の欠点を克服できるという大きなメリットの代償ですのでご了承ください。
XMLHTTPまわりのエラーについてはこれから検証してみたいと思います。今後とも
ご指導よろしくお願いいたします。
エラーを確認しました。
Set xmlHttp = CreateObject("MSXML2.XMLHTTP")
xmlHttp.open "GET", "
http://headlines.yahoo.co.jp/hl?c=flash ", False
「書き込みできません」が当環境Windows2000Serverで発生します。document.write
だからセキュリティー的に蹴られることはないと思うのですが、スレッドモデルが
原因だとすれば、貴重な勉強の機会をいただいた事になるかと思います。
クロスドメイン問題かも知れません。HTTP系はURL上のHTMLなら同一ドメインでしか 有効ではありませんよね。特例としてローカルファイルであることを条件に別ドメイ ンへのリクエストが許可されるとしたら、about;blank生成のHTMLだと蹴られると いうストーリーはありそうな話だと思います。 実ファイルを指定してHTMLを形成しながら生成前にWIN32ディスパッチを送り込む 方法がひとつだけあります。WIN32API的にHTMLダイアログを表示する方法です。 HTMLダイアログの引数オブジェクトとして指定したディスパッチは当然の事ながら HTML構築時に参照可能だからです。HTAタグによる修飾は無効ですがHTMLダイアログ ベースの方が自由度が高いと評価する理由はこの辺にあります。CreateDlgWindowの 引数として実パスを指定するオプションを追加したいと思います。
基礎的な検証は終了しましたが実装は後日となります。実ファイルを指定した場合 HTTP系のリクエストは成功しますし、格納後はres://に変換することで実ファイル 扱いになると考えます。こんな小さな変更でも予期しない事態が複数発覚し、その 都度アンドキュメントな部分の学習をさせていただいていることをありがたく感じて おります。
今回のHTABOX2デモには「スクリプトからコントロールできるHTMLオブジェクトが あれば、それがHTAでなければならない理由は希薄なのではないか」というテーマ を持っています。「実ファイルでなければエラー」という事態は想定内で、そうい う要求のために親を持たないHTMLダイアログをHTAと対等な機能を持つクラスとして 用意していた次第です。
実際にHTMLダイアログにWIN32ディスパッチを組み込んで生成過程を眺めるとなか なか興味深い動きをします。好意的に解釈すれば「そいういう使い方を想定してい ない」になりますし、そうじゃない見方をすれば「そういう使い方をして欲しくな い」になります。改めてプログラミングとは終わりの無い推理ゲームだと痛感しま した。この技術よりスケルトンHTMLファイルを読ませ、レジストリに依存しない形 で注入したディスパッチ経由で内容を自由に操ることができます。
ttp://kuroda.bglb.jp/htabox/demo.zipを更新しました 。
暫定的にCreateDlgWindowはひとつの文字列引数をとります。従来の引数無しと等価
な呼び出しはCreateDlgWindow("about:blank")となります。
HTTP GETを実験するためのソースを提示します。c:\http.htmを以下の内容で作成します。
<html>
<head><title></title></head>
<INPUT type="button" value="Button" ID=Button1>
</body>
</html>
以下の内容のVBSを実行します。
dim WIN32
'#define set '
set WIN32 = CreateObject("HTABOX.Application"):WIN32.ScriptFullName = WSH.ScriptFullName
'#undef set
'HTAインスタンス、主要ディスパッチ、HWNDを変数に保存しています。
dim DLG: set DLG = WIN32.CreateDlgWindow("c:\Http.htm")
dim SCR: set SCR = DLG.Script
dim HWND : HWND = DLG.FraHwnd
sub GetHttp()
Set xmlHttp = CreateObject("MSXML2.XMLHTTP")
xmlHttp.open "GET", "
http://headlines.yahoo.co.jp/hl?c=flash ", False
xmlHttp.setRequestHeader "If-Modified-Since", "Thu, 01 Jun 1970 00:00:00 GMT"
xmlHttp.send
Set DataFile = CreateObject("Scripting.FileSystemObject").CreateTextFile("c:\Res.txt")
DataFile.Write xmlHttp.responseText
DataFile.Close
WIN32.MsgBox "OK"
Set xmlHttp = Nothing
Set DataFile = Nothing
end sub
set SCR.Button1.onclick = GetRef("GetHttp")
call DLG.Show()
call WIN32.WiteForWindow(HWND)
call WIN32.MsgBox("正常終了")
set WIN32 = nothing
set DLG = nothing
set SCR = nothing
dialogArgumentsにWIN32インスタンスがある場合のメニュー構築部分を書いてな いので現状ではあまりHTABOX2で実行するメリットがないことを謝らなければなり ませんが、HTTP系のように実パスによるHTML生成が必要な時はCreateDlgWindow で対応してゆこうと考えております。
364に<body>が抜けていました。お詫びして訂正いたします。 <html> <head><title></title></head> <body> <INPUT type="button" value="Button" ID=Button1> </body> </html> 8月からサーバーを営業運用できるように整備する作業に入りますのでしばらくレ スポンスが悪くなるかも知れません。自身のサーバー管理スクリプトをHTABOX2の 上で書いてコモンダイアログやWIN32APIを追加してゆくつもりです。この場が無か ったら皆さんから励まされてプログラミングすることも無かったでしょうからこの サーバーを管理してらっしゃるスタッフの方にも感謝申し上げます。
久しぶりに人間らしい睡眠時間を取ることができました。少しだけ本音を吐露させ てください。私のやっていることはスクリプトをスクリプトの知恵の輪で解決しよ うとすることを楽しみとしてきた方たちにとって大変興ざめな事だと思います。 従来でもオリジナルのCOMを使えば何でもありでしたが、逆にそういたことをせず に知恵だけで問題を解決してゆくゲームがスクリプトだという捕らえ方もできると 思いますし、私自身それに興じてきました。
HTABOXコアそしてHTABOX2はEXEへのドロップまたは引数実行という起動手段をと ることによりレジストリに登録していない形でのCOM拡張を実現していますから 従来の「COMを使わずに」が「何もインストールせずに」だとすれば単に置くだけ で機能するHTABOXは「COMを使わずに」に含まれる反則技ということになります。
でも私が目標としているのは「スクリプトによるアプリケーション開発」なんです。 スクリプトを単に知恵の輪を楽しむルールではなしに実際に運用し、販売できる アプリケーションを開発する手段として昇華させる為にコードを書いています。 「スクリプトは所詮個人のツール用」という嘲笑はいつまでも存在すると思いますが 私は私の夢を実現するために愚直にもがき続けようと思っています。
HTABOX2は新たな可能性を秘めています。現状ではGUIを持つスタンドアロン アプリケーションを格納して配布することを目的としていますが、パブリック COMサーバーとしてDLLまたはEXEを構築する手順をすべてスクラッチコード で実装していますので、ドロップしたスクリプトをCOMDLLやCOMEXEとして 配布することに技術的障壁は存在しません。
したがって標準装備されたWIN32APIをコールするスクリプトコードをドロップ するだけでなんらCOMに対する知識なしにオリジナルのCOMコンポーネントを 生成できる機能を提供することができます。従来スクリプトを使ってもらう ということはコードを使ってもらうということでしたが、パース後のディス パッチのみを使ってもらうという選択肢ができるわけです。
当然のことながら上記COMコンポーネントはオートメーションをサポートする あらゆる言語環境から利用できることになります。動作環境がWindowsである ことを公表する必要はあるでしょうが、内部がスクリプトであることを公表 する必要はまったくありません。
同じことがHTABOX2のリリース後に生成されるEXEにも言えます。 EXEを実行するユーザーはそのウインドウがCreateWindowExで生成されたのか CreateHtaWindowで生成されたのかを知る必要はありませんし知らせる必要も ありません。単にそのEXEが代価を支払うに足るものであるかどうかが評価 されるべきです。
私が抱いている夢の目的は単に技術的なことではありません。 「汗をかいた人間が報われるフェアーなルール」を実現することです。 資本や信用が無くてもそのアイディアと情熱でひとつのプロジェクトを完成 させ、それが正当に評価される世界を思い描いているのです。
いつかHTABOX2が国境を越えて、たとえ貧しい境遇に生まれた若者でもその 知恵と努力で世界を相手にアプリケーションを発表できる。そんな未来を 見るために、消えようとする蝋燭に油を継ぎ足すような日々をすごしています。
スレ違いという声を回避する為に「プログラミングにBGMは重要」という言い訳
を用意して愛聴しているラジオサイトを紹介します。
ttp://www.dr.dk/radio/ 128kですが極めて安定していますしコマーシャルも入りません。DR Worldという
チャンネルは各国の民族音楽を主体としていて日本代表は沖縄音楽の場合が多い
ようです。
プログラミングは精神的消耗戦の様相をていする場合があります。自分では 完璧と考えるソースコードがエラーの場合、それを解決できるのはさっきま での自分とは別人の自分でなければなりません。そうでなければ永遠に間違 いに気づかないことなります。そんな状況を続けていればどうなるかは目に みえていますよね。音楽は人間が作り出した最高の芸術形態だと思います。 時間と言う刹那から逃れることのできない悲しさもその楽しさも音楽に凝縮 されている気がします。食うに困らない状態になれたら一日ピアノを弾いて 暮らしたいと思っています。
これならばHTMLから相対パスでの指定ができますね
……スクリプトでスケルトンHTMLを書き出し、起動後に削除という使用法を咄嗟に思いつきましたが、
>>339 のファイル生成が不必要というガイドラインに抵触するようでもあり。
>>380 HTABOXそのものは一時ファイルを生成しないことを約束したいという意味での
ガイドラインですので開発者が必要とすればHTMLダイアログ用のHTMLファイル
を一時出力してパスの解決を簡略化するという手法は多いに活用されるべき
だと考えます。スケルトンHTML+スクリプトという手法は最も柔軟性のある手段
としてHTABOX2の主たる開発手法となるかも知れません。
HTAとHTMLダイアログの違いを理由も含めてまとめておきます。 HTAは実パスを指定して生成した場合onloadに間に合うような形のでディスパ ッチ注入ができません。結果としてHTABOXコアのように注入を待ってWIN32を 使用する必要が生じます。これを回避するためにHTABOX2ではabout:blankで 生成->WIN32注入->HTMLのwrite->メニュー構築とcloseという手順にしたいと 考えています。 実パスを指定しないと動作しない、または書きにくいケースがあります。 HTABOX2では親の無いHTMLダイアログをHTAと同等に操作でき、実パスを指定 した生成を行ってもダイアログの引数としてWIN32が与えられていますから 開始当初からWIN32は存在します。WIN32を有効にするには実パスHTMLのスク リプト冒頭で var WIN32 = window.dialogArguments; を宣言していただく 必要があります。
親の無いHTMLダイアログをウインドウとして採用した場合、これはほとんど 何の制約も無いウインドウとなります。プロセス中に複数生成させても何ら 問題は発生しません。HTABOXコアを発表する前にHTMLダイアログでこれを実 現しようとしていたとお話したことがありましたが、HTMLダイアログの場合 EXCELのように親ウインドウに子ドキュメントが複数存在するというMDI状態 を作れるのです。今後の研究課題ではあるのですがMDI関連のAPIをスクリプ トへ公開してコントロールすることも可能だと考えています。
デモ最新版だとMicrosoft.XMLHTTPでも大丈夫なので、
HTABOXコア本体と同じくIE5.5以上を動作条件とすることができますね。
ただ、
HTAをもっと流行らせる計画 Part2
http://pc12.2ch.net/test/read.cgi/tech/1220874815/48-51 あたりで触れられているXMLHTTPオブジェクトの種類によってはリファラにHTAのフルパスが含まれる、
というのがHTABOXコアではどうなるのかちょっと気にはなります。
まあ自力で検証する技量はないんですが……
あとhttp.htmウインドウのサイズと位置をどう指定されているのかご教示いただきたく。
やはりHTAをデスクトップアプリケーションらしく見せるにはこの記憶が欠かせないと思いまして。
>>384 考えてみるとHTABOXコアも一旦難読化したHTMLをdocument.writeしていますか
らローカルファイルからのHTTPリクエストは「書き込めません」がでます。
ただしフレーム形式としてサーバー上のHTMLの場合はdocument.writeにもかか
わらず成功していたので不思議です。勉強が足らないと痛感しています。
HTMLダイアログの初期サイズなんですが、リリース時にはデフォルトのアプリ
ケーションウインドウサイズにしようと考えています。勿論非表示な状態から
表示する段階でSetWindowPosにより自由なサイズとすることもできるようにな
ります。現状はまったくずさんなことにHTAが事前にCreateされていればその
サイズをデフォルトとして記憶、Createされていなければ640*480というのが
真実です。
正直Windowsのデフォルトサイズを取得する方法が解からなくてCW_USEDEFAULT を指定したWindowを無駄に生成して取得することになるんですが、例によって 基本的な知識が抜けている結果の愚行ではないかと不安です。どなたかもっと スマートな方法をご存知の方そっと教えてください。
位置についてもリリース時はCW_USEDEFAULTで生成した空振りウインドウの値 をそのまま採用するつもりです。それが一番普通のアプリケーションらしく 見えるのではないかと考えているからです。現状のHTMLダイアログはサイズが 決定された後にスクリーンサイズを取得しセンタリングされています。
どうも私のプログラムとBrowseForFolderの相性が悪いことに気づいてはいた のですがほったらかしにしていました。フォルダダイアログをズリズリする とソリティアのクリア画面状態だったんですが、なんとか打開策が見つかり そうです。これで最低限の条件はクリアできたかなぁっと思っています。
ttp://kuroda.bglb.jp/htabox/demo.zipを更新しました 。
コモンダイアログを使用する例としてDialogs.jsを追加しました。あくまでデモン
ストレーションですからリリースまでに仕様の変更があるかもしれませんが若干の
説明をさせていただきます。
SCR.Func1 = function()
{
var Fold = WIN32.BrowseForFolder(HWND,"タイトル",0x0010,"c:\\");
var Path = (Fold != null)? Fold.Items().Item().Path : "";
WIN32.MsgBox(Path);
}
SCR.Func2 = function()
{
var Path = WIN32.GetOpenFileName(HWND, "開く", "ALL(*.*)\\0*.*\\0TEXT(*.txt)\\0*.txt\\0", "c:\\", 0);
WIN32.MsgBox(Path);
}
SCR.Func3 = function()
{
var Path = WIN32.GetSaveFileName(HWND, "保存", "ALL(*.*)\\0*.*\\0TEXT(*.txt)\\0*.txt\\0", "c:\\", 0);
WIN32.MsgBox(Path);
}
WIN32.BrowseForFolderはSHELL32形式のフォルダオブジェクトを返しますので 上記例のようにItems....でパス文字列を取得する必要があります。第3引数は オプションの数値です。オプションフラグの詳細についてはMSDN等で確認できる と思います。
WIN32.GetOpenFileNameとWIN32.GetSaveFileNameはほとんど同じなのでまとめた 説明をします。まず第3引数のフィルターですが、本物のWIN32APIは区切りとして \0を用いますが、スクリプトからの呼び出しでは文字列中に\0を表現することが できません。そこで\\0を代替とすることにより内部で\0に変換しています。 終端は\0が二つ必要ですが文字列終端には自動的に一つ付加されますのでスクリ プトコードからは\\0を終端とすればいいわけです。
最終引数はオプションです。OFN_OVERWRITEPROMPT 0x00000002なんかは保存時 に便利なオプションかも知れません。これを書きながらこのオプションの部分を コメントアウトしてビルドしていたことに気づきましたので数分後に再度更新し たいと思います。デモなんですがこれで少し遊べるようになったかと思います。
ダイアログの枠にマウスを持っていってそのまま親ウインドウへ持っていく と<-->になってしまうのはちょっと美しくない点なんですが、これを解決す るためにはダイアログで親のアクティブを奪ってからその子としてコモンダ イアログを...というような手法しか成功していないものですから今後の課題 とさせていただきます。
HTABOXコアからHTABOX2へ移行で最大のテーマとしているのがツールとしての 透明性です。従来HTABOXコアが内部で処理している事をそのままCOMとして公 開すれば、書いている私も楽だし開発する側もメカニズムが見えて利用しや すくなるはずだという発想からスタートしています。事実、現状でのソース ボリュウムはHTABOXコアの半分にも満たない量ですんでいます。
今後もっと重要な課題と考えているのがWIN32APIの動的呼び出しです。 現状では私が用意しないといかなるWIN32APIも使えないわけですが、例えば MessageBoxという名前要求があった場合にuser32.dllの当該モジュールを 動的にコールできるようにしなければならないだろうと考えています。
HTAでWIN32APIを使おうとしたら、 Excel VBAとかSFCmini+win32api.jsとかを経由するしかない現在に比べると大進歩になりますね WIN32APIを叩けるのでやろうと思えば割と何でもできることがHSPの強みの一つのような気がしますし
HPがなくなっちゃったね
test
htaboxでもマニフェストを使った外部のdllの利用が出来ました。
test.exe.manifest ってな感じで同じ階層にmanifestとdllを置いておけば、
wshのときと同じようにdllが使えます。
システムに外部のDLLを入れたくなくて、ポータブルで運用したい人は、
独自の関連付け出来るXFinderなどで、マニフェストつきのcscriptやwscript,mshtaを
関連付けて起動させるか、スクリプトの冒頭で、指定の場所のマニフェスト付き
exeで再起動させる方法がありました。
htaboxの仕組みをつかうと、例えばtest.exe用のマニフェストとDLLを置いておくだけで
スクリプトの側ではなにも気を使わずにガンガンDLLを使えます。
そういう意味でも便利です。
>>お前ら、wsh使ってますか? Part7
>>
http://hibari.2ch.net/test/read.cgi/win/1190548945/722 722 名前:名無し~3.EXE[sage] 投稿日:2009/12/05(土) 23:46:56 ID:/VdO4Ha3
とりあえず、ポータブルのJScriptでもAutoItXでアプリ制御、SeraphyScriptDialogでGUIフォーム、SFCminiでWin32API、いくつかは動いたんで最後のまとめ。 cscript.exe.manifest の中身。
>>400 貴重な情報をありがとうございます。
VISTAと7はUACがあるのでさまざまなケースを想定して実験を繰り返さなけれ
ばならないことろですが、なおざりになっていることをご容赦ください。
最終的にHTABOX2での格納配布実行ではマニフェストが不要であることをガイ
ドラインにしたいと思いますが、開発者がツールとしてレジストリ登録する
場合にはマニフェスト若しくは右クリックの「管理権限」が必要な仕様にな
ろうかと考えております。今後ともよろしくご指導ください。
以前にゲームを作るためにジョイスティック系APIをというお話があったのですが、 それをきっかけにDirectX系APIをスクリプトから簡便に呼ぶためのブリッジを研究 しました。HTML上のゲームはFlashでそれなりの作品ができるようなのでより高機能 でなければ提供する意味が無いという理由からです。
ただし**3Dという部分は単にハードウエア機能をコールするだけであり、抽象化し ても苦労の割に実りが少ないのは目に見えていますので深入りしない事としました。 DirectDrawによる直接vramアクセス、DirectSoundによるWAVのリアルタイム再生 と録音、DirectInputによる入力ディバイスのリアルタイムステータス取得が主な 機能となりそうです。
まだ技術的な検証が終わったのみでデモに組み込むのは先の話になるのですが、 WIN32.CreateDirectWindow(800, 600, 16); とすればスクリーンが800*600でビット深度16になり、あとはご自由にどうぞ という展開になろうかと思います。
405 :
193 :2010/09/09(木) 00:40:58
まだ私は初めの一歩を踏み出せていませんが、応援しています!
>>405 ありがとうございます。なにぶん自堕落な私の仕事ですのでゆっくりとした歩みに
なろうかと思いますが、プログラミングそのものをゲームのように楽しめる環境を
提供できたら、たくさんの方がプログラミングに興味をもっていただけるんじゃな
いかと考えています。
サイト復活お疲れ様です(まだHTABOX関係はないようですが)
>>407 ありがとうございます。
IIS上の独自認証システム確立に大変手間取りましてごめいわくをおかけしま
した。HTABOXコア旧来のまま復活させますが、HTABOX2をメインに展開させる
予定でおります。まだ基幹システムテストの状態で内容が無いことをお詫び
します。
サーバー管理のスクリプトはHTAやWSHではなくHTMLで書いています。理由は 単純でMSE7上でブレークポイントを設定しデバッグできるからです。でも問 題がひとつあります。IISメタベースを扱うためのGetObjectなんかは通常の HTMLセキュリティーでは実行できません。
どこかの設定をいじれば実行できるんでしょうが面倒なものですから WIN32.GetObjectとWIN32.ActiveXObjectという偽者関数を作りました。 これがなかなか便利で、今までHTAやWSHにならざるを得なかったモジュール を全部ひとつのHTML中スクリプトにまとめる事ができます。次回HTABOX2 デモを更新するときにはこの偽者関数が含まれる予定です。
Htaboxのexeは同じフォルダのhtmやhtaを起動させるみたいだけど、 例えば特定のフォルダ名の中のhtmを起動できたっけ? 決め打ちで同じフォルダのhtalibとかの名前のなかの同じ名前のhtmを動かせると すっきりさわやかなような気がする。 って、もしかしてもう出来てたのを自分が知らないだけかもw
同じフォルダに同名のhta・htm・htmlが存在しない上でバッチやWSHで引数として指定すれば何とか
せっかくexeで起動できるのにバッチを使うのは意味ないような気がするけど・・・ exeのほうで対応しとけば、最初に、隣のhtmを探して無ければ、次は既定値のフォルダ名のなかの htmを探すとか出来ると思うんだわ。 ほかには、たとえばexeの名前を、hoge__lib.exeにしとけば、同じフォルダのlib内のhoge.htmを使って htaboxが起動する、というような仕組みってことね。 もう出来てて、自分がしらんだけかもしれないけど。
>>413 有益なご意見ありがとうございます。
HTABOXコアもHTABOX2も最終的には旧HTABOXのようにスクリプトやHTMLを
ドロップし、EXEにして配布することを目的としていますので現在の仕様
となておりますが、肝心のドロップ格納仕様を決めかねておるところです。
起動バッチスクリプトという構想も以前から抱いていましたが、デモを公開中
のHTABOX2.EXEではHTMLではなくJS、VBSを実行主体とできますので、そこから
任意の相対パスにあるスケルトンHTMLを実体化させる手法になろうかと思い
ます。HTABOX2では「単にドロップ」と「スクリプトによる細かな制御」を両立
できる状態にしたいと考えております。
ttp://kuroda.bglb.jp/htabox/demo.zip
ベクターを掘っていて見つけたHTABOXの義理の御先祖様的ソフト
> 美友紀ちゃん 0.03
>
ttp://www.vector.co.jp/soft/win95/net/se115583.html > HTMLファイルから実行ファイルを作成
> (99.12.21公開 1,171K フリーソフト インターネット&通信:HTML作成:変換)
格納したHTML(とそこから参照している同一フォルダの)ファイルをTempフォルダに展開、
IEコンポーネントブラウザで表示している模様。
ヘルプによるとVersion0.01が99/09/06とIE5.0リリース、
つまりHTAと同年だったんだからこれがそのまま発展していれば……と死んだ子の年を数えてみる
……死因の一部は生成されたexeのアイコンと展開ダイアログとタイトルバーのデザインのような気がしますが。
単純なリソースハッカーのアイコン置換程度では動作しなくなるし。
>>415 ずいぶんと昔にチャレンジしていた方がいらした事は知りませんでした。
HTA出現と同年ということはHTAによって存在意義が無くなると判断されたの
かも知れませんね。HTAは今も昔も変わらず強力な手段な訳ですが、この10年
で悪者というレッテルを貼られている観があって「じゃあ見た目EXEなら文句
ないでしょ?」というのがHTABOXの出発点だったと思い出しました。
HTABOX2.EXEで実際に救急情報管理ソフトを書き上げてみました。HTABOXコア で何らかのソフトをリリースできなかった最大の要因はデバッグ環境と隠蔽後 の実行環境があまりに違うためリリース後にエラーが発生してもどこがエラー なのか見当がつかない点だったのですが、今回はデバッグ時と隠蔽時の変化が できるだけ無いようにこころがけました。
そして、上記目的のためには今のところドロップによるEXE内への格納は行わ ない方がいいという結論に達しましたので、HTABOX2という呼称は封印して HTABOXコア2.00を次期リリースバージョンの呼称にしたいと思います。 HTABOXコア2.00は同名JS、VBSが存在すれば優先的に実行することにより従来 よりきめ細かな制御が可能となります。またCOM登録してデバッグもできます。
ソースの隠蔽手法についてはJS、VBSを独自エンコードしたファイルを生成 することにより行います。つまりhoge.jsをhoge.jsxxにエンコードし、同名 ファイル検索時のルールとしてhoge.jsxxを優先し内部でデコード後に実行 するものです。デモではHTA中のスクリプト隠蔽も実験していますが、やは りabout:blank生成のHTAでは自身の実パスが決定していないことからIE8で 予期せぬ動作を見せる部分があるようです。
現時点での結論をまとめます。 次期リリースバージョン呼称は HTABOXコア2.00となります。 HTMLまたはHTA中のスクリプトエンコードはEXE内への格納仕様が決定するまで 実装されません。 外観を記述した実在HTMLへJS、VBSで関数ディスパッチを追加する手法の場合 はソースコードを隠蔽することが可能となります。
>>415 wikipediaにはIE5.0が必要とあるけど、僕は'96年頃にMSVS4.0にHTAが付属してたと記憶してるよ。
プログラマになったばかりだったので勉強してたんだけど、勉強した結果を報告したら殴り倒された。
「こんなおもちゃで遊ぶな!」ってさ。
たぶん今でもHTAにアレルギーを示す方はいらっしゃると思うんですよね。 ですから内部でHTA的な事をしていることをまったく隠してHTMLでGUIをデ ザインし、隠蔽スクリプトをJSかVBSで書いて変換するとEXEが生成される 統合環境を提供できれば理想的なんですが力が及びません。 3年以上も勉強しながら未だ皆さんに喜んでいただける物を提供できていない 自分を省みて、情けなく、ただ情けなく気分が落ち込む日々です。
423 :
415 :2010/10/24(日) 14:53:19
>>423 > ActiveXやHTMLを部品として使い...はとても先進的なキャッチですね。
やはり自作COMでブリッジになると思うんですがVC++の半オートメーションで
COMを作成するとプログラムが複雑になった場合改訂が億劫になるんです。
自動でコードが生成される代わりにトラブルの切り分けが難しくなるからです。
HTABOXコア2.00に向けた勉強の過程で、スクラッチコードでCOMを生成できる
手法を実験していますので、いつかご紹介できたらいいと思っています。
話題が手前味噌な方向へ変化して恐縮なのですが、
プログラミング初心者向けにコンテンツを用意してみました。ターゲットは
小学生高学年?くらいなのですが、「HTAで迷路を作って遊ぼう」を題材に
しています。すでにベテランの方もオブジェクトの設計手法で参考にしてい
ただける部分があるかも知れません。
http://kuroda.bglb.jp/hello/index.htm
なんとかHTABOXコア2.00手法で救急情報管理ソフトをリリースできました。 親、上、下のフレーム構成とし実在親フレームを対象にJSからDialog生成 手法でコントロールしています。親、下フレームはクライアント側にHTML ファイルとして配布していますが、200Kを超えるスクリプトは全部JS内に 存在しHTMLの外観形成とは非同期に遅延転送されます。したがってスクリ プトの量にもかかわらずクイッキーな起動が可能となりました。
おめでとうございます
開発時にHTABOXをCOM登録してデバッグできることによりほとんど隠蔽リリー スと同じ環境で開発を進めることができます。課題はサーバー側に子フレーム を置いた場合何が可能で何が不可能なのかの線引きを明確にすることです。 今回のリリース作業でもIE7とIE8の解釈の違いでドタバタしましたのでそこ が明確になりしだい実用的なデモをお見せできるだろうと考えています。
>>427 ありがとうございます。
サーバー側の仕様も固まってきましたのでお手持ちのPCで簡便に独自認証
システムが構築できるシステムとして技術提供できる日も近いと思います。
もはや日々の糧にも困窮する状況なのですが、初心を貫徹したいと思って
います。
こんなものでも描画部分をAPIで処理しようとすれば胃が痛くなるでしょうが、 HTMLなら鼻歌まじりで作れます。通常はその代償にスクリプトが見えてしまう わけですが、それもいやだというわがままからHTABOXは生まれたわけです。 これで量産体制ができましたので下手な鉄砲なんとやら状態でネタさえあれば 2,3日でドキュメントも含めたアプリを1本作れそうです。
HTABOXコア2.00のドキュメントを作ろうと思うのですが、さて何から書いて いいものやらとキーを叩く手が止まります。私と、このスレッドにお付き合 いいただいている方にはある程度ストーリーがインプットされていますから 理解できる事でも、初めて見る人へ十分な説明を行うためにはかなりのボリ ュームの文章が必要になる気がします。
少なくとも ・個人用ツールとしてHTA+α的な使い方のニーズ ・WSHからHTMLを制御したいというニーズ ・最終的にアプリケーションとしてリリースしたいというニーズ 程度の分類をしないと書いている方も混乱してしまいそうです。 そしてフレームアプリケーション構築と一部ASP化の留意点、 IISでの認証制御の手法、独自認証のためのISAPIDLL、HTABOXサーバー、 最後に総合的なHTABOXシステムの管理手法という流れにしたいと思います。
書き始めて気づいたのですがHTABOXコアを特化されたIE互換ブラウザと位置 づければ話がわかりやすくなる気がします。このブラウザにはWIN32というIE には無いオブジェクトが存在し、コンパクトでレジストリにも関与しないか らアプリケーションと一緒に配布できる。必要であれば独自エンコードを利用 してソースを隠蔽できる。という流れなら理解しやすいかも知れません。
HTABOXコア2.00の基本的な仕様を決定しました。 CreateHtaWindow(path); はpathで指定されたファイルを表示します。動的に生成したい場合は引数を about:blankにして生成した後にopen, write, closesしてください。 CreateDlgWindow(path, arg); はpathで指定されたファイルを表示します。第2引数にWIN32を指定すればHTML 中のスクリプト冒頭からWIN32は有効です。
配布用エンコードは以下の仕様です。 エンコーダーは指定されたパスのJS又はVBSと同名のEXEを生成します。EXE内 のリソースにエンコードしたスクリプトが格納され、この時EXEアイコンリソ ースも任意なものに置き換え可能とします。生成EXEが起動された場合はリソ ース中のスクリプトが実行されるものとします。 尚、ソースの全面書き換えなので既存HTABOXコアの一部機能が継承されない 場合もありますが、ご指摘いただければそのつど追加します。またDirectX系 機能の提供は2.00の安定が確保された後に予定しております。
436を訂正します。 アイコンリソースをちょっと甘くみていたようです。だいたいどんなサイズ と色深度のアイコンを何個必要とするかは用途に左右されるわけですし、 それを動的にコントロールするのはかなりハイテクニックな事のようですね。 VisualStudioが生成するデフォルトアイコン(32*32)の状態でバイナリ置き 換えが可能な方はいいとして、別なサイズが必要な場合は希望のicoファイル をお借りして再ビルドするサービスで対応した方が確実だと考えています。
HTABOXコア2.00の最終的なドキュメントとサンプルソースの記述作業を行って います。世間様から見ればまさに重箱の隅をつつくような分野の事を3年以上 にわたって追い続けてやっと自分でも満足のいくゴールにたどり着けたと思い ます。本当にこの老いぼれた人間の愚行を暖かく見守っていただいた方々に 感謝します。私に何らかの功績があるとすればそれは私を支えてくれた方々 の功績だと痛感しております。
3時なんで休まないと体がぶっ壊れますよ。
>>439 ありがとうございます。不摂生な生活にもかかわらずこれといった病にも縁
が無いのはご先祖様のたくましいDNAのおかげかもしれません。
スクリプトの格納仕様を決定しました。JSとVBSの混在も...と考えましたが
いずれかの言語で単一ファイルとしました。大きさは無制限です。暗号深度
は内部呼称レベルBにしました。これは同一ソースでもエンコードするたびに
異なったバイナリとなる方式です。また、極端に短いソースのエンコードを
繰り返すアタックに対して何らかの制限を加える可能性もあります。
今日はすこし早く寝ます。
HTABOXのCOMDLL作成版の構想もまとまりました。普通に書いたJSかVBSを雛形 DLLに格納し指定されたCLSID、クラス名、スレッドモデルで内部情報を置き 換えます。使う側はディスパッチ形成がスクリプトで行われているとは思いも しないでしょうからちょっと見栄が張れるかも知れません。 COMBOXという名称がいいかと思いましたが既に検索にわんさかヒットするので COMDLLBOXとでもしてリリースしたいと考えています。
エンコーダーを完成させました。例によってまだ抜けている事があると思い ますが、明日HTABOXコア2.00をお見せできるようにドキュメントの作成に没 頭しています。プログラミングという作業は考えている時間の方が長くタイ ピング量は少ないのですが、文章の作成ではタイピング量が勝負ですので 肩こりに悶えながら作業しております。
ドキュメントを書きながら自分でもどういうストーリーで今日に至ったかを 整理して考える事ができました。長文というのはその長さだけで敬遠されま すからここにその要点を記録しておこうと思います。
HTABOXコアの出発点はMSHTA.EXEが実現していたHTMLApplication環境を自身 のプロセス内に出現させることから始まりました。別プロセスで実行中の ドキュメントインスタンスを補足しDLLフックでメッセージを操ることは従来 から行われていたでしょうが、本質を変更できる手法ではありません。
HTABOXコア1.xはインプロセスでHTMLApplicationを生成できるなら別エンジ ンでパースしたスクリプトを遅延転送してコードを隠蔽できるだろうという 発想で進行しました。あくまでもHTML形式ファイルありきで、そのスクリプト を隠蔽しようとすれば一旦全体がエンコードされていなければならず結果と して非同期に行われるスクリプトブロックの評価タイミングや、転送スクリ プトの出現タイミング等の問題を検討しようにも隠蔽されているのでデバッ グできないという状況に陥りました。
隠蔽とデバッグという相反する要素を両立させるために発想の転換が必要で した。HTMLApplicationをインプロセスで生成する関数そのものをWSH環境で 実行するスクリプトに公開すれば通常のスクリプトと同様にデバッグでき、 単純に当該スクリプトをエンコードしてEXE格納することが可能となります。 HTABOXコア2.00はその手法のためにゼロから書き直されました。
HTABOXコア2.00はデバッグ用にレジストリ登録できるEXE形式のCOMサーバー である必要がありました。VC++のATLに頼らずEXE形式のCOMサーバーを構築 するコーディングにすこし苦しみましたが、C++内部でもディスパッチ経由 で関数呼び出しを行えばまるでスクリプトプログラムのような簡潔さでC++ コードが記述できるという新たな発見もありました。
結果的にHTABOXコア2.00は隠蔽よりもデバッグ重視な性質を持っています。 JScriptの場合明示的に隠蔽ディスパッチでラップしないとHTML中に公開 したインスタンスから芋ずる式にtoString()でコードが見えることも考え られますので注意してください。そういった心配の必要が無くしかも高速 なVBScriptに正直心引かれるようになってきました。
HTABOXはHTMLでのGUI、スクリプトでのアルゴリズム記述、C++単純DLLでの スクリプト拡張でアプリケーションを構築しようという趣旨なわけですが、 今回の改訂はC++プログラマーという立場から見ると進展の無いものになる ことをお詫びしなければなりません。コモンコントロール等をHTMLで構築 できることをお待ちだと思うのですがもうすこし時間をいただくことにな ります。
今日は公開するメソッドを分類しクラスを再編成する作業を行いました。 サンプルを実行しながらデバッガで眺めるWIN32オブジェクトがあまりに 雑然としていたからです。これって何のための関数?と自分でも首をか しげるものが出てきたりして考古学者気分になりました。
ひとつ不思議なのはMS社がなぜHTMLApplicationの実行環境を改善しようと しなかったのかという点です。もしMSHTA.EXEがDocumentインスタンスを取 得できるCOMコンポーネントだったら、私がこんなものを造るまでも無く HTMLApplicationは最も簡単で強力なアプリケーション開発手法として認知 されていたに違いありません。
>>430 のアプリケーション起動時にエラーメッセージが表示されました。
以下内容
Source = Microsoft JScript 実行時エラー
Description = 'WIN32.Resource' は Null またはオブジェクトではありません。
Line = 82 Char = 2
SourceLine = ??|
>>452 「どうせ誰も使ってないし」と思ってサーバーサイドのASPをHTABOX2.00の
仕様変更に合わせて書き換えて実験しそのままにしていました。今、元に
戻しましたのでエラーは出ないと思います。ご迷惑おかけしました。
今日こそと思っても細かな修正点が出るのはいつもの事ですが、サンプルの ファイル構造も決まりましたのでまもなくお見せできます。今回は英語版の 短いドキュメントも作成して日本以外の方にも使っていただこうと思ってい ます。興味を持っていただける開発者がどれほどいらっしゃるかは未知数で すが積極的にメールも出そうと思います。ありきたりな言葉ですが、倒れる なら前向きに倒れたいと考えています。
HTMLとスクリプトの分離という方向に進みましたから、自分で使うツールを 気軽にEXEへ変換というニーズとは離れてしまったかも知れませんが、隠蔽 を必要としなければカスタムリソースへバイナリデータを格納するロジック は確立しましたので、単純にHTAと画像をEXEに格納できてメニューやアイコ ンドロップが有効というようなお気軽エディションも作れそうな気がします。
ドキュメントに書きましたが、ID="POPUP"のTABLEタグが無い場合は通常の右 クリック動作を阻害しない仕様としました。SetLayeredWindowAttributes等 のウインドウコントロール関数も実装しています。すべてはこんなソフトに も関わらず関心をもってくださる方々がいるおかげと感謝しております。
予定通り 「四角い迷路」をベクターにフリーソフトとして公開しました。 HTABOXシステム手法が受け入れられればいよいよ量産体制に入れると考えて います。
HTABOXコア2.00にHTML格納用カスタムリソースを定義しました。 C++でUpdateResourceできる方は利用していただいて結構です。 リソースタイプ "HTMA" リソースID 105 リソースタイプ "HTMB" リソースID 106 リソースタイプ "HTMC" リソースID 107 リソースタイプ "HTMD" リソースID 108 上記変更が加えられた後のバージョンを2.10としてまもなくリリースします。
ビルドした後のEXEへはres://参照リソースをIDとは無関係に追加可能? いろいろ実験しているのですが、画像格納まで考えるとIDより名前管理 の方が自然ですよね。両者に一長一短があるんでしょうけれど勉強不足で これがベストと言い切れる方向を見出せていないかも知れません。 いずれにせよHTMLや画像のリソース格納は当面WIN32APIで直に操作して いろいろな反省を踏まえてからエンコーダーへ追加して行きたいと考え ています。
どうも独白スレッドになってしまいますが、あらためて スレッドのテーマである「HTABOXコアへの要望」を募集しています。 HTMLアプリケーションだからあれができないこれができないという話は無し にする事が目的ですから、突拍子もない要望こそ価値があると考えています。
サーバーも開発環境も2003への移行実験を開始しています。世間様から見れ ばなんで今頃ということになるんでしょうが、私というのはそういう人種で すからご勘弁ください。で.NETとかASP.NETのドキュメントをまじめに読む んですがその方向性にあらためて疑問を持ってしまいます。
MS社は「一行のコードも書かずに」が最高の開発環境だと勘違いし続けてい るわけです。みんなが同じボタンを同じ順序で押して生成されるコードに満 足するだろうという発想なわけで、そこから外れた創意工夫を活かす機会を 軽視しているように思えます。プログラマーの財産はどのボタンを何回押し たかではなく再利用可能なソースコードをどれだけ持っているかだと思うの です。
>>468 >MS社は「一行のコードも書かずに」が最高の開発環境だと勘違い
言いがかりかと。
でなければ、開発環境や実行環境の
開発にあれほどのパワーをかけないよ。
>プログラマーの財産はどのボタンを何回押し
>たかではなく再利用可能なソースコードをどれだけ持っているかだと思う
そうだと思うけど、それをMSに期待する
ことは間違いでしょう。
>>466 まだ十分に使い込んでいないいま、とっさに思いつくのは既出のリソース格納を除けば
ウインドゥ表示→アプリケーションメニュー生成のタイムラグ短縮、
それと配布形式exeの改変をアイコンに加えてバージョン情報も許可して欲しいのと
独自言語化しつつあるHTABOXコア向けHTML・WSHドキュメントのさらなる整備ですね
あとは正直、バージョン1代のHTML起動にも未練が……
>>469 「言いがかり」じつに適切な見識だと思います。正直誰かの書き込みを見て
みたくなったのです。大変すばらしい仕事をしているエンジニアがいるから
こうして楽をさせていただいているわけですから文句を言うべきはありませ
んよね。
>>470 表示->メニュー生成のタイムラグは結構根深い問題になります。消極的解決策
としてはメニュー生成完了までウインドウを表示しない書き方も可能です。
バージョン情報リソースについてはできるだけ早期エンコード時に設定できる
ようにしたいと思います。HTML単体の取り扱いについては思い切って旧HTABOX
をきちんと書き直すという方向で考えています。今後ともよろしくお願いしま
す。
旧HTABOXの最大の弱点は単に引数パスを表示するEXEを作成して身代わりに 置かれてしまう事でしたが、今は格納されたEXE自身がHTA実行しますので 本当にMSHTA.EXEなのかを調べる必要く極めて単純な動作に書けるはずです。 もし、自身EXEがデバッグ環境下でステップ実行されていることを認識したら 動作を拒否するというロジックを組み込めばこれはこれで使えるんじゃない かと考えています。
HTABOXコアがレジストリに登録されていない環境で、リソース内または一時 出力HTMLファイルからHTAインスタンスを生成しながら、スクリプト冒頭で WIN32ディスパッチを滑り込ませる方法があることに気づきました。 要はActiveXObject以外の方法で任意なディスパッチを取得できればいいわけ ですからshowModalDialogをActiveXObjectの代替にしてしまうものです。
HTABOXコアは自プロセス内でHTMLダイアログを監視します。そこでabout:blank だったらとか、1px*1pxだったらとかいうルールを設けて該当した場合ダイア ログのreturnValueにWIN32ディスパッチをセットして返せばActiveXObjectと 等価な動作となります。
結果としてレジストリ登録されていない配布先環境でもHTML中のスクリプト 冒頭から自由にWIN32ディスパッチが使えます。WIN32インスタンスがあれば あとは何でもありにできますから、デモのHTA版で行ったようにWIN32のデコ ード関数にハッシュコードを与える形式のスクリプト生成を行いソースコード を隠蔽できます。
やはりこういった機能をHTABOXコアに追加するのでは作ってる方も混乱します し、使う側はなおさらだと思いますので、一時ファイル生成を前提とした別の エディションとしてリリースすることになると思います。 ただし、ちゃんと飯が食えて私が生きていたらという前提ですが...
HTABOXコアの「コア」はシステムの中心であるという意味です。システム全体 の目的はHTMLアプリケーションの一部をオンライン化することです。将来は 私のサーバーエリアを貸し出すことによって誰でも確実に収益が得られる形で アプリケーションを発表できるようになるでしょう。最初はフリーソフトとし て発表し、動作件数を確認してからサーバー側ファイルを置き換えて有料ソフ トへ移行させるという柔軟性がありますから、フリー版はこのくらいの機能で というさじ加減に悩む必要はまったくありません。
ただ、そういったニーズを持たないユーザーにとってHTABOXコアの仕様はやや 面倒なものに思えることでしょう。今日からHTMLアプリケーションを書き始め る方にいきなりCreateHtaWindowと言ったところで「はぁ?」になるのは必至 です。ですからMSHTA.EXEでの実行とHTABOXコアでの実行の中間に位置する 実行環境は絶対に必要だろうと考えています。 そして私の意に反してそっちの方が重宝されるという展開を予測します。
エラーメッセージに誤記らしきものを見つけたので報告 ・Unknown Errorダイアログのタイトルが「HTABOX2.0 DEMO」 ・「引数ファイルは拡張子VBS、JS、HTA、HTMでなければなりません」
>>480 ありがとうございます。
ご指摘の部分のコードを即座に改善します。
HTABOXコアのリソース格納エンコーダーについて概要を説明します。 ポイントはリソースタイプが入れ子にできない事にあります。つまりHTMLフ ァイル群がHTMというリソースに格納された場、合画像をimg/hoge.pngという 相対パスでで参照することは構造的に不可能です。もちろん同一リソースタ イプへの格納であれば単にhoge.pngでいいのですが美しくありません。 画像がIMGリソースに格納されるとすればHTMリソースからの相対参照は ../IMG/hoge.pngになります。これを踏まえてリソース格納を前提とした ファイル構造をこころがけていただく必要があります。
プロジェクトのルートフォルダに起動JSかVBSを置きます。 サブフォルダhtmにHTMLファイル群を置きます。 サブフォルダimgに画像ファイル群を置きます。 サブフォルダetcにその他の参照ファイルを置きます。 エンコーダーはスクリプトパスが与えられると各サブフォルダの存在を確認 し、当該フォルダ名を大文字にしたHTM、IMG、ETCリソースへファイル内容を 格納します。
開発中とリソース格納後の差を吸収するためには最初にCreateするファイル のパスを環境毎に切り分ける必要がありますが、 //スクリプトパス終端が.exeだったらリソース環境と判断 if(WIN32.GetScriptPath().search(/\.exe$/i) == -1) { DLG = WIN32.CreateDlgWindow(DIR + "\\htm\\Main.htm", WIN32); } else { DLG = WIN32.CreateDlgWindow("res://" + WIN32.GetScriptPath() + "/htm/Main.htm", WIN32); } というようなコードでいずれにも対応できると考えています。
>>474 の実装実験を行いました。結果は何の問題も無く望みどおりの動作を
行えるというものでした。驚いたのは今まで0pxのダイアログはセキュリテ
ィー制限により存在が認識されないと考えていたのですが、まだ表示されて
いない初期の段階で捕捉することにより実体のあるダイアログとして扱える
ことです。したがってスクリプト冒頭に
var WIN32 = showModalDialog("about:blank", null, "dialogHeight:0px;dialogWidth:0px;unadorned:yes");
というまったく表示されない記述でWIN32を認識させることができました。
ActiveXObject以外の方法でスクリプトがまだ一行も評価されていないHTMLへ 任意のディスパッチを送り込めるメリットは計り知れないものがあります。 あらゆるカスタマイズをCOMという規格が約束してくれます。タイミングや 順序に悩む必要のない自由な拡張が可能になるのです。 HTMLへの対応に思いを巡らすことで今回の実験にたどりつけました。 そのきっかけを与えてくださった方に感謝の気持ちでいっぱいです。
これでHTML全体をバイナリエンコードしてEXE内に保持し、一時ファイル生成 時に独自のスクリプトデコードルールを導入できます。 例えばデモのHTA版でやったように128bitの予測不能な数値を引数として、 一度の呼び出ししか許さないデコード関数に置き換えることができるのです。 ただし、HTMLと同じスレッドにWIN32が生成されますのでWIN32側がスレッド をブロックしてしまう動作はそのままHTML側のフリーズ状態となるはずです。 ですからこの手法の場合WIN32を積極的に使うのではなく、EXE格納時にHTML 中のスクリプト冒頭へ自動的に追加される一行によってスクリプトコードが 保護されるというストーリーがいいのではないかと考えています。
HTABOXコア2.20をまもなくリリースします。 エンコーダーは指定されたJSまたはVBSが存在するフォルダのサブフォルダを 列挙し確認ダイアログを表示してフォルダ名をリソースタイプとし、全ファ イルを格納するという単純なルールにしました。 HTABOXコア2.20にはバージョン情報リソースが存在します。将来はエンコー ダーのGUIで内容を設定できるようにすべきですが、まだ対応していませんの で生成されたEXEのバイナリを直接いじってもらう必要があります。
旧HTABOXの継承バージョンとなるソフトの名称をHTABOXクイックにしようと 思います。簡単で手軽だといことを端的に表現しているつもりです。 HTABOXクイックはドロップされたファイル、サブフォルダファイルを一覧表示 して、起動HTMLファイルを選択し、各ファイルについて一時生成直後に消去す るかどうかを選択できます。格納ファイルサイズに制限は設けません。
HTABOXクイックはHTABOXコアが提供するメニュー等の付加機能を一切排除し て単純にMSHTA互換なHTMLアプリケーション実行環境として位置づけます。 HTABOXクイックは複数ファイルをアーカイブして実行時に一時展開する目的 でのみ利用されるものとなります。したがってEXE内への格納時、一時ファイ ル生成時にエンコード機能は提供されません。 HTABOXクイック用にエンコーダーを別途用意します。このエンコーダーはEXE へのリソース格納時にレベルBエンコードを行い、一時ファイル生成時には スクリプトをハッシュデコードすることで隠蔽します。 また、実行HTMLにはHTABOXコアと同等のWIN32機能が提供され、メニュー等を 利用できるものとします。
仕様を眺めてみるとC++レベルで新たに必要なる技術は何もありませんので 楽屋裏的にはコアのモジュールをそのまま使いながらCOM登録やWIN32機能を 制限するという作業になろうかと思います。 クイックのエンコーダーは旧HTABOXで挫折していた頃の私に見せてやりたい 軽妙なものとなるでしょう。そういう意味で私は自身に勝利することができ たと確信しています。
考えてみるとHTABOXクイックはHTABOXコア環境のスクリプトで記述可能なこと に気づきました。新たにバイナリをコンパイルする必要も無くスクリプトを書 けばそれで終わる仕事です。手前味噌ですがコアの威力を再認識しました。
HTABOXコアに関する早急な課題としてEXE化後の引数(ドロップ)動作につい ての修正が必要と認識しています。現状では中身が空な状態と同一ですから 格納後は格納アプリケーションの実行を最優先にする予定です。 やっと当たり前のアプリケーションとしてHTABOXコアが生成したEXEを配布 できるようになりつつあります。上記改良後にご要望に応じカスタマイズし たHTABOXコア(新たなAPIコール機能、アイコン、バージョン情報等)の提供 サービスを開始する予定です。もちろんそういった過程で汎用に有益な機能 は公開版HTABOXコアにフィードバックされることになるでしょう。
HTABOXコアエンコーダーを要認証にする場合ここでお世話になった方々への 御礼としてオフィシャルユーザーを募集しようと考えています。つまり購入 済みアカウントとしてデータベースに登録します。レポートが必要なわけで はなく1ヶ月に1度でもエンコーダーを利用していただいた場合は自動的に権 利が継続されるというサービスにしたらどうかと考えています。
起動すべき内部リソースをXML管理するバージョン2.30を書いています。 この2.30で私の実現したかった夢を世に問うことができると判断します。 まだまだ未熟なソフトではありますが、全世界のソフトウェアを開発する 個人、団体に向けてHTABOXコアの情報を積極的に配信してゆく予定です。 もちろんHTABOXコアの真の威力について即座に理解してくれる方は少ない でしょうが、私自身が短期間にソフトウェアを開発、リリースすることで いやおうなしにその力に気づかざるを得ないことになるでしょう。
もう一度私の目指す方向性を明確にさせたいと思います。 「プログラムをみんなで書こう」という方向と「ソース隠蔽」は一見矛盾する 事に思えるかも知れません。 私の目指す最終目的は個人のレベルでも自身のアイディアや情報を利益につ ながる形で発表できなければ本当に有益なアプリケーションやコンテンツは 生まれてこないという判断に基づいています。
ただで提供する情報に誰が何の責任を負うでしょうか?。ただで提供するア プリケーションは一時期脚光を浴び製作者も心血を注ぐかも知れません。 でも、継続したメンテナンス作業になり当初の情熱を失った時に何の報酬も 無しにそれが継続可能でしょうか? 少なくとも私にはそんな慈善事業に時間を費やす余裕はありません。 書けない人は書いた人の労力にお金で報いるという当たり前なことを実現した いのです。そして書くための敷居を下げればきめ細かな用途のソフトウェアが 世に出て利用する側の利便も向上するはずです。
「オープンソースなアプリをどんどん書きましょう!」それはすなわち製作 者の権利を無力化してハードまたはプラットホームを提供する企業の利益を 優先する戦略に他なりません。 「さぁプログラミングしましょう。あなた自身のために。」
このソフトはWin 7(32bit, 64bit)に対応してますか? あと、ビジュアルスタイルにも対応してるでしょうか。
>>502 Win7で動作します。64bitコンパイルは現在行っていません。32bitのみです。
「ビジュアルスタイル」という言葉を初めて聞きましたので正確な回答になっ
ていないかも知れませんが、テーマ等はそのままウインドウの外観に反映され
ると思います。
試してないけど <meta http-equiv="MSThemeCompatible" content="yes">
>>505 インターネット上に存在する全てのサイトにそれが記述されてればそれで問題ないとおもいます
>>504 じつに奥深い話だったのですね。ボタンの形状をユーザー毎に変化させること
ができるとは知りませんでした。この件につきましてはすこしお時間をいただ
いて調査することになりますが、同じ環境でMSHTA.EXEを使った場合どうなる
のでしょう?おそらく追従しないですよね。今のところは外観の細部について
はCSSでのコントロールになろうかと思います。
HTABOXクイックのドキュメント作成に入りました。 明日にはお見せできると思います。2つ書くのが面倒なのでエンコーダー付 きの単一ソフトにしました。HTABOXクイックを書きながらWSH環境とEXE格納 環境で共通に起動引数を扱う関数が必要だったのでHTABOXコアに追加しまし た。ですからHTABOXコアも2.31になる予定です。
>>507 ありがとうございます。
ユーザ毎に変化させることができる、というのはhidebouさんもなさっていることだと思います。
サイトにあがっているスクリーンショットから推察するに、XPの標準スタイルからクラシックスタイルに変更していますよね。
Windows Vista以後だと、標準のスタイルはAeroです。
MSHTA.EXEを使用した場合は、
>>505 を記述することで追従させられます。
が、
>>506 で指摘したように記述しないと追従させることはできません。
標準で追従させることができれば、それはHTABOXコアの優位点となると思います。
>>509 ひとつ気にかかる点があるのですが。もしHTABOXコアを一般のブラウザのよ
うに未知のURLを表示する目的でお使いでしたら大変危険ですのでおやめに
なった方がいいです。MSHTA.EXEもそうですが、アプリケーションとしてURL
にあるソースを解釈しますのでなんらセキュリティー警告が出ません。
HTABOXコアは原則としてファイルとしてローカルコンピューターにあるHTML
やスクリプトを実行する目的で作成されていますからその点をご了承ください。
こういう機能はどうでしょう? 動画処理とか音声処理などでdllを使わずに、exeを使って処理することがあります。 現状では、処理結果のテキスト出力が不要なら、runで処理してエラーを受け取ると思います。 処理結果のテキスト出力が必要ならexecで標準出力を受けながら処理すると思います。 しかしexecだと画面に一回コンソールの画面が出ます。 これが嫌な人向けに、コンソール画面非表示のままで実行したあとの出力結果を受け取る機能はどうですか? フリーのbasp21のdllを使って、stdout = bobj.Execute2(command,1);って感じでやれば、 WSHやHTAでも、いまでも出来る機能なんですけど、 標準機能で出来るとHtaboxを使おうとする人の敷居を下げられるかと思います。 ちなみにbasp21では、コマンド終了時の画面のテキスト出力を一括で受けることは出来ますが、 1行単位とか1文字づつ出力を受け取る機能はありません。 その場合は、WSHのexecを使うしかないのが現状です。
mazeが生成する一時ファイルを全て教えてください。手動で削除したいです。 いまのところC直下にあったout.txtとtable.txtは見つけて削除しました。 (ファイルの作成日時が11/08となっていたので、古いmazeにあったバグが原因?)
>>511 ご指摘のとおりWScript.ShellのExecとFileSystemObject.GetStandardStream
を使えば親の立場、子の立場で標準入出力ストリームを扱う事ができますが、
それをラップした関数を用意するのは大変有意義だと思います。場合によって
は入力結果を蓄積できるというのもすばらしいアイディアだと思います。
パイプに関して追加したいと考えていあるのは、名前付きパイプサーバー
機能です。これにより複数プロセスのスクリプトが連携して動作可能となり
ます。大変有意義なご意見をいただきありがとうございます。
いつものことですがまだ煮詰め足らない部分があるように思います。 象徴的なサンプルを少し処理した実績しかありませんのでご容赦ください。 ※重要な注意点 EXEファイルはソースHTMLファイルと同じ位置に生成されます。もしその位置 で一時生成&消去動作をした場合ソースHTMLは上書き後に消去されますので、 生成されたEXEファイルは必ず別の位置に移動してから実行してください。
516 :
デフォルトの名無しさん :2010/11/25(木) 00:29:50
ウィンドウへのファイルのドロップ、メニューのサポート、簡単なプロセス間通信、 非表示でのExecの標準入出力の管理、これが全部出来ればすごいね。 例えばウィンドウに[OK] [Cancel] [Option1] [Option2] [Option3]とかの 5つくらいボタンやチェックボックスをつけて、 その下にログウィンドウをくっつけて処理内容をprintするだけでも それなりのツールにはなる。 いろんなツールのフロントエンドを作るのが実に簡単になりそうだw 使う技術はほぼHtml + Javascriptでそこまでできれば、ほとんどの人はそれで満足してしまいそうだ。
>>516 HTABOXがターゲットとするアプリケーションのサイズはイメージされている
とおりピンポイントな用途へのツールだと私も考えています。個人が持って
いるノウハウやテクニックを気軽に書いて販売できればもっとプログラミン
グに興味を持つ方が増えるんじゃないかという想いで開発しています。
今後ともよろしくお願いします。
最新版(
>>465 )でも
>>512 の現象は修正されていないようです。
これはバグなのですか?仕様ですか?
いずれにせよ、アンインストール方法をご教示ください。お願い致します。
というか、一時ファイルをCドライブ直下に作成するという事自体をやめてほしいです。 なにかのトラブルで一時ファイルが消されなかったときに残存してしまいます。 一時ファイルは標準の一時フォルダ内に作成して欲しいです。 それならば、例え削除されなくとも、一定時間が経過すればWindowsが消去してくれますから。
>>519 私の書き込みのタイミングでご指摘に気づかない状態になり失礼しました。
開発中のデバッグ出力機能がそのまま付加されていたかも知れませんので
早急に調査して対応させていただきます。四角い迷路は本来まったく一時
ファイルを必要としないプログラムですので単に私のミスです。ご迷惑を
おかけしました。
>>519 状況を確認しました。c:\out.txtとc:\table.txtが作成されます。これは開発
中のデバッグ情報出力でリリースバージョンでは削除すべきところを見落とし
たものです。即座に訂正させていただきます。
HTABOXクイックは実行指定されたHTMLソースに対して</head>直後にスクリプ トタグを挿入し、例の0pxダイアログでWIN32を取得しています。またファイル 出力前に#define処理も行っていますのでHTABOXコアがレジストリ登録されて いればWSHと同じように通常環境でデバッグしたソースのままEXE化できます。 ただし微妙な差なのですが#defineは以下の書式でなければなりません。 //#define var // var WIN32 = new ActiveXObject("HTABOX.Application"); //#undef var
WSH環境ではスクリプトスコープ外からWIN32が追加されHTML環境では追加さ れたスクリプトブロックでvar WIN32 = ....としている違いによります。 ちょっと紛らわしいのですが今のところご容赦ください。
>>524 と
>>526 のHTABOXクイックで作成したexeを実行すると、
タイトルなしのタスクバーが現れるだけで作動しないのですが……
何にせよHTABOXクイックで
一時ファイル展開→コマンド実行→一時ファイル削除のできるインストーラ作成ソフトで
HTABOXコアとソースファイルを格納する作業から解放されるのですが、
さらなる要望として
○一時ファイルの展開先をTempフォルダとするオプション
○HTAタグsingleinstance="yes"で単一起動とした場合、多重起動はエラーダイアログを出さず既存のウインドウをアクティブにして終了する
○エラーダイアログのタイトルバーにアイコン及びHTMLから取得したタイトル+Errorと表示
などと放言してみます
>>529 環境を教えていただければ原因の究明が早いと思いますが、こちらでも試験
してみます。HTA:applicatinタグの取り扱い周辺で予期せぬ事が起こってい
るかも知れません。ご迷惑をおかけします。ご要望の点については是非実現
してゆきたいと考えます。
531 :
529 :2010/11/25(木) 19:42:26
>>531 了解しました。押している作業があるのでお時間をいただきますが、IE6
での実働試験を行ってデータを収集してみます。
533 :
529 :2010/11/25(木) 19:50:50
書き漏らしその2
>>514 のバージョンでは正常に作動します
当方もwindows2000 + IE6 でだんまりもしくはタスクバーに空の表示という 状態を確認できました。514以降に行った変更をチェックしてみます。
>>523 対応してくださりありがとうございます。
HTABOXの開発、応援しています。お体に気をつけて頑張ってください。
クリス・アンダーセン氏の...を読みました。 世界は「個人」から始まり「個人」を尊重し、その労苦に敬意をはらうこと 無しに存続し得ないと考えています。NETの発展によってリアルな社会での 仕事は激減してゆくでしょう。その中で若者が夢を持って生きてゆくために 私にできることは何かという問いかけへの現実解がHTABOXです。 情報を食べて生きている人類にとって無料で食べ放題な状態はひとつの理想 でしょうけれど、その先にあるものはどこを見渡しても同じビスケットしか 無い状態でしょう。バターたっぷりのクッキーが食べたいと思った時にはも う遅いのです。
今日はHTABOXクイックのコンテンツを当サイトに新設する予定ですが、気分 が急降下で作業が進みません。HTABOXシステムでアプリケーションを提供し た場合、サイトのページが閲覧されたと同じようにアクセスログが残ります。 そこで突きつけられる数字というのはごまかしようの無い現実なわけで、私 が想うところと現実とのギャップにすべてをたたんでおしまいにしたい気分 になることもあります。
540 :
529 :2010/11/26(金) 22:10:47
……どう受けるべきあるいはどう受けないべきかわかりませんが、
ひとまず
>>536 及び
>>538 で生成した実行ファイルがXP+IE6で作動するのは確認できました。
迅速な対応有難うございます。
>>540 ご報告ありがとうございます。しょげてても前に進まないので書くしかあり
ません。せめて「あいつでなければ書けない」といわれるものを残して往き
たいと思います。
Twitter に登録しました。残念ながらhidebouは既存でしたので _hidebou_ にしました。気軽に声をかけてください。
>>543 私はTwitterの動きを見ていて「自動つぶやきロボット」というのを作りたく
なりました。誰かのつぶやきに瞬時にするどい突っ込みを入れるロボットなん
かは楽しいかも知れません。
>>529 のsingleinstance="yes"をお礼に何らかの形で実現したいのですが、
1. 同一パスのexeだったら抑制
2. パスが違っても同一exeファイルなら抑制
3. たとえexeファイル名が変更されようが抑制関数引数が同一なら抑制
という選択肢があった場合どれが一番お望みでしょうか?私は3番がいいと
思うのですが。
説明が不足してしまいましたが、2つ目のHTAが起動動作に入ってからでは 多分手遅れなのでコア上のスクリプトでコントロールすることを前提にすれ ば1,2,3を柔軟に選べる関数とすることができます。 クイックでやる場合は実行ファイルオプションでSingleにたいな項目を設け チェックする手法になりますので、ご意見を伺いたいのです。
自己レスになっちゃいますが、クイックでもドロップダウンリストにして 3択できればベストですよね。
548 :
529 :2010/11/28(日) 08:07:01
仰るとおり三択できれば最良ですが、あえて順番をつければ1、3、2となりますかね 一番厳しい3だと別のパスまたは別のファイル名で起動という逃げ道も塞がれるので用途により良し悪しですし、 2は同一ファイル名で中身は別のexeが起動していると面倒なことになりそうですし
了解しました。
コアにCreateSemaphoreとWaitForSingleObjectを追加し、同一条件をセマフォ 名とし、WaitForSingleObjectに小さな待機時間を指定した結果がWAIT_TIMEOUT だった場合許可インスタンス以上の起動であるという判断をするという方向で 書き進めています。 クイック上では同一パスでの許容インスタンスを1とし、既存であった場合 FindWindowで同一タイトル、同一クラスのHWNDを取得しアクティブにして 自身は無言で終了するストーリーを考えています。クイック上でのSingle オプションはチェックボックスでのオンオフ選択としたいと思います。
考えてみるとFindWindowは素人くさいので、プロセスのスナップショットを 取得しプロセスIDからモジュール名を取得して真に同一パス由来のHWNDなら アクティブにするという動作にしたいと思います。この過程で使用する関数 はwindows2000以降となりますのでそれ以前はサポート外となります。
553 :
529 :2010/11/28(日) 22:15:33
>>552 のバージョンで生成した実行ファイルのXP+IE6上での作動を確認しました
ただ何回か試している内に一回だけタイトルなしのタスクバーだけが現れて無反応という症状が再発しましたが、
再現もできなかったので詳細は不明です
そろそろ一名無しに戻りますが、コア・クイック共々さらなる発展に期待しております
ありがとうございます。私もIE6で実験してみます。ちょっと強引に0pxダイア ログを出しては引っ込める動作が原因でトリプルクリックになった時とかは やや不安定な気がしています。今後とも改良を重ねますのでよろしくお願い します。
今回の改良でHTABOXクイックを1.10とします。 どうも日本人受けしないのでデフォの表示を英語にします。サーバー側ASPも 更新しますので従前のバージョンはサポート外となります。作業が終了しだい 報告します。
>>557 これは内部でMessageBoxを呼んでいる部分ですね。HTML系のalert等を回避し
てMessageBoxの本来の引数をコアで利用できるようにすればある程度コントロ
ールできるのでしょうね。
HTMLでGUIを構築できるのですから作る側はCSSでコントロールすべきだという
のが今のスタンスです。で、使う側がそのデザインを変化させたいと考えた場
合についてまでは今の所考えが及んでいません。
ひとつ思いつくとすればアウトプロセスのIEドキュメントを横取りして制御
する手法でしょうか。これならHTAではなく通常のHTML扱いですからIEで可能
な修飾はすべて使えることになります。ただしソース隠蔽はCOM無しでは不可
能だと予測します。
訂正します。可能かも知れません。 IEをローカルHTMLファイルへナビゲートしてHTABOXクイックで使っている 0pxダイアログ手法を用いればスクリプト生成初期にCOMを注入できるかも 知れません。今までプロセスの中だからという観念しかありませんでした のでこれに気づいたことは大変大きな意味があると思います。 動作が遅くなり、IEのごちゃっとしたメニューには付き合わなければなり ませんが、外観重視の場合は単にHTMをIEで表示してディスパッチだけ送り つけるという手法もありだと気づきました。ありがとうございました。
とりあえずCreateHtmWindow関数(IEナビゲート)をテストし実用に耐えれば クックの実行ファイルオプションとして「IEで実行」を付け加える方向で検討 したいと思います。 場合によってはHTAドキュメントとIEドキュメントのすり替えも可能かも知れ ません。プログラミングなのかクラックなのかという判断が曖昧な世界になっ ていますが「EXEをクリックしたんですから何でもありでしょう」という観点 から見ればすべては正当なプログラミングテクニックと解釈してください。
やってみるとIEはファイルがローカルだというだけでありがたい「Internet Explorer情報バー」を表示するんでしたね。もちろんサーバーサイドのURL なら表示されないわけですから、無害なURLで安心させといて横からコントロ ールする手はありますが、美しくないので別の手をさがします。
あぁ!ということはコアならOKということを示唆しているんですね。確かに コアならスクリプト無しのHTMLが基本ですからIEも文句を言わないし、イン スタンスさえ捕捉できればあとはやり放題ですから。 これで解決です。CreateHtmWindowは「情報バー」にげんなりして作ったまま 放置したんですが、単純な事に気づきませんでした。ありがとう!!!
コアのスクリプトからIEに依頼する形でHTMLを生成させドキュメント系イン スタンスとHWNDをHTAやDLGのように取得することができました。 今後実行中の別インスタンスを取得させてくれとかツールバーやタブはどう 操作するとか本来の目的とは関係ない要望がわんさか来てしまういやな予感 はするのですが、一つの選択肢として表示にIEを使うことはできそうです。
今日は私に万が一のことが起こった場合に備えて今までの全ソースコードと スタンドアロン版に書き換えたコア上のプログラムをCDRに焼いて妻に渡そう と思っています。その作業が終わったらできるだけ多くの海外フリーソフト サイトへクイックを登録したいと考えています。月が改まるたびに自責の念 が重くのしかかります。
クイック1.10の開発にともなってコアのユーティリティー関数に追加と仕様 の変更がありましたのでHTABOXコア2.40としてリリース予定です。ドキュメ ントの準備が整いしだい公開します。 HTABOXコア2.40にはCreateHtmWindow関数でIEを使ったHTMLインスタンス生成 とディスパッチ追加のデモンストレーションが含まれます。
コア2.0デモのWSH起動で
>>562 を連想していたんだからその時点で書き込めばよかったw
まあ役立てたならば何よりです
そして元ネタの人にはごめんなさい
「素直にHTAにすればいいんじゃ」とか考えてました
元ネタの人は大いに困惑しております。 実装系というのは全く見識が及ばないので head内にタグ1つ挿入するくらいのことなのだから、わけもないだろうと考えていました。 なんかごめんなさい。htaにメニューバーつけたかったんです。
元ネタの人とは
>>562 の「VBScriptでGUI 」を書いた人を指したつもりだっんだけどまあいいや
なんか私が見当違いな事をしているようであらためて勉強すると
ttp://msdn.microsoft.com/ja-jp/library/ms997646.aspx にXP以降で有効なAPIの例があって
HTHEME OpenThemeData(HWND hwnd, LPCWSTR pszClassList)
とか見たことの無い関数があるんですね。でHTA系は
<META HTTP-EQUIV="MSThemeCompatible" CONTENT="Yes">
で適用されるんですよね。だから適用してもらいたいアプリを書いている人
は書けばいいという展開でよろしいんでしょうか?
で、私が提供する実行環境だとこれが無視されてしまうというストーリー なんでしょうか? だとすればこのmsdnのどおりにやれば適用されるものができるのかも知れま せんがちょっとお時間をいただくことになろうかと思います。
HTABOXコア2.40への改訂作業で一時エンコーダーを停止しています。
エンコーダーフォルダにもリソース格納のサンプルを置きましたので、 EXE作成時に雛形としてください。クイックは使いやすいとは思うのですが、 数日でクイックを完成できるほど強力な開発環境がコアですのでどうか かわいがってあげてください。
尚、現在HTABOXクイックに関する情報を独立したコンテンツとして提供する 作業を行っております。HTABOXシステムの一端として紹介するとページ数だ けで入門者には敬遠されてしまうだろうという判断からです。数ページの内 容となりますが、完成するとQuick.zipのダウンロードURLも変化しますので 運用を開始したらここでご報告されていただきます。
・私のような貧乏人がクラウドに対抗するためのHTABOXサーバー ・HTMLアプリケーションの可能性をどこまでも拡張できるHTABOXコア ・単にドロップするだけでEXEを生成するHTABOXクイック 私が考えていた以上に系統だった構成となりました。これもひとえに皆様の 暖かいご支援のおかげでです。もし私に先立つものがあれば、皆さんを庄内 にご招待して大宴会をしたいのですが、食うや食わずの身なので、今しばら くこれをビジネスにつなげてゆく努力をさせていただきます。
HTABOXクイックは皆さんの為に作りました。単純にドロップしてEXEが生成 されながらHTABOXコアと同等の拡張機能を利用できます。メニューは例に よってTABLEを宣言するだけです。 これを使って皆さんが書き溜めていた自分のためのスクリプトを世に出して ください。どんなに局所的なツールでも自分が必要なものは世界中で何千、 何万の人が必要と感じているに違いありません。 その手助けをするためにHTABOXクイックは存在します。
次に向かう方向については以前にもお話したようにスクリプトへの DirectX基本機能操作メソッドの公開と考えています。DirectXの表 層部分は仕様変更が激しく実装しても意味がないと考えますが、 DirectDraw、DirectSound、DirectInputの基本的インターフェースは 今後も有効であろうと予測しています。
たとえばリアルタイムなWAV録音と再生メソッドがあるだけでもHTABOXを 使ってスクリプトを書こうとする方が増えてくれるのではないかと考えます。 まぁ、いつものように私が知らないだけで、「みんな楽々とそんなこと実現 していますよ」だったときはそっと教えてください。
引き続きHTABOXコア、HTABOXクイックについてのご要望をお待ちしております。 具体的な動作でなくとも「こんなアプリケーションを書きたい」という目的 から、具体的な機能が追加されるわけですから、気兼ねなく書き込んでください。
有益な情報ありがとうございます。 彼にとって私のプログラムは脅威となるように思えます。 HTABOXシステムのアドバンテージは当初フリーで使ってもらい必要に応じて アカウント制限をかけることも、それを解除することもできることです。 その特徴を最大限に利用した戦略で臨みたいと思います。
アプリケーションをパッケージとして渡す時代は終焉しました。その対極 にあるのがクラウドですがこれは大資本がなければ設備を持つことすらま まなりません。私たちに残された選択肢はただ一つ賢いWEBアプリケーショ ンを書くことだけです。 その観点から眺めるとHTMLアプリケーションはそのために存在するような環 境であることに気づきます。そして問題はただ一つソースが見えるか見えな いかに集約されます。これは意地悪が目的ではなく対クラック用の武装とし て必要なだけなのです。
「何をやりたいのか?」という質問に「プログラミングという概念を変えたい」 と答えたところで多くの方にとっては無謀な試みに思えるでしょう。 まして既存の面倒くさい開発手法にかかる時間を理由に法外な値段を提示して いる業界にHTABOXの利便性を説明したところで「いやなものを見てしまった」 くらいにしか思われていないのでしょう。 ちょっと愚痴をこぼしたくなりました。
サーバーのログにもちらほらJP以外のユーザーエージェントが見られるよう になってきました。儲かる商売ができるようになったらもっと温暖で税金の 安い国に拠点を移そうと夢見ています。日本はすばらしい国ですが、残念な がら沈む行く国に見えます。特に私のような田舎では出歩いてもたまに老人 を見かけるくらいで、人そのものがいないのです。
考えてみるとC++部が物理データと接触する部分はANSIを想定しているので UNICODEも柔軟に処理できるようにしないと苦手な英文メールがたくさん来 てしまいそうな気がします。Quick.exeも明らかにHTMLのGUIを持っているわ けで、それだけでも驚きでしょうが、それがまたHTAのようなEXEを生み出す わけですから初めて見る人は狐につままれている気がするでしょうね。
実際に行動してみて思うのですが、プログラミングという分野はあまり言葉 の壁を意識しないで済むんですね。少々誤訳があったとしてもソースを例示 すれば万国共通ですから「あっそう」になるわけで、そういう意味では最も 世界に成果を発信しやすい分野だと思います。ぜひ皆さんもコアやクイック を使って世界をターゲットに作品を発表してみてください。
Freeware Guideにも登録してたんですが、よく判らないんで適当なカテゴリ に投稿したにも関わらず「HTML to EXE HTML Conversion Tools」と紹介され ていて、またちょっと感動しました。海外のサイトって大雑把なんじゃないか と思ってたんですが、なかなかきめ細かい管理がなされているんですね。
開発環境は一応の完成を見ましたので、主題はその上で何を書くのかにシフ トしてゆく事になります。そして具体的テーマで必要とされるものがコアに 追加され、安定した動作が確認できれば公開関数として紹介されてゆくこと になります。
いまもところ漠然としているのですが、もっとも重要なテーマは「通信」に なろうかと思います。たとえばクライアントコンピューターを仮想的にサー バーにしてしまうこともHTABOXの技術を使えば可能です。これを発展させれ ば稼働中のクライアントパワーを結集して巨大な仮想サーバーを構築する ことができるかも知れません。 誰の管理下にも無い「群集」という意思を持った巨大サーバーというのは プログラミングに携わるものにとってとても魅力的なテーマではあります。
今日は金策のための書類を作成するという実に自営業者らしい一日をすごし ました。考えてみればプログラミングという作業はビデオゲームに没頭して いる時のような浮世離れした感覚を伴います。すべてはコンピューターという 箱の中で起こっていることなのですが、それが広い平原に思えたりごつごつ した岩肌に思えたり。その中で自分がどう立ち回るのかをプログラミングして いる感覚です。プログラミングを楽しいと感じる方々はたぶん分かっていただ ける話だと思います。
他の事で手一杯だったものですから当サイトのコンテンツは成長が止まって いたのですが、JScriptネタにXMLとXSLの実用的なサンプルを追加したいと 思います。クイックのファイルリストテーブルは正にそれでできています。 構造体代わりにXMLを使えばXPathで極めて少ないソースコードと高速な処理 を両立できます。ただしプログラムでは見通しがいいXMLもユーザーから操作 してもらう段階ではHTMLに変換しないと扱いにくいものになりますが、XSL 変換で処理すればこれまた楽ができます。IE8ではTDCが使用不能であることに 最近気がついたものですから、TDC代替ソート付テーブルをXMLとXSLで実現 するストーリーにしたいと考えています。
TDC代替オブジェクトのサンプルスクリプトは清書したんですが、日本語で 解説を書くのが面倒で、ちょっと一休みしてます。私自身これを書いたとき は目から鱗が落ちましたので、何かしらデータを一覧表示して見せたい系の アプリケーションの場合、有効なテクニックだと思っています。
話題を変えてHTABOXコア誕生秘話をすこしだけさせてください。 これだけネットワークインフラが整備されると、データであれプログラムで あれ、ありとあらゆる物がコピーされクラックされ、本来対価を伴うはずの 開発、製作の労力は報われることのない状態となています。私はそれを使う 側のモラルの問題だとは思いません。ただで使いたいというのは自然な流れ ですし、そうできてしまうプログラム側に問題があると考えています。
自身もクラッカーとして自身が作ったプログラムを攻撃するわけですが、 クラッカーが一番いやなのはサーバーがらみのシステムだった場合です。 たとえばバイナリ書き換えで正解を探ろうにもサンプリング動作のログ がサーバーに残るわけですからうかつにテストも行えません。 また、クラックにはパケットの解析が不可欠となりますがHTABOXシステム のように揺らいだ規則のエンコードの場合やはり多くのサンプリングを 必要としますのでサーバー側からシャットダウンされる可能性が高まります。
サーバーとのコネクションが必須であればクラックしにくいことは理解いただ けたと思います。では次にサーバーとのコネクションがスパイウェアのような 動作だと判断されないためには何が必要でしょうか?その答えはご想像のとお りブラウザのGET要求を起点とするコネクションであればいいのです。もし この動作を危険と判断するならばすべてのGET要求は危険なことになります。
HTABOXによるHTMLApplicationは「簡単」なのに「クラックしにくい」という 状態を実現するために作られたのです。これによって初めてアプリケーション の「使用を許諾する」という言葉が実効性を帯びるわけです。 私がなぜHTMLApplicationをベースに据えた開発環境にこだわったかという理由 は以上の要因からです。
JScript再入門にTDC代替オブジェクトの作成コードを追加しました。
同時に本サイトの静的有料コンテンツの価格を月額105円に統一しました。
サーバーの灯が消えれば、HTABOX関連の技術を提供することもままならない
状態となりますので他のコンテンツともどもよろしくご検討ください。
当サイトサイトマップ
ttp://kuroda.bglb.jp/sitemap.htm
「中小企業優秀新技術・新製品賞」ソフトウエア部門へのエントリーを予定 しております。締め切りが迫っておりますのでレポートの作成に集中したい と考えております。このスレッドに対するレスポンスが鈍ると思われますが、 ご了承ください。
レポートのネタにと思って.NETのJScript(jsc.exeコンパイル)から CreateHtaWindowでインプロセスHTAを生成してみたのですが、いい感じで 動きますね。jsc.exeで生成されたファイルのコードは厳密には隠せません から個人用ツールという位置づけになりますが、.NETのJScriptはWSHと違い CPUの占有率がおとなしいですから、こいうった利用方法も紹介すべきかと 思っています。
で、やろうと思えば、静的なEXEファイル中にはエンコード文字列を置いて 起動後にデコードしてコンパイルし、カジュアルなクラックくらいは防げる かも知れません。ついでにHTMLをリソース格納できればHTABOXコアの.NET版 になるかも知れません。まぁあんまり需要があるとは思えませんが。
.NET環境のJSC.EXEでコンパイルしたEXEからCreateHtaWindowするデモを作成
しました。.NET1.1以上が必要と思われます。詳細はReadMe.txtをご覧くださ
い。.NET環境で実行されるEXEプロセスはIDispatchExのマーシャリングがブロ
ックされているように感じます。ですから単純にWIN32を追加できず、window.
openerへのセットとしています。詳細はソースコードをご覧ください。
ttp://kuroda.bglb.jp/htabox/jscdemo.zip
wscriptかcscriptで実行されると自分自身をhtabox.exeで引数実行しなおすVBScriptを適当に書いてみた On Error Resume Next strPath = LCase(CreateObject("Scripting.FileSystemObject").GetBaseName(WScript.FullName)) If (strPath = "wscript") or (strPath = "cscript") Then CreateObject("Wscript.Shell").Run "htabox.exe """ & WScript.ScriptFullName WScript.Quit End If On Error GoTo 0
>>611 とてもスマートなコーディングですね。コードを公開してくださって
助かる方も多くいらっしゃると思います。ありがとうございます。
なぜベクター側のバイナリを変更せずに動作を変更できるのか不思議に思う 方もいらっしゃるかも知れませんが、ダウンロードされたバイナリには迷路 を生成するコードはあるもののトリガー部分が無い状態となっています。 トリガー部分はサーバーにありますのでどういった動作とするのか、認証を 必要とするのかといった決定をサーバー側のセッティングで変更することが できます。
もし、すべての動作をサーバーサイドで行うクラウドであればすべての動作を サーバー側で変更可能ですが迷路の場合、サイズが30以上となるとサーバーの CPU稼働率は瞬間的に100%に達します。当然複数の要求を平然とこなすことは 不可能です。迷路の作成はクライアントCPUで行い、その制御だけをサーバー 側で行うという選択を可能にするのがHTABOXシステムの実像です。
C++コードからマネージ環境コンパイラを起動してJScriptコードをメモリ内に ディスパッチ化し呼び出すというコードを勉強していました。確かに時が過ぎ ればFSOを呼び出すかのようにSystem.IOを利用する事になるでしょうから.NET 環境でのスクリプトを起点としたHTMLアプリケーションも必要だと感じました。
私はまだ.NETのことを良く知らないのですが、静的なファイルのデコンパイル によってソースが暴かれているとすれば、今日のコードでそれは阻止できる ことになります。まぁ世の中そんなに甘くはないでしょうから実行中のマネー ジコードを観察できるようなツールがあったりするんでしょうね。
マネージ環境向けソースコードの動的コンパイルは生成アセンブリを外界と 通信可能なCOMでラップすることによりHTML中のスクリプトから.NET機能を 呼び出せる可能性を生みます。極端な例ではEvalする形式でC#コードをHTML 中のスクリプトに書けそうな気がします。 「C#にできることはお好きにどうぞ」 が実現できれば、私がWIN32APIへのブリッジを書く必要もなくなるわけで 大変楽ができそうです。
> KSプログラミング 4.9
>
ttp://www.vector.co.jp/soft/winnt/prog/se101656.html > すぐに作れる、簡単、快適、Windowsソフト作成用プログラム言語システム
> (10.06.01公開 1,443K フリーソフト プログラミング:その他)
> ソフト詳細説明
> ・すぐに作れる、簡単、快適、Windowsソフト作成用プログラム言語システム。
> ・習得が簡単といわれているHTMLライクなプログラム言語
> その名も 「KSプログラミング」。
> ・ちょっとしたプログラムがあっという間にできあがる。
> ・単体で動作するEXEファイル作成までばっちり対応。
HTML、C#、.NET機能呼び出しで三題噺的にこれを連想
……でも実際あんまりHTMLライクじゃないよねこれ
>>619 興味深い情報をありがとうございました。.NETの内部(マネージ空間)では
何でもありですので自前の言語仕様を設計したい気持ちになるでしょうね。
でも、私は既存スクリプト(ネイティブ)とマネージ空間とのブリッジを
目指します。既存言語仕様の拡張なら必要なければ使わなければいいという
選択肢がありますが、新規言語仕様になるとたとえ単純でも敷居が高くなる
気がしています。
今考えているストーリーは例えば HTML中のスクリプトからSystem.IO.StreamReaderを利用したいとする。 WIN32APIのようにそのターゲットだけをスクリプトに出現させることは簡単 ですが、それでは他の要求があるばあい1つづつ書き足す必要が生じる。 私は横着なのでそんなことしたくない。スクリプトにはNetEval関数を提供し 動的に希望のインスタンスをディスパッチとして提供したい。 みたいな感じです。鬼門はマーシャリングになるでしょうか。
で、もし可能であればシステムアセンブリを自前で持つ形にし、サイドバイ サイドで.NETを実行させたいという野望があります。セキュリティーという 面ではシステムアセンブリのアップデートを無視するのでよしく無いわけで すが、枯れた.NETバージョンならありなのではないかと。結果的にインスト ールの必要なく自身が必要とする.NET機能を使えるわけです。
ここ数日.NETのことをまじめに分析してみたのですが、なぜそこまで閉鎖的 に作ったのかという疑問が残ります。結局内部ではDispatchでInvokeなわけ ですから、ネイティブなコードからツールとして使える窓口を作ればそれな りに重宝なモジュール群だと思うのですが、内向きにしか機能を公開しない 設計なために中で書くのか外で書くのかの選択を迫っているかのようです。
幸いC++ではマネージとアンマネージの混在コードが書けますから、外界から のソースコードをメモリ上にコンパイルして、結果として生成されたアセン ブリを外界へCOMモジュールとして公開することができそうです。ですから 自分が使いたいと思う機能を実現するクラスを書いたソースコードを動的に コンパイルして、そのメソッドをスクリプトから呼んでもらうというのが 一番自然な流れになると思います。
あぁ肝心な事を忘れていました。.NETの動的コンパイルは実ファイルの生成 を指定せずメモリ上の生成としても一時生成ファイル領域に頼みもしないフ ァイルを生成しています。ということはマネージ環境のソースを隠すことは 難しいですね。.NETは対Javaな訳ですからそういう性質のものだと。
アプリケーションの起点が.NETだからソース全般が見える訳で、ネイティブ を起点とし、必要な局面だけマネージコードを使用するという方向性はいい んじゃないかと感じています。.NETのソースは隠蔽できないので難読化する しか無い訳ですが、シンボル名の変更等の手段しかなくてかわいそうです。
「.NET系のソースを難読化する必要があるのか」とういう趣旨の論議に目を 通しました。最も印象深い発言は「.NETレベルのコードに隠す必要性を感じ ない」というものでした。確かにすでに用意されているアセンブリをどう組 み合わせても既知の技術の組み合わせにすぎないわけですから然りです。 でもアプリケーションで構造そのものが重要な意味合いを持つ場合、単に実 装手法というようなレベルの話題では割り切れない局面もあると思います。
私はアプリケーションを「一時製作者の叡智を借りるもの」と考えています から、アプリケーションは製作者から離れた製品ではなく製作者の分身また はエイリアスだと認識しています。それが無断で使用されるとかソースが盗 用されることは人権の侵害以外の何ものでもないと思います。 そんな理屈をこねていても世の中前に進みませんのでHTABOXを書いていると いうのが私の姿です。
C++ネイティブコードの観点から.NETを眺めてみるとCLR非依存の状態である 程度の操作が行えるように準備されていることに気づきます。というか.NET であろうがプロセス起動初期は通常のPE仕様でのプロセスですから当然とい えば当然です。
私は今や誰も見向きもしないv1.1.4322のディレクトリを眺めているんですが 当時から切り離す事が決まっていたJ#系のDLLとTLBは独立した構成となって います。現在取り組んでいる課題とは方向が異なりますが、これを解析する ことによりWindows上の高速なJava環境を復活させる事ができるかも知れませ ん。
C++ネイティブコードでCLRをロードし、動的に文字列をコンパイルするとい うことに取り組んで見たのですが、最終局面で例外が発生します。動的では なく既存アセンブリの実行なら問題ないですから、既存アセンブリ内に動的 コンパイル動作を記述すればいいのですが、そのアセンブリが作られた.NET バージョンを暗黙に要求することになるので、できれば回避したかったので す。
脳みそと時間が足らない状態での検証でしたので、すべてを知り尽くしたわ けでは無いのですが、概ね.NETの雰囲気はつかめたと思います。上記実験の 結果としてHTML中スクリプトから.NETの機能を使う場合はコンパイルした自 前のDLLを用意してもらい、ネイティブ環境からDLL内のクラスとメソッドを 指定した呼び出しがあった場合に中継するというのが自然な流れになります。
もうひとつの方向は
ttp://kuroda.bglb.jp/htabox/jscdemo.zipで行ったよう に.NET環境へHTMLコンポーネントを提供する手法です。おそらくこちらの方
がインパクトは大きいように思います。現状でHTAを知っていてコードを書く
人間にとって.NETの機能が使えたところであまり喜ばれない気がします。
それよりは、C#しか書いたことが無いという人間にアプリケーションウイン
ドウとしてHTMLコントロールを使ってもらう方が喜ばれるでしょう。ですか
ら混乱を避けるために新たな名前を考えるべきですね。今のところDNETBOX
にしようかなと思っています。ファイル一時生成でいくかリソースのままで
いくかはまだ未定です。
DNETBOXのキャッチとしては最初 「C#とHTMLでお気軽プログラミング」 いつの間にか 「C++マネージコードとHTMLで楽々プログラミング」 最終的に 「C++COM構築とHTMLで本気なプログラミング」 という展開は実に私らしい落ちでいいかもと思っています。
執念深くコードを書いていたらC#の場合ソースコードをネイティブな外殻EXE 内に保持して、実行環境を判断してから動的にコンパイルし、生成アセンブリ を起動することに成功しました。つまり開発環境でコンパイルするのでは無し に、スクリプトのようにC#ソースを暗号化して保持し実行時にコンパイルする 事が可能です。したがって書き方によっては.NETのバージョンを選ばないソー スとすることができます。若しくはアセンブリの実行前に外殻EXEからきめ細 かな指示をユーザーに与える事ができます。
どうしてもJScriptに愛着があるものですからJScriptCodeProviderで実験を 行っていたのですが、アンマネージC++がロードしたCLR環境だとCompileで こけます。例外も出せないようなこけ方ですので構造的に無理なんじゃない かと思います。CSharpCodeProviderの場合は慎重にコーディングすれば動作 します。
637 :
デフォルトの名無しさん :2010/12/19(日) 17:52:10
質問。HTABOXで書かれたソフトを使ってるとき、勝手に作者さんのサーバーにIPアドレス等の個人の情報が送られることはあるんですか? スレをざっと眺めたかんじだと、ソースの管理と称して危険な感じがするんですけど。
そういったご質問をお待ちしてました。結論から申しますと、私は個人の 情報などは一切収集しておりません。POSTされるパケット長を監視してい ただければ理解できると思いますが将来のために当サーバーのアカウント 情報を暗号化して受信し記録する機能は現時点で持っています。
そもそもプログラムを実行するとはブラウザでページを見る事とは本質的に 違う判断に基づくものであることはご理解いただけると思います。EXEファ イルの実行はコンピューターに対するユーザーの権限を製作者に委ねる行為 と言えます。
これはHTABOXに限ったことではなくあらゆるプログラムに言えることですが、 プログラムは実行中のコンピューターに対してあらゆる事ができますが何を 行うのかは製作者のモラルに帰着しますし、製作者との信頼関係が無ければ 不用意にEXEファイルを実行してはなりません。
で質問の内容に戻りますが、HTABOXコア、HTABOXクイックで生成されたEXEが 何かをどこかに送信することはありません。 HTABOXエンコーダー、HTABOXクイック格納動作時にはフレームの上側をサー バーのレスポンスで形成し、将来そこに埋め込まれる当サイトの認証情報を サーバー側へポストするという動作としています。現在は無認証ですので 内容のあるものとはなっていません。
HTABOXコア、HTABOXクイックは極めて簡単にHTTP経由のアプリケーションを 作成できます。それはご指摘のように危険もはらむ両刃の剣です。もし私の 作ったHTABOXが結局HTAのように悪戯の道具にされるならば、提供する開発 者毎にバイナリを生成し識別規則を設ける必要があるだろうと考えています。 ただし、そんな日が来ないことを信じています。
643 :
637 :2010/12/19(日) 21:49:49
つまり、 1、hidebouさんのサーバーからなんらかのコマンドを受け取る機能は持ってるが、それは有効化されていない。 2、いまの仕様は、hidebouさんのサーバーへ認証をしない仕様になっているので、そのパケットのやり取りは全くしていない。 3、Exeを実行するなら、当然だが各自で責任を持て。 ってことで、とりあえずはIPアドレス程度の情報でも、勝手に収集される心配はないってことで理解していいですよね?
説明の仕方が悪かったかも知れませんのでできるだけ噛み砕いて説明します。 HTABOXコア本体であるHTABOX.EXEは単にローカルで実行するEXEファイルです。 これ自体は格納されたスクリプトを実行する入れ物に過ぎません。引数なし で起動された場合のレジストリ登録機能以外は自分で何かをするという能力 はありません。
次にHTABOXコアにフレーム形式のHTMLファイルを表示させ一部をサーバーレ スポンスで形成している場合(HTABOXエンコーダー、クイック)についてで すが、通常にブラウザでサーバーからページをGETする動作になりますので 収集するしないに関わらずサーバーにはログが残ります。当サイトをブラウ ジングしているのと同じですから時刻、IP、エージェントは残ります。
646 :
637 :2010/12/20(月) 01:45:38
そちらのサーバーの機能を利用してない場合は、ログは残らないってことでいいのですかね?
上記形式の動作時に将来の認証追加に備えて当サイトへのログインアカウン ト情報を暗号化してローカルPCからサーバーへPOSTしています。現在は無認 証ですのでゲスト用アカウント情報です。番号毎に回答しますと 1.HTABOXエンコーダー、HTABOXクイックはサーバーとのコネクション無しに は動作しません。 2.クライアント側から見てフレームページのGET、当サイトのログイン情報 のPOSTを行っています。 以上の説明でご理解いただけるでしょうか?
ログが残る=サーバーと通信しないと動かないと理解しました。夜分遅くまでありがとうございました。
>>646 どうもグズなので入れ違いの書き込みとなってしましました。
HTABOXに格納されたプログラムがサーバーとのコネクションを要求しないも
のであればまったくのスタンドアロンプログラムとして動作します。
>>648 いいえ、こちらこそReadMeやHELPに明記すべきですので、今後は明確に動作
を説明する記述を心がけたいと思います。お気づきの点がありましたらお気
兼ねなくご質問ください。
ってことは
>>646 の解釈でいいってことですよね。
ファイアーウォールの警告も出ないから、どうやって通信してるかと思ったwんだけど、
迷路のようにデータをサーバーに取りに行く仕様にしてあれば、当然のごとく通信するけど、
自分でスタンドアローンで動く仕様でスクリプトを組んだ場合は、そちらのサーバーとは通信しない。と理解しました。
メニューを生成しているウインドゥをF5で更新してみたらテーブルのほうも表示されるw CSSで非表示にしておくのが無難なようです
>>653 F5での更新は気づいていませんでした。完成したHTMLのメニュー用TABLE
はご指摘のようにCSSでdisplay:noneを指定することを推奨します。
ウインドウメッセージを細かく拾えば今後対応できる可能性もあります。
ありがとうございました。
.NET用BOXの検証が大体終わりました。今の構想では 各言語へHTMLインスタンスを生成し操作できるロジックを与える。 コンパイルしてエラーが無いことを確認済みのソースファイルをドロップし てEXE格納する。EXE内には暗号化したリソースとして格納される。 EXEが実行環境でクリックされた場合システムが提供する場合デフォルトCLR を取得し、当該環境で多言語用コンパイラを生成する。 生成されたコンパイラへ格納済みソースをデコードして渡し、実行環境に適応 したアセンブリを生成する。 可能であればこのアセンブリはユーザーから見えない状態とする。
つまりVisualBasic、CSharp 、JScriptを未コンパイルな状態で保持し実行時 コンパイルとすれば.NETのバージョンを気にする必要が無くなるだろうという 極めて安直な発想からスタートしています。勿論下位互換を意識したコーディ ングがあってこそ実現可能ですが、将来.NETがバージョンアップした場合も そのまま動く可能性が大であるというメリットはあると思います。
C:\WINDOWS\Microsoft.NET\Frameworkにある各バージョンのファイル構成を 眺めると、毎度の事ながら単純な状態から拡張が行われる過程を眺められる 状態でないと何が重要で何がそうでないのかの判断が難しいだろうと痛感し ます。ちなみにアンマネージ状態のC++からCLRを操作するには<Mscoree.h> が重要になりますが、1.1なら総当りで解析してもそれまでという量でも3.5 になると絶望的な量になります。
アセンブリを外見上生成せずにソースコードをメモリ上でコンパイルして 実行することに成功しました。これにより.NETコードを隠蔽実行すること ができます。セキュリティー上の理由で実行前にアセンブリをチェックし たいという要求とは相反する動作となりますが、これで動的なCLRコード 解析以外の方法ではソースが見えない状態を実現できました。
659 :
653 :2010/12/21(火) 18:18:15
もしやと思ってサンプルのコア+HTML+WSHで表示したウインドゥをF5で更新してみたら、 WSHファイル側に記述して送りつけているプロシージャが全滅…… 構築と注入のタイミングを再考してみれば当然の動作とはいえこれはちょっとまずいんじゃないでしょうか
>>659 私もクイックのデモで同じ状態を確認しています。ダイアログベースの場合
は発生しないのでHTAベース固有の問題なのかも知れません。今取り組んでい
る課題にけりが付き次第F5問題に取り組みます。ご迷惑をおかけします。
以下がCreateHTAWindowで生成したウインドウに対するF5キー直後のメッセー ジとRefカウンターの動きです。 DocMsg 00000111 MSG = 000e03a4 MSG = 000e03a4 MSG = 000e03a4 MSG = 000e03a4 Release Menu 00000005 Release Menu 00000004 Release Menu 00000003 Release Menu 00000002 MSG = 000e03a4 Mother Release 00000011 Mother Release 00000010 Mother Release 0000000f Mother Release 0000000e Mother Release 0000000d
起点はドキュメント側プロシージャに対するWM_COMMAND(0x0111)でしたの で単純にif(uMsg == WM_COMMAND) return(0);で解決できそうです。 できるだけ早急に各ダウンロードZIPを更新する予定です。この問題を指摘 してくださった方に心から感謝申し上げます。
あらためてF5とCTRL+F5について調査すると F5の場合 wParam=00011799:lParam=00000000 CTRL F5 wParam=0001179b:lParam=00000000 ですから何を条件に蹴るべきかちょっと悩むんですが、ドキュメントにメニ ュー系コントロールが乗ることはないと思うのでlParamの数値にしようかと 考えています。それから当然の事ですがCreateHtmWindowは別プロセスIEです からDLLフックしない限りメッセージを制御できません。したがってF5につい ての対策を行う予定はありません。
ついでですからHTABOXコアに.NET用ソースの実行時環境メモリ上コンパイル 機能を追加して簡単なデモをお見せできればと考えています。今のところ 動作を単純化するためにターゲットEXEの単一ファイルを処理する機能とし ています。まだまだ.NETって何?の状態ですから知識のある方の目に留まっ てダメだししていただければいいなぁと思っています。
上記デモのポイントはHTABOXコア自体は従来どおりネイティブなEXEとして 存在することにあります。HTABOXコア自体がマネージではその時点でCLRを 要求してしまいますから意味がありません。あくまでもネイティブなEXEと してCLRロードのネゴシエートを行いメモリ上でのアセンブリ生成と起動を 行う事にあります。
メモリ上でのアセンブリ生成といってもどこかに一瞬ファイルが生成される はずですから現時点では完全なものではありませんが、少なくとも現存する ファイルを対象とした静的デコンパイルツールは無力化されることになりま す。
668 :
653 :2010/12/22(水) 18:57:55
素早いF5対策有難うございます。 アイコンはあまり気にしないほうなのでこれは要望になるのですが、 ドロップでの実行機能を削除、想定していない拡張子のファイルが引数に指定された場合は無言で終了する コマンドライン版?のHTABOXコアを今後のバージョンに添付していただけると 個人的に使い勝手がありますので、ご検討くだされば幸いです。
htaboxで麻木さんキャプ職人のための支援ツールを作ろうと心に誓う。 勉強はおいおいやろうと思う。ではでは。
>>668 了解しました。コマンドラインからの呼び出しについても見直して2.50とし
いと思います。
>>669 私はプログラミングって最もお金のかからないゲームだと思います。かから
ないどころか、ひょっとしたら大金持ちになれるゲームです。
マイペースで楽しんでください。
デモ用にCSharp、JScript、VisualBasicの各言語でHelloWorldを書いてみま した。今回のチャレンジでひとつはっきりしたことがありました。この3つ の中でCSharpは最もシステムに近い位置にあります。これはネイティブ環境 からコンパイルを試みると参照すべきDLLが少ないことで確認できます。 CSharpを基本として外界のCOMが必要な場合にJScriptでラップするという使 い方が最も賢いんじゃないかというのが現時点での感想です。
やっとwscでdllもどきを作ってgetobjectするという使い方の便利さが判ったんですけど、hidebouさんはwscを使いますか?
「HTABOXは.NET用の各言語をスクリプトとして扱う」という表現をすれば私 のやろうとしている事が理解されやすいかも知れません。.NETはレジストリ 依存のCOMDLLシステムが生み出したDLL HELLからの脱却を目指した訳ですが 逆に.NETのVERSION HELLを生み出しました。MS社にしてみれば常に新しいバ ージョンを追わなければならない状況を作り出したいのでしょうが、私はそ の戦略に一石を投じたいのです。
中間コンパイルファイルであるアセンブリには生成された環境の.NETバージ ョンが埋め込まれます。で実際に動作する環境のバージョンとすり合わせが 行われ、実行できない場合も発生するわけです。でもソースのまま保持し、 実行環境で取得された.NETバージョンでコンパイルすればその問題は生じま せん。
現在の構想では製作者がソースをEXE格納する段階で、希望する動作バージョ ン、それが取得できなかった場合のメッセージ又は動作、を細かく設定可能 でなければ意味が無いだろうと考えています。従来はWindows内部で行われて いたネゴシエートを開発者側で行えるようにします。
>>672 すいませんでした。だらだら書き込んでいて反応できませんでした。
WSC(Windows Script Components)だとしたら私はあまり使いません。
結局スクリプトでできない事はWIN32APIで実現するしかないので自分用の
COMコンポーネントとしてもHTABOXをレジストリ登録して使っています。
ただし、そういう低層の機能ではなくスクリプトでのアルゴリズム記述が重 要となるモジュールを使いまわしたい場合は有効な手段だろうと思います。 HTABOX内部でもスクリプトで書いたモジュールをCOMの一部として利用して いますので、スクリプトをドロップするとDLLができるHTABOXのDLL版も要望 があれば実現できます。
675の続きです。 どうせ実行時コンパイルとするなら、実アセンブリを生成しない選択肢が用 意されているわけですから、使わない手はないだろうという展開です。 実行時コンパイルと聞くとタイムラグがあるんじゃないかと心配する方もい らっしゃるでしょうが、JScript以外は実行時コンパイルであることに気づか ないレベルだと感じています。これは実際に大規模なプログラムを動かさな いと確定しないのですが、ソースから中間ファイルへの変換作業は極めて小 規模なのではないかと推察しています。
今日は.NETのバージョンで悩んだんですが、一応結論が出ました。初期の1.0 は無かったことにしてこの世にはv1.1.4322とv2.0.50727しか存在しないとい うのが結論のようです。v3.0 v3.5 v4というのはプログラム側から見た場合 架空のバージョン番号でv2.0.50727へ拡張がほどこされたものにすぎないと 考えることができます。ちなみにWindows7でデフォルトバージョンを取得し てもv2.0.50727という報告になります。
ですから現状の材料ではソースをドロップ後、v1.1.4322とv2.0.50727のどち らでコンパイルしたいのかを選ぶということになります。その後に希望の環 境が取得できなかった場合、デフォルトを受け入れるのか、メッセージを表 示して停止するのかを選択する流れになると思います。
実際にv1.1.4322とv2.0.50727の差異を吸収したネイティブコードを書く作業 を行っていますが、JScriptのコンパイル動作が両環境で微妙に違います。 逃げ道としてはCSharpでコンパイルアセンブリを生成しJScriptソースを処理 させることなのですが、それでは美しくないのでさまざまな可能性を試しなが ら妥協点を探っています。1000の実験ソースを書いて、10動き、それを分析し て1にしてゆく。ろくにドキュメントの無い分野で何かをやろうとすれば避け ては通れない関門です。
今日は低水準Microsoft_VsaでのJScript操作を見直したコードを書いていた のですが通常のJScriptCodeProviderより確実に軽量です。CodeProviderでは 他の言語と同じ取り扱いができますがJScriptだけコンパイルが遅いんです。 これは内部でMicrosoft_Vsaを使い外見上CodeProviderに見せているからでは ないかと推測できます。Microsoft_Vsaなら実に軽量で痕跡も残さないという 結果です。
昨日までJScriptはお荷物な存在に感じていたのですが、ネイティブからCLR 側を操作する手段としては最適に思えます。JScriptはまったくタイプライブ ラリを必要とせずObject.Method()というコードをGetIDsOfNamesとInvokeに 置き換えてくれますからCLR側からネイティブ側を覗く窓としても最適です。
いろいろとお疲れさんです。無理せず健康に注意してください、といってる自分は夜二時にカキコしてるとw すいません。
>>684 不安で朝方まで書いているのもですから、結局昼近くまで寝てしまうという
パターンになってしまっています。今日の課題はいかにコンパイル後のアセ
ンブリにオリジナルディスパッチを滑り込ませるかです。できればデモのよ
うにIEを非表示で起動して...は美しくないので行いたくないのです。
今日は貴方の暖かい励ましで私の心が温まりました。ありがとうございます。
今日の課題をクリアできました。これでマネージコード内のJScriptスコープ にまったくストレスなくパース当初から独自ディスパッチを認識させることが できます。CSharp、VisualBasicについてはHTABOX.EXEにIDispatch*のExport 関数を用意しますからご自由にどうぞという展開が一番スマートだと思います。
これで各言語からWIN32.CreateHtaWindow等が使えますからHTMLでGUIを形成 し、処理を各言語で記述できます。したがって今後HTABOX自体へ積極的に WIN32API機能を追加する必要は無くなると考えます。JScript以外はPInvoke できるわけですし、JScript主体だとしても他言語でPInvokeを記述したアセ ンブリをコールすればいいからです。
エンジン部が完成し、v1.1.4322とv2.0.50727での実働試験も良好です。 あとはHTABOXにコピペしデモ用のEXEをコンパイルするだけです。 .NETの世界はそのままドキュメントを受け取ると分けわかんない用語の世界 に突入し、特にCOM連携になると煙に巻かれそうになります。
でもネイティブC++から改めて動作機序を眺めてみるとActiveScriptSiteの 拡張のようにも見えます。なぜならネイティブ空間でCSharpをコンパイル する時にJScript機能への参照が必要になるからです。これは一見不思議な 振る舞いに思えましたが、内部でJScriptをマザー言語、またはユーティリ ティー言語として使用していると考えれば納得できます。
ネイティブ状態から起動するとは言え、CLR取得後は楽をしたいのでスクリプ トコードを実行させる訳ですが、現状だとHTABOX.EXEの静的文字列領域にコ ードがそのまま格納されてしまうので一工夫しています。今までVC++エディ タのマクロは書いたことがなかったのですが、マクロ用VBも.NETオブジェク トを操作できることにちょっと感動しました。
今更なんですが、MS社のやりたいことってこういうことなのかと納得してい ます。あらゆる言語が同一の仮想マシンに向かって協調しながら動けばいわ ゆるクリティカルな状況も発生しないだろうという発想ですね。更にソース コードレベルでチェックを行えるようにあえてネイティブコードを生成する 手段を提供しない。結果として総ては手のひらの上で踊るはずだと。
結局最後の静的文字列暗号復号ルーチンに一番時間がかかってしまいました。 これでダンスを踊る準備が整いました。ただし私のダンスはちょっとばかり 独創的なわけですが。
ソースコード中の静的文字列置き換えで久しぶりにBASE64モジュールを見直 しました。ソースコードの理想形は短いことではなく、10年目を離していて も内容を即座に理解できる事につきると思います。つまり速度を犠牲にしな い程度に説明的なソースを書くことです。ソースコードは自分への手紙です。
//BASE64ENCODE need <comdef.h> _bstr_t Encode64(char *data, int len = -1) { if(len == -1) len = lstrlen(data); _bstr_t re = ""; char ascii[] = { 'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P', 'Q','R','S','T','U','V','W','X','Y','Z','a','b','c','d','e','f', 'g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v', 'w','x','y','z','0','1','2','3','4','5','6','7','8','9','+','/' };
char samp[] = {0,0,0,0}; char ch[] = {0,0}; for(int c = 0; c < len; c++) { samp[lstrlen(samp)] = data[c]; //3文字蓄積されたかループ最終の場合 if(lstrlen(samp) == 3 || c == len - 1) { //終端で処理すべきサンプルが無ければ離脱 if(lstrlen(samp) == 0) break; //3バイトで24ビットのデータを作成 int base = ((samp[0] & 0xff) << 16) + ((samp[1] & 0xff) << 8) + (samp[2] & 0xff); //---------------------------24bit //842184 218421 842184 218421 //fc0000 03f000 000fc0 00003f ch[0] = ascii[(base & 0xfc0000) >> 18]; re += ch; ch[0] = ascii[(base & 0x03f000) >> 12]; re += ch; ch[0] = ascii[(base & 0x000fc0) >> 6]; if(samp[1] != 0x00) re += ch; else re += "="; ch[0] = ascii[(base & 0x00003f)]; if(samp[2] != 0x00) re += ch; else re += "="; ZeroMemory(samp, 3); } } return(re); }
結局今回のチャレンジは自動的にCLRバージョンを要求しない状態が重要です から、あくまでもネイティブなEXEに見せかけて動的CLR取得後のマネージ環 境プログラミングになります。この場合、マネージ環境での定石が通用しな い局面に多々遭遇します。CLRの外界に公開されているインターフェース以外 は、試しにInvokeしてだめだったらあきらめるしかないのが現状です。
そこでJScriptエンジンを仲介役に利用するという発想は間違っていなかった ようです。結果的に実行ソースコードがJScriptな場合はソースに起因するア センブリをテンポラリとしても生成せず実行することができました。これを 他の言語にも拡張できれば完全なソースコード隠蔽が実現できると考えてい ます。
なにがなんだかわからんが、とにかく凄いことが起きてるようだ。 でも年末年始は休業したほうがいい。
HTABOXに3つの関数を追加したいと思います。 CorBindToRuntimeEx -> 引数に指定したCLRの取得を試みます。 RunDotNetCode -> ソースコードをコンパイル実行します。 ReleaseRuntime -> 取得したCLRを開放します。 できれば日付が変わる前にデモをお見せできればと考えています。
HTABOX2.50デモを公開します。
ttp://kuroda.bglb.jp/htabox/dnet.zip HTABOXコア2.50ベータEXEと.NET機能を呼び出すCompiler.js
各言語で記述された3つのファイルで構成されています。
HTABOXコア2.50をレジストリ登録後、Compiler.jsへ各ファイルをドロップ
すると.NETがあれば取得し、メモリ上コンパイルで実行します。
2.50デモでの遊び方を説明します。その前にWIN32名前空間には数的な限界が あるらしく、以降サブの名前空間名を明示することとします。サブの名前は DotNetです。 WIN32.DotNet.GetRunTime("v1.1", "wks", 0); これはCorBindToRuntimeExの先頭3つの引数と同一ですが、最初の引数省略は NULLではなく文字列の""です。""の場合デフォルトを取得します。バージョン 指定文字列"vn.n"があった場合レジストリを調査し指定文字列が含まれる実在 バージョンを取得します。この関数はCLRを取得できた場合バージョン文字列 を、取得できなかった場合空文字列を返します。
WIN32.DotNet.RunDotNetCode(Sour, RegExp.$1.toUpperCase(), Ref, ""); は第1引数ソースコード文字列、第2引数"JS","CS","VB"のいずれか 第3引数参照システムDLL名(名前終端は\n必須)、第4引数はコンパイラオ プション文字列です。
動作させてみれば、たったこれだけの事なんですが、.NETが未インストールの PCでも醜いエラーダイアログを出さず、通常テンポラリーが生成される c:\docume~1\hoge\locals~1\temp\を実行中に眺めても該当するファイルが無 いことを確認していただけると思います。
構想としてはHTABOX2.50エンコーダーは従来のアンマネージJS,VBSに加えて マネージJS,CS,VBを起動スクリプトとして選択できるようにしたいと考えて います。まだ勉強不足でよくわからないのですが、.NETプロジェクトをその ままドロップできるようなDNETBOX(仮称)に発展させることができればと 考えています。
今思ったのですが、コアはプロフェッショナル向けにアンマネージ起動を原 則として、マネージソースコードを暗号化保持するオプションを設けてデモ のように呼び出してもらうというのが美しいかもしれません。でDNETBOXは 単純にドロップすると実行したいCLRバージョンや参照DLLをGUIで指定する 形式(Quickのように)にすればキャラが被って混乱を招くこともない気が します。
まじめに.NETって何?を考え始めたのがファイルの日付を見ると今月の11日 でしたからC++書いてたのは正味2週間程度です。この新たな世界で自分なり のカラーを出すにはどんな技術が必要か?というイメージは実現できた気が するのですが、はたしてこんな短期間の分析で人の役に立つものができたの かすこし不安です。
今日の課題は複数言語のソースを同時にコンパイルしていずれかの実行イン スタンスから他方をモジュールとして呼び出すことです。これが実現すれば JScriptからCSharpモジュールを呼べますから私がコツコツWIN32APIへのブリ ッジを書く必要がなくなるわけです。
あと、話題は変わりますが私の野望は意外と簡単に実現できるかも知れませ ん。.NETという約束事は従来のタイプライブラリやCLSIDをシステム全体から 切り離した一種のプライベートな空間で実現するものに見えますからローダ ーとアセンブリデータさえ自前のEXEに内封すれば独自の.NET環境を実行でき そうに思います。
なかなか今日の課題は問題山積でした。ポイントはJScriptだけ直接WIN32を 呼べない事にあるので、JScriptから他の言語のメモリ上モジュールをディス パッチとして呼ぶことは成功しているのですが、これをJScriptスコープから のきれいな関数呼び出しにできるかというと難しいかも知れません。もうす こしだけ粘ってみますが、「WIN32コール主体ならJScript以外で書くこと」 という仕様を受け入れた方がわかりやすいかも知れません。
どうしても別体アセンブリをライブラリ(DLL)で参照する場合実在ファイル であることが動作の基本になっているように思えます。だいいち他人の書い たDLLで無い限りソースは存在するはずですし、ソースが存在すれば単一な ファイルにすることはできるはずです。逆に他人の書いたDLLの場合はソース を保護してあげる必要も無いわけですから実ファイルで添付できるはずです。
今回の変更でJScriptが最も立ち上がりの早い言語となります。 また、予想されたことですが、マネージ環境は使用したWIN32オブジェクトへ 正確な数のReleaseを発行しないためWIN32.Quit()を使わないとEXEインスタン スが残留します。具体的にはHello.jsのコードをご覧ください。
JScript.NET空間へ並列に存在するCSharpのアセンブリディスパッチを認識さ せるのは面倒でもネイティブなJScript空間になら簡単に認識させられること に気づきました。つまりネイティブなJScript、VBScriptからCSharp等のコー ドをメモリ上でコンパイルした結果をディスパッチとしてコールできます。 いつもの事ながら奥まったことばかりに目が行き、単純なことを見落として しまいます。
//WIN32API Beep Call var MyLib = " using System;\n" + " using System.Runtime.InteropServices;\n" + " namespace MyLib\n" + " {\n" + " public class CallBeep\n" + " {\n" + " [DllImport(\"kernel32.dll\")]\n" + " private extern static bool Beep(uint dwFreq, uint dwDuration);\n" + " public void Main()\n" + " {\n" + " Beep(262, 500); // ド\n" + " Beep(294, 500); // レ\n" + " Beep(330, 500); // ミ\n" + " Beep(349, 500); // ファ\n" + " Beep(392, 500); // ソ\n" + " Beep(440, 500); // ラ\n" + " Beep(494, 500); // シ\n" + " Beep(523, 500); // ド\n" + " }\n" + " }\n" + " }"; var Assembly = WIN32.DotNet.CompileDotNetCode(MyLib, "CS", Ref, "", false); var Dipspatch = WIN32.DotNet.CreateDispatch(Assembly, "MyLib.CallBeep"); Dipspatch.Main();
まもなくデモのファイルを更新しますが、上記コードはデモの一部です。 通常のJScriptからCSharpコードでWIN32APIをコールするDLLをメモリに生成 し、音階を鳴らすコードです。したがってHTML中のスクリプトからもまった く同じ事ができることになります。勿論.NET必須ですが。
わたしのやりたかった事はまさしくこれですね。どうもC++コードばかり書い ていると細かな事に心とらわれて大局を見失います。COMの登録なしにHTMLコ ード中から.NETアセンブリコードを動的にコンパイルしてWIN32APIを呼び出 す。実に自然な流れで美しい!!これぞ私の世界!!
ついでですからCreateDispatchFrom(Path, TypeName)も装備し実在ファイル アセンブリからもDispatchを取得できるようにしましょう。これで事実上 「HTMLアプリケーションから不可能な呼び出しは何も無い」 という状態が実現できたと思います。
HTABOX2.50デモを更新しました。
ttp://kuroda.bglb.jp/htabox/dnet.zip Beep.htaはHTML中のスクリプトから動的にDLLを生成しWIN32APIを呼び出す
デモです。デモではWIN32オブジェクトをActiveXしていますが、HTABOXへ
格納された配布状態の場合自動的に追加されます。したがって配布先環境
ではまったくCOMを登録することなしに同じ動作を実現できます。
WIN32.DotNet.RunDotNetCodeは引数を追加し WIN32.DotNet.CompileCode(str, type, ref, option, flg); になりました。最終引数はEXE形式の場合true,DLL形式の場合falseです。 返却値はEXE形式の場合return結果VT_I4、DLL形式の場合VT_DISPATCHで このディスパッチはAssemblyを表現しています。DLLのメソッドを呼ぶには var Disp = WIN32.DotNet.CreateDispatch(Assembly, "MyLib.CallBeep"); のようにアセンブリからクラスを指定してコンストラクトする必要があります。 CreateDispatchの返却値は実際に呼べるディスパッチですので関数名を指定し Dips.Main(); で実行できます。また実在アセンブリ用に WIN32.DotNet.CreateDispatchFrom(Path, TypeName); も追加しました。
>>698 正直言って休みたいのですが、休んだ心地になれるほど私の周りの状況は
平穏では無いのです。今回のチャレンジは私がソースコードを書く人間と
して存在できるか否かが問われているという認識で取り組みました。
まだこれを世に出さないとなんとも言えませんが、私はまだ書き足らない
し、この続きを心に余裕を持って書く日がくることを信じています。
皆さんにとって2011年がよい年でありますようにお祈り申し上げます。
今日はHTABOXコアのソース細部を見直し、デモにJScript.NET起動によるHTML アプリケーションを追加できればと考えています。JScriptの場合アンマネー ジでもマネージでも拡張子はJSなものですから、ソース内の特徴でいずれなの かを判断しなければなりません。今のところ安直にimportが宣言されているか で判断しようと考えています。
で、.NET用Quickという位置づけで「HTABOX DotNet」という名称にしようか と考えています。一応推奨起動スクリプトはJScript.NETにしてHTMLインスタ ンス生成手法をデモにすればHTABOXファミリーと位置づけてもいいのではと。 それとJScript.NETスコープのWIN32からWIN32.DotNet.CompileCode();等を 使えば、CSharpCodeProviderがらみを書かずにWIN32APIが使えると思うので これはこれで完結した世界になると思います。 勿論HTABOXコアはクイックやドットネットの上位に位置しますので両者が内 部で行う処理を細かくソースコードで管理できることになります。
HTAの延長線越えた気がする。 なにやってるのか全然理解できない(プログラミングがわからないので) これはまだスクリプティングの領域なんでしょうか?
>>723 スクリプトという表現はとても曖昧なものですよね。マシン語を直接生成し
ない開発環境は内部でCOM呼び出しを行います。だとすれば実行インスタンス
へオリジナルのCOMを注入さえできれば何でもありにできます。
通常はCOMというとレジストリに登録してあるDLLが呼び出されるわけですが、
HTABOXの場合内部に持つスクリプトエンジンやCLRエンジンに対してそれを
行いますので結果的に登録無しで何でもありにできるということです。
話題はそれますけど自分が金を出して買ったマシンをカスタマイズする権利や 自由な動作を行わせる権利は当然有しているわけです。だけど開発の煩雑さや 開発環境を提供する側の思惑でその権利が抑制されていると感じるのです。
あぁそうですかと納得してそれに従うのもいいでしょうが、ちょっとまじめに COMのレベルで眺めてみると、手を加える余地がいろいろと見えてきます。 COMプログラミングというと「難解」という誤解があるようですが、スクリプ トや.NETで使われているディスパッチは「そういう名前のメソッドあります?」 「このIDでInvokeしてくださいね」「了解」の単純な繰り返しですから.NET のドキュメントを呼んで迷子になるよりずっと単純だと感じています。
HTABOX2.00の時点で全面的にC++ソースを書き換えたのですが、C++ソース内 の関数群そのものがIDispatch継承クラスのメソッドとして存在する構造と しています。つまり、内部で使うクラスも原則的にCOM呼び出しを行うように しました。 一見面倒に思えるでしょうが、これによりC++はJavaかスクリプトのように可 読性が向上します。今回はDotNetというクラスを作って関数を4つ宣言したわ けですが、必要なければこの部分だけ削除すればそのままコンパイルが通り ます。普通、プログラムは機能が多くなると自重で潰れかかるものですが、 HTABOXに関してその心配がまったく無いため、気軽に機能を追加できていま す。
723さんへの回答になっていない気がするので今回追加された機能の流れを 再確認したいと思います。 1. .NETが有るか無いかを確認し任意なバージョンの.NET環境を取得する。 2. 取得した.NET環境で実ファイルを生成しないコンパイル動作を行う。 3. 2がEXE形式ソースであれば.NETのソース隠蔽実行となる。 4. 2がDLL形式ソースであればHTML中からコールできる状態とする。 結果としてHTML中スクリプト、WSHスクリプトからCSharpコードを動的にコン パイルして任意なWIN32API呼び出しが実現できる。という流れです。
私のような貧乏人は劣化した部品を入れ替えながらWindows2000やXPを使い 続けるでしょうが、一般のユーザーは半数以上がVista以降になっているん じゃないでしょうか。だとすればもうWIN32APIは.NET経由で呼んでもらおう という趣旨です。私はDirectXとか単にWIN32APIを呼ぶだけでは実現できない 機能の追加に集中できることになります。
最後にひと粘りしてみたのですが、JScript以外の言語アセンブリへメモリ 上のIDispatchインスタンスへの参照を滑り込ませるのは今の力量では無理 なようです。これで.NETソースコード格納による動作の方向性がはっきり しました。原則としてCSharp、JScript、VisualBasicのソースを格納した 場合、なんら操作を加えずにコンパイルして実行します。GUIは.NETの機能 で構築してもらいます。この場合のメリットはソース隠蔽、CLRバージョン の柔軟性ということになります。
ただし、DotNet.RunJScript()を新設しこれがコールされた場合のみHTABOXは オリジナルディスパッチであるWIN32を実行インスタンスへ追加するものとし ます。したがって.NET環境ソースコードを起点としてHTMLアプリケーション を構築したい場合の言語はJScript.NETのみとなります。勿論これは起点と なるスクリプトですからJScript.NETから既存アセンブリを呼ぼうが、動的に CSharpやVisualBasicのコードをコンパイルしようが自由ですからなんら制約 にはならないと考えます。
また、2.50のコマンドライン対応ですが、おそらくドロップ実行では実行 スクリプトへの引数を認識できないという意味だと思いますので、案として htabox.exe /Run hoge.js Argument1 Argument2 Argument3 hoge.jsを実行、以降をスペース区切りで引数と認識でよろしいでしょうか?
むしろ単一exe化していない場合にドロップで想定外のファイルを実行されたくないというか
>>733 なるほど。私としてはその方が記述は簡単です。確かにHTABOXをレジストリ
登録してデバッグできるようになったわけですから、ドロップしての実行は
旧バージョンの遺産という気もします。もうすこし考えてみます。
HTABOX2.50デモを更新しました。
ttp://kuroda.bglb.jp/htabox/dnet.zip Hello.jsは単なる.NETコードになり、Hello2.jsが.NET環境でWIN32を使う例
になっています。WIN32.DotNet.RunJScriptCode(Sour, "");を追加しました。
第2引数は参照DLL名を\nで連結し終端にも\nを追加した文字列です。
しばらく自分でもいじってみますが、問題なければ2.50の仕様にしたいと考
えています。
Hello2.jsを書いていて思ったのですが、本来コンパイルして実ファイルが 生成されるはずのコードを中空でコンパイルしていますので、自身のパス 取得に苦労する可能性があります。外側を覆っているHTABOX側で環境変数 をコントロールできればいいのですが、できなかった場合はMainの第一引数 を親であるHTABOX.EXEのパスにするといった対策を考えています。
.NETソースコードの実行時コンパイルでは、ソースを文字列として評価して いる局面が存在しますから、独自のプリプロセッサーフェーズを設けてC/C++ 互換のプリプロセッサマクロを提供することができます。例えば__FILE__は ソースファイルのパス文字列に置き換わる等です。少なくとも__HTABOX__は 自身が格納されているHTABOXの絶対パスに置き換わるというルールを設けれ ばHTABOX.EXEの公開関数を単純に[DllImport(__HTABOX__)]で利用できそうに 感じます。実験はこれからですが。
上記実験は公開関数が単純な内容なら成功しますが、そうではない場合は成功 しないようです。マネージ側でスレッドモデルを指定すればCoInitializeExが 適切に呼ばれるというドキュメントなんですが、どうも実行時のメモリモデル そのものが違う感じのとまり方になります。もしHTABOX.EXEがDLLだったらマ ネージ側の環境に合わせた設計とすることもできますが、DLLに成り下がる気 は今のところありませんので、今後の宿題にしたいと思います。
どうしても.NETの場合はアセンブリがキャッシュされる初回の起動に時間が かかります。これを突き詰めると事前にDLLをバイナリデータとして保持する ことになりますし、さらに突き詰めるとEXE内にバイナリデータを事前に保持 することになります。つまり.NETがインストールされていなくてもHTABOXが .NETのDLLを総て保持している状態を作ることも可能だと考えています。
ただ、今回はそこまで突き詰める予定は無いので、そのための技術を確立す る意味で、動的コンパイルによって生成されたアセンブリをメモリ上に永続 化して動作の高速化を目指しています。現時点では僅かな時間の差にしかな らないでしょうが、この技術は.NETバージョンを選ばない生のアセンブリを 生成、保持できる可能性を生みます。つまりコンパイルは格納時に行われて いるのに、実行時に任意のCRLバージョンで動作するできることになります。
コンパイル済みソース(アセンブリ)のバイトデータを任意な領域、又は ファイルへ退避させ、必要なときにアセンブリ化して実行するということは ネイティブな環境でも問題なくできるようです。今後.NET用ライブラリを HTABOX内に保持する場合は呼ばれる度にコンパイルではなく用意してある バイナリをそのまま提供という形にできると思います。
まだ勉強不足で確定的なことは言えないのですが、ソースではなくアセンブ リバイナリをスクランブルした形でEXE内に保持し、実行時にメモリ上インス タンスを生成すればアセンブリがコンパイルされた環境とは別バージョンの CLR上でも問題なく動作させられると考えます。アセンブリの直接格納はさす がにHTMLアプリケーションとは無関係な存在となりますのでDNETBOXみたいな 名称の別アプリケーションとして公表されるかも知れません。
私なりに知りたいと考えた情報はほぼ取得できましたので、具体的製品への フィードバック作業に入ります。まずHTABOXコア2.50は.NETに関する低水準 関数を総て装備します。今後HTABOXコア2.50はプロフェッショナル向けの製 品と位置づけてゆきたいと思いますので、ドキュメントも有る程度知識のあ る方を対象にしたものになると思います。
HTABOXコア2.50によってHTABOXクイックは1.50となります。クイック1.50は デモのHTAのように.NETコードを動的にコンパイルし.NETクラス又はWIN32API を呼び出す事ができるようになります。従来からそうですが、クイックは潜 在的にHTABOXコアの機能をすべて持っています。でもその総てを解説するこ とは逆に初心者の混乱を招くため機能の紹介は限定的なものになります。
HTABOXドットネットはVisualBasicEngine及びJScriptEngineへのオリジナル ディスパッチ注入を利用した新たなHTMLアプリケーション手法として育てて ゆきたいと思います。今までの実験では.NETアプリケーション固有のクラス で構築するGUIは残念ながらJava以下のレスポンスに思えます。軽量なHTML のGUIと.NETの低水準関数操作による新たなカテゴリーになると思います。
最後に単純に.NETソースを隠蔽実行するBOXを製品化したいと思います。 格納形式は 1. ソースを格納し実行時コンパイル 2. アセンブリを暗号化格納し実ファイルを生成せず実行 3. 実ファイルを生成して実行 が選択できる状態になろうかと思います。
nilscriptとhtaboxコアは、凄いことが出来そうwってのはわかるんだけど、難しくて付いていけないw とっかかりの入門サイトがないと厳しい。
>>749 おっしゃるとおりだと思います。まだ先を掘削する作業になってますので、
十分な導入のための解説に手が回っていません。やれることの見極めがつき
ましたら、導入のためのコンテンツ作成を行いたいと考えております。
Microsoft.VisualBasic.Vsa.VsaEngineの解析を終わりました。VisualBasic とJScriptのエンジンを統一して扱おうとすると差異を吸収するクラスが必要 になりましたが、JScript単体で行っていた手法より堅牢な手法で実行インス タンスへディスパッチを注入することができています。デモのhello2.jsを VisualBasicで記述できることになりました。ということは内部でCSharpを 使うことなくWIN32APIが使えるはずですが、まだ実験してないので結果は後 ほど。
最初はHTMLインスタンスとの連携ポイントを探るのに苦労しましたが現時点 で最強な手法がレイトバインディングモードVisualBasicを用いた上記デモ になります。.NET全般に言えることですが、初回起動時の参照DLLマッピング に時間こそかかりますが、動作中の振る舞いは美しいと思います。HTML中の スクリプトやWSHスクリプトは単純に全リソースを奪って動作しようとします ので、すこし負荷のかかるプログラムになるとPCはハング同然の状態となり ますが、.NETはマルチスレッドを前提に動作していると考えられます。
これでお見せしたいデモも出揃ったと感じています。レイトバインディング ができないCSharpにHTMLインスタンスを公開しても今のところ使いにくいだ けですので対象としていません。ただIHTMLDocument系のタイプライブラリは 必ずWindows系PCには存在しますので将来はアーリーバインディングでHTMLを 扱えるようにできる可能性はあります。
.NETの学習を始めて1ヶ月になりました。奥まった機能を使うプログラミング では当該分野でのサンプルコードを探すことから始まりますが、CLRをネイテ ィブから取得し、実際にその後仕事をするというサンプルは皆無です。これは .NETがやや閉鎖的なために.NETを活用する側とそうでない側との間に溝ができ ているからだと考えます。.NET側の人間はネイティブなら単純に解決できる問 題のために長大なコードを書く羽目になり、C++プログラマーはそれを横目で 眺めながらも手を貸そうとしないように見えます。
結局プログラムとは紙と鉛筆で行う演算を高速に処理してくれる工夫だと思 います。ならば、プログラムを作成することにかかる時間が短ければ短いほ ど優れた問題解決手法となります。そのために使えるものは骨の髄まで使う べきです。従来は生産効率とソースの隠蔽度は相反する要素でしたが、HTA BOXはその概念を打ち破るために生み出されました。
JScript、VBScript、HTML、CSS、ASP、JScript.NET、VB.NET、CSharp、C++ HTABOX.EXEそのものは単純なモジュールの集積なのですが、ミドルウェアと して数多くの言語と向き合わなければならないためHTABOX.EXEの作成には広 範な知識が要求されます。まぁ仕事として選んだわけですから自業自得なの ですが、私の勉強方法を紹介します。
これだけの範囲になると何かを集中的に扱っているときは他の情報が飛んで ゆきます。これはしかたのない事です。ですから何がどこに書いてあるのか というメタ情報を記憶します。具体的にはMSDN(ローカルPC)を暇があれば眺 めます。これは内容を読む必要は無く最低でもページタイトルを眺めるので す。例えば.NETの開発言語ドキュメントだけで膨大な量になりますが、とに かく全ページを開いて、各セクションのボリュームを確認するだけでも意味 があります。
もうひとつデモに追加すべきものがある事に気づきました。これを実現して いるプログラマーがいるかどうかわかりませんが、JScript中に自然な形で CSharpコードを混在させることができます。hello2.jsでは文字列としてCS コードが存在しますが、通常のコードとして記述し、JSから呼び出す事が可 能なことに気づきました。これでJScriptからも自然にWIN32APIを呼べます。
私は上記JScript拡張言語にJScriptExという名前を付けようと思います。 HTMLインスタンス等のネイティブCOMとの連携が自然で、.NET機能も使え 直接CSharpコードを記述することでWIN32APIを呼べる最強の環境です。 今回の研究で苦労した割には結局必要なかったテクニックがあったのですが 最後のどんでん返しでそのテクニックが最も価値あるものになったようです。 実験コードが動くのを見ながら生きていてよかったとつぶやきました。
上記手法はJScript.NETコード中に#includeを導入することで実現したいと思 います。混在した場合奇異な印象を与えるでしょうし、何より編集しにくい と考えるからです。将来は他の言語にも#include機能を与えられる可能性は ありますが、現時点ではJScript.NET固有の特性を利用して実現されています のでJScript.NETだけをえこひいきしているわけではありません。
#includeに対応したエンジンを設計していますが、通常のスクリプトエンジン と比べ生成ディスパッチをバイナリデータとして永続化できますから非常に 面白いものになります。開発中はソースコードからコンパイルしてユーティ リティーオブジェクトを生成させますが、リリース時には当該オブジェクト を永続化させてEXE内に暗号化して埋め込み、エンジンを起動することなく 機能だけを高速に利用できます。夢じゃないかと頬をつねりたくなります。
#include対応エンジンは完成しましたが、HTABOXへの実装は明日にしたいと 思います。今回の作業を振り返ってみると、マネージC++主体で記述すれば 半分くらいの労力で済んだかも知れません。それほど.NETが必ず存在するこ とが期待できればプログラミングは楽になるでしょう。ただし、開始地点が マネージコードであるということはそれだけで攻撃者に情報を与えてしまう 可能性が出ますからアンマネージにこだわった設計を貫きました。
これはあくまでも推測なのですが、ピュアにWIN32APIだけを使ったネイティ ブコードEXEは逆コンパイルすると以外に読みやすいものになってしまうので はないかと考えます。そこにCOMを導入すればオブジェクトは動的なものに なりますので追跡しにくくなるはずです。その考えの延長としてCLRヘッダを 持たないネイティブEXEからマネージコードを扱った場合さらに追跡しにくい 状態が生まれるのではないかと推測しています。
.NETアセンブリを格納するBOX用にEXEアセンブリが実行中に実DLLファイルを 探し、発見でなかったイベントをキャッチしてメモリデータ中のDLLアセンブ リを渡すことに成功しました。これもマネージコード中ならMSDNに書いてある とおりなのですが、ネイティブからやろうとするとかなりの難問になります。
上記テクニックが確立したことによって.NETアセンブリ格納BOXは実行EXEと 周辺DLLアセンブリを無造作に格納する仕様にできます。つまりHTABOX DotNet はソースコード状態の格納で実行時にJScriptの#includeのような何らかの追加 機能を提供するものであり、DNETBOXは生成アセンブリを暗号格納しファイルを 生成せずに実行するものであるという明確な性格付けができました。
DNETBOXはアセンブリ格納後の実行でHTABOX内の暗号化されたリソースデータ のバイトストリームからアセンブリインスタンスを生成します。これは周辺 DLLについても同じです。私の知る限り、ファイルが存在しない実行中アセン ブリのデバッグはネイティブコードと同等の情報しか得られないはずです。 結果として.NET各言語はソースコード隠蔽という観点においてネイティブと なんら変わらないものとなります。むしろ単純な構造のネイティブEXEよりも 内容を類推しにくいものとなります。
今日はあまりコードを書かない日にしたいと思います。今回の研究で.NET環境 でのC++コーディングのあるべき姿が見えてきたのでそれを頭の中で整然とした 形に整理したいと思います。具体的なコードというレベルでは何度も書き直し ができますが、どういうスタイルで書くのかというレベルは取り返しが効かな い決断になるからです。
従来、ソースコードとはアルファベットが読めるように並んでいるテキスト ファイルな訳ですが、.NETの場合アセンブリをソースコードに埋め込んだ方 が開発効率が向上します。勿論バイナリデータをテキストファイル中に記述 すれば破綻しますからBASE64的な手法で文字列化して置く訳です。 この、ソース->アセンブリ->文字列 の変換作業はVisual Studioのマクロに 行わせることができます。マクロ実行環境はVB.NETそのものだからです。
Visual Studioのマクロに選択中のソースコードを認識させて任意な言語とし てコンパイルし、生成アセンブリをエンコードして文字列化しソースコード へフィードバックする手法は正解のようです。いままでのライブラリをこの形 式で動作させたテストも良好です。これでネイティブEXEから.NET機能を利用 する規格が定まりましたので本格的に実装作業に入れます。
マネージ空間にIUnknownを侵入させて生成済みオブジェクトと通信させれば そこでどんなインターフェースが使われているのかを監視することができま す。そういった解析を行うとアンドキュメントなインターフェースが沢山う ごめいている事に気づきます。ただし、各言語におけるclassはアンマネー ジ空間から単なるIDispatchとして利用可能であるということがわかりました。
また、.NETのアセンブリは本物のDLLのようにプロセスメモリ空間にマッピン グされるものではありませんから、実在ファイルの形式をとる必要がありま せん。中空に出現させて利用し消滅させることができます。従来のCOMでも それは可能ですが、当該COMのソースが無い限りファイルを実在させる必要が あるように思います。でも.NETは他人様が書いたDLLバイトデータをリソース として持てばまったく気づかれずにそれを利用できてしまいます。私はソース が暴露しやすい事よりもこの事実の方が深刻な事態だと考えます。
DNETBOXは格納されたアセンブリをファイル出力せず実行可能となります。 したがって、ファイルを逆アセンブルできないばかりではなく、アセンブ ルバイナリを不正な再利用から保護する意味でも威力を発揮するのではない かと考えています。
一日だけという期限を自分で作って、可能な限り低水準な手法でネイティブ 空間からマネージ空間オブジェクトを操作するという検証を行いましたが、 行ったところでコードが煩雑になる割には軽量化が期待できないという結論 でした。有る程度の仕事をマネージに依頼して結果を受け取る。またその逆 を行う。つまり両者の接点が少なければ少ないほど設計としてシンプルにな るようです。
.NET SDKにはアセンブリのtlbをエクスポートするコマンドラインツールが付 属していますが、これは各オブジェクトについてIDispatchもどきのそっけな い情報しか出力しません。.NETの世界ではTypeInfoの代替であるTypeを調べ て実行時に自身で解決しなさいという作りのようです。私の見る限りこの規格 が.NET全体のレスポンスを悪いものにしています。特に同名で引数の違うメソ ッドを問い合わせるという動作がループ中で無造作に使われた場合、致命的な 遅延を招くはずです。
.NETの言語から.NETアセンブリを使う分には上記呪縛から逃れるすべはあり ませんが、そうでない場合は何らかの改善策を提示できるのではないかと感 じています。具体的にはC++ネイティブコードからType経由での問い合わせ無 しにアセンブリ中のバイナリを利用できる仕組みです。もしそれが実現できれ ば.NETに対する評価が根底から変化するのではないかと考えます。
いよいよHTABOX2.50もリリースコンパイルテストの段階になりました。 考え方として単純ですし、インパクトもあるでしょうから単にコンパイル済 アセンブリを隠蔽実行するDNETBOXが本体コアより先行して発表される可能性 が高いです。コアに追加される関数は10に満たないでしょうが、そこにきち んとした解説を加えるとなるとかなりの作業量になるからです。
VB.NET及びJS.NETをソースのままスクリプトとして扱い、HTMLインスタンス を操作可能なHTABOXドットネットは最も最後に発表されることになると思い ます。非.NETなPCが現役な状態ではあまり注目されないかも知れませんが、 次世代のHTMLアプリケーションの姿を提言する存在になると思います。
何を目的に何が可能になるのかを総括しておきたいと思います。従来はスク リプトに低水準な機能を開発者が追加する場合C++でDLLを書く必要がありま した。HTABOXコアは単純にIDispatch*をExportするDLLで十分ですが、それで も敷居の高いものであると感じていたのです。それで.NET系からのWIN32API 呼び出しを活用できれば敷居が下がるはずというのが出発点です。
.NETの世界を眺めてみると、バージョン問題、逆コンパイル問題、を解決す ることはCLRヘッダを持つ従順な.NETプログラムでは不可能という直感から ネイティブEXE内での独自CLRエンジンを開発することとなりました。このエ ンジンの特徴はファイル実体を持たないアセンブリインスタンスを実行可能 にすることで静的なアセンブリファイルを対象とした逆コンパイルツールを 無力化します。
次にHTABOXコアが持つ動的なCOMインスタンスを当該エンジン内部へ滑り込ま せる手法、逆にエンジン内のCLR環境インスタンスをネイティブ空間へ引きず り出す手法を確立しました。これにより.NET用のアセンブリでもHTABOX経由 でHTMLインスタンスを認識できますし、HTML側からの要求もアセンブリへ到 達します。
上記動作を柔軟に行うためにはコンパイル済みアセンブリではなくソースコ ードの実行時コンパイルの方が適しています。.NET系のコンパイルとは中間 言語へのコンパイルでしかありませんのでマシン語を生成するほどの時間は 要しません。.NET系のコンパイルはいわばスクリプトのパースのようなもの です。ならば、WSHのようにスクリプトとして扱うという発想が生まれました。
781を具現化するのがDNETBOXであり、783の具現化がHTABOX DotNetです。 これらの機能はHTABOXコアへ関数を追加することで実現されていますから 自動的にHTABOXコア、HTABOXクイックも.NET機能を持つことになります。
この掲示板に大変感謝しています。私として当初おぼろげに何かをイメージ するわけですが、それをここで自問自答させていただくことで非常に効果的 なウォールトークができています。結局、手探りで未知の分野のプログラム を完成させるためには、どれだけ多角的に物事を捉えられるかが勝負です。 変な表現かも知れませんが、不可能だと結論した自分の愚かしさに気づくこ とでしか可能なプログラムを書くことはできません。日常の中でそういった 気づきを促すことは困難なのですが、ここに書き込んだ自分の言葉を自分で 読み返すことでそれが実現できています。
HTABOX内部で実行されるアセンブリ又はコンパイル結果アセンブリは正しく 自身のプロセスを認識するようです。あとはクイックのソースを参考にアセ ンブリがドロップされた場合のオプション設定GUIを書くだけとなりました。 DNETBOXはアセンブリをそのまま暗号格納し復号して実行します。同時に格納 したDLLも同様に暗号格納され復号して実行インスタンスからの参照へ動的に 対応します。格納できるアセンブリ等のファイルに量的制約はありません。 さらに、実行CLRバージョンを指定し希望するバージョンが得られない場合穏 やかに終了することも可能になります。HTABOXはHTMLアプリケーションに興味 がない方には存在さえ知られていないでしょうが、DNETBOXは全Windowsプログ ラマーにとって無視できない存在となるはずです。
DNETBOX用スクリプトを書いています。このスクリプトをHTABOXコアにリソー ス格納すればDNETBOXができあがります。実際に作業してみると単にQuick用 スクリプトの余計な部分を削除するという作業なのですが、C++ばかり1ヶ月 も眺めてきたので頭がHTML&JScriptに切り替わるまで時間がかかります。 HTMLはそのデザインだけで飯を食ってるプロがいるわけですから奥の深いも のですが、今のところデザインまで気を使う余裕が無いものですからそっけ ないHTMLを書いてしまいます。いつかもっとクールな外観のHTMLを書いてみ たいものです。
HTABOXコア内部では楽をしたい局面でActiveScriptSiteを内部でも利用して います。ActiveScriptSiteはHTMLインスタンスとは違い軽量なインスタンス ですから異なる言語の複数のインスタンスが稼動したとしてもストレスには なりません。ただしActiveScriptSiteにはパース結果をバイナリとして保存 する機能はありませんから、利用初期にソースをパースする必要があります。 .NETが生成するアセンブリとはスクリプトパース結果の永続化と捉えること ができます。もはやソースはコメントとして保存しパース結果であるバイナ リを何らかの形でEXEに保持して高速に機能を利用することができるのです。
この事実は私のプログラミングに革命を起こしそうです。やがて私はCLRの ロード部とメッセージプロシージャだけをC++で書いて他の部分を.NETコード で記述し、永続化したアセンブリ生成結果をEXEから利用することになるだろ うと思います。そうした場合の生産性の高さ、バグの少なさはピュアなC++ コーディングの比ではありません。
Mscorlib.dllとネイティブC++だけで何がどこまで可能かを確認していたので すが、なかなか細かな問題に遭遇して思うような成果を挙げるには至りませ んでした。要は想定される.NETジョブがMscorlib.dllのみを使う軽量なもの である場合、初回起動時のシステムDLLキャッシュにかかる時間を短いものに したいという目的なのですが、今後の宿題にして製品のリリースに集中した いと思います。
かれこれ4年間ひとつの夢を追い続けて、睡眠不足な日々を過ごしてきたので すが、今のところ世間様の評価はさっぱりです。4年の労力はほぼ3000万円に 匹敵しますので、それだけ投資してほとんど回収できていないというざまな わけです。サンデープログラマーの頃はちょっと人が真似できないことを実現 すれば十分食える気でいたのですが、そうではないという事を知るためにこれ だけの時間と、労力が必要だったのかと自分を責めたくなります。
それでも何かしらのものを書いて、誰かに見てもらえることを幸せに感じて います。目が覚めれば「さぁ続きを書こう」という気持ちだけが私を肯定し ます。ふんわりと積もった新雪がすべての物の形をまるく変えて綺麗です。
DNETBOX用スクリプトを書き上げました。ドロップされた複数のアセンブリは EXEファイル内に格納され、EXEアセンブリ実行時にDLLへの参照が発生した場 合HTABOXはその参照を仲介します。この動作はDLL側からEXEへの参照が発生し た場合も同じく機能します。DNETBOXの動作においてHTABOXコアが持つ大半の 機能は必要が無いためこの目的に特化したコンパクトなコアを書く予定です。 そのC++ソースは暗号モジュールやHTML生成モジュールが含まれないものとし、 希望する個人やソフトハウスへお譲りできる状態にしたいと考えます。
正直なことろ.NETでHelloWorld以上のものを書いていなかったものですから すこし実用的なコードを書いて格納するともうちょっと手直しすべき点があ るようです。勿論、得るものがあれば失うものもあるわけで、実ファイルを 隠した状態で乗り越えられない壁がなにかしら存在しても不思議ではありま せん。
実際にちょっとしたフォームを.NETで書いて実験しています。HTMLウインドウ のように動的にウインドウ全体を書き換えるという動作には向いてないでしょ うが、各種コントロールをドラッグしてそれに対するイベント処理関数を書く という「GUI付スクリプト」と捉えればなかなか便利な手法なのかもしれない と思います。とりあえずスタンドアロンなEXEとしてDNETBOXβを今日中に公開 したいと考えます。サーバーに依存しない状態となりますので試用版としての 格納数量制限が付加されることをご了承ください。
DNETBOX(ディーネットボックス)βを公開します
ttp://kuroda.bglb.jp/htabox/dnetbox.zip 全くのスタンドアロンEXEですのでインターネット未接続環境でも動作します。
アセンブリを生成する環境で使用されることから1.1以上の.NETが必要です。
一旦格納されたアセンブリは逆コンパイルできません。アセンブリ以外のファ
イルを格納することはできません。リソースはアセンブリに格納した後に当該
BOXへ格納されるべきとの判断からです。
DNETBOXは現状で80Kです。ソースは紙にすれば10枚程度でしょうか。改めて 眺めるとこれといって私だからできるという部分は無いのですが、総合的な ネイティブCOMとマネージオブジェクトの連携をテーマにしたサンプルはこの 世に皆無ですので思いのほか時間がかかってしまいました。任意なCLRバージ ョンの選択とか、きちんとファイルダイアログを出して対象アセンブリを選択 するとか、製品化までに整備しなければならない課題も多いのですが、とりあ えずお見せできる段階に漕ぎ着けたことをご報告します。
CLRヘッダを持たずに.NET言語を使う手法を確立しましたので、本プログラム の主要な部分はVB.NETで書かれています。VB.NETからネイティブPE形式への リソース格納は.NETインスタンスへネイティブCOMを公開する手法で実現して います。今回のプロジェクトで目には見えないのですがVS2003はC++ソース内 にIDLを記述できることからIDLでインターフェースを記述し継承クラスでデ ィスパッチを形成しています。つまりEXE内にタイプライブラリが存在します。
HTABOXコアの公開関数もタイプライブラリを生成してActiveXObjectした場合 にコードヘルパーで関数名と引数を表示させるための実験として取り組んで みました。従来の動的TypeInfo形成はタイプライブラリを必要としないので 自身で使う分には軽量で素敵なのですが、関数が増えてくるとそれを説明する 手間が必要になりますのでタイプライブラリは便利な道具になると思います。
D-NETBOXのGUIで初めてVB.NETを使ったわけですが、だいたいの事は直感的な 操作でアプリケーションを作れるように工夫されていると感じました。VBだ けというのも寂しいのでヘルプにはお家芸のHTMLウインドウを表示させてみ たのですが、GUIのレスポンスはHTMLの方がクイッキーですね。どうも.NETは ラジオボタン一つの操作でもどんよりした動きなように感じます。特に動的 に必要とされるDLLを読みに行くと思われるタイムラグはCLRのバージョンが あがる度にDLLが大きくなるはずですからより顕著になると予測します。
題材にもよるでしょうが、どっちで書きますか?と問われればHTMLアプリケー ションの方を選択します。スタティックなコントロールが数多く存在しなけれ ばならないような局面で.NET系のフォームエディタは便利ですが、やはりプロ ジェクトが大きくなった時に万が一自動生成コードがクラッシュしたら... を考えるとコントロールやその動作関数をより自由に設計、管理できるHTML の方に安心感を覚えます。
D-NETBOXは現状の仕様の場合逆コンパイルが不可能ということが目玉になり ますから、アマチュアプログラマーにはあまり縁が無い製品になると思いま す。.NETを使いながら自社のノウハウを隠蔽したいソフトハウスがメインの ターゲットです。ですから試用版でないD-NETBOXは希望のアイコンを埋め込 んだオリジナルビルドの形で納入されるというシナリオを考えています。
ただし、将来は格納される.NET各言語へ何らかのオリジナルオブジェクトを 提供することが可能だと思います。例えば現状のFormベースのGUIではなく HTMLベースのアプリケーションウインドウを提供することです。JSとVBにつ いては現状でもHTMLインスタンスを使うデモに成功していますが、C#のアー リーバインディングにも対応した形で提供できれば使いやすいものになるで しょう。そのために今回確立したタイプライブラリ生成、管理のテクニック が重要な意味を持つと考えています。
D-NETBOX関連の製品価格を決定しました。 D-NETBOXオリジナルビルド 50k Microsoft Visual Studioプロジェクト(非C++向け)100k Microsoft Visual Studioプロジェクト(D-NETBOX)500k プロジェクトはやや高額ですが、それぞれ1週間、1ヶ月の賃金に相当する額 としました。その期間で当該テーマに対する具体的なコードか書けるかを考 えれば妥当な金額ではないと考えています。
809のお間抜けな誤植を訂正します。 ×妥当な金額ではないと考えています。 ○妥当な金額ではないかと考えています。
HTABOX系にしても今回のD-NETBOXにしても私の作るプログラムの根底には 「プログラムって誰のもの?」というテーマに向けたものになってます。 簡単に書ける->言語のCOM化->書いたことが見える->プログラマーの使い捨て という流れを断ち切りたいのです。プログラムを書くということはクリエイ ティブな作業です。人格の発露と表現してもいいくらいです。ソースを提示 した契約でないかぎりソースは隠されるべきです。ソースが生み出す便宜や 利益はそれを書くことに汗した人間に還元されるべきです。
D-NETBOXをリリースしました。まだ十分な検証が行われているとは言いがたい 状況ですが、とにかく脱兎のごとく動いて結論を出さなければなりません。 作業対象をHTABOXコア2.50、HTABOXクイック1.50に変更します。.NET系機能 については欲張るときりが無いので基本的な機能に絞った実装になると思い ます。
また、HTABOXコアに関しては製品として全体のクォリティーを向上させ格納 時のGUIもクイックと同等なファイル一覧表示にしたいと考えます。その作業 後にHTABOXコアの格納エンコーダー使用にはアカウントが必要な状態に移行 する予定です。前にもお話しましたが、その際にはこの掲示板に敬意を表し てオフィシャルアカウントが取得できる期間を設けたいと思います。
例によってつたない英訳でD-NETBOXサイトを更新します。日本語ページは 後方へ移動しますので815のページURLも移動します。ただし、プロジェク ト公開は当面、日本語を理解できるお客様に限定しようと考えています。
HTABOXコアをレジストリ登録した場合に公開関数のインテリセンスを有効に したかったのですが、インテリセンスはDLLでなければ機能しないように感じ ます。そういえばMSEでMSWORDやEXCELのインテリセンスが効いている状態を 見たことがありませんから、これは仕様なのかも知れません。
COMDLLの仕様を再確認するためにインテリセンス有効なDLLを作成しました。
ttp://kuroda.bglb.jp/d-net/TypeLibDll.zip 実装メソッドは2つ
HRESULT About();
HRESULT ShowHTMLDialog([in]BSTR url, [in,optional]VARIANT arg, [in,optional]BSTR opt, [out,retval]VARIANT *re);
ShowHTMLDialogはモーダルダイアログを表示しwindow.returnValueを返却します。
WSH主体なんだけど、ちょっとだけGUIが必要という場合なんかに便利かも知れません。
HTABOXコアは単一CPPファイルで生成されることをガイドラインに作成してい ますのでIDLを使用せずTypeInfoを生成しているのですが、VC7以降はソース にIDLが書けますので、積極的に活用しようと思います。IDLの場合[optional] の一言で省略可能引数を表現できるのは大変素敵なことです。
MIDLの仕様からするとBSTRへの[optional]は警告対象のようです。BSTRでも 実害はありませんが、818の引数optはVARIANTにするのが正式なようです。 The [optional] attribute is valid only if the parameter is of type VARIANT or VARIANT *.
ttp://kuroda.bglb.jp/d-net/TypeLibDll.zip を更新しました。もうこの習作に機能を追加する予定はありませんが、モード
レスダイアログも表示可能としました。モードレスは当然ながら待機関数を呼
ばないと即座に終了します。実装関数は4つ
HRESULT About();
HRESULT showModalDialog([in]BSTR url, [in,optional]VARIANT arg, [in,optional]VARIANT opt, [out,retval]VARIANT *re);
HRESULT showModelessDialog([in]BSTR url, [in,optional]VARIANT arg, [in,optional]VARIANT opt, [out,retval]VARIANT *re);
HRESULT WiteForHtmlDocument([in]IDispatch *doc);
このDLLはWSHからだとはじめからHTAで書いた方がいいんじゃない?という 存在ですが、.NET言語から利用すると素敵な存在になるだろうと思います。 JScript.NETとこのDLLで稼働中のサーバーでも安心して動作できる管理ス クリプトを書くことができると思います。
IDLでのタイプライブラリ生成とIDispatchExの関係を検証して一日が終わり ました。こうしてまがりなりにも仕事として腰をすえた検証が行えるので 一日でけりがつきますが、何か本業を持ちながらだと確実に1週間はかかるで しょうね。自分自身そうでしたが、休日だけ考えるというペースで到達でき るレベルというのは限界があります。
EXEだけでなくDLLでのリリースにも対応すべくATLを使用した場合のメリット について検証してみました。結果として私のように低層のコードを書きたい人 種にとって<atlbase.h>をインクルードすることはストレス以外の何ものでも ないという結論です。その名のとおりテンプレートライブラリですのでちょっ とでもシナリオから外れると訳わかんない世界に突入します。
そう言えばMS-DOS時代は日本語文字列をグラフィック表示するためにROMから 16*16のビットパターンを取得し、更に回転して1px描画しなければならなか った事を思い出しました。結局人間は相対的に物事を判断します。車での移 動が当たり前だと思えば歩くことは苦痛になります。逆に地べたをはった経 験があれば同じ事が楽しいことに感じられます。そういう意味で今の子達は かわいそうです。
C++再入門的なコンテンツを書き始めました。確かにC++はあらゆる事を最も 高速に処理できる反面、CPUは書かれたコードを正しいものとして実行する ことからバグの無いコードに到達する前にくじけてしまうことになりかねま せん。私のコンテンツのポリシーはなぜそうなるのかを自分の目で確認でき る土台のコーディングからスタートします。最終的にCOMプログラミングに よって従来のGUIをHTMLで置き換える手法へ誘導します。
目的が達成できるならプログラミング手法は簡潔な方がいいと再三発言して いますが、趣味としてプログラミングを捉えた場合全く逆の事が言えます。 少ないピースのジグソーパズルは確かに簡単ですが、完成の満足感は小さい ですし、他人に見せたいとも思わないでしょう。色の変化が少なくピースが 多いジグソーパズルをわざわざ高いお金を出して買うのはなぜでしょう。 C++によるWIN32APIプログラミングは最も高級なジグソーパズルです。
HTABOXコアを全面的に見直すコードを書いています。COMの寿命管理で若干 対症療法的記述があるものですからタイプライブラリ手法へ変更する機会に すべてをクリアな状態にしたいと思います。この書き換えが成功した場合 HTABOXコアは3.00を呼称する予定です。従来は親子関係にあるCOMオブジェ クトが相互を握る形式だったのですが、やや考えすぎていた感がありますの で、シンプルで軽量な方向に変更されます。
id="menu"でメニュー生成でなくid="HTABOX_menu"などで メニュー生成に変更してくださったらありがたいなぁ…って思ったり。 menuで実害はないんですが、私が書くhtmlやcssではmenuを頻繁に使うので……
>>831 名前は直感的すぎると衝突するんですよね。私もあまりに直感的すぎて邪魔
をする場合もあるんじゃないかと感じていました。対策を考えます。
ご意見ありがとうございました。
内閣の定例記者会見方式でお聞きしたいと思います。 フリーランスの上杉です。え〜、スクリプトを使い始めた素人さんたちが、 HTABOXコアでツールを作ろうとする場合、 デバッグ作業のお勧めの方法論、環境構築術はありますか? お勧めのエディタ、よく使うマクロなどについてどうお考えでしょうか?
HTAの場合FrontPage2002以降でクリップアート使いまくりの外観を形成し、 そのままMSEを起動してスクリプトを編集するというのが最強の環境だと 思います。現状ではFrontPageを入手するのが困難ですが、Wordでも似た ような事は行えるはずです。HTABOXの場合HTMLエンジンはIEと決まってい ますからブラウザ互換を気にした通常のHTML作成環境ではなしに思いっきり IE固有の機能を使うという発想が面白いものを作るポイントとなります。
あと、必ず開発時にはWindows Script V5.6 ドキュメントとHTMLREF.CHM (office付属の英文HTML解説)を即座に参照できるようディスクトップに ショートカットを置きます。やっていることが広範囲なわりに私の頭はそ の場限りの容量しか無いものですから参照すべき情報というのがとても重 要になります。
IE5.5〜9までに対応しなければならない、って考えると最初は気が滅入った。
コーダーやってるといつもIEに悩まされるという印象があるからね。
でも、Firefox、Chrome、Safari、Operaにも対応するという暗黙の前提があるから
気が滅入るだけの話だった。そうだ、IEだけに対応すればいいんじゃん。
他のレンダリングエンジンは考慮しなくていいんだ。
>>835 の通りで、あとはいかにIEの機能を引き出すかが勝負。
今までとは違う発想が求められる。HTABOXコアは、新しいオモチャになりそうだ。
838 :
193 :2011/02/18(金) 22:37:15
まだ勉強を始めることができません・・・ 何しろ、まずは何から覚えたら良いのかさえ判らない状態です。 学生時代に教育用言語とアルゴリズムは習ったので、 何かとっかかりさえあれば始められそうなのですが・・・
839 :
193 :2011/02/18(金) 22:58:50
まずは今、サイトを上から順に読んでいます。 ヒントが見つかったらここに残し、これから始めの一歩を踏み出す人へのヒントにしたいと思います。 (掲示板に残そうとしたのですが、いつの間にか無くなっていたんですね)
>>839 自分の興味がある分野に関連付けるという事がポイントになります。勉強と
いう目的で何かを眺めても楽しく無いですからね。一番手っ取り早いのは、
いつもコンピューターを触っていて「これめんどくさい」という操作を自動
化するというテーマはどうでしょう?きっとそのツールはみんなが喜ぶもの
になると思います。
まもなく2回目のサーバー入れ替えを行いWindows2003にする時点で掲示板も
整備したいと考えます。ここは自由に消せないというガバナーが効いた状態
ですので、もっと気軽に話しあえる場にできればと考えています。
なんとかHTABOX3.00の骨格を動作させることができました。どういう形かは 決定していませんが、HTABOX.EXEと同等の機能を持つHTABOX.DLLを添付でき そうです。HTABOX.DLLはActiveXObjectしたオブジェクトの関数についてイン テリセンスを表示しますので、いちいち関数の解説を見なくても使えるもの になるはずです。今回の作業はDLLを主体にTypeLibでディスパッチ群を構築 し、そのコードをアウトプロセスサーバーのEXEで利用できる妥協点を見出す ことでした。
また、MultiByte、Unicode、32ビット、64ビットの各環境でも共通にコンパ イルできる事をガイドラインにソースを見直しました。あとは具体的なコー ドを移植するだけですので1日か2日で3.00βをお見せできると思います。
835はクリップアートではなくオートシェイプですね。単なる画像では意味が なくて、VML命令で余計なファイル無しに画像を表示してこそIEのメリットが あるわけです。VMLはワード等でお気軽に自動生成できるわけですから積極的 に使うべきだと思います。
>>838 まずは定番の電卓、つぎはキッチンタイマー、そしてつぎは2chの保守ツールですね。わかります。
電卓というとポケコンを思い出すのですが、ポケコンに小さな液晶にサイン カーブとかの表示を行う機能があって関心したものです。IEはVMLで自由に グラフィック書けますから、方程式の解をグラフィック表示で見せてくれる ツールなんかは素敵かも知れません。
HTABOX.DLLには従来のスクリプトコントロール1.0の上位互換という位置づけ を持たせるのも面白いと思います。従来のSC1.0に加えJS.NET、VB.NETをパー スしてモジュールとして保持でき、JS、VBSからコールでき、逆もできる。 別な言い方をすればHTABOXが提供するHTMLウインドウ生成ディスパッチと アンマネージスクリプト、マネージスクリプトの3者がシームレスに呼び出し 合える環境を提示して、使い方は自由という緩い規則にすればもっと沢山の 方がHTABOXを利用してくれるかも知れません。勿論なんらかの収益が出なけ れば開発を維持できませんのでEXE化はサーバーサイドで実行という案です。
>>835 ただでHTMLのレイアウトを作るならポータブルでも動くOpenOfficeのワープロでも出来るよ。
グリッドに沿わせて大雑把にボタンの位置をそろえたり、グループ化とかもできる。単位にピクセルは使えないけど。
素の設定のままだと、文字やボタン等の名前と位置だけがHTMLに出力される。
で、いま改めていじって見たら、ボタンへのイベント用ダイアログに設定した項目も出力された。
ただそのままじゃ使えなさそうな文字列なので、エディタでいじらないと使えそうもないが・・・。
やり方は、OOOのメニューのツール。その中のオプションでエキスポートのところをIEを選んで、OpenOfficeBasicにチェック入れて、HTMLで保存するだけ。
すると、出力されたHTMLに、ボタンへのキーやマウスへのイベントに自分で設定した関数の文字列らしきものまで出力される。
何もないよりは目安にはなると思うんで、あとは自分で直せばいけそう。
最終更新が2005年だけどフリーでこんなのも
……まあ自分はVBScriptしか書けないんですけど
J-Scriptor
ttp://www.pololon.com/koby/software.php?id=J-Scriptor > 概要
> WYSIWYG式エディターとJavaScriptコード補完機能を備えたソースエディターを併用することで、
> 効率的にDynamicHTML文書を作成することができるソフトです。
> WYSIWYG式エディター画面ではマウス動作で選択されたタグの属性を一覧表示で確認することができ、
> 属性値の変更も即座に反映されるため、初心者のHTMLの学習にも最適です。
> JavaScript専用のコード補完機能を備えたソース編集画面では、
> オブジェクトの入力と連動してメンバの候補がポップアップ表示されるため、
> 効率的にコーディングを行うことができます。
> おもな特徴
> WYSIWYG式エディター搭載
> コード補完(Code Completion)機能
> DOM構造ツリー表示機能
> スタイルシート対応
> OfficeXPスタイル
HTMLエディタは最も選択肢の多い分野かも知れません。いろんなエディタを 使えば、いろんなアイディアに触れることもできますし、情報をいただけれ ば参考になさる方もいらっしゃると思います。 今日はHTABOXコア3.00の.NETスクリプトエンジンを再設計しました。引数と して言語を渡された場合JS、VBが切り替わるコンパクトなクラスになりまし た。HTABOXインスタンスも自動的に参照可能としますが、アプリケーション の開始起点はHTABOXコアの場合WSHと決めた方が混乱しないという方向で考 えています。HTABOXコアにおける.NETの位置づけは「WIN32でDLL書くよりは .NETでWSHやHTMLスクリプトの機能を拡張したい」にとどめ、.NETを開始起点 としたHTMLアプリケーションは別ものでないと、私自身が混乱してしまうから です。
現状での仕様は WSHからJS.NET又はVB.NETコードをスクリプトエンジンでパースしてWSHから 利用することができます。また、既存アセンブリファイルをLoadしてWSHから 利用することができます。したがって間接的にHTML、WSHから全.NET機能を 利用することができます。取得する.NETのバージョンは今のところシステム が返すデフォルトバージョンにしたいと考えています。
基本的な検証が終了しました。条件の厳しいアウトプロセスサーバーで実験 を行いましたが、予定通りの機能を実現できそうです。ただしWSHから直接 Unwrapしたオブジェクトを操作しようとするとさすがに怒られます。HTABOX はマネージ空間側に任意なモジュールを動的に作成できますので、結果を返 してくれる関数をパースしてマネージ空間で仕事をさせ、結果を取得すると いうごく当たり前な姿勢で開発すればまったく問題とならないでしょう。
WIN32.JSParse又はWIN32.VBParse関数は3つの文字列引数をとります。 WIN32.JSParse(js, "Root", "System.Windows.Forms.dll"); 第1引数は.NETソースコード、第2引数はルート名前空間名、第3引数は参照DLL で複数存在する場合はカンマ(,)で区切ってください。コンパイルエラーな 場合はエラー箇所をダイアログで表示します。返却値は生成されたアセンブリ です。MSE等のデバッガで返却オブジェクトを見るとAssemblyのプロパティー をすべて持っていることを確認できると思います。
したがってHTMLやWSH中にも関らずAssemblyをマネージ空間であるかのように 扱う事ができます。 var Dispatch = Assembly.CreateInstance("Root.Dialog"); のCreateInstance関数は私が書いたわけではなくSystem.Reflection.Assembly のメソッドです。インスタンス化したクラスのメソッドは通常の関数と同じよ うに呼び出すことができます。 var Files = Dispatch.OpenFile();
デモにstaticな要素の呼び出し例を忘れていましたので今追加しました。 WIN32.JSParseは同じですが、アセンブリに対してTypeを問い合わせます。 var Type = Assembly.GetType_2("Root.Dialog"); このTypeの静的要素を呼び出す関数がInvokeMember_3なのですが、引数が多い のとSAFEARRAYを生成する必要があるのでヘルパー関数を用意しました。 WIN32.TypeInvoke(Type, "test", 256); TypeInvoke関数は第3引数に呼び出しフラグ(BindingFlags)を取り、その後 10個までの引数を処理できます。上記例はBindingFlags_InvokeMethod(256) で引数が全くないtest関数呼び出しの例です。
このデモで提示している手法はマネージオブジェクトを自前の.NETスクリプト でラップしたクラスを生成しそのメソッドを呼び出して間接的に結果を得よう とするものです。この「間接的」なことが重要で、結果的にマーシャリング周 りのことを全く考慮する必要がなくソースを書くことができます。 悪戯好きな方は生のマネージオブジェクトを引きずり出すコードを書いていろ いろ試してください。私の言っていることの意味が理解できるはずです。
831で話題になったメニューのIDはメニュー生成を促すBuildMenu関数に省略 可能な2つの文字列引数を持たせることで対応したいと考えています。 WIN32.BuildMenu("HTABOX_MENU", "HTABOX_POPUP");等とすることで既存の IDとの衝突を防ぐことができるはずです。ただし、自動的にBuildMenuが呼ば れるQuickに関しては引数が省略されたものとみなし従来どおりの処理にした いと考えています。今回からインターフェースをIDLで記述していますので いままで不可能だった柔軟な引数のへの対応が可能となりました。
まだ仕様が固まっていないのですが、システムの静的なメソッド呼び出しの 結果として返されるマネージオブジェクトはWSHからも操作可能です。デモの EXEをレジストリ登録すると下記のスクリプトが動作します。 var InvokeMethod = 0x100; var WIN32 = new ActiveXObject("SAMPLE_EXE.CMother"); var Domain = WIN32.CUtil.CurrentDomain(); var COR = Domain.Load_2("Mscorlib.dll"); var File = COR.GetType_2("System.IO.File"); var Stream = WIN32.TypeInvoke(File, "OpenRead",InvokeMethod, WScript.ScriptFullName); var Byte = Stream.ReadByte(); WScript.Echo(Byte);
上記スクリプトはMscorlib.dllからSystem.IO.FileのTypeを取得しTypeInvoke で自身スクリプトの先頭バイトをバイナリー読み込みしてその値を表示する ものです。この場合は単純な数値ですのでそのまま表示可能ですが、Byte配列 等をJScriptやVBScriptの配列に変換するヘルパーが必要だろうと考えています。
Windows2000での動作実験を行っているのですが、リンクしているライブラリ バージョンの違いからか例外が発生します。できるだけ歩み寄ってみますが 場合によってはWindows2000を動作対象から外す可能性もあります。
864は私の思い違いでした。 原因は実験機のWindows2000が不安定だっただけのようです。
HTABOX3.00デモ
ttp://kuroda.bglb.jp/htabox/htabox3.zip メニュー及びポップアップメニューを実装しました。デモに双方のIDを指定
するサンプルを追加しました。このデモ用HTMLを見ていただけるとわかりま
すが、起動JSからCreateHtaWindowでHTMLが生成される場合、</head>直後に
<script language="jscript">
var WIN32 = showModalDialog('about:blank',null,'dialogHeight:0px;dialogWidth:0px;unadorned:yes');
</script>
と記述するだけでWIN32が取得できるものとしています。格納を想定する場合
#defineで打ち消す必要がありますが、自分用ツールの場合はこの記述で冒頭
からWIN32が有効となります。HTABOXはHTA起動直後に大きさ0の子ウインドウ
が存在した場合その返却値としてWIN32オブジェクトを返します。
上記 「格納を想定する場合 #defineで打ち消す必要がありますが」はミスです。 この手法は格納時にも有効です。事実Quickは格納時にこの手法でWIN32を 取得し、システム側のJSからBuildMenu();を実行することでメニューを生 成しています。そろそろ50歳ですから物忘れが激しくなってきました。
バージョンアップの機会にTreeViewコントロール機能を追加したいと思って います。TreeViewは通常ランタイムみたいなCOM経由で使うらしいのですが、 HTABOXはメニューがそうであるようにピュアWIN32APIの軽量なコントロール になる予定です。単純に<ul ID="TREE">内のli,ul階層を処理できればと考 えています。イメージリストについては適当な大きさに限定するかも知れま せん。
Listviewコントロールの方も需要ありそう
通常のhtmlじゃtreeなんてまず使わないから被らないだろうけど やっぱりHTABOX_TREEとかにしたほうがよさそう。
というか、そんなこと気にするの俺だけかな……
>>872 勿論HTABOXコアからのHTML生成ならメニューのように任意なIDを選択すること
ができます。例え少数のご意見だとしても、方向を変えるのではなく選択肢を
増やすという解決策が取れるのであれば総て受け入れて改良したいと考えてい
ます。IDを縛るのは私自身も気にしていた部分ですので今後追加されるすべて
のコントロールは任意なIDを選べる関数で認識される予定です。
HTMLドキュメントウインドウにTreeViewを乗せ、ドキュメント全体がスクロ ールされても破綻しない処理というのにちょっと手間取りましたが、予定ど おりのものになりそうです。このコモンコントロール操作手法が確立すれば ツールバーやリストビュー、タブコントロール、プロパティーシートについ ても短時間で対応できるものと考えています。
HTABOX3.00デモ
ttp://kuroda.bglb.jp/htabox/htabox3.zip TreeViewデモを追加しました。まだ仕様として煮詰まっていないので画像は
COM登録されたEXEを起点に検索しています。たぶんHTMLに従属的ActiveXでは
ない形でツリービューを乗せたのは私が初めてなんじゃないかと思いますが、
上に乗っているのはCreateWindowEx(WS_EX_CLIENTEDGE, WC_TREEVIEW....
で生成された本物ですのでこれ以上クイッキーにはできないほど軽量です。
基本的にHTML中のULエレメント座標上にコントロールを配置しますので、 メニュー用TABLEとは違いvisibility="hidden"な状態としています。これに よりウインドウサイズが変動して基準となるULが動いても自動的に追従して 表示されます。ただあくまでも別ウインドウですからページウインドウを 意地悪く縮小させた場合の処理にもう一工夫必要なのかなぁーとも感じてい ます。現状はページウインドウのスクロールバー描画を阻害しないように自身 ツリービューのウインドウサイズを縮小させる選択をしています。
プログラムを作るというとテクニカルな分野が主体となりがちですが、この ツリービューコントロールを目次にして書籍のように文字や、画像や、音楽 を楽しめるコンテンツを作って販売するなんていうのもいいんじゃないかと 思います。プログラミングという言葉にアレルギーを持つような方でもこれ なら使えそうだと思っていただけるものにしてゆきたいと思っています。
リクエストもあったことですし、ListViewも付け加えたいと思います。Tree にしてもListにしてもできるだけシンプルに宣言できることを主眼とします ので、ドラッグドロップとか、要素の直接編集とかは今のところ守備範囲に 入っていません。ただListViewの場合、ネイティブコードレベルでの高速な ソートが魅力でしょうから、それは是非実現したいと思います。
アプリケーションメニューとツリービューは今のところHTML表示前に形成さ れ動作中の追加、変更をサポートしていませんが、リストビューの場合動作 途中での生成、更新に対応したいと思います。HTMLとは異次元な速度のソート 表示を目的としますので通常はHTMLデータとは切り離されていなければなり ませんが、必要に応じてベースとなるTableタグとの同期をとるメソッドも 必要になるだろうと考えています。
TreeViewの宣言について説明します。 <ul id="HTABOX_TREE" imglist="bmp/close.bmp,bmp/open.bmp,bmp/doc.bmp"> <li image="0" selected="1">フォルダ1 <ul> <li image="2" selected="2" onclick="alert('001')">ドキュメント</li> <li image="2" selected="2" onclick="alert('002')">ドキュメント</li> <li image="2" selected="2" onclick="alert('003')">ドキュメント</li> </ul> </li> </ul>
TreeViewはWIN32.BuildTree("HTABOX_TREE");のようにIDを指定して生成され ます。このIDを省略した場合は"TREE"が検索されます。指定IDのタグはulで なければなりません。内容はli/ulのみが有効でそれ以外は無視されます。 ルートulタグにはimglist属性があります。表示に使いたい画像をしています。 尚、現段階ではHTABOX3.EXEを基準とした相対パスとなります。 子タグにはimage/selected属性があります。これはimglistで設定した画像の 配列インデックスを表現しています。imageは非選択、selectedは選択時に 表示される画像です。各要素が選択されるとHTABOXはエレメントに対して click()を呼び出します。したがってonclickを記述すればイベントを受け取る ことができます。
リリースまでには細部の煮詰めや属性が存在しない場合の処理等を書かなけ ればなりませんが、「簡単、軽量」を極限まで追求した現在のスタイルは 従来のTreeViewに対する観念を完全に払拭するものではないかと自負して います。
説明が抜けていましたが、現状では画像サイズ16*16のbmpファイルであると いう想定で動作しています。ここに大きな画像が必要になることはないので はと考えているのですが、サポートすべきサイズについてご要望があれば対 応します。また、背景、前景色については元となるulの同設定を取得して反 映する予定です。
「タブレットPC時代に、このHTABOXコアの製作環境から入っていくことが、定番になるくらいに 敷居が低く、かつ潰しがきく仕様であることを心から望みます。」 〜江戸城より
XP+IE6で試すとtree.jsは正常に作動するけど、demo.jsとmenu.jsは 空のウインドウとそのタイトルありのタスクバー、加えて空のタスクバーが表示された上に リモートプロシージャコール失敗とのWSHエラーになります
>>886 ご迷惑をおかけします。当方でも環境を変えて検証してみます。
HTABOX3.00デモをXP+IE6用に更新しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip Quickリリース時にIE6用に慎重なコードを書いたのですが、試験的にもっと
緩やかにしていました。現状で従来のチェック方式に戻しました。HTA中の
WIN32取得スクリプトは変数宣言が一行増えて
var HIDEDLG;
var WIN32 = showModalDialog('about:blank',null,'dialogHeight:0px;dialogWidth:0px;unadorned:yes');
となります。尚、レジスト登録の為にHTABOX3を起動すると開発中の変なもの
が見えますが気にしないでください。
Menu、Tree、Listの各コントロールはHTML中のエレメントIDで作成すること もできるし、XMLDocumentを渡しても生成できるとすれば私はたいしたことを 書かずとも汎用な取り扱いができることに気づきました。そしてTreeやList がスクリプト側の問い合わせに対して現在の状態をXMLで返せば何がどう選択 されているのかをこれまた柔軟に認識することができます。 こういった「どうしたら楽ができるか」を考えさせた時私は世界で一番貪欲 な気がします。
vectorにあるHTABOX.exeと、今度のHTABOX3.exeはこれからも共存していくんですよね?
ListViewはいわゆる詳細表示モードを主体に考えています。データが貧弱だと せっかくのソート速度が体感できないのでこのPCのsystem32にあるファイル 情報(約2,500ファイル)を一覧表示させています。その都合で表示にすこし 時間がかかる場合もあると思いますが、ハングではなくデータが大きいだけ ですので心配しないでください。
まだ選択イベント等の処理について書いていないのですが、考え方として 何かがチェック、又は選択されたらテーブル本体へ単にclick()を送り、 スクリプト側はリストボックスのXML情報を見て何らかの動作を行うかを 決定してもらおうと考えています。なんだかんだとここのところよく寝て いないのでちょっと未完成すぎる気もしますが、WIN32ならではの高速な ソートをお楽しみください。 他人のデータではつまらないという方向けにTABLEデータを作成する側の スクリプトもこれからアップします。
>>892 となると、レジストリに登録しないとテスト出来ない仕様になるって事なんですかね。
ポータブルの環境や、レジストリを汚さない前提の環境では開発は厳しいことになるのですかね。
あらためてTreeとListを眺めてみるとListの方が存在意義は大きいように思い ます。Treeの場合は数千とか数万とかの要素を扱うことは考えにくく、したが ってDHTMLで代替可能な分野です。それに比べListの方はどうひっくり返って もHTML+スクリプトでは不可能な速度を実現してしまいます。今回はWIN32で ウインドウを生成しレンダリングもWIN32で行っているわけですが、この手法 を進展させると、WIN32の速度を保ちながらJavaBeansのようにコンポーネント の組み合わせでアプリケーションを構築することも可能でしょう。
896>> いいえ、ご心配には及びません。デモ版ですからドロップされたスクリプト を処理する能力が無いだけです。HTABOX3.00は上位互換として2.40の機能 を受け継ぎます。
HTABOX2.00以降はC++からのHTMLアクセスでもレイトバインディングを使って います。自分用ツールなら#import "mshtml.tlb"でインターフェース定義を 活用できるわけですが、汎用に使ってもらおうとすると危険をはらんでいま す。本来インターフェースとは公開後に変更されないものですが、IEのバー ジョンアップが原因なのかタイプライブラリの記述どうりでは呼び出せない 場合が発生するのです。
この問題は、スクリプトと同じようにレイトバインディング(照会と実行) を行うことで克服できます。反面、常に照会が発生するというデメリットも 生じるわけですが、一旦照会だけを行って実行関数IDを保持し、以降は照会 なしに直接実行を繰り返すことでそのデメリットも打ち消す工夫を3.00では 採用しています。特にWM_PAINTでドキュメントのスクロール量を取得するよ うな局面ではこういった小さな事の積み重ねが全体のレスポンスに影響を与 えることになります。
jscriptファイルとhtmファイルの関係についてなんですが、
htmファイルを読み込むという形ではなくて、一気に文字列で読み込ませてしまうような組み方はできるんですか?
strhtml='<html><head><hta:application id="HTA"> <meta name=vs_targetSchema content="
http://schemas.microsoft.com/intellisense/ie5 ">';
strhtml+='<meta http-equiv="Content-Type" content="text/html; charset=shift_jis"><title>Button</title></head><body><input type="button" value="Button" ID="Button1"></body></html>';
var HTA = WIN32.CreateHtaWindow( strhtml );
んな感じで。
そのあとで、動的にタグを付け加えていくような作り方をする場合のことなんですけども。
var obody = document.getElementsByTagName("body").item(0)
var oinputtext = document.createElement("input");
oinputtext.style.setAttribute('cssText','font-size:9pt;font-weight:bold;position:absolute;');
obody.appendChild( oinputtext );
ってな感じで。
>>901 HTAを動的に生成する目的によっていくつか手法がありますが、javascript:
プロトコルを使う方法もあります。引数ファイルパスの代わりに
mshta javascript:alert()
とするとalertが表示されます。これの応用で
javascript:document.write("........");document.close();のような引数
で有る程度の長さのHTMLを指定できます。
その限定されたHTML中に標準入力を取得するコードを書いて親スクリプトか らの標準出力で全HTMLを動的に生成する実験というのを行った記憶がありま す。 HTABOXコアの場合はWIN32.CreateHtaWindow("about;blank");の返却オブジェ クトからドキュメントへ書き込みが簡単にできますが、"about;blank"生成 のHTAは自身のドメインやファイルパスを認識していない不都合がありますの で制約のある存在となります。
目的にもよりますが、コンパクトでいいですから実在ファイルで生成し、 そのスクリプトから標準入力なり、ファイルなりを読み込んで最終的な HTMLを形成する手法にすればなんら苦労することはありません。 スクリプトタグ自体を後付で追加することはできませんが、追加スクリプ トコードをごっそりexecScriptで評価すれば問題がないと記憶しています。
このテーマはHTMLオブジェクト生成のデータソースとなるURLモニカをオリジ ナルな動作ものにすりかえることができるかに帰着すると考えています。 ただ、それを実現したところでデバッガでのソース追跡をかわせるわけでは ありませんので、徹底したチャレンジを行っていないのが現状です。
いろいろぐぐって参考にして、こんな感じでjsで作っておいたバッチに、簡単なGUIを付けて使ってました。 sdbl=String.fromCharCode(34); var oexec= new ActiveXObject('WScript.Shell').Exec('MSHTA.EXE ' + sdbl + "javascript:new ActiveXObject('Scripting.FileSystemObject').GetStandardStream(0).ReadAll()" + sdbl) oexec.StdIn.WriteLine(shtml) oexec.StdIn.Close(); sret = oexec.StdOut.ReadAll(); WScript.Echo(sret);/ * htaで作ったGUIの戻り値によって簡単な処理をする使い方 * /; で、教えてもらった var HTA = WIN32.CreateHtaWindow("about;blank") のヒントからいろいろ試しているのですが、いまいちよくわからないのです。 もしよかったら、もう少し教えてもらえませんでしょうか。
試してみたら出来ました。ありがとうございました。 var HTA = WIN32.CreateHtaWindow("about:blank"); HTA.document.body.innerHTML='<input type="button" value="Button" ID="Button1">'; //HTA.document.write('<body><input type="button" value="Button" ID="Button1"></body>');
// ポータブル環境で、単独のjsファイルで、htabox.exeで試行錯誤してみる場合で書いてみた。↓のパスに、htabox.exeのフルパスを指定する。環境変数を使ってもいいかも。 var phtaboxexe="V:\\portableapps\\htaboxcore"+"\\"+"htabox.exe"; main=function(){HTA.window.onFileDrop = Drop;SCR.Button1.onclick = hello; HTA.Show();HTA.window.resizeTo(200,140);WIN32.WiteForWindowVisible(HWND);WIN32.MsgBox("正常終了"); }; var argcl=[];var argdrop=[];var argdropadd=[]; var oshl=new ActiveXObject("WScript.Shell");var ofso=new ActiveXObject("Scripting.FileSystemObject");var oenvprocess=oshl.Environment('process'); if(typeof(WScript)!='object'){ var n=oenvprocess.item('arglength');if(n==''){n=0;}; for(var argcl=[],iii=0;iii<n;iii++){argcl.push( oenvprocess.item('arg'+iii));};}else{ for(var argcl=WScript.Arguments,iii=0;iii<argcl.length;iii++){oenvprocess.item('arg'+iii)=argcl(iii);};oenvprocess.item('arglength')=argcl.length; oshl.run( phtaboxexe + " " + WScript.ScriptFullName,1,false);WScript.Quit();}; var HTA = WIN32.CreateHtaWindow("about:blank"); shtml='\ <head></head><body id=mainbody>argdrop[]=ウィンドウにドロップしたファイル<br>argcl[]=起動時の引数<br><input type="button" value="終了" ID="Button1"></body>\ ';HTA.document.write(shtml); var SCR = HTA.Script;var HWND = HTA.FraHwnd; function hello(){SCR.alert("ウィンドウにドロップされたファイルは---"+argdropadd.join("\n")+ "\n---コマンドラインの引数は\n" + argcl.join("\n"));SCR.window.close();}; function Drop(sarg){ argdrop = sarg.replace(/^"|"$/g,"").split("\"\x20\"");argdropadd=argdropadd.concat(argdrop);oshl.popup( "---"+argdrop.join("\n")+ "---"); }; main();
まさしくCreateHtaWindowやCreateDlgWindowは今までHTML中のスクリプトと いう制約の有る状態でしか操作できなかったHTMLオブジェクトをWSHという 自由度の高い環境に引きずり出そうという関数ですので、それを理解してい ただいて今まで不可能だったことをどんどん実現していただきたいと思いま す。
3.00リリースの前にもう一つだけ機能を追加したいと思います。その機能は 「自由な形のウインドウ」です。 これもHTML + スクリプトでは実現できるはずが無い操作ですが、WIN32では 普通に使われるテクニックです。最終的にはビットマップを準備して指定色 をマスクしたウインドウを生成できるようにする予定ですが、まずは基本的 図形で基礎実験を行いたいと思います。
HTABOX3.00デモを更新しました。自由な形のウインドウデモを追加しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip kumo.jsはHTAの表示前にSetWindowRgnFrom関数でウインドウの形を自由に変形
させます。この処理は画像データを元に1px単位で行われますので表示にやや
時間がかかると思います。これにより文字だろうが絵だろうが自由な形のウイ
ンドウを生成することができます。
SetWindowRgnFrom関数は2つの引数を取ります。最初はマスクを生成するため のbmpファイルへのパスであり、二つ目はマスクのカラー数値です。まだこな れていないため第1引数は絶対パスで指定してください。第2引数はWIN32での RGBですのでBGRの順になります。白は0xffffff、青0xff0000、緑0x00ff00... bmpファイルは1bit白黒、4bit16色、8bit256色、24bit、32bitに対応 しています。現時点でマスクは許容範囲を持ちませんので明らかな純色を指定 してください。
本来はウインドウメッセージを見えていないタイトルバーへ転送してドラッグ 移動できるはずなのですが、開発最終段階でなぜか無視されてしまいました。 これは早急に対策を考えて修正する予定です。このデモのようにマスクと画像 位置を同じくするためにはbodyにtopmargin="0" leftmargin="0"を指定する必 要があることに注意してください。是非いろいろな画像(手書きもOK)でおも しろい形のウインドウを作成してみてください。
ものはついでとツールーバークラスを書いたらなかなか美しいできばえでし たので急遽3.00機能に追加することにします。本来ツールバーは最も簡単な 部類のコモンコントロールなわけですが、HTMLウインドウという有る意味閉 鎖的で、他人様が書いたウインドウに後付しようとすると最も困難を極める コントロールになります。正直、美しいメッセージの流れでそれを実現する ことがあまりに難しいものですから知らないふりをきめこんでいました。 どんな分野でも一旦理解してしまえばただそれだけことなのですが、私にと っては3年越しくらいの課題に決着をつけることができてとてもすがすがしい 気分です。
これで、HTMLウインドウについて知りたいことは、ほぼ調査できたと感じてい ます。ウインドウレベルでの操作で「何でもあり」を実現でることは大変大き な意味を持ちます。例えばタブブラウザのように複数スレッドのドキュメント 画面を切り替えることも可能です。そういった機能もおいおい追加してゆく予 定です。
HTAの場合、生成初期にダイアログを出してディスパッチを取得する関係上 ウインドウがフォーカスを失った状態で表示されることがありますので SetForegroundWindowをメッセージループ初期で必ず1実行するように改めま した。
ツールバーも細かな機能を盛り込むとわかりにくくなるだけですので、単純 に一行のテーブル内のTDに背景画像で設定してあり、onclickが定義されてい ればボタンが押された場合実行されるという仕様にしました。 <table id="HTABOX_TOOL" imgsize="32"> <tr> <td onclick="alert('Tool0')" width="32" background="bmp/tool0.bmp" height="32"> </td> <td onclick="alert('Tool1')" width="32" background="bmp/tool1.bmp" height="32"> </td> <td>-</td> <td onclick="alert('Tool2')" width="32" background="bmp/tool2.bmp" height="32"> </td>
HTABOXが読む部分はイメージのサイズである<table>のimgsize属性、各<td>の background属性です。<td>のwidthとheightは単に編集中の見栄えの為に設定 されています。上記例では間隔用に<td>-</td>としていますが、内部的には background属性が無い<td>はスペース用と認識しています。 また、ツリービューも含めてマスク色を指定できるように整備しますが、現在 は純黒0x000000をマスクと認識しています。
どうも全般に初期ウインドウ構築が安定しない局面がありますので場合に よってはスプラッシュウインドウでも表示してこの問題を根本から解決し たいと思います。まぁ私の勉強不足が原因なのですがウインドウのアクテ ィブ設定というのは結構奥の深いものだと感じています。
【経済】フレッツ光、2800円から NTT東西が新料金
http://raicho.2ch.net/test/read.cgi/newsplus/1298870574/497 497 名前:名無しさん@十一周年[sage] 投稿日:2011/02/28(月) 14:58:57.92 ID:RfceUFt90
全てのプロバイダが談合して従量制に移行するのが決まっていて、
ネット代が月3万円以上するのが普通になるみたいだ。
【今までが】ついに従量制課金へvol.1【良かった】
http://hibari.2ch.net/test/read.cgi/isp/1297435617/ 5 名無しさんに接続中… 2011/02/12(土) 07:28:23 ID:sCFMzbBe
>>3 総務省のお墨つきが出ているし、大手ISPはどこもやりたがっているから間違いなく従量制が主流になるでしょう。
友人がみかかの組合にいるけれど、組合には「案」が下りて来ているとのこと。
簡単にまとめれば従量制と定額制の並存になる。
ただし…
・定額制には1ヶ月もしくはは1日あたり、一定容量以上の利用でダウンロード規制。
・従量制は上限プランに応じて品質の差別化を図る。
マスコミで発表された「上限5985円」はメールとポータルサイト閲覧者向け。
ダウンロードが上限額に達したところで通信規制の対象となる。
最大の上限プランはは3万〜4万の辺で調整。ただし、このプランは通信規制の
原則対象外となる。
・小規模法人で家庭用プランを利用しているユーザーには法人向けプランへ誘導
する。
ことの話で確定済み。
経営側役員レベルでは、現状の料金体系では将来にわたる品質維持に支障になる と、料金体系の改善を迫っているとのこと。これは光のみならず、ADSLやISDNも 同じなんだと。 あと、現行の料金プランのユーザーも2〜3年後目処に新しい料金プランへ移行させ る方向で話をまとめているとのこと。 生活にネットはなくてはならない時代になったから、従量制にしても問題はないは ずだが。
現在のデモは本来2枚であるHTMLウインドウの中間に割って入ったウインドウ を存在させてコントロールしようとしているのですが、それによって本来の ウインドウ同士の通信を阻害してしまう事態が発生しているのかも知れません。 あくまでも他人様が書いたものですから、仕様が公開されているわけでもなく すべては手探りになるわけですが、現状の打開策としてツールバーを利用する 場合、はじめからドキュメント上部の余白をHTML的に設けてもらうことにすれ ばとりあえずこの難解な問題には関らずに済むと思われます。
ツールバーのボタンにオンマウスでtitle属性のようなツールチップ表示はできないでしょうか?
>>928 このデモだとエラーダイアログが
DInvoke Error:readyState GetDispID 80070005
DInvoke Error:readyState InvokeEx 80070005
DInvoke Error:parentWindow GetDispID 80070005
DInvoke Error:parentWindow InvokeEx 80070005
SAMPLE_EXE:Unknown Error
と連続して起動できずに強制終了するのですが……
ちょっと悩みがあってコードを短時間に書き換えて実験していますが、 希望通りにならない原因を究明できていません。安定したらここで告知 させていただきます。
VC6では問題の無いコードがVC7.1だとタイミングによってストールします。 コンパイラオプションをチェックしたり場合によってはVC6でライブラリを 形成してから結合する作業が必要になるかも知れません。一旦デモは停止 させていただきます。いかなるストレスがかかっても安定動作するものを 提供しなければ意味がありませんし、こういう機会こそ新たな成長のきっか けになるものです。
今回の混乱の最も大きな要因は開発コンピューターそのものの不安定でした。 一つの完成したモジュールをお見せする裏では何百回とコンパイルと実行が 繰り返されるわけですが、そのほとんどがエラー停止又は強制終了になりま す。その原因を探る作業がプログラミングの本質ですが、今回は主にウイン ドウメッセージ系のプログラミングですのでいつもになくダメージが蓄積し ていたようです。ヘッダファイルのバージョンによる差異はありますが、結 果的にVC6とVC7.1は同じ結果を報告してきましたので一安心しました。
ツリーとリストのサイズについては参照元となる<UL>、<TABLE>のサイズを 基本としますが、特にリストの場合実際の<TABLE>高さとリストコントロール の高さが大きく違う場合がありますのでこの両者に関しては常に下端を表示 ドキュメントウインドウに合わせるオプションを追加したいと考えています。
>>929 ですが、
demo.jsとkumo.jsはウインドウの中身が空になることがあり、
list.jsはウインドウ表示前に
DInvoke Error:readyState GetDispID 80070005
DInvoke Error:readyState InvokeEx 80070005
のエラーダイアログが必ず出ます
>>935 ご報告ありがとうございます。今書いている部分が終わったら私も別バージョン
のIEで総合的なチェックを行いたいと思います。しばらく時間をください。
htabox3.zip内のkumo.pngをみてみたところ、ドロップシャドウが半透明なんですね! かなりwktkしてきました。
HTABOX3.00デモを更新しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip まだ根本的なIE6対策は行われていませんが、HTAのメニュー生成を他のコン
トロールと同じようにWSH側にWIN32があれば可能としました。これにより
HTAでメニューを生成する場合に<head>直後にダイアログ呼び出しを書く必要
はなくなりました。このダイアログ呼び出し時のストールが原因ですので
さらに原因を煮詰める作業を行います。
あとは2.40が実装していた機能を継承してドキュメントの作成に入りたいと 思います。勿論さまざまなご要望があればお答えしますが、まずはリリース に向けて完成度を上げることに主眼をおきたいと思っています。.NETスクリ プトが実行でき、新たなコモンコントロールが追加された3.00のリリースは HTMLアプリケーションに新たな1ページを刻むはずです。
また
>>929 ですが、
list.jsが
DInvoke Error:readyState GetDispID 80070005
DInvoke Error:readyState InvokeEx 80070005
Windows Script Host:サーバーによって例外が返されました。 80010105
とエラーダイアログが連続してウィンドウ表示にまで至らないようです
他のサンプルは格段に安定したのですが……
>>941 ありがとうございます。今一度、細部の煮詰めを行いたいと思います。
HTABOX3.00デモを更新しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip ページャーコントロールのデモを追加しました。これはまだ込み入った手順
を抽象化できていなのでHTABOX3.EXEそのものを起動するとご覧になれます。
このページャーコントロールでは主たるHTMLインスタンスとは別のインスタ
ンス(モードレスダイアログ)をコントロールの内容としてスクロール表示し
ています。これ自体はDHTMLで行った方がいいような処理なのですが、もしこ
の親ウインドウがHTMLではなくWIN32ウインドウの場合は大きな意味を持ちま
す。最小限のC++コードでHTMLコントロールを生成しGUIをHTMLで書きながら
処理をC++で書けるからです。
私が理想とするプログラミングモデルは常に2つあります。JScript主体で効 率的にアプリケーションを生産し、足らない部分だけをC++のCOMモジュール で補おうとする考え方と、C++を主体にして堅牢かつ繊細な管理を行いながら 煩雑なGUI形成だけをHTMLとスクリプトで補おうという考え方です。 つまりこのページャーコントロールは後者のためのアプローチになります。
マイクロソフトが3億円くらいで買ってくれないかね?HTAの正常進化版としてWindowsに添付してほしいわ。 そしてこれがWindowsPhoneでも動くなんてことになれば凄いことになるんだが。
マイクロソフトにはHTMLオブジェクトのソースがあるわけですから、私のよ うに手探りでメッセージを解析したりしなくても、この程度のことなら即座 に提供可能なんだろうと思います。ただ、それが企業としての方向性とは相 容れないものだろうことも明らかです。「WindowsをよりフレンドリーなOSと する為に」とでも題して本社にメールしてみましょうか。
941の話題なのですが、HTAがbusyな場合に配慮して実際のInvokeExを行う前 に監視スレッドを投げて100msというのんびりした間隔で単にGetDispIDだけ を問い合わせています。で、そのループでS_OKを確認した後の本番呼び出し でストールしています。つまり一度はIDの取得に成功しているにも関らず再 度実行した場合、0x80070005(access denied error)が返されるなら、もはや 制御下にない状態だと考えられます。
>>946 だめもとで本社にメールしたら面白いよ。Titanium、TitaniumMobileとかHTMLアプリで開発者を取り込む動きもある。
HTABOXがMSの既存の商品とバッティングするといって忌避されるとは限らない。
この現象を再現するためにストレスのかかったIE6で繰り返し実行しています が、同じ状態に遭遇できていません。現実には650kのテーブルを読むだけでも IEのエンジンにはかなり負荷がかかりますから、生のHTMLではなくHTAが安定 した後にデータベースでの取得かXMLでの取得を行ったほうが安全だろうとい う教訓かも知れません。ちなみに現在公開中のデモにはlist2.jsが存在し、こ れはCreateHtaWindowをCreateDlgWindowに変えただけの存在です。Dlgの方が 軽量ですのでこちらで長大なリストビューをご覧になれるかも知れません。
その
>>941 ですがlist2.jsは正常に動作するもののlist.jsは相変わらずでして
>>950 了解しました。何かもっと気の利いた方法があるのに気づいていないんだと
思われますので、継続した課題として認識したいと思います。私としてはHta
を使うメリットは若干のウインドウスタイルの違いだと思いますのでDlgの使
用をお勧めします。
と書いていて気づいたんですがDlgでアイコンを任意なものにする機能が必要
ですよね。それを書きたいと思います。
普通のbmpファイルから透過アイコンを生成するコードは思いがけず複雑な ものでしたが、克服できたようです。これで普通のPaintで作成した各種BMP ファイルを指定してウインドウアイコンとすることができます。内部では TrueColorとして扱っていますので色についてもなんら制約がありません。
リストビューコントロールとHTMLとの通信仕様を決定しました。本来は長大 なデータをHTML側で高速に処理可能なように生のXMLインスタンスを共有した かったのですが、コモンコントロール側はウインドウズメッセージ駆動での XML操作となりますのでHTML又はWSHスレッドとの同期が難しくなるようです。 そこでコモンコントロール側はHTMLテーブルの各<TR>にchecked、selected 属性をfalseで初期化し、チェック又は選択時に属性へ逐次反映させるものと しました。ツリービューに関しては同じ理由でXMLでの生成を今回はサポート しません。動的なツリービューが必要な場合はスクリプトで動的にul/liを 生成してからツリービューを構築関数を呼ぶことになります。 明日最終的なデモを公開する予定です。
イメージ画像をアップします。次世代という表現は大げさですが、今後のHTML
アプリケーションはその外観の面でも通常のアプリケーションと同等のものと
なります。
http://kuroda.bglb.jp/htabox/newhta.png HTA固有の問題なのですが、アクティブウインドウの確実な設定に取り組みまし
た。また、HTAウインドウの内部構造を解析することでページャーコントロール
を一般化しました。上記画像のようにフラットにするとなかなかおしゃれだと
感じています。
このページャーコントロールは単に指定されたファイルパスのHTMLをスクロール 表示するという単純且つ汎用性の高いものです。尚、ツールバーと水平スクロー ルバー、ページャーコントロールと垂直スクロールバーは排他的存在となります ので双方を利用した場合、スクロールバーは表示されませんがこれは仕様です。
ページャーコントロールの仕様について説明します。ページャーが表示する 内容はHTMLダイアログです。デモのleft.htmがこれにあたります。 var LeftScript = Obj.BuildPager(Dir + "\\left.htm", "140"); BuildPager関数は第1引数に絶対パス、第2引数に横幅を取ります。縦はHTMLが 必要とする長さを自動的に取得します。本体ウインドウのクライアント領域 高さ(ツールバー表示ならその分を除く)がHTMLの要求高さよし小さい場合 スクロール用のボタンが自動的に表示されます。このHTMLは当初起動WSHと は無関係ですが、BuildPagerはダイアログHTML側スクリプトインスタンスを 返しますので上記例ではLeftScript変数に保存し関数の追加を行っています。 詳しくはtool.jsとleft.htmをご覧ください。
list.jsでのリストビューデモにはチェックされた複数のアイテム、選択された 単一のアイテムをalertで表示するデモとなっています。コントロールには任意 な表題をドラッグして自由に並び替えることができるスタイルも追加しました。 このメカニズムは極めてシンプルでコントロール側は与えられたHTMLのTRに属性 checked、selectedを新設し真偽をセットします。HTML側では単にTRをループで 検査し当該属性が真であるかを確認し表示しています。 詳しくはlist.jsとlist.htmをご覧ください。
過去にもステータスバーは何度か試したんですが、時たまフリーズするんです。 今回はかなり真剣に多方面から分析しているのですが、サイズブリップが設置 されているとデフォルトのウインドウが持つ同等なメッセージの流れを阻害し てしまうのではないかというのが現時点での推理です。したがって現時点のデ モではサイズブリップの無いステータスバーとしています。もしこの推理が正 しく、ステータスバーが安定したものとなれば、メニューに説明文を付加して ここに自動表示されるといった使い方を考えています。
WIN32なら書こうと思えば何でも書けるわけですが、正直言って自分がこれほ どのものを書けるとは思っていませんでした。一年前にHTABOXコアを世に出し た時は自分でさえ、機序を理解していない危うさがあったのですが、COMとそ れを最大限に利用したC++コードの書き方とは何か?という根源的なテーマと 向き合った結果、非常に見通しのいい設計ができるようになりました。一年間 このスレッドにお付き合いいただいた方々への御礼のつもりで3.00を仕上げた いと思います。
ステータスバーは安定動作しているようなので、アプリケーションメニュー にtitle属性文字列が存在する場合、状況依存の説明文としてステータスバー に表示される機構を採用しました。ただし、ステータスバーと水平スクロール バーも排他的な存在のようです。 従前バージョンが装備していたWIN32APIの実装作業に入りました。次に公開する HTABOXコアはデモではなくβバージョンと呼称する予定です。
まだβを呼称できる状態にはいたっていませんがデモを更新しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip tool.jsに変更点が集約されています。メニューとポップアップの生成関数を
別にしました。ツールバー、ページャーに装飾のための線描画オプションを
追加しました。ステータスバー生成関数BuildStatusを新設しました。アプリ
ケーションメニューの最初の項目にマウスが乗るとステータスバーに説明文字
列が標示される動作を確認できます。
ヘルプを作成するのですが、ちょっといいアイディアを思いつきました。 せっかくTreeを表示できるのでから、<h1>....<h6>を表示時に解析し見出し 文字列を階層表示してくれるTreeを作れば単なるHTMLをコンパイルされたヘ ルプファイルのように閲覧することができるはずです。通常こういった階層 判断は整形XMLでないと面倒な事になりますが、実行時であればdocumentが 保持しているDOMノードをたどれば破綻しないわけですから実に軽量なソース になるはずです。
とりあえず前原外相辞任ということで、菅内閣がやぶれかぶれ解散する前に 次スレの名前を決める論議もはじめないといかんだろう。 候補を挙げとくから、各自でTPP論議並みに慎重に判断してほしい。日本の運命が掛かっとるぜよ! HTABOXコア Part2 HTABOXコア増量中Part2 HTABOXコア人生劇場Part2 HTABOXコア プロジェクトXPart2 HTABOXコア+D-NETBOX Part2 大河プログラムHTABOXコアPart2 HTABOXコア ヤッショーマカショPart2 今日は一日HTABOXコア三昧Part2 HTABOXコア プログラム深夜便Part2 HTABOXコアだよ!全員集合!Part2 連続プログラムドラマHTABOXコアPart2 HTABOXコア 吹けば飛ぶような将棋の駒にPart2 俺のHTABOXコアがこんなにかわいいわけがないPart2 そうだったのか!HTABOXコア いい質問ですねぇ!Part2 HTABOXコア+D-NETBOX+C++COMオブジェクトHTMLアプリ Part2
HTABOXコア ヤッショーマカショPart2 に一票入れます。 ヘルプエンジンの中核部分は完成しました。後は動的ドキュメント解析と ツリーメニューとドキュメントの同期部分です。たとえどんなに気の利いた ものを作っても、情報として伝わりにくければ使ってみようということにな らないでしょうから、HTABOX.EXEのHelpから起動するこのエンジンの出来栄 えは重要だろうと考えています。
HTABOXコアヘルプエンジンが完成しました。
http://kuroda.bglb.jp/htabox/helpdemo.zip helpdemo.exeはHTABOXそのものですが、HELP表示モードで起動します。
起動後に添付のtest.htmを開けばミニMSDNであることがご理解いただけると
思います。このEXEは汎用なHTML、HTAを自身のウインドウ内で実行できます。
表示HTML内に順序だった<h1>-<h6>が存在するとinnerTextをラベル名にTree
表示し、選択されたTree項目へ自動的にスクロールします。遊び方としては
複数のHTAを長い画面にまとめてTreeからランチャーのように必要な部分を
表示させて実行するというのがおもしろいかも知れません。
今回はあえてHTABOXに装備されている既存クラスを使わずにできる限り独立 したモジュールとしてこのエンジンを設計しました。このエンジンは左右の ウインドウサイズを変更できますが、本家MSDNのように破線表示に逃げずに このスプリッターバーをどれだけ軽量にできるかというのも重要なテーマで した。HTMLウインドウ自体が壮大なオーナードローウインドウですのでそれ が重い場合には対策が難しいのですが、説明を目的としたコンテンツの表示 に関しては考えていた以上のクォリティーに仕上がったのではないかと思い ます。この<H*>による階層表示、スプリッターも抽象化できればスクリプト からコントロールできることになると思います。
作者さん、大丈夫? カキコないと心配だよ
>>970 ありがとうございます。
私の住む庄内は日本海側ですので被害もなく開発を続けております。
今回の地震災害に遇われた方々に心からお見舞い申し上げます。
HTABOXコアヘルプエンジンを更新しました。
ttp://kuroda.bglb.jp/htabox/helpdemo.zip 汎用に使える機能ではありませんが、ツールバー下をドラッグするとリッチ
テキストエディタが出現します。HELPで項目を選択するとここでサンプルコ
ードが出現し、その場で実行可能となる予定です。また、エディタですから
サンプルを書き換えて、実行することも可能となる予定です。
まだβを呼称できる状態にはいたっていませんが開発環境としてのHTABOXの
イメージを理解していただく目的でファイルを更新しました。
ttp://kuroda.bglb.jp/htabox/htabox3.zip ツールバー右側ボタンの操作でエディタを開きtest.jsを読み込んで実行する
ことができます。この場合レジストリには関与せず自身のクローンインスタン
スへパイプ経由でスクリプトコードを渡して実行します。
そろそろ光熱費も危うい状態ですので、この統合環境はシェアウェアで公開 する予定です。いくばくかでもお金をいただけるクオリティーを目指すという ことでエディタ部のコメント及び予約語の表示には一週間ほど費やして軽量 な動作を目指しました。リッチエディットではこういうことができないという のが定説のようですが、ITextDocument系インターフェースを解析すれば可能 です。TABで複数選択行のインデントができます。SHIFT+TABで逆を行えます。 動作軽量化のために文字色はカレント行での操作を監視しますが、複数行を 選択後にCTRL+TABで当該領域の予約語を再評価します。
素のHTABOXコアは従来どおりアマチュアならフリーとする予定ですがEXE生成 機能はプロ、アマチュアを問わず会員アカウント制に移行します。この統合環 境はHTABOXワークベンチとでもして、プログラムなんか面倒で書く気にならな いという面々にヘルプを眺めながらサンプルコードを実行してその簡単さに気 づいてもらうことをイメージした設計となっています。また、インテリセンス 有効なDLL版HTABOXをディープなスクリプター向けに販売します。
今回ソースコードのコメント、予約語判定をかなり本気で書いたのですが、 C++の威力をまざまざと見せ付けられた感があります。ソース解析では前段 で静的文字列領域の確定、コメント領域の確定、その後すべてのトークン に対して予約語候補と一致するかを検定するわけですが、現状のHTABOXソー スコード(150k)を与えても瞬時で終了する速度には驚嘆してしまいます。 これがスクリプトだったらどんなに賢く書いても30秒位は帰ってこないと 思います。このリッチエディットをCOMインスタンスとして扱う手法もいつか コンテンツに整理して公開したいと思います。
次スレの前文の一案として考えてみました。こういうのもありうるということで。 C++のことまで説明しても、食いつきが悪いと思って省きました。 ”将来にわたって潰しが効く開発環境”をキーワードに考えてみました。 これに拘らず、早めに次スレを立てて、このスレは埋めないで残しておいたほうがいいと思うよ。 HTABOXコア ヤッショーマカショ.NET Part2 hidebou氏開発によるHTMLアプリ開発環境HTABOXコア、HTABOXクイックのスレッドです。 HTMLとJavascriptといった多くPCユーザーに使われている潰しの効く技術から、 Windowsに付属するHTAでは不可能なウィンドウへのドロップやメニューなどの 使いやすいGUIを取り入れながらアプリを作ることが出来ます。 またドットネット(.NET)やWIN32APIの機能を使うことも出来るので、 ドットネットを使うノウハウも取得しておきたいという方にも 将来に渡って潰しが効く製作環境となるでしょう。 そしてこの環境で作ったアプリを、ソースを限りなく隠蔽した状態で 販売、または配布するための環境も用意されています。
ありがとうございます。私用でネットの無い環境にいたものですからレスで きませんでした。とても的確な前文で、私よりもHTABOXのことを理解してい ただいているようで大変うれしく思います。私が次スレッドを作ってもいい のであれば是非使わせていただきたいと思います。
>>977 >潰しが効く
個人開発で非オープンのソフトが
そんなわけないだろ。
作者がサポートしなくなったら、
その時点で終了。
>>980 潰しが効くっていう主な理由は、HTMLとJavascriptで組めるから。それと.NETも使えるから。
仮にHTABOXコアがサポートなくなっても、ここに費やして得たノウハウはほかのHTMLアプリにも生かせる。
Titanium、TitaniumMobileなどのHTMLアプリへ移行してもいいし、HTAでも生かせる。そういう意味もある。
>>980 アマチュアがツールとして使う機能はたとえ私が居なくなっても有効である
事をガイドラインとしています。ビジネスの為のツールとして使う場合は管
理下に置く意味でオンライン認証をメインとすることになります。まだ、そ
この線引きを明確にできていないのでちょと漠然とした表現になってしまう
のですが。
WindowsやIEが様変わりしたら...についての対応は企業だとか個人だとかと
いうのは別問題で対応する技術があるかないかだけの問題だろうと考えます。
RICHEDITコントロールで何ができて何ができないのかの見極めもだいぶついて きました。RICHEDITは他のコントロールとは違いIDispatchで操作するための インターフェースが装備されていますのでそれをスクリプトへ公開するという 手法で有る程度のことは実現できるのではないかと考えています。ただし用途 からして独立したウインドウの方がいいのではないかとも思います。つまり CreateRtfWindow()で新たなPopupウインドウが生成されITextDocument2を通じ て操作してもらうという構想です。従来はすべてMSHTML.DLLがらみのウインド ウでしたが、非HTMLなウインドウをスクリプトから操作することになります。
エディタ部はほぼ出来上がったのでファイルを更新しました。まだβではあ
りませんから本格的にスクリプトを実行する機能はありません。
ttp://kuroda.bglb.jp/htabox/HTABOX3.zip ソースは16Mbまで行は99999まで予約語はJS、VBそれぞれの.NETの4種類に切り
替える事が可能で、行番号部分をクリックするとブックマークとして記憶され
コンボボックスの選択で即座にジャンプ可能です。メモ帳よりは幾分使いやす
いと思いますので遊んでみてください。ツールバーの「スクリプトエディタの
表示」でエディタが現れます。