とにかくdat落ち必死なこの話題をどうかひとつ。
関連スレ:
【GUIライブラリ】wxWindowsでのひょーん
http://pc2.2ch.net/test/read.cgi/tech/1052186697/
【C++】マイナーGUIツールキット
■ このスレッドは過去ログ倉庫に格納されています
NGNG
412デフォルトの名無しさん
2008/06/16(月) 09:58:39 Windowsで初心者なら.NET一択じゃね
ウンコウンコ言われながらも、情報量が圧倒的過ぎる
ウンコウンコ言われながらも、情報量が圧倒的過ぎる
413デフォルトの名無しさん
2008/06/16(月) 10:06:46 情報量は圧倒だが、アウトプットのアプリは皆無。
414デフォルトの名無しさん
2008/06/16(月) 13:28:18415デフォルトの名無しさん
2008/06/16(月) 13:32:49416デフォルトの名無しさん
2008/06/16(月) 13:37:21 一番好きなプログラミング言語は?
http://itpro.nikkeibp.co.jp/article/OPINION/20080528/304478/
プログラマに対象を絞って聞いた「一番好きなプログラミング言語」は,「C/C++」(24%)が最も多く,
「Visual Basic(VB)」(20%),「COBOL」(13%)と続いた(図2)。企業の基幹システムに浸透しつつあるJavaや,
Webアプリケーション関連で使われることの多いスクリプト言語は,上位3位までに食い込むことができなかった。
C/C++ 24%
VB6.0 20%
COBOL 13%
Java 9%
Perl/PHP 7%
C# 2% ← m9(^Д^)プギャー
一番好きな言語と対比する格好で「最もよく使っているプログラミング言語」も聞いてみたが,
ここでは「C/C++」と「VB」の順位が逆転,「VB」が一位だった。
http://itpro.nikkeibp.co.jp/article/OPINION/20080528/304478/
プログラマに対象を絞って聞いた「一番好きなプログラミング言語」は,「C/C++」(24%)が最も多く,
「Visual Basic(VB)」(20%),「COBOL」(13%)と続いた(図2)。企業の基幹システムに浸透しつつあるJavaや,
Webアプリケーション関連で使われることの多いスクリプト言語は,上位3位までに食い込むことができなかった。
C/C++ 24%
VB6.0 20%
COBOL 13%
Java 9%
Perl/PHP 7%
C# 2% ← m9(^Д^)プギャー
一番好きな言語と対比する格好で「最もよく使っているプログラミング言語」も聞いてみたが,
ここでは「C/C++」と「VB」の順位が逆転,「VB」が一位だった。
417デフォルトの名無しさん
2008/06/16(月) 21:56:13 C#はいい言語だと思うんだがなぁ…
.NETじゃくネイティブコードコンパイラなければもっと使ってるのに…
COBOL(13%)ってのはITPro(というか日経)の読者層を反映しすぎてる気がする
.NETじゃくネイティブコードコンパイラなければもっと使ってるのに…
COBOL(13%)ってのはITPro(というか日経)の読者層を反映しすぎてる気がする
418デフォルトの名無しさん
2008/06/19(木) 23:55:15 ここにも貼っておく
ttp://torjo.com/egui/
ttp://torjo.com/egui/
419デフォルトの名無しさん
2008/08/10(日) 00:45:15 VB6.0にCOBOLが2〜3位って、時代に取り残されたおっさん確定だろ
そんな奴らにC#の良さが分かるとは思えないw
そんな奴らにC#の良さが分かるとは思えないw
420デフォルトの名無しさん
2008/08/10(日) 06:46:14 >>419
4番目にJavaはともかく、5番目にPerl/PHPだもんなw
4番目にJavaはともかく、5番目にPerl/PHPだもんなw
421デフォルトの名無しさん
2008/08/10(日) 08:56:54 GC.AddMemoryPressureが追加されるまでのC#は実用にならないゴミだったから仕方が無い
422デフォルトの名無しさん
2008/08/11(月) 04:31:35 >>417
海外だとC#で書いたものが多くなってますよね
日本じゃまだ目新しすぎてついて行けないだけじゃないかなぁ
C/C++が一番多いのは納得だけど、VB6が20%なのは厨房SE/PGが多い日本ならでわかと。
海外だとC#で書いたものが多くなってますよね
日本じゃまだ目新しすぎてついて行けないだけじゃないかなぁ
C/C++が一番多いのは納得だけど、VB6が20%なのは厨房SE/PGが多い日本ならでわかと。
423デフォルトの名無しさん
2008/08/11(月) 07:57:16 Delphiがその他のどのくらいの割合なのかが気になる上に
VB6.0て分けるぐらいならC/C++も分けるべきだったろに。
VB6.0て分けるぐらいならC/C++も分けるべきだったろに。
424デフォルトの名無しさん
2008/08/11(月) 20:01:01 >>422
厨房がVB6なんて知ってるわけねえだろ。
厨房がVB6なんて知ってるわけねえだろ。
425デフォルトの名無しさん
2008/08/12(火) 08:25:15426デフォルトの名無しさん
2008/08/12(火) 10:38:25427デフォルトの名無しさん
2008/08/24(日) 00:05:28 gtkmm
428デフォルトの名無しさん
2008/08/25(月) 00:03:40 だれか、使いやすいのを作ってくれ
429デフォルトの名無しさん
2008/09/05(金) 22:59:18430デフォルトの名無しさん
2008/09/06(土) 00:25:07 >>429
> でも20代なんてカネ稼いでない層だろ。
え?
現役で「プログラマ」をやってるのは圧倒的に20〜30代が多い、でしょ?
少なくとも日本では。
業界にもよるが、基本的にプログラマは下っ端の兵隊で、高級なデベロッパが
ほとんど存在しないという文化だからね。
> でも20代なんてカネ稼いでない層だろ。
え?
現役で「プログラマ」をやってるのは圧倒的に20〜30代が多い、でしょ?
少なくとも日本では。
業界にもよるが、基本的にプログラマは下っ端の兵隊で、高級なデベロッパが
ほとんど存在しないという文化だからね。
431デフォルトの名無しさん
2008/09/06(土) 02:22:15432デフォルトの名無しさん
2008/09/06(土) 02:59:58 脱しようと今起業しているがなかなかプログラムだと稼げないね
今年入った収入は1万8千円
受注仕事やるといいんだろうが、起業している意味ないしなあ
今年入った収入は1万8千円
受注仕事やるといいんだろうが、起業している意味ないしなあ
433デフォルトの名無しさん
2008/09/06(土) 03:16:16 1万8千円って俺の月収より低いな
434デフォルトの名無しさん
2008/09/06(土) 10:49:21 携帯ゲームあたりだろうか
435デフォルトの名無しさん
2008/09/06(土) 23:25:16 WTL
436デフォルトの名無しさん
2008/11/07(金) 23:19:54 自作してみたいんだが、どうすればいい?
環境は WindowsXP で VC2008EE
環境は WindowsXP で VC2008EE
437デフォルトの名無しさん
2008/11/08(土) 01:28:14 既存APIのラッパーを作ることから始めてはどうか
438デフォルトの名無しさん
2008/11/08(土) 01:31:14 質問する段階なら、APIの薄いラップのみでいいんじゃない
物足りなくなったら、他のツールキットがどういうアーキテクチャになってるか
調べて取り入れるとか
あと、オレオレライブラリの類は、演習と割り切って作らないと前に進むのが遅くなるよ
結局、既存のツールキットを使ったほうが便利な場面も多いし
ってこのスレで言うことじゃないなw
物足りなくなったら、他のツールキットがどういうアーキテクチャになってるか
調べて取り入れるとか
あと、オレオレライブラリの類は、演習と割り切って作らないと前に進むのが遅くなるよ
結局、既存のツールキットを使ったほうが便利な場面も多いし
ってこのスレで言うことじゃないなw
439デフォルトの名無しさん
2008/11/08(土) 01:33:29 ボタンもリストも基本はWindow。その辺はググれば出てくる。
多くの人間が通る道として、それらをC++でラップしたコントロールを作る。
そしてメソッドで対応するのが面倒になり、GetHwnd()とか作ってごまかして終了する。
VC2008EEで生産性を追及してGUIを自作したいなら、個人的には
ResEditとかフリーのリソース作成ツールが吐き出したソースを
サポートする形にするのが良いかと。
多くの人間が通る道として、それらをC++でラップしたコントロールを作る。
そしてメソッドで対応するのが面倒になり、GetHwnd()とか作ってごまかして終了する。
VC2008EEで生産性を追及してGUIを自作したいなら、個人的には
ResEditとかフリーのリソース作成ツールが吐き出したソースを
サポートする形にするのが良いかと。
440デフォルトの名無しさん
2008/11/08(土) 17:29:15 ふむ、アドバイスdクス
まず、ラッパからやってみるよ。
できたら晒しにくるよ。
まず、ラッパからやってみるよ。
できたら晒しにくるよ。
441デフォルトの名無しさん
2008/11/08(土) 22:08:18442デフォルトの名無しさん
2008/11/08(土) 22:30:22 メンバ関数名にまでWindowは付けなくていい。
あとメッセージループもメンバ関数にしたらどうだろう。
エラーの原因はポインタの扱いだから、
その辺復習しながら作るといいよ。
あとメッセージループもメンバ関数にしたらどうだろう。
エラーの原因はポインタの扱いだから、
その辺復習しながら作るといいよ。
443デフォルトの名無しさん
2008/11/08(土) 23:43:45 久しぶりにネット繋いだらVC++6.0に怒濤のごとく更新入った
444デフォルトの名無しさん
2008/11/08(土) 23:53:16 >>442
アドバイス有難う。
うまく表示できた。
さて、ウィンドウの表示はできた。
次は、
LRESULT CALLBACK WindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
の中でしているのをどうするかだ。。。
ここで、メッセージループをしているのをどうにかしたい。
じゃないと、ラッパを作る意味がないきがする。
アドバイス有難う。
うまく表示できた。
さて、ウィンドウの表示はできた。
次は、
LRESULT CALLBACK WindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
の中でしているのをどうするかだ。。。
ここで、メッセージループをしているのをどうにかしたい。
じゃないと、ラッパを作る意味がないきがする。
445デフォルトの名無しさん
2008/11/09(日) 00:13:01 >>444
WindowインスタンスごとにVirtualAllocで確保した領域に
ECXにthisを入れてメンバのWndProcに飛ぶコードを動的生成して
それをRegisterClassExでコールバックとして渡しておく。
そうすればWindowsが直接メンバ関数を呼んでくれるようになる。
あとはそれをOnXXXとかのvirtualなハンドラに飛ばして、
必要に応じて外部に委譲させておけばおk。
WindowインスタンスごとにVirtualAllocで確保した領域に
ECXにthisを入れてメンバのWndProcに飛ぶコードを動的生成して
それをRegisterClassExでコールバックとして渡しておく。
そうすればWindowsが直接メンバ関数を呼んでくれるようになる。
あとはそれをOnXXXとかのvirtualなハンドラに飛ばして、
必要に応じて外部に委譲させておけばおk。
446デフォルトの名無しさん
2008/11/09(日) 01:47:00447デフォルトの名無しさん
2008/11/09(日) 02:04:48 とりあえず他でやって欲しい。
448デフォルトの名無しさん
2008/11/09(日) 02:05:45 マイナーGUI(ラッパか・・・)作ってるからいいんじゃね?
449デフォルトの名無しさん
2008/11/09(日) 02:27:18450デフォルトの名無しさん
2008/11/09(日) 02:41:11 私のレベルは、簡単なものならAPIをガリガリでモノを作れる。
MFCは使ったことなし。
>stdcallとcdeclは知っている?
これは名前は知っている。
>clのABIはthiscallでECXにthisが入るのは知っている?
これは、知らない。
cl・・・コンパイラ?
ABI・・・アプリケーション・バイナリー・インターフェイス?
thiscall ≒ cdecl?
ECX・・・アセンブリは全く知らない
つまり、アセンブリを知らないとできないってこと?orz
MFCは使ったことなし。
>stdcallとcdeclは知っている?
これは名前は知っている。
>clのABIはthiscallでECXにthisが入るのは知っている?
これは、知らない。
cl・・・コンパイラ?
ABI・・・アプリケーション・バイナリー・インターフェイス?
thiscall ≒ cdecl?
ECX・・・アセンブリは全く知らない
つまり、アセンブリを知らないとできないってこと?orz
451デフォルトの名無しさん
2008/11/09(日) 03:14:18 >>450
アセンブリと言っても別に難しい知識は必要ない。
C言語が使えるんなら、レジスタとスタックの操作、
つまりmovとpushくらいは3分でわかるはず。
そして引数がスタックに積まれることが理解できれば良い。
そのスタックをどこで戻すかの違いがstdcallとcdecl。
インスタンスメソッドに対してはインスタンスが引数として扱われる。
それがcl(VC++のコンパイラ)ではECXで渡されるということ。
ちなみにgccだと第一引数としてスタックに積まれる。
こういう呼び出し規約のことをABIと呼ぶ。
なぜこんな知識が必要か?
それはインスタンスメソッドに対してコールバックさせるため。
実際にATLではこの方法が使われている。
ハッシュで済ませるんなら必要ないんだけど、
外部に委譲させるときに悩むことになる。
アセンブリと言っても別に難しい知識は必要ない。
C言語が使えるんなら、レジスタとスタックの操作、
つまりmovとpushくらいは3分でわかるはず。
そして引数がスタックに積まれることが理解できれば良い。
そのスタックをどこで戻すかの違いがstdcallとcdecl。
インスタンスメソッドに対してはインスタンスが引数として扱われる。
それがcl(VC++のコンパイラ)ではECXで渡されるということ。
ちなみにgccだと第一引数としてスタックに積まれる。
こういう呼び出し規約のことをABIと呼ぶ。
なぜこんな知識が必要か?
それはインスタンスメソッドに対してコールバックさせるため。
実際にATLではこの方法が使われている。
ハッシュで済ませるんなら必要ないんだけど、
外部に委譲させるときに悩むことになる。
452デフォルトの名無しさん
2008/11/09(日) 03:23:19 ふと疑問に思って昔作ったGUIクラスをひっぱりだして覗いてみたら
SetWindowLong( hWnd, GWL_USERDATA, (int)this );
みたいな感じのを使ってた。ハンドルと32bitデータを関連付けられるらしい。
で、Windowプロシージャで
GetWindowLong( hWnd, GWL_USERDATA );
を使って、ハンドルから対応クラスのポインタをひっぱってきて
Window別のイベントを処理してた。なつかすぃ。
SetWindowLong( hWnd, GWL_USERDATA, (int)this );
みたいな感じのを使ってた。ハンドルと32bitデータを関連付けられるらしい。
で、Windowプロシージャで
GetWindowLong( hWnd, GWL_USERDATA );
を使って、ハンドルから対応クラスのポインタをひっぱってきて
Window別のイベントを処理してた。なつかすぃ。
453デフォルトの名無しさん
2008/11/09(日) 03:33:48 >>452
その方法だとたとえばウィンドウ上でIMEの入力をしているときに
候補の上でホイール回したりしてIMEが作ったhWndが飛んでくると
不正なポインタに飛ばすことになって落ちるよ。
結局、登録されたhWndかどうかチェックするとハッシュになってしまう。
その方法だとたとえばウィンドウ上でIMEの入力をしているときに
候補の上でホイール回したりしてIMEが作ったhWndが飛んでくると
不正なポインタに飛ばすことになって落ちるよ。
結局、登録されたhWndかどうかチェックするとハッシュになってしまう。
454デフォルトの名無しさん
2008/11/09(日) 07:15:09455デフォルトの名無しさん
2008/11/09(日) 09:30:36 同じくで、サンク作る方法は自分でも書いたことあったけども>>454の意味はちまちまわからんとこが。
ATLのソースか、エディタのGreenPadがそんな方法使ってたから見てみてもいいかも。
わかりにくい上に機械語直接埋め込むから試しに自分でラッパ書いてみる、って段階ではどうかと思うが、早いし。
ウィンドウハンドルとthisを関連づける方法はGWL_USERDATAの他にSetProp/GetPropAPIもある。
ttp://hp.vector.co.jp/authors/VA022575/c/msgmap.html
ttp://hilbert.elcom.nitech.ac.jp/~taki/program.html
一応この辺がその辺の話。
ATLのソースか、エディタのGreenPadがそんな方法使ってたから見てみてもいいかも。
わかりにくい上に機械語直接埋め込むから試しに自分でラッパ書いてみる、って段階ではどうかと思うが、早いし。
ウィンドウハンドルとthisを関連づける方法はGWL_USERDATAの他にSetProp/GetPropAPIもある。
ttp://hp.vector.co.jp/authors/VA022575/c/msgmap.html
ttp://hilbert.elcom.nitech.ac.jp/~taki/program.html
一応この辺がその辺の話。
456デフォルトの名無しさん
2008/11/09(日) 10:50:11 454だけど、実際にATLがどうやってるのかは>>455のリンク先が詳しいのでそっち見てね。
あと、WndProcからthisを手に入れる方法を適当にまとめてみた。他にも方法あるかも。
どこにHWND↔thisの対応を入れておくか
・Set/GetWindowLongPtrを使う(GWLP_USERDATAを使うのか、cbWndExtraで確保しとくのか)
・Set/GetPropを使う(キーは文字列かATOMか)
・ハッシュテーブルを使う(排他制御はどうすんのか)
・サンクを使う(CPUのアーキテクチャごとにry)
どのタイミングでHWND↔thisを関連づけるか
・WM_CREATEで(thisはCreateWindowの最後の引数か、グローバル変数から)
・最初にWndProcが呼ばれた段階で(thisはグローバル変数から)
・WH_CBTとかWH_CALLWNDPROCフックで(thisはグローバル変数から)
・そもそもWM_CREATEイラネ、CreateWindowを呼んだ後で
ただしグローバル変数にはTLSも含む
あと、WndProcからthisを手に入れる方法を適当にまとめてみた。他にも方法あるかも。
どこにHWND↔thisの対応を入れておくか
・Set/GetWindowLongPtrを使う(GWLP_USERDATAを使うのか、cbWndExtraで確保しとくのか)
・Set/GetPropを使う(キーは文字列かATOMか)
・ハッシュテーブルを使う(排他制御はどうすんのか)
・サンクを使う(CPUのアーキテクチャごとにry)
どのタイミングでHWND↔thisを関連づけるか
・WM_CREATEで(thisはCreateWindowの最後の引数か、グローバル変数から)
・最初にWndProcが呼ばれた段階で(thisはグローバル変数から)
・WH_CBTとかWH_CALLWNDPROCフックで(thisはグローバル変数から)
・そもそもWM_CREATEイラネ、CreateWindowを呼んだ後で
ただしグローバル変数にはTLSも含む
457デフォルトの名無しさん
2008/11/09(日) 12:24:53 いくつか意見がでてるけど、個人的にはハッシュが一番楽じゃない?と思う。
std::map<HWND,[基底クラスのポインタ]> g_controlList;
LRESULT CALLBACK WindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
基底クラス *p基底クラス = g_controlList[ hWnd ];
// コントロール別イベント処理
p基底クラス->OnEvent(msg, wParam, lParam);
}
最近C++書いてないんで色々間違ってそうだけど、キモはこんな感じかと。
ここは、より良い方法がでてきたら差し替えることにして
次へ進んだ方が本人の為になるし、スレ的にも面白いw
std::map<HWND,[基底クラスのポインタ]> g_controlList;
LRESULT CALLBACK WindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
基底クラス *p基底クラス = g_controlList[ hWnd ];
// コントロール別イベント処理
p基底クラス->OnEvent(msg, wParam, lParam);
}
最近C++書いてないんで色々間違ってそうだけど、キモはこんな感じかと。
ここは、より良い方法がでてきたら差し替えることにして
次へ進んだ方が本人の為になるし、スレ的にも面白いw
458デフォルトの名無しさん
2008/11/09(日) 13:50:14 >>454
インスタンスごとにクラスを登録しているのはWindows Formsだね。
インスタンスごとにクラスを登録しているのはWindows Formsだね。
459デフォルトの名無しさん
2008/11/09(日) 18:40:07 この流れを見てるとこのスレの住人はやっぱり結構自分ラッパを書いてしまっているんだなあと感じて親近感がw
しかし>>450は付いてきているのか。周りが凄い盛り上がってしまってるけど。
しかし>>450は付いてきているのか。周りが凄い盛り上がってしまってるけど。
460デフォルトの名無しさん
2008/11/09(日) 21:38:28 >>450は単語一個一個調べたり、根が真面目そうなんで、
今、大量の情報がドカドカ出てきたので知らん部分をググってる最中じゃない?
期待がプレッシャーにならない程度にマターリ待つのが良いかと。
俺もラッパ作ちゃった1人なんだが、結局デザイナーツールの作成が面倒で
活用には至らなかった。
その辺までしっかり作った人っているの?
今、大量の情報がドカドカ出てきたので知らん部分をググってる最中じゃない?
期待がプレッシャーにならない程度にマターリ待つのが良いかと。
俺もラッパ作ちゃった1人なんだが、結局デザイナーツールの作成が面倒で
活用には至らなかった。
その辺までしっかり作った人っているの?
461デフォルトの名無しさん
2008/11/10(月) 00:28:53 なぁ、>445 の方法って、ネットで探しても情報ないのな。
ATLのソース読んでみようと思ったけど、どこから読んだらいいのかわかんねw
>450 は初心者っぽいしきつい気がするのは俺だけか?
そういや、昔、CマガでGUIライブラリを作るってのがあったが
あれは参考にならないか?
もう、手に入らないけど。
ATLのソース読んでみようと思ったけど、どこから読んだらいいのかわかんねw
>450 は初心者っぽいしきつい気がするのは俺だけか?
そういや、昔、CマガでGUIライブラリを作るってのがあったが
あれは参考にならないか?
もう、手に入らないけど。
462デフォルトの名無しさん
2008/11/10(月) 02:05:47463デフォルトの名無しさん
2008/11/10(月) 06:11:25464デフォルトの名無しさん
2008/11/10(月) 07:58:51 『組み込みGUI(ウィンドウ・システム)環境の設計と実装』って本
読んだことある人います? おもしろい?
読んだことある人います? おもしろい?
465デフォルトの名無しさん
2008/11/10(月) 08:11:08466デフォルトの名無しさん
2008/11/10(月) 13:35:58467デフォルトの名無しさん
2008/11/10(月) 15:47:24 >>464
フレームバッファ直描きでウィンドウシステムを作る本だよ。
OSを作ったりとか、LinuxでXを使わないGUIを作ったりとか、
そういうことに興味がある人には面白いと思う。
Windowsアプリを作るのにはほとんど参考にならない。
フレームバッファ直描きでウィンドウシステムを作る本だよ。
OSを作ったりとか、LinuxでXを使わないGUIを作ったりとか、
そういうことに興味がある人には面白いと思う。
Windowsアプリを作るのにはほとんど参考にならない。
468デフォルトの名無しさん
2008/11/10(月) 21:28:35 一つずつ
>>451
>つまりmovとpushくらいは3分でわかるはず。
mov・・・ジスタやメモリに、データの転送を行う
push・・・スタックにデータを積む
>そのスタックをどこで戻すかの違いがstdcallとcdecl。
このことでいいのかな?
ttp://www.ne.jp/asahi/nagoya/ahomaro/builder/cpb-055.html
>ECX
レジストリと
こんな場所がある、程度でいいのかな?
>>451
>つまりmovとpushくらいは3分でわかるはず。
mov・・・ジスタやメモリに、データの転送を行う
push・・・スタックにデータを積む
>そのスタックをどこで戻すかの違いがstdcallとcdecl。
このことでいいのかな?
ttp://www.ne.jp/asahi/nagoya/ahomaro/builder/cpb-055.html
>ECX
レジストリと
こんな場所がある、程度でいいのかな?
469デフォルトの名無しさん
2008/11/10(月) 21:32:35470デフォルトの名無しさん
2008/11/10(月) 21:34:28471デフォルトの名無しさん
2008/11/10(月) 22:41:30472デフォルトの名無しさん
2008/11/11(火) 17:08:05 WindowsXP SP2のDEPでATLのThunkが問題になってたような気がするんだけど、
あれは何でなんだろ?
あれは何でなんだろ?
473デフォルトの名無しさん
2008/11/11(火) 17:22:32 >>472
ウィルス等がバッファオーバーフローでヒープに不正コードを埋め込むことの対策として
ヒープのコードを実行できなくしたのがDEP。
ATLではサンクをHeapAlloc領域でやっていたため引っ掛かることになった。
今のATLはVirtualAllocでPAGE_EXECUTE_READWRITEで確保するため問題ない。
ウィルス等がバッファオーバーフローでヒープに不正コードを埋め込むことの対策として
ヒープのコードを実行できなくしたのがDEP。
ATLではサンクをHeapAlloc領域でやっていたため引っ掛かることになった。
今のATLはVirtualAllocでPAGE_EXECUTE_READWRITEで確保するため問題ない。
475デフォルトの名無しさん
2008/11/13(木) 03:52:36 おまえら!
言いたいのをガマンしてるなら、代わり俺が言ってやるよ!
あくまでもおまえらの代弁だからな!俺が言いたいワケじゃないんだからな!
なるほど、わかりやすい説明Thunkです。
言いたいのをガマンしてるなら、代わり俺が言ってやるよ!
あくまでもおまえらの代弁だからな!俺が言いたいワケじゃないんだからな!
なるほど、わかりやすい説明Thunkです。
476デフォルトの名無しさん
2008/11/13(木) 07:05:21 さみぃw
477デフォルトの名無しさん
2008/11/17(月) 23:11:46 こんな方法どうやって勉強しました?
478デフォルトの名無しさん
2008/11/18(火) 22:33:44 >>477
Windows 3.1の頃(15年前)からプログラム作ってたら嫌でも身に付く
Windows 3.1の頃(15年前)からプログラム作ってたら嫌でも身に付く
479デフォルトの名無しさん
2008/11/19(水) 18:52:55 class window
{
public:
static window *m_this;
static LRESULT CALLBACK StartWindowProc(HWND, UINT, WPARAM, LPARAM); //スタートアップ
static LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM); //本命
HWND SetHandle(HWND hwnd);//ウインドウハンドルを設定する
void Create();//ここでクリティカルセクションを設定してCreateWindowを呼ぶ
}
window *m_this;
LRESULT CALLBACK window::StartWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
window *pThis = window::m_this;
window::m_this = NULL;
//ここでクリティカルセクションを取り除く
::SetProp(hwnd, _T("THISCLASS"), (HANDLE)pThis);
pThis->SetHandle(hwnd);
::SetWindowLongPtr(hwnd, GWL_WNDPROC, (LONG)window::WindowProc);
return window::WindowProc(hwnd, msg, wParam, lParam);
}
かなりふざけた方法だけど...
俺はこんな感じでやってる...
{
public:
static window *m_this;
static LRESULT CALLBACK StartWindowProc(HWND, UINT, WPARAM, LPARAM); //スタートアップ
static LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM); //本命
HWND SetHandle(HWND hwnd);//ウインドウハンドルを設定する
void Create();//ここでクリティカルセクションを設定してCreateWindowを呼ぶ
}
window *m_this;
LRESULT CALLBACK window::StartWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
window *pThis = window::m_this;
window::m_this = NULL;
//ここでクリティカルセクションを取り除く
::SetProp(hwnd, _T("THISCLASS"), (HANDLE)pThis);
pThis->SetHandle(hwnd);
::SetWindowLongPtr(hwnd, GWL_WNDPROC, (LONG)window::WindowProc);
return window::WindowProc(hwnd, msg, wParam, lParam);
}
かなりふざけた方法だけど...
俺はこんな感じでやってる...
480デフォルトの名無しさん
2008/12/01(月) 20:53:23 何となく、自分も昔作ったGUIを晒してみようとサンプル動かしてみたら、
リストビューを拡張して作ろうとしたらしいGridViewがいきなりバグってた。
出直してきます。orz
リストビューを拡張して作ろうとしたらしいGridViewがいきなりバグってた。
出直してきます。orz
481デフォルトの名無しさん
2009/01/12(月) 01:32:46482デフォルトの名無しさん
2009/01/28(水) 13:05:32 保守あげ
483デフォルトの名無しさん
2009/01/31(土) 16:42:03 ATLを使うと勝手に各アーキテクチャごとにthunk作ってくれる。
使い方は↓のようなかんじです。
class HogeWindow {
ATL::CStdCallThunk thunk;
HWND hWnd;
static LRESULT CALLBACK redirect(T* object, UINT msg, WPARAM wParam, LPARAM lParam) {
return object->WindowProcedure(msg, wParam, lParam);
}
LRESULT WindowProcedure(UINT m, WPARAM w, LPARAM l) {
(処理)
}
HogeWindow() {
(HWNDを作る)
thunk.Init((DWORD_PTR)redirect, this);
SetWindowLongPtr(hWnd, GWL_WNDPROC, (LONG_PTR)thunk.GetCodeAddress());
}
};
使い方は↓のようなかんじです。
class HogeWindow {
ATL::CStdCallThunk thunk;
HWND hWnd;
static LRESULT CALLBACK redirect(T* object, UINT msg, WPARAM wParam, LPARAM lParam) {
return object->WindowProcedure(msg, wParam, lParam);
}
LRESULT WindowProcedure(UINT m, WPARAM w, LPARAM l) {
(処理)
}
HogeWindow() {
(HWNDを作る)
thunk.Init((DWORD_PTR)redirect, this);
SetWindowLongPtr(hWnd, GWL_WNDPROC, (LONG_PTR)thunk.GetCodeAddress());
}
};
484デフォルトの名無しさん
2009/03/21(土) 03:51:43 SOL9をVC++2008SP1で試してみた。
>c:\usr\include\sol\window.h(68) : error C2664: 'GetClassNameW' : 2 番目の引数を 'char *' から 'LPWSTR' に変換できません。(新しい機能 ; ヘルプを参照)
1> 指示された型は関連がありません。変換には reinterpret_cast、C スタイル キャストまたは関数スタイルのキャストが必要です。
(面倒だから全部は乗せない)
こんなエラーが大量に出てきた。
これって、VC++2008SP1では使えないのか?
>c:\usr\include\sol\window.h(68) : error C2664: 'GetClassNameW' : 2 番目の引数を 'char *' から 'LPWSTR' に変換できません。(新しい機能 ; ヘルプを参照)
1> 指示された型は関連がありません。変換には reinterpret_cast、C スタイル キャストまたは関数スタイルのキャストが必要です。
(面倒だから全部は乗せない)
こんなエラーが大量に出てきた。
これって、VC++2008SP1では使えないのか?
485デフォルトの名無しさん
2009/03/21(土) 07:50:26486デフォルトの名無しさん
2009/03/22(日) 02:27:38487デフォルトの名無しさん
2009/03/22(日) 02:29:43 SOL9って何?
Solaris9??
Solaris9??
488デフォルトの名無しさん
2009/03/22(日) 02:34:23489デフォルトの名無しさん
2009/03/22(日) 15:53:22 使いやすいのない?
490デフォルトの名無しさん
2009/05/20(水) 19:07:36 ほしゅ
491デフォルトの名無しさん
2009/07/10(金) 06:59:47 Qt LGPL版が出ました。
492デフォルトの名無しさん
2009/07/19(日) 07:23:32 gtkmm一択
493デフォルトの名無しさん
2009/07/19(日) 13:17:11 >>491
10 年前にその選択をしてればな…
10 年前にその選択をしてればな…
494デフォルトの名無しさん
2009/08/04(火) 21:50:27 マイナー用のこのスレで聞くのもどうかと思うけど、
OSSプロジェクトで一番使われているマルチプラットフォーム対応の
C++ GUIツールキットってどれでしょうか?
wxWidgetsとQtはどっちの方が使われてるのかな?
OSSプロジェクトで一番使われているマルチプラットフォーム対応の
C++ GUIツールキットってどれでしょうか?
wxWidgetsとQtはどっちの方が使われてるのかな?
495デフォルトの名無しさん
2009/08/08(土) 08:10:43 fltk
496デフォルトの名無しさん
2009/08/09(日) 13:16:20 今からクロス開発するならQtのほうがよさげ。
497デフォルトの名無しさん
2009/08/09(日) 13:31:27 >>496
できれば理由も聞きたい
できれば理由も聞きたい
498デフォルトの名無しさん
2009/08/09(日) 14:18:48 Qtのほうが作りやすい。API綺麗だし開発ツールも充実してるから。この辺さすが商用は強い。
wxは古臭さ複雑さを隠し切れんな。元がMFCを参考にしているからな。もう限界だろ。
個人的にQPLか高い商用ライセンスがキライだっただけで
今QtをLGPLで使えるなら選択しない理由はあまりないな。
wxの強みはドマイナーなOS環境まで考慮されてることだけど、別にそこまで使わんしw
wxは古臭さ複雑さを隠し切れんな。元がMFCを参考にしているからな。もう限界だろ。
個人的にQPLか高い商用ライセンスがキライだっただけで
今QtをLGPLで使えるなら選択しない理由はあまりないな。
wxの強みはドマイナーなOS環境まで考慮されてることだけど、別にそこまで使わんしw
499デフォルトの名無しさん
2009/08/09(日) 19:49:08 Qtは微妙な独自色がなければ最高なのに。qmakeとかLinguistとかWindowsのUIとか。
500デフォルトの名無しさん
2009/08/14(金) 20:53:50 500
501デフォルトの名無しさん
2009/09/05(土) 08:41:35 Lily C++ GUI Library
ttp://kengolab.net/lily/lily_download.html
windows専用らしい
ttp://kengolab.net/lily/lily_download.html
windows専用らしい
502デフォルトの名無しさん
2009/09/09(水) 10:32:56 >windows専用らしい
イミネーwww
イミネーwww
503デフォルトの名無しさん
2009/09/09(水) 17:37:53 仮にただのMFCラッパーだとしても、使い勝手がよければそこに意味はあるはずだ
あとこのスレって別にマルチプラットフォーム限定ってわけでもないっしょ?
あとこのスレって別にマルチプラットフォーム限定ってわけでもないっしょ?
504デフォルトの名無しさん
2009/09/09(水) 20:51:20 ぺたぺた貼れるなら、使い勝手うんぬん言えるが、できないじゃんwwwww
505デフォルトの名無しさん
2009/09/12(土) 16:58:33 ペロッ
この味は・・・PHPer!
この味は・・・PHPer!
506本田
2009/09/26(土) 17:53:33 Object Windows Library
Inprise/Borland
http://cc.codegear.com/partners/bcb5/exclusive/object_windows_library/index.html
This release of the Object Windows Library is based on the OWL 5.4
release and is denoted as OWL 5.5.
It has been ported to Borland C++Builder 5 by Yura Bidus, author of OWLNExt.
It includes source code and debug and release libraries of, OWL, BIDS and OCF.
Inprise/Borland
http://cc.codegear.com/partners/bcb5/exclusive/object_windows_library/index.html
This release of the Object Windows Library is based on the OWL 5.4
release and is denoted as OWL 5.5.
It has been ported to Borland C++Builder 5 by Yura Bidus, author of OWLNExt.
It includes source code and debug and release libraries of, OWL, BIDS and OCF.
507本田
2009/09/27(日) 12:40:46 >>506
~ OWLNext project home ~
http://owlnext.sourceforge.net/
~ About OWLNext ~
http://owlnext.sourceforge.net/about.html
Advantages of using OWLNext:
* OWLNext is an object-oriented framework, built on top of the Windows API without adding much overhead.
* OWLNext is pure C++ library, which does not use any vendor- or compiler- specific extensions.
* OWLNext fully supports developing Unicode applications.
* OLE, OCX and ActiveX support (server and consumer)
* OWLNext can be used with wide range of C++ compilers. Currently it is tested with
o CodeGear Developer Studio 2007 and 2009
o Borland Developer Studio 2006
o Borland C++ Builder 6.0
o Borland Free C++ Compiler 5.5
o Borland C++ 5.01/5.02
o Microsoft Visual C++ 2003, 2005, 2008
o Microsoft Visual C++ 6.0
Also in the past it has been working with Borland C++ Builder 1.0-5.0, Microsoft Visual C++ 5.0 and GCC and has been ported to Linux using WINE
* OWLNext offers easy upgrade path for porting legacy OWL applications to modern compilers and operating systems.
* OWLNext is open-source project, it's based on contributions and directions from it's community
~ OWLNext project home ~
http://owlnext.sourceforge.net/
~ About OWLNext ~
http://owlnext.sourceforge.net/about.html
Advantages of using OWLNext:
* OWLNext is an object-oriented framework, built on top of the Windows API without adding much overhead.
* OWLNext is pure C++ library, which does not use any vendor- or compiler- specific extensions.
* OWLNext fully supports developing Unicode applications.
* OLE, OCX and ActiveX support (server and consumer)
* OWLNext can be used with wide range of C++ compilers. Currently it is tested with
o CodeGear Developer Studio 2007 and 2009
o Borland Developer Studio 2006
o Borland C++ Builder 6.0
o Borland Free C++ Compiler 5.5
o Borland C++ 5.01/5.02
o Microsoft Visual C++ 2003, 2005, 2008
o Microsoft Visual C++ 6.0
Also in the past it has been working with Borland C++ Builder 1.0-5.0, Microsoft Visual C++ 5.0 and GCC and has been ported to Linux using WINE
* OWLNext offers easy upgrade path for porting legacy OWL applications to modern compilers and operating systems.
* OWLNext is open-source project, it's based on contributions and directions from it's community
508デフォルトの名無しさん
2009/09/27(日) 13:03:16 何だ、クロスプラットフォームじゃないのか…
509デフォルトの名無しさん
2009/09/27(日) 13:47:44 クロスプラットフォームとかいらんだろ
510デフォルトの名無しさん
2009/09/27(日) 16:06:52 クロスプラットフォームじゃなかったら何の意味が?
511デフォルトの名無しさん
2009/09/27(日) 20:08:34 WINEで動けば充分
> has been ported to Linux using WINE
> has been ported to Linux using WINE
512本田
2009/09/27(日) 20:39:01 >>508
Object Windows Library
http://en.wikipedia.org/wiki/Object_Windows_Library
In 1993 Borland launched Borland C++ 2.0 for OS/2 which included a version of OWL 2.0.
OWL 2.0 used BIDS, the newer template library for 'container' or 'class library'.
In January 1994 Borland launched Borland C++ 4.0 for Windows which also included OWL 2.0.
It added Doc/View support, VBX controls, OLE. Win16, Win32s and Win32 was supported
(Windows 95, the Win32 successor of Windows 3.x appeared in August 1995).
Late in 1994, Novell CEO Raymond Noorda resigned.
Novell expansion plans were reconsidered,
AppWare development was stopped and so was OWL for AppWare.
In 1995 a group of original team members bought AppBuilder.
In the same year, Software UNO (www.uno.com) offered a commercial port for OWL 2.0,
to several platforms:
AIX 3.2.5, DEC Alpha OSF/1, HP-UX 9.03, Linux 1.2, Solaris 2.x, Sun OS 4.1.x, and SVR4 fox x86,
it was called WM_MOTIF.
Object Windows Library
http://en.wikipedia.org/wiki/Object_Windows_Library
In 1993 Borland launched Borland C++ 2.0 for OS/2 which included a version of OWL 2.0.
OWL 2.0 used BIDS, the newer template library for 'container' or 'class library'.
In January 1994 Borland launched Borland C++ 4.0 for Windows which also included OWL 2.0.
It added Doc/View support, VBX controls, OLE. Win16, Win32s and Win32 was supported
(Windows 95, the Win32 successor of Windows 3.x appeared in August 1995).
Late in 1994, Novell CEO Raymond Noorda resigned.
Novell expansion plans were reconsidered,
AppWare development was stopped and so was OWL for AppWare.
In 1995 a group of original team members bought AppBuilder.
In the same year, Software UNO (www.uno.com) offered a commercial port for OWL 2.0,
to several platforms:
AIX 3.2.5, DEC Alpha OSF/1, HP-UX 9.03, Linux 1.2, Solaris 2.x, Sun OS 4.1.x, and SVR4 fox x86,
it was called WM_MOTIF.
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- なぜリベラルは人気がないのか 斎藤幸平さんが指し示す未来への道筋:朝日新聞 ★4 [少考さん★]
- 鈴木農相「おこめ券はお米しか買えないわけではない。例えば卵、味噌、しょうゆ、こうした購入に利用可能」 ★3 [Hitzeschleier★]
- 三谷幸喜氏 温泉嫌いの理由を熱弁「知らない人の股間を素通りしたお湯なんですよ」「おじさんの肛門を通り過ぎたお湯が自分の前に」 [Ailuropoda melanoleuca★]
- 「ヒートテックに寿命があります」ユニクロが明かした“3年劣化”の理由 暖かさが落ちる意外な原因とは [ぐれ★]
- 【名古屋】警備員にけがをさせ逃走 刻みネギのパックをエコバッグに入れる姿を見て声をかけたところ… 女は20代ぐらい 南へ逃走 [煮卵★]
- サナエノミクスについて力説 積極的な財政出動で「所得増える 消費マインド上がる 税収増える」片山さつき財務大臣 [少考さん★]
- 他サポ2025-301
- 他サポ2025-300
- 阪神競馬5回4日目 阪神JF
- 【NJPW】新日本プロレスワールド part.2431
- 第80回甲子園ボウル 立命館大学 vs 関西学院大学★1
- 中山競馬5回4日目その2カペラエス
- 【神展開】安倍晋三「高市早苗からわーくにを救うために私は地獄からカムバックいたしました」 [517791167]
- 喜多川海夢(その着せ替え人形は恋をする)純白ドレスでプライズのフィギュア化キタ━━━━(゚∀゚)━━━━!!​ [395563314]
- 喜多川海夢​(その着せ替え人形は恋をする)純白ドレスでプライズのフィギュア化キタ━━━━(゚∀゚)━━━━!!​ [395563314]
- 喜多川海夢(その着せ替え人形は恋をする)水着シーンのフィギュア化キタ━━━━(゚∀゚)━━━━! [723839345]
- ワイ32歳Fラン文系卒都内「年収550万です」←どうなん?
- あ、出ちゃう、イクッ😫💦🏡
