今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net

[過去ﾛｸﾞ] 今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

396(60): 2018/02/17(土)16:26 ID:KjUUJ1nJ(1/9) AAS
Wineは、Desktopの直接の子であるような、Win32における「OVERLAPED WINDOW」
的な物しか、XWindow の Window を作らないのだろうか？？
Wineのソースをダウンロードして、FIXME(WARNでもいいはずだけど)で実行を調べてみた。
でも、良く分からない。ビルドとmake installに時間がかかるため、大変。
本当はもっと実験したいんだけど、時間的に難しくなる。

ソースを見ると、HWNDの親が Desktopの場合にだけ、XCreateWindowしているように
見える。これが、透明ウィンドウが遅くなる理由かもしれない。LinuxのNativeなWindowの
場合、実験した限り透明にしても速度が余り変わらない。でも、Wineがもし、自前で透明処理
をやっているとなれば遅くなるのも頷けるが。

1つのソースしか修正してないのに、ビルドが始まるまでに数十秒かかる。make installに
省2

397(1): 2018/02/17(土)16:41 ID:eqmjcJnH(1/2) AAS
>>396
>ソースを見ると
どこだかわからんから外部ﾘﾝｸ:source.winehq.orgのリンク貼ってくれ

415(3): 396 2018/02/18(日)01:13 ID:DznsC7ZZ(1) AAS
WINEにおいて、

1. MDIのCMDIChildWndのCViewのCLIENT領域全体(子ウィンドウの
　中全体と言ってもよい) に >>409の1.の色を塗って、完全透明
　にしている時は、CMDIChildWndのタイトルバー(子ウィンドウの
　タイトルバー）をドラッグしても高速に動かせる。

2. 1のCViewの中に、pDC->LineTo()で直線を一本描いた状態にしてから
　同じ事をしようとすると、とても遅くなる。

3. 2.は、直線の代わりに pDC->TextOut() で文字を描いても同様に遅く
　なる。

4. 推定では、Wineは、Win32のCreateWindow系で、Parent Window が
省11

424: 396 2018/02/18(日)14:19 ID:HH6qVqdM(7/9) AAS
>>418 さんの指摘は凄く役立ちました。有難うございます。

ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
>矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。

「X側の描画性能の低下」が原因ではなく、「ピクセル値を比較する処理」自体が、
実は「静止状態」でも、常時、大幅に増加していた、ということです。

何の変化がないときにでも、百万ピクセルを比較し、ランレングスを導き出す処理を、
原則的には秒間20回もやっています。

また、図形が複雑だと、システムコールを呼び出す回数がランレングスの変化の回数倍
省7

425(2): 396 2018/02/18(日)14:38 ID:HH6qVqdM(8/9) AAS
【厳密化】

1. 多分、6,000回ではなく、4,500回程度でした。
2. 比較処理自体は、図形の複雑さとは無関係にほぼ一定の重さです。
3. 図形が複雑な場合、システムコールの回数が増えます。
4. 横方向の1つのランレングスで、3つのシステムコールが呼ばれます。
5. 図形が何も描かれていない場合、1つのy座標に対して、1つのランレングスです。
6. N 本の直線の場合、大体で言えば、3N 個のランレングスになります。
7. だから、1つのy座標に対し、9N 個のシステムコールが呼ばれることになります。
8. 縦 500 ドットの場合、500*9N = 4500 N 回のシステムコールとなります。
9. よって、中に描かれている直線の本数が増えると、大体 O(N) で処理時間が
省2

426: 396 2018/02/18(日)15:25 ID:HH6qVqdM(9/9) AAS
>>425
【訂正】
「6.」のランレングスの個数は、3N個ではなく、2N+1 個でした。

お騒がせしました。

428(1): 396 2018/02/18(日)17:01 ID:hqeoLLBF(1) AAS
>>427
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。

少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。

429: 396 2018/02/19(月)12:40 ID:v4nZjJQ1(1/2) AAS
特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。

430: 396 2018/02/19(月)15:28 ID:v4nZjJQ1(2/2) AAS
調べてみると、/wine/libs/wine/loader.c の中の build_dll_path()
関数の中で、環境変数 WINEDLLPATH が、読み取られ、: を 0x00に
変えてから、dll_paths[] 配列に : で区切られたそれぞれの文字列
の先頭アドレスを代入している。

しかし、その処理に入る前に、get_dlldir() 関数が NULL 以外を返した場合、
dll_paths[0] にその関数が返した文字列のアドレスを入れてしまう。

そして、実際の get_dlldir() は、"/usr/local/bin/../lib/wine"
という文字列を返してくるので、そっちのパスの方が、WINEDLLPATH
の優先順位よりも上になってしまう。そして、

/* retrieve the default dll dir */
省10

432: 396 2018/02/19(月)19:22 ID:WuPPo4Ry(1) AAS
loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。

433(1): 396 2018/02/20(火)03:10 ID:nCkYsCc8(1/4) AAS
surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。

434: 396 2018/02/20(火)05:59 ID:nCkYsCc8(2/4) AAS
DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。

なお、>>433は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。

なぜ遅いままなのかは謎です。

437: 396 2018/02/20(火)18:49 ID:nCkYsCc8(3/4) AAS
遅い原因の1つは、Onldle の中にあることが分かりました。

1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
　それがとんでもなく重い事が判明。

2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
　が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
　出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
　 10*N 回呼び出されるような感じです。タイマーメッセージがくる度に、
　メニューなどを更新するためのメッセージが来ているような気がします。
　多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
　ならないんじゃないかと思います。通常、OnCmdMsg は頻度が低いことが
省7

442: 396 2018/02/20(火)20:06 ID:ErFPSqeX(1) AAS
結論だけ書いておくと、surfaceが非NULLの時の LineTo の実体は、
windrv_LineToで、surface を lock する以外は、dibdrv_LineTo と同じ。
dibdrv_LineToは、bits なるpixel配列に 32BITの色値を書き込む。
実際は汎用性のため、必ずandしてからxorする。SOLIDモードの場合、and値は0。
xor値は、00RRGGBB で、最上位バイトは0。
実際への画面の反映は、定期的に「xxx->flush」なる関数ポインタを介して、
x11drv_surface_flush() を呼び出す事で行う。その中で、議題になっている
update_surface_region() も呼ばれる。最後に bits の内容を実画面に反映させる
ため、XShmPutImage()または、XPutImage(), XFlush()を行う。

surface->image の pixel バッファは、bits[] 配列と共通らしい。
省2

443(1): 396 2018/02/21(水)16:48 ID:SJPTXnf1(1/13) AAS
update_surface_region() が遅いんだと思って、
XShape の作成を、XShapeCombineRectangles() を使う方式から、
XCreateBitmapFromData() と XShapeCombineMask()
を使う方式へと変えた。

すると、1146 x 745 のサイズの Window で、

1. 自前のコードによる 1bit の mask bitmap 作成にかかる時間 :
796 (us)

2. XCreateBitmapFromData() と XShapeCombineMask() にかかる時間 :
38 (us)

3. XShmPutImage() と XFlush() ; x11drv_surface_flush()内の両方にかかる時間 :
省10

446: 396 2018/02/21(水)17:35 ID:SJPTXnf1(3/13) AAS
>>445
それは、
>>427-428
の部分と深く関係しています。

449(2): 396 2018/02/21(水)17:57 ID:SJPTXnf1(5/13) AAS
AA省

450(1): 396 2018/02/21(水)17:58 ID:SJPTXnf1(6/13) AAS
AA省

451: 396 2018/02/21(水)18:24 ID:SJPTXnf1(7/13) AAS
>>448
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。

455(1): 396 2018/02/21(水)18:58 ID:SJPTXnf1(11/13) AAS
元々の Windows では、LineTo などを実行すると瞬間的に実画面に反映される。
だから、そもそも Flush せずに見えないままの描画が残っているなんて時間は
ほぼ 0。

そう考えると、。Wine のこの実装はおかしいな・・・。

1. そもそもメッセージループを回している時しか flush される可能性が全くない
　実装になってしまっているらしい。

2. メッセージループを回していても、メッセージがキューに残っている時は、
　 100回程度メッセージを読まない限り、flush されない。

Windows を「エミュレート」するのであれば、例えば、描いてから 50(ms) 経てば、
必ず flush する、という実装でなくてはならないはず。
省1

459: 396 2018/02/21(水)23:23 ID:4g3iPm6d(1/2) AAS
うーんと。それはまあちょっと置いておいて、、、。

MDI Child Wnd の TITLE BAR を Drag している最中、メッセージループは一つも
回ってないんじゃないかと思う。

だから、>>455 の「1.」に書いた「flushされる必要条件」が満たされてない。

そのため、surface の pixel配列の内容が実画面に反映されないのではなかろうか。

460: 396 2018/02/21(水)23:38 ID:4g3iPm6d(2/2) AAS
ドラッグ中にマウスを静止させてしばらく待っていると、 x11drv_surface_flush() と
flush_surface_region() の両方が呼び出された事が FIXME 出力で確認できた。
静止させずにマウスをドラッグし続けると、FIXME 出力が全くでない。
しかも、それを行った時間が長いと、マウスボタンを離した後も、非常に長い間
システム全体がハングアップした様な状態になる。そして、長い沈黙の後、FIXME出力が
出る。

この沈黙の時間は、それまでドラッグしていた時間に比例しているように思える。

なぜだろう？？？　これはどこかに「何かが溜まっている」時の現象の様に思える。
しかし、>>449 を見ると、message_cnt は、減らされるときは、一期に 0 になるのであって、
少しずつ減らされるわけではない。
省1

463: 396 2018/02/22(木)00:35 ID:9+xI5ulA(1/17) AAS
AA省

464: 396 2018/02/22(木)00:45 ID:9+xI5ulA(2/17) AAS
あるいは、Peek されるだけで、一部のメッセージは取り残されるなら・・・。

465(1): 396 2018/02/22(木)01:30 ID:9+xI5ulA(3/17) AAS
Wine で、MDI Child Wnd の TITLE BAR をドラッグしたときの処理について。

DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_NCLBUTTONDOWN
-->NC_HandleNCLButtonDown()
-->case HTCAPTION
-->SendMessageW( hwnd, WM_SYSCOMMAND, SC_MOVE + HTCAPTION, lParam )
-->DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_SYSCOMMAND
-->NC_HandleSysCommand()
-->WINPOS_SysCommandSizeMove()
省15

466(1): 396 2018/02/22(木)01:32 ID:9+xI5ulA(4/17) AAS
さらに次のような、枠だけを書くか、実際に動かしてしまうコードが続く :

if (!DragFullWindows)
draw_moving_frame( parent, hdc, &sizingRect, thickframe );
else {
RECT rect = sizingRect;
MapWindowPoints( 0, parent, (POINT *)&rect, 2 );
SetWindowPos( hwnd, 0, rect.left, rect.top,
rect.right - rect.left, rect.bottom - rect.top,
( hittest == HTCAPTION ) ? SWP_NOSIZE : 0 );
}

467: 396 2018/02/22(木)02:01 ID:9+xI5ulA(5/17) AAS
あー。

FIXMEを消してしまっていただけだった・・・。

update_surface_region() や、flush_window_surfaces() は、
ドラッグ中でも、マウスを静止してしばらくすると呼ばれるようです。
マウスを動かしつづけていると呼ばれないらしい。

468(2): 396 2018/02/22(木)02:44 ID:9+xI5ulA(6/17) AAS
【やっと原因判明】

CMainFrame を WS_EX_LAYERED で透明化していて、今回の条件に当てはまる時に、
CMDIClientWnd のタイトルバー上でマウスの左ボタンを押し始め、そのまま
マウスをずっと動かし続けると、WINPOS_SysCommandSizeMove() の中の

if (!GetMessageW( &msg, 0, 0, 0 )) break;

の部分の GetMessageW() 関数の中で停止してしまう。詳細は、GetMessageW() の
中で、メッセージキューが空だった場合に呼び出されるところの、

wait_objects()　　　 ;dlls/user32/message.c
-->wow_handlers.wait_message()
-->wait_message()　　;dll/user32/winproc.c
省5

469(1): 396 2018/02/22(木)10:45 ID:9+xI5ulA(7/17) AAS
AA省

470: 396 2018/02/22(木)10:46 ID:9+xI5ulA(8/17) AAS
【通常時、WM_MOUSEMOVE がキューへ追加される時の実行経路】

X11DRV_MsgWaitForMultipleObjectsEx()
--> process_events()
---> call_event_handler( Display *display, XEvent *event )
---> handlers[event->type]( hwnd, event );
event->type = MotionNotify (6)
---> X11DRV_MotionNotify( HWND hwnd, XEvent *xev )
XMotionEvent *event = &xev->xmotion;
INPUT input;
---> send_mouse_input( hwnd, event->window, event->state, &input );
省21

471: 396 2018/02/22(木)10:47 ID:9+xI5ulA(9/17) AAS
AA省

473: 396 2018/02/22(木)16:31 ID:9+xI5ulA(11/17) AAS
Msg が付く方の WaitXxxx で、usleep() で、0.3秒ほど停止しながら、
Polling (Loop) するようにしてから、FIXMEでメッセージを観察してみた。
普段は、usleep() 命令は、呼び出してから 0.3 秒で戻ってくる。
ところが、先日からの遅くなる条件でドラッグし続けた場合、単純な usleep() の
1命令が、呼び出してから、永久に戻ってこなくなる。ドラッグをやめると、
人間が長く感じるほどの長い時間が経過してから戻ってくる。

これは、WINEの問題ではなく、Linux Kernel の問題だろうか？？？

474: 396 2018/02/22(木)16:45 ID:9+xI5ulA(12/17) AAS
AA省

475: 396 2018/02/22(木)17:29 ID:9+xI5ulA(13/17) AAS
かなり色々やったつもりだけど、ちょっとこれ以上深入りは難しいので、もう諦めようかも。
以下の上京からするとLinuxカーネルの問題かも知れない：

1. タスクバーも操作不能になる。
2. 単純な usleep() も無限に帰ってこない。

476: 396 2018/02/22(木)17:39 ID:9+xI5ulA(14/17) AAS
Wineでは、昔の MSDN Library の CD もインストールは出来ただが見られなかった。
hh.exe が xxx.COL ファイルを開けないと言ってくる。
yyy.CHM ファイルは、開くことはできたが、右のペーンだけが見えて、左側の目次や
検索のぺーンには何も表示されない。

今回 WINEのソースを見て思うのは、意外とちゃんと書かれていないということ。
MsgWaitXxxx にも、戻り値が明らかに間違っている部分を発見した。
また、TRUE (1)を引数に渡す必要があるところで、1ではない非0 の値を渡している
箇所も見つかった。そのようなコードは後々問題を来すかも知れない。
それに、MsgWaitXxx もちゃんと書かれていない。同時に待機するのは、アプリ・プログラマ
がどんだけ頑張ってもかけないから API が用意されているのだが、そこに明らかな
省3

477: 396 2018/02/22(木)18:45 ID:9+xI5ulA(15/17) AAS
usleep() の部分を setitimer(), pause() に変えてみたら、そこは指定した
時間でちゃんと帰ってくるようになった。でも、Linux全体が停止に近い状態に
なる症状は変わらない。端末内の FIXME の表示が途中の文字まで書かれた状態で
改行までいく前に長い間停止する現象が起きてしまっている。

478: 396 2018/02/22(木)23:32 ID:9+xI5ulA(16/17) AAS
X Window System は、Server と Client で通信を行っているから、Client側では処理が
一瞬で帰って来ているように見えても、Server側では処理に凄く時間がかかっている可能性
があるかもしれない。だから Client側で、関数の呼び出しの前後の時間を計測をしても
それは単にServer にコマンドを送る処理の時間を計測しているに過ぎないのかも
知れない。イメージのバイト数が多いいときには、通信時のデータ・コピーに時間がかかる
から多少時間がかかるかも知れないが、それはまだ表面上の時間に過ぎず、Server 側は
Shapeのくり抜き処理(?)や重ね合わせの処理に膨大な時間がかかっている可能性も否定できない。

だから、XCreateBitmapFromData(), XShapeCombineMask(), XPutImage() の前後の時間を
計測しているだけでは速く見えても、見えない場所でCPUパワーを全開にしてがんばっても
まだ処理を終えてないのかもしれない。
省5

479: 396 2018/02/22(木)23:41 ID:9+xI5ulA(17/17) AAS
そういえば、update_surface_region() が呼び出されたことを示すデバッグ文字列は、後からまとめて
ドドッと出てくる。それは、文字列が「出てない」間には関数が呼ばれてないことを意味する
訳ではなく、実は呼ばれてはいるが、文字列が flush されてないか、または、flush
されていても、端末に CPU リソースが割り当てられないから、文字表示だけが行われずに
文字列がバッファに溜まった状態になってしまっている・・・・。

こう考えれば辻褄が合うかも。

480: 396 2018/02/23(金)00:00 ID:rGoiNTvu(1/9) AAS
本家の Windowsでは、描画処理が重いときには、OnPaint や OnDraw の関数が終わるまで
の時間も長い。だから、メッセージがたくさんたまっているのに描画が追いついていない事は、
メッセージ・キューに残っているメッセージの個数が多い事で大体の判断が付く。だから、
InvalidateRect(NULL)をしておけば、描画が追いついてない場合は、メッセージループ
が WM_PAINTメッセージを送るタイミングを自動的に後回しにしてくれる。

ところが、X Window System の場合、実際の描画がまだ終わってない場合でも、
「描画関数」自体は一瞬にして戻ってきてしまうから、上記のアルゴリズムが「勘違い」を
起こしてしまうことがある・・・。

そらに悪い事に、WINEが、内部で Surface を持っているときには、LineTo 関数自体は高速に
処理を終えるのに、アプリが予想もしないタイミングで、時間の掛かる flush の処理が行われ
省7

481: 396 2018/02/23(金)00:09 ID:rGoiNTvu(2/9) AAS
さらに、>>465-466 >>468 に書いた、WINPOS_SysCommandSizeMove() は、
CWinApp などとは別の、独自のメッセージループを持っている。
そこでは、さらに、WM_PAINT が不適切に大量に発生してしまっている
可能性がある。

だんだん分かってきたかも。

482: 396 2018/02/23(金)00:23 ID:rGoiNTvu(3/9) AAS
原因は推定できてきたけど、さて、どうやってこれを解決すればいいか・・・。

485(1): 396 2018/02/23(金)12:30 ID:rGoiNTvu(4/9) AAS
>>483
それでは、日本人の自分に取って手も足もでない状況になってしまうので、とても
困ります。

487: 396 2018/02/23(金)12:36 ID:rGoiNTvu(5/9) AAS
協力しにくくしにくくなるように仕向けられて、どうしようもない状態になってる気もする。
make時の表示の無駄が多すぎて、特に警告が出ていても見逃しやすいし、HDDも膨大に
消費するし、ダウンロードやアップロードにも莫大な時間がかかるし。

なんだか、アメリカと北欧の社会的環境以外ではとっても負担が大きいかも、

488(1): 396 2018/02/23(金)12:36 ID:rGoiNTvu(6/9) AAS
>>486
意味が分かりません。

490(1): 396 2018/02/23(金)12:41 ID:rGoiNTvu(7/9) AAS
MSのやり方に困った人が集まってくるのがLinux。
でも、Linuxのやり方にもまた困る。UbuntuのUpdateも自分には出来ない。
なぜなら、HDDのパーティションの容量が足りないのと、DLに時間がかかりすぎるからと、
クリーンインストールしなきゃならないから、せっかく入れた Wine や Wz, VC++ などの再
インストールに莫大な時間がかかってしまうのとで。それでやっとの思いでなんとか協力
したいと思っているのに、また、ライセンスがどうのこうのとか。

わけが分からない。LinuxやUbuntuのバグに悩まされて、しょっちゅう Logout と Login
を繰り返しながら、やっとの思いでやってます。

493(1): 396 2018/02/23(金)12:43 ID:rGoiNTvu(8/9) AAS
>>489
そんな心配はないはずです。

自分は権利を放棄するつもりでやってますし、法的には Wine の LGPL が優先されて、
5ch は権利は主張できないハズ。もし、権利を主張するなら、5ch自体が人が来なくなって、
閉鎖されるでしょう。

498: 396 2018/02/23(金)13:42 ID:rGoiNTvu(9/9) AAS
【ついに出来た】

x11drv_surface_flush() の中で、

update_surface_region( surface );

を実行後、

XPutImage(・・・);
XFlush( gdi_display );
XSync( gdi_display, TRUE );
XSynchronize( gdi_display, True );
省14

501: 396 2018/02/24(土)02:46 ID:OWf5FxmD(1/3) AAS
>>500
WINE 本家に正式採用されなくてもいいなら、github にプルリクエストを送る、なんて
事は可能なんでしょうか。

ライセンス上は、修正した箇所のソースの断片でも、どこでもいいからネット上のどこかに
アップロードしておけば良いんだと思うんですが。

ネットの回線が遅いから、自分が全く修正してない部分まで全部アップロードというのは
かなり困ります。

502(1): 396 2018/02/24(土)02:53 ID:OWf5FxmD(2/3) AAS
要は、著作権が発生するようなソースを書かなければいいんですね。

WINE で、WS_EX_LAYERED の場合に、現状の様に XShape を使わずに、
XCreateWindow の depth に 32 を指定して、ARGB カラーを使うようにして
透明化を実験して見たところ、高速になったようです。

まだ、中途半端ですが。

503: 396 2018/02/24(土)03:51 ID:OWf5FxmD(3/3) AAS
透明化、完全に上手く行きました。速度は劇的に向上。
システムの(事実上の)ハングアップも全く起きません。

現状で Windows との非互換な部分は、透明部分をクリックしても、下にある Window
にマウスメッセージが送られない、という一点だけです。

511(2): 396 2018/02/27(火)17:20 ID:fxlvg2HV(1/3) AAS
Linux の X Window の XShape と、 Win32 の WS_EX_LAYERED は相性が悪いために
単に Win32 を Emulateしようとすると、多分、どうやっても遅くなってしまうと思うんです。

だから、Wine 専用に Windows には無いフラグや関数を定義して、ある新定義の
独自APIを呼んだタイミングでだけ、XShapeを呼び出す仕様にすればいいと思うん
です。それを呼び出さなくても、中の図形や透明部分は自由に変えられると。
で、メッセージが下(Desktopなど)まで届く部分を指定したい場合(外形を変えた
い場合等）だけは、その関数を呼ぶと。例えば、透明を使った一般のアプリでも、
輪郭は楕円にしておいて、中の絵だけを高速に変えたいような需要はあると思う
んです。それは、今の Wineでは出来ません。でも、今述べた方法なら可能になり
ます。
省8

512: 396 2018/02/27(火)17:21 ID:fxlvg2HV(2/3) AAS
>>510
早速、ここでの話を受けて、 Qiita に書いてみてます。

516(1): 396 2018/02/28(水)01:21 ID:nqkdrNZG(1/5) AAS
結論的には、Wineを改造しても Windows API の仕様を変える訳ではありませんので、
もし、Wineの一部であっても、Windows API だけを使った dll の部分は、Wineの
バージョンが変わっても、原則的には自由に入れ替え可能な可能性があるのです。

kernel32.dll, gdi32.dll, user32.dll, ntdll.dll の4つの dll 以外のdllは、
WINEの内部がどのように実装されているかには依存していない可能性があると
いうことです。もしそうであれば、Wine のソースを改造してもこれらのdll.so以外は、
本家Wineが今後発表する新バージョンのものを、改造 Wine のバイナリファイル群に
後から上書きしても、互換性が保たれ続けるんじゃないかな、と思いました。つまり、
以下の 4つの dll.so だけを配布すれば、かなり長い間、独自の Wine として動作
できる可能性があるのではないかと。loader.c を修正した libswine.so.1.0 を配布
省9

517: 396 2018/02/28(水)01:22 ID:nqkdrNZG(2/5) AAS
>>516
その際、「wine server」の「server request」の仕様を変更さえしなければ、
標準の Wine を使ったアプリと、まさに同時実行も可能ではないかと。
実際、自分が実験する限り、標準の Wine を使った VC++ と Wz が、
特に問題なく独自 Wine の自前アプリと同時実行で来ているように見えますので。

なんというか、例えば、Wineの実装の構造体にメンバ変数を独自に追加した場合、
それが直接見えているソースは、同一の構造体の他のメンバの相対アドレス、構造体の
サイズが変わるために再コンパイルが必要です。しかし、それを直接見ているのは、
上の 4つの dllのdll.soファイルだけではないかと。そして、その他のdllは、その
構造体を直接見てないのではないかと。それで、カプセルの様にブラックボックスの
省3

518: 396 2018/02/28(水)01:33 ID:nqkdrNZG(3/5) AAS
「dll.so」ではなく「drv.so」ですが、

/wine/dlls/winex11.drv/winex11.drv.so　1,797,340

も配布が必要ですので、合計20MB程度。圧縮すれば 10MB程度のはず。
だから、アプリ本体のバイナリと同時に 10MBを配布すれば独自修正 Wineが
配布できるかと。

519: 396 2018/02/28(水)01:52 ID:nqkdrNZG(4/5) AAS
>>515
やはり、そう思われますか。

一部の透明アプリに取っては、改造Wineの方がWindowsとの互換性がかなり上がりますが、
他の透明アプリに取っては下がる、見たいな状態になるので、意見が分かれるかな、と思って
たんです。でも、恩恵を受けるアプリもあります。

523: 396 2018/02/28(水)15:05 ID:nqkdrNZG(5/5) AAS
MSDN Library の CD-ROM 版を、Wineにインストール出来ました。

外部ﾘﾝｸ:qiita.com

なお、確か、MSDN Library 2008 の ISO イメージは、無料で DL 出来たと思います。

531: 396 2018/03/03(土)10:25 ID:YW+cC+A2(1/4) AAS
「片山 ReactOS」でGoogle検索した時に一番上に表示したページが、
ウイルス感染している事を、BitDefender Traffic Light が報告したので注意
してください。

これは煽りや虚偽ではありません。

540: 396 2018/03/04(日)11:19 ID:bPq1RsH0(1/3) AAS
Wine において HTML HELP (CHM) を表示時、リンク先へ飛べない場合の原因が分かって来ました。

外部ﾘﾝｸ:qiita.com

飛べる場合 : 　リンクに Java Script を使ってない。
飛べない場合 : リンクに Java Script を使っている。

Java Script の実行が上手く行ってないのではないでしょうか。どなたかにさらに原因を追求して
不具合を直していただければ幸です。

541: 396 2018/03/04(日)11:21 ID:bPq1RsH0(2/3) AAS
なお体験から言えば、リンク先のHTMLのファイル名に日本語が使われている場合も、
リンク先へ飛べないことがあるようです。

543: 396 2018/03/04(日)21:46 ID:bPq1RsH0(3/3) AAS
[HTML HELP (MSDN Library) 関連]

nativeなDLLの組み合わせを根気よく実験したところ、上手く行く組み合わせが見つかり、
飛べなかったリンクへも飛べるようになりました。詳しくは、上のリンク先を見てください。

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.212s*