17/11/15 17:34:03.45 IQx2T/FT.net
iptables
hosts
189:login:Penguin
17/11/15 18:51:45.95 Jnv1uTUv.net
wineとvirtualboxと両方いれてるけど、両方とも捨てがたい面白さがあるな
なんで素のWindowsで動かすより楽しいんだろ
190:login:Penguin
17/11/15 19:09:10.44 PItAYZMm.net
気持ちはわかるがなんでと言われると俺もうまく説明できんな
191:login:Penguin
17/11/15 20:18:22.38 nadr0cJ+.net
楽しくないからLinux Subsystem for Windowsが欲しい
192:login:Penguin
17/11/15 20:20:38.02 6A4Rs5GX.net
>>179
iptableｓなんかの設定見直してみれば
Sambaは動いているだろうにNetBiosでの名前解決が出来ないことから自体おかしい
193:login:Penguin
17/11/15 22:01:51.60 oATZSiR0.net
>>179
スレ違いだけれど、そういうときはstoneを使っていたな。
URLﾘﾝｸ(www.gcd.org)
194:login:Penguin
17/11/15 23:02:29.38 Df+srf5D.net
wineでLINEを入れようとしたんだけどエラーが出る
今のwineではLINEは動かないの？
195:185
17/11/15 23:26:03.43 zX+/kLPg.net
>>187
ありがとうございます。
うおおstoneすごい懐かしい
Win2000くらいの頃にSSHトンネリングで使った記憶があります
196:login:Penguin
17/11/16 22:41:50.86 6aI/ZRqG.net
>>188
別に普通にインストールしてるけど？
197:login:Penguin
17/11/17 19:25:15.03 9jxbQuiV.net
linux mintの18.2のxfceだけど
LINEを起動させるとプログラムエラーのウィンドウが出ます
198:login:Penguin
17/11/17 19:40:09.27 zQEjDQyH.net
うんこが臭いのは悪玉菌じゃね？
199:login:Penguin
17/11/18 05:38:06.51 p8WfAtYV.net
確かに最新版にアプデすると起動できなくなるな
200:login:Penguin
17/11/18 19:46:21.29 UdOuyQ/l.net
ver 4.10.1.1256は最新版じゃないの？
起動出来てますが
201:login:Penguin
17/11/18 19:47:22.41 UdOuyQ/l.net
起動出来ないのはMintなんていうチョン臭い盗人寄生虫ディストロ使うからだろう
Ubuntuがdebian使いなさい
202:login:Penguin
17/11/18 20:03:43.00 bycYHPOE.net
DebianはいいとしてUbuntuが言うか！ww
203:login:Penguin
17/11/18 21:07:26.74 kpnh1UKt.net
RedとかSlackwareってまだあるの？
204:login:Penguin
17/11/18 22:11:58.58 erSkGVCZ.net
やっぱコーエーのゲームは鬼門だな
全然動かねえ
205:login:Penguin
17/11/18 22:56:28.78 bycYHPOE.net
コーエーの罠
206:login:Penguin
17/11/18 23:19:14.14 sVrF0uKC.net
こえぇぇぇ
207:login:Penguin
17/11/18 23:49:14.58 2K6DBm7Z.net
Slackwareはまだバリバリやで
ちょっと興味ある
208:login:Penguin
17/11/19 02:24:12.08 n2NB7kQF.net
Red Hatもまだバリバリだが、もう企業しか使ってない
209:login:Penguin
17/11/20 05:24:20.59 ufyoE7fF.net
>>197,201,202
今、SlackwareベースのPuppy Linux、Slacko Puppyをイジってる。
でも、SlackwareのリポジトリーにはJDがないんだよなあ。
WineでJane Style 4.00が動くようになったから
それ使えばいいじゃんという話もあったりするが。
Red Hatのベータ版的な位置づけのFedoraがあるぞ。
こいつは一般人というか、一部のPCオタクも使ってる(はずだ)。
210:login:Penguin
17/11/20 11:12:22.95 vD/yuLid.net
Slackwareはまだ1人でやってるのかな
がんばるなぁ~
211:login:Penguin
17/11/23 05:24:20.00 ec1EgXkn.net
WindowsXPからコピーしてきたMS UI Gothicのノーマルは表示できるのに
ボールドやイタリックが別のフォントになるのはなにか設定が悪いのかな
212:login:Penguin
17/11/23 06:08:37.05 qNGNilYk.net
>>205
窓厨がそれはライセンス違反だと激怒するぞ。
213:login:Penguin
17/11/23 07:49:07.17 ec1EgXkn.net
>>206
ぐぐったら8年前の過去ログでてきてまさにそれで文句言われてたわ
214:login:Penguin
17/11/23 08:16:58.75 UjM0DnVX.net
デュアルブートしてるからWindowsのfontsディレクトリにシンボリックリンクで使ってるけどそれも駄目なのだろうか
215:login:Penguin
17/11/23 08:55:16.55 oYwUc+9/.net
>>208
どんな言い訳をひねり出そうとしてもダメなものはダメです
216:login:Penguin
17/11/23 11:36:31.51 I93zAJ+1.net
WSLでWine使う場合は問題ないと思う。
Windowsの中で閉じているわけだし・・・
217:メモ
17/11/23 18:29:28.01 ONL1vZ5p.net
フォント置換用レジストリ （優先される項目順）
1. HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes
Replacements 存在しないフォントを別のフォントで代替 (MS UI Gothic を Ume UI Gothicで代替)
SystemLink 文字補完用（欧文フォントに和文部分を補充） ファミリー名ではなくフォント名で登録
FontSubstitutes 別名追加用 （システムフォントの○○という名前でXXフォントを使用）
-----------------------------------
例えばWindowsでは
・FontLink\SystemLink
Tahomaは以下のフォントで構成される
MSGOTHIC.TTC,MS UI Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic
SEGUISYM.TTF,Segoe UI Symbol
・FontSubstitutes
MS Shell Dlg 2 と言う名前で Tahoma を使用する
となっている
-------------------------------------
方法１ フォントとレジストリをWindowsからまるまる持ってきて入れ替える （Wine\Fonts\Replacementsは削除する）
方法２ 存在しないフォントと互換性のあるフォントを全て入れ、Wine\Fonts\Replacementsに書き込む (Wine標準の方法)
方法３ FontSubstitutesやFontLink\SystemLinkに使用したいフォントを書き込む (Windows標準の方法)
方法４ FontForgeでフォントファイルを改造して偽造する
218:login:Penguin
17/11/23 20:54:04.57 bG63KsTb.net
wine-stableとwinehq-stableって違うんです？
219:login:Penguin
17/11/23 23:06:42.09 ec1EgXkn.net
>>211
サンクス
でもそれはフォントインストーラーSAKURAまかせでぜんぶやった
でもやっぱもともとボールドやイタリックを含まないフォントに関してはLinuxがわ任せなきがするよ
220:login:Penguin
17/11/24 16:11:37.97 XmgiKOdY.net
>>207
前はそういう話しが出ると必ず突っ込みが入っていたが、
最近はどうしてかあまり言われなくなった。5chかwineが廃れたって事かな。
221:login:Penguin
17/11/24 17:22:53.83 dM0zMNZT.net
昔マイクロソフトのアプリケーションが個人情報を吸い上げている！
とか騒いでたのにFacebookGoogleだので特に気にならなくなってあまり騒がなくなったのと同じかな
それともWindows10で強引なアップデートされて流石に堪忍袋の緒が切れてフォローできなくなったのかな
222:login:Penguin
17/11/24 21:52:54.08 fYHCS0wK.net
>>210
現状WSLじゃWineは使い物にならんぞ…32bit
223:バイナリ動かないからWine64しか動かない。exe側も64bit用のバイナリじゃないと駄目。 BoxedWineってのもあるけど、まともにメンテされてないっぽい。
224:login:Penguin
17/11/25 21:46:38.97 NIO92dI8.net
The Wine development release 2.22 is now available.
What's new in this release (see below for details):
- Source selection dialog for scanners.
- Improvements in ARM64 support.
- Float audio formats with more than 2 channels in XAudio.
- Fixes for DLL injection support.
- Input methods improvements.
- Various bug fixes.
225:login:Penguin
17/11/26 10:15:47.97 CDaEW04C.net
財布が追いつかないペースでまた発売
226:login:Penguin
17/11/29 23:15:31.68 s/prMD1Z.net
前に1.6が残るって騒いでたけど>>212で解決した
1.6消してwine-stableとwinehq-stable入れたら直った
両方いるなんて分からん
227:login:Penguin
17/11/30 00:58:50.96 qebhjSTk.net
ディストリは何ですか
228:login:Penguin
17/11/30 04:42:02.68 sBC4c9ex.net
WineのIME関係はまだいろいろおかしいけど、今開発者にアジアの人いないのかな
履歴みたけど10年前くらいのログにdlls/winex11.drv/xim.cをちょこちょこいじってる日本人らしき名前があるけど
229:login:Penguin
17/11/30 06:18:56.94 qFCu30fF.net
>>219
wine-stableとwinehq-stableって両方入れないとイカンの?
winehq-stableしか入れてないんだけど。
230:login:Penguin
17/11/30 06:33:14.47 sBC4c9ex.net
むしろ別のWineは削除してくださいって一番最初に書いてあるよ
URLﾘﾝｸ(wiki.winehq.org)
231:login:Penguin
17/11/30 08:43:12.83 otxLOnG+.net
debの依存関係がいろいろぶっ壊れてるな。
232:login:Penguin
17/11/30 09:06:52.83 IxeR2Y43.net
だからソースから入れれば複数同居できるだろが
233:login:Penguin
17/11/30 12:37:16.98 qRMso+63.net
>>152＝>>168＝>>175＝>>219です
まぁエディタが豆腐になった時点で何かやったんだとは思う
stable入れる前に1.6は消してたし文字化けの前にやったのはそれこそwine更新くらいで
removeしても1.6が残ったりして混乱状態に
wine-stableだけの時は/opt/wine-stable/があるのにバージョンでwine1.6が出てきたり
その後winehq-stableを入れたら2.0.3に戻ったって次第
今はwine-stableとwinehq-stableが入っててちゃんとwine-2.0.3が出てくるし文字化けもなくなった
234:login:Penguin
17/11/30 19:41:00.70 7ljKqpkA.net
wineでソフトウェアが動かない場合、wineだけでなくOSとの相性が悪いってこともある？
235:login:Penguin
17/11/30 20:44:07.79 O/ur2rlc.net
>>227
OSっていうかライブラリ入ってないと動かない場合は当然あるぞ
URLﾘﾝｸ(wiki.archlinux.jp)
236:login:Penguin
17/11/30 23:49:24.78 jciCAcUm.net
理由は分からないけどlxdeだとWineのアプリからhtmlファイルが開けない
だからlxdeは嫌い
237:login:Penguin
17/12/01 02:09:40.53 xqcwKr1j.net
>>227
可能性としてはあるかもしれない
Mint18.2にOffice2013入れたけど、Word、Excel、Accessは動いたけどPower Pointだけはどうしても動かなかった(一回だけ起動したけど直ぐにフリーズしてしまった)
でも他の酉では動いてる人が実際いるようなのでOSとの相性なのかも、と思ってしまう
ちなみに2007のPower Pointは同じ設定でちゃんと動いてる
238:login:Penguin
17/12/01 19:15:53.35 1BMF+j4q.net
>>230
OSとの相性が問題としてあるなら
諦めるしかなさそうだ
239:login:Penguin
17/12/03 13:30:08.94 r7l8ZQ4Y.net
>>221
IME関係がおかしいところって、XIMのせいだったりしないの?
240:login:Penguin
17/12/03 20:54:42.91 3e2lP79Y.net
>>232
ソースちょろっと見ただけだけど変換中のキーバッファをwine
241:側で取得してなさそうだった 変換候補を表示する座標が変なのはWineに限らずJavaなんかでもおかしいからibusやFcitx側の問題かもわからん
242:login:Penguin
17/12/03 21:05:53.27 3e2lP79Y.net
Linux上のブラウザはjquery.autoKana.jsで変換中のキーイベント取れてるからフリガナ表示できる
変換中のキーバッファはwinex11.drv側で取得してWM_KEYDOWNなんかで渡すべきなんだけど今はLunux側にフィルタされて一切取得不可能なのよね
243:login:Penguin
17/12/04 11:44:56.42 iXIboIR8.net
ここの人たちにはcrossoverは邪道なの？
244:login:Penguin
17/12/04 16:19:01.30 Zs8Xf/Rp.net
泥版なら
245:login:Penguin
17/12/06 20:30:01.64 TkPErGb/.net
デスクトップ環境にMATEを使ってたが、気分転換にLXDEに変えたらWineの起動が早い気がする。
246:login:Penguin
17/12/06 22:12:26.02 WwvX2OLs.net
mateはかなりファイル開きっ放しだからな
GNOME3 KDE >= Xfce > mate >= GNOME2 > LXDE
しかしLXDEは色々と機能が足りなかったり（DE WM でのIME切り替えとか管理とかみたいな）
あと たいかんｗ でしかないけど、Win32のウィンドウサイズ関連が上手く動かない、みたいのが
LXDEだと多い気がする（BunBackupとかスプリッタで変な事してる様なのとか）
247:login:Penguin
17/12/07 01:03:53.96 cWwLfUQD.net
fcitx-mozcだけどWineとIMEって相性悪いのか
テキストエディタと小物ソフトとゲームしかWIｎソフト入れてないけど
変換候補のずれもなくなってたな
248:login:Penguin
17/12/07 01:33:46.12 i4cTkEur.net
ibusで問題ないわ
249:login:Penguin
17/12/07 01:55:02.12 GZ0adcwJ.net
起動速度はフォントの数に比例してる気がする
250:login:Penguin
17/12/07 06:39:59.41 nA6CF77g.net
pkgで新しいwineをインストールすると、古いwineはどこに言ってしまうの？
ssdの容量が減りっぱなしなんだけど、どこかに残っているの？
251:login:Penguin
17/12/07 07:24:41.18 Cxxv6MlI.net
BSDで使ってるのか？
ここはLinux板だが
252:login:Penguin
17/12/07 07:34:31.25 GZ0adcwJ.net
OSXじゃないの？
253:login:Penguin
17/12/07 08:05:38.60 nA6CF77g.net
Linux板でしたか、すいませんosxでした
254:login:Penguin
17/12/07 10:35:12.71 lLyHhCQa.net
システム入れ替える前に、wineのDLLのオーバーライド設定控えるの忘れた・・・
せめてどっかにwinetricksぶっこみまくっても無難に動く設定転がってないかな？
あれまたDLLのインスコ前後の差分取って、不安定要因を１個１個確かめてとか、
やりたくねぇ ＿／＞ ...〇
255:login:Penguin
17/12/07 11:39:30.77 whCDA5/s.net
DLLOVERRIDEをexportするスクリプトを書いて実行していればそのバックアップだけで済んだのにな。
ご愁傷様
256:login:Penguin
17/12/07 23:54:38.44 /7maLNKe.net
Fcitx, iBusどっちでもいいけれど、Wineだと文字入力以外のIME機能が使えないんだ
読み仮名とか、変換中の文字列を得るとか、再変換、
IMEのON/OFFステータスの取得や切り替え、IMEの無効化みたいな
257:login:Penguin
17/12/08 00:29:41.16 9tFy6Pyf.net
imm.c見たらわかるけど、ほとんどのAPI関数はエラーが出ない
258:程度にSetLastError入れてスキップしてる IME使うのはアジア圏だけだろうから深刻なバグがない程度に放置されてるんだと思う
259:login:Penguin
17/12/08 17:14:43.40 6G06S73N.net
有用な情報だ
年末時間あったらIMM関連のコードいじってみたいなあ
260:login:Penguin
17/12/08 17:15:29.05 6G06S73N.net
IMEだった
261:login:Penguin
17/12/09 01:09:27.00 iNQgA4Hw.net
いたるところスタブだらけだなぁ
これはきつそう
262:login:Penguin
17/12/09 09:25:19.32 zN2YiaEH.net
いたるところ刺されてしまったら死んでしまう
263:login:Penguin
17/12/09 12:32:57.92 7fOeTESL.net
winetricks 20171018-next
$WINEARCH win32
winetricks の kindle が起動しません。
ウインドウ枠だけが表示されフリーズしています。
動作されてる方いますか？
264:login:Penguin
17/12/09 14:05:17.10 UOGmtvtC.net
俺の環境(wine2.22, arch linux)だと
WINARCH=32 インストーラーがabort
WINARCH=64 初期化時に無限ループして起動しない
という感じだった
265:login:Penguin
17/12/09 18:32:55.53 YqOwDV0c.net
ようやく3.0-rc1発売したな
266:login:Penguin
17/12/09 21:09:37.39 ZizBMPX7.net
The Wine development release 3.0-rc1 is now available.
This is the first release candidate for the upcoming Wine 3.0. It
marks the beginning of the code freeze period. There have been many
last minute changes, so please give this release a good testing to
help us make 3.0 as good as possible.
What's new in this release (see below for details):
- Direct3D 11 enabled by default on AMD and Intel GPUs.
- AES encryption support on macOS.
- Implementation of the task scheduler.
- Registry export support in the reg.exe tool.
- Progman DDE support.
- OLE data cache improvements.
- More event support in MSHTML.
- Relay debugging improvements.
- Various bug fixes.
267:login:Penguin
17/12/10 13:52:47.90 klaJNAZw.net
3.0-rc1にならないなぁ・・・
どうやっても2.22で止まり
268:login:Penguin
17/12/10 16:59:10.41 +7C7vpay.net
リリースされてもしばらくは反映されなかったりする
ちょっと時間をおけば反映されるよ
269:login:Penguin
17/12/10 17:02:36.92 +7C7vpay.net
ちなみに途中で止まってしまう時なんかもちょっと時間をおけば大丈夫だったりするね
270:login:Penguin
17/12/14 00:28:29.66 uasM/WcC.net
Macに3.0-rc1入れたけど、2.0-rcに比べるとインパクトがないな。
1.xに比べると劇的に早くなったと記憶してるが・・・
271:login:Penguin
17/12/14 00:29:38.55 uasM/WcC.net
あ、2.0の前は1.8.xが安定版で、1.9.xが開発版だったな。
272:login:Penguin
17/12/14 05:51:27.84 v8B75yuf.net
>>259-260
やっと3.0-rc1になったよ
273:login:Penguin
17/12/16 14:22:39.44 bW5YVtYr.net
The Wine development release 3.0-rc2 is now available.
What's new in this release (see below for details):
- Bug fixes only, we are in code freeze.
274:login:Penguin
17/12/23 12:09:46.38 H8q0qY+f.net
もう、rc3かよ・・・
年明けには正式リリースか？
275:login:Penguin
17/12/23 15:13:03.61 cWtVfPXD.net
まだしばらくは様子見だな
276:login:Penguin
17/12/23 23:20:13.85 lw33zAzW.net
The Wine development release 3.0-rc3 is now available.
What's new in this release (see below for details):
- Bug fixes only, we are in code freeze.
277:login:Penguin
17/12/24 10:34:08.86 VPPBoKnS.net
Stableの2.0.2でまったく困ってないのでよほど大きく進歩しないかぎり入れ替えはしないなあ
278:login:Penguin
17/12/24 17:20:01.23 1I2BjjZG.net
何が進歩したのか実感ないな
279:login:Penguin
17/12/24 17:32:48.54 IBZwHax5.net
まあ動くソフトが増えれば進歩だから、増えたのかね
どうなんだ
280:login:Penguin
17/12/25 02:35:07.72 dS73rF3k.net
winegstreamerのバグはいつ治るのやら(´･ω･`)
281:login:Penguin
17/12/27 06:20:28.79 SVEhAMrp.net
昨日、uninstallerを起動しようとして
何か間違ったか知らんけど、偶然画面の解像度や色の深度などの設定画面が出て
「あったのか！ ラッキー」と思ったんだけど、
Whiskerのメニューでコマンド入力したので履歴に残ってないんですよね
何を入力したのかまったく覚えてない・・・
どなたか、その設定画面の立ち上げ方知りませんかね？
一応3.0-rc3 devだけど・・・
282:270
17/12/27 06:23:26.93 SVEhAMrp.net
271は解決しました
ただのDirectXコントロールでした
283:login:Penguin
17/12/29 13:03:53.69 S/CsVkMC.net
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
00570E2KI1
284:login:Penguin
17/12/29 17:28:26.99 iNY0EDJE.net
K-POPや韓国製品を賛美するコメントを書き込むだけの簡単なお仕事です
285:login:Penguin
17/12/30 15:04:24.86 LSgSNlwf.net
The Wine development release 3.0-rc4 is now available.
What's new in this release (see below for details):
- Bug fixes only, we are in code freeze.
286:login:Penguin
17/12/30 22:49:45.08 5BLxWiUb.net
rc4ダウンロードできないね
サーバ落ちてるのかな
287:login:Penguin
17/12/31 01:01:21.40 HzVxAEPF.net
自己解決
URLﾘﾝｸ(repos.wine-staging.com) から直接落としてきて
/var/cache/apt/archives に入れてupdateかけるか、dpkg実行すればいいみたい
288:login:Penguin
17/12/31 01:30:30.01 oPkRQXpp.net
Archにはもう来てた
289:login:Penguin
17/12/31 14:26:31.17 qgVtfis0.net
Debianだと、3.0-rcから.desktopファイルに書かれたexeの起動が遅いか全くできない。
Ubuntuなら問題なし。
290:login:Penguin
17/12/31 14:39:16.45 gcCl9kvt.net
Debian使えないな
291:
18/01/01 13:32:54.82 ato00EWB.net
でも、OSの根本的な部分はDebianが安定してるな。
292:login:Penguin
18/01/02 03:01:20.38 5XHTzRzf.net
3.0-rc4 だと.dotnet2.0のインストールに失敗する(COMの登録に失敗してる感じ
一旦1.6に戻して試したら普通行ける
293:login:Penguin
18/01/06 13:16:21.44 7VrAA8Ax.net
The Wine development release 3.0-rc5 is now available.
What's new in this release (see below for details):
- Bug fixes only, we are in code freeze.
294:login:Penguin
18/01/10 15:41:07.41 QCZkn0Oz.net
3.0-rc5 でaviutl EX gui(64bit版のx264)がエラー吐かなくなった
295:login:Penguin
18/01/10 18:05:43.72 NU1g8fVP.net
winetricksがまともに動くまではstableで傍観しとこう
296:login:Penguin
18/01/10 19:06:03.70 QCZkn0Oz.net
wine amd64にdotnet4.0は入るんだけど
4.5.1が入らない．．．
悪戦苦闘中．．．
297:login:Penguin
18/01/11 01:19:26.45 bCgxtA6k.net
4.5sp1は自分も断念したな
たしかインストーラーが途中でファイルをダウンロードしようとして落とせなくて中止せざるを得なく
一度終了すると、winetricksのスクリプトが2.0sp1がすでにインストールされていると誤認して
そのWine構成では2度とスクリプトが続行できなくなる
298:login:Penguin
18/01/12 13:42:56.03 gYYqUthF.net
wine2.1で、4,5までははいるんだけど
使用したいソフトがカーネルエラーでおちる
wine3.0だとdotnetfx_cleanup_tool使っても4.0までしか自分では入れれなかった
archlinux x64 初心者なので断念
299:login:Penguin
18/01/12 13:46:09.36 vkXa7tZa.net
カーネルエラー？
エラーメッセージ貼って
300:!omikuji!dama
18/01/12 21:05:29.90 jOlAt89d.net
カーネルパニックだろ
多分
301:login:Penguin
18/01/13 10:12:54.96 VMyQS4xx.net
wineをインストールしてから数日はすぐ起動するのですが数週間経つとソフトが起動するまで3分程度かかります。ログファイルか何が原因かと思い探して見たのですが解決出来ませんでした。原因が分かる方いますか？
因みにwineで使っているのはfoobar2000です
302:login:Penguin
18/01/13 15:52:29.65 ZYUrszxm.net
流石に3分はないけどすごく起動が遅くなる時があるよね
最初はwineserverがFontキャッシュでも作成してるのかと思ったけど
すでに他のEXEが起動しているのに起動が遅い場合があってよくわからん
海外のフォーラムだと wineboot --update で治ると書いてあったけど眉唾すぎる
303:!omikuji!dama
18/01/13 16:42:49.27 WoaJDBLo.net
よく分からん状態になったらwine関係のプロセスを粛正しまくってる。
これで大体解決する。
304:login:Penguin
18/01/13 18:04:46.56 B3Ohx7ND.net
使ってる人が原因かと
305:login:Penguin
18/01/13 18:58:19.48 ZYUrszxm.net
ubuntuクリーンインストール直後の更な状態でも遅いからおま環とかじゃないはずだよ
306:login:Penguin
18/01/13 19:17:20.69 aO/skiFy.net
システムのwineでも特定のアプリ用に保存してある1.7.55でも一回も遭遇したことがないなあ
本当ならfoovarとかいうので検証してみたいところだが先2週間くらいは暇がないし……
307:login:Penguin
18/01/13 19:43:06.84 0ImOITEW.net
wine をバージョンアップするとなんとかを更新してますってダイアログが出て
少し時間がかかる時はあるがそれ以外で時間がかかったりかからなかったりと
挙動が変わるという経験は一度も無し。
308:login:Penguin
18/01/13 19:49:41.09 rQueZPLB.net
バージョンダウンしないとPlayOnLinuxがだんまりになるのはいつ治るの？
309:login:Penguin
18/01/13 20:37:21.07 +qCFvz08.net
wine2.0.2だけど最初の起動にやっぱり時間がかかる
aviutlは10秒くらいかかってる
でもまあ一度起動してしまえばあとはすぐに起動するから問題ないと思ってる
310:login:Penguin
18/01/13 20:54:51.56 ZYUrszxm.net
何度かOS起動しなおしてプロセス確認してみた感じ、winserverの起動時間で若干のオーバーヘッドがある
.NetFrameworkに依存しないソフトなら割と早いから
.NetFrameworkのためにservice.exeを起動するので時間かかってるソフトもありそう
あと>>293は外出でChromeやら何やらと起動放置した状態だったから、実際はWineのせいではないかも
311:login:Penguin
18/01/14 04:02:31.93 c00KIfxq.net
office2007のExcelやwordもやっぱり最初だけ起動に10秒くらいかかるね
でも最初だけであとはどのソフトを立ち上げても速攻立ち上がる
312:login:Penguin
18/01/19 15:05:53.58 hGEl50jm.net
3.0リリースage
窓の杜に紹介されてたw
URLﾘﾝｸ(forest.watch.impress.co.jp)
313:login:Penguin
18/01/19 15:35:29.14 5AGAtRRq.net
発売まだー？
314:login:Penguin
18/01/20 13:26:21.82 QNCJHR2/.net
Ubuntu16.04なんだけど、wine3.0のバイナリパッケージが
まだstableブランチに来てないみたい。
develブランチにもだけど。待ってるのになー。
315:login:Penguin
18/01/20 13:56:15.17 ST9AkHo4.net
>>305
そう云うのは仮想環境で試すものだよ
多分ltsのstableにくるにはそれなりの安定性が確保された後だから
316:login:Penguin
18/01/20 14:04:02.97 jECh1545.net
rc5くらいからはそれなりに安定してる気がするけど
317:login:Penguin
18/01/21 01:00:17.88 E8yLG1bL.net
>>306
stableが出てくるまで待ってるわ
318:login:Penguin
18/01/21 02:51:19.12 v9DGKoF8.net
wineは複数ブランチとかないし新しいバージョンほど基本安定している
バックポートは甘え
319:login:Penguin
18/01/21 04:12:52.13 PdVXby3O.net
stableも3.0になったけどwinetricksでdotnetがインストール出来ない不具合治ったかな？
いちいち古いバージョンでwine環境作るのめんどくさいんじゃ
320:login:Penguin
18/01/21 07:33:36.49 ZoqjSopw.net
stable3.0来たねえ。これで一安心。
321:login:Penguin
18/01/21 15:28:51.30 cqgGWWH9.net
stable2.0.2から3.0に
とりあえず.net2.0はインストールできた
あとはこれから
office2007もaviutlもhuffyuvも問題なくインストール出来た
とりあえず検証はこれから
URLﾘﾝｸ(i.imgur.com)
322:login:Penguin
18/01/21 19:00:02.85 mnBw72Yr.net
The Wine team is proud to announce that the stable release Wine 3.0
is now available.
This release represents a year of development effort and over 6,000
individual changes. It contains a large number of improvements that
are listed in the release notes below. The main highlights are:
- Direct3D 10 and 11 support.
- The Direct3D command stream.
- The Android graphics driver.
- Improved DirectWrite and Direct2D support.
Once again, because of the annual release schedule, a number of
features that are being worked on have been deferred to the next
development cycle. This includes in particular Direct3D 12 and Vulkan
support, as well as OpenGL ES support to enable Direct3D on Android.
323:login:Penguin
18/01/21 23:44:11.08 uMqVfBQE.net
>>310
素→2.0 成功
素→2.0→3or4 失敗
素→3→4 失敗
素→3 成功
素→4 成功
上げていくと失敗する
他にも失敗条件があるから失敗したら素からやり直す
成功したら.netバージョン毎に.wineをバックアップを取る
324:login:Penguin
18/01/22 00:38:29.04 4V0t3/Lk.net
>>314
サンクス。それは1.6の頃と変わらないから3.0develのregsvr32のdll登録の失敗バグは治ってる
３と４やsp1なんかを全部入れるときはそれぞれ新規で環境作ってインストールさせてから
ファイルを一つの環境下にコピーしてレジストリゴニョゴニョしてやってる
winetricksで対応してくれないかな
325:login:Penguin
18/01/22 02:09:45.36 3DZiHNcD.net
winetricksはどうだろう
あまり期待はしすぎないほうがいいと思う
adobe airなんかもいまだに2 .0だし
windows版のairはインストール時に文字化けしない2.8になってるってのに
326:login:Penguin
18/01/22 05:56:21.79 sg4WtIHW.net
3.0リリースおめ
しかし前から思うんだけど
wineて前進してるんだろうか
毎回物凄い数の修正してて凄いと思うけど
バージョンあがると、動いたり動かなかったり
327:login:Penguin
18/01/22 12:37:51.85 pTAsElVi.net
2.0になってoffice2013がサポートされるようになったようにそれなりに前進してるとは思う
ただ今回のメジャーアップデートはDirectX10と11のサポートやアンドロイドのグラフィックドライバーなどグラフィック関係のサポートがメインで、多分ゲーム分野の取り込みと拡大が狙いなんだろう
ゲームをしない自分にはあまり関係のないアップデートかもしれないけど、他にどこが変わったかはこれからゆっくり見てみようと思ってる
328:login:Penguin
18/01/22 15:37:16.16 kKAYm2a6.net
URLﾘﾝｸ(wiki.winehq.org)
を見てて気づいたが、WineのAndroid用apkはここから落とせるんだね
URLﾘﾝｸ(dl.winehq.org)
CPUエミュレータはたぶん入っていないので、x86版をVirtualBox上の
Android-x86で試してみたけど、普通に動く
329:login:Penguin
18/01/22 15:54:35.65 e6iLgqD7.net
な、なんと！
今日は雪で早く帰るけど、うまく家に帰れたら試してみるかな・・・
330:login:Penguin
18/01/22 17:03:20.00 L3AK43SD.net
atomのAndroidでしか使えなさそうだな
331:login:Penguin
18/01/22 17:04:19.53 e6iLgqD7.net
Macに3.0入れたら起動がスゲー遅い・・・
rc6までは問題なかったのに。
332:login:Penguin
18/01/22 19:50:02.64 8gLiYv5f.net
ChromebookならIntel入ってるしAndroidアプリ対応だから使えるかな
333:login:Penguin
18/01/22 22:16:59.83 jDSqHtL9.net
そっか、Android用もあったか
Chromium系OS調べてみよっかな
334:login:Penguin
18/01/22 23:29:19.11 i9V8iudJ.net
arm版はqemuとかとの連携機能待ちだな。
335:login:Penguin
18/01/23 01:26:34.66 bIPDOfti.net
CrossOver for ChromeOSならGoogleアプリストアから入れられるよ
Pixelbookで重宝してる
336:login:Penguin
18/01/25 21:51:50.70 Ka0jz2eD.net
macOS 10.13.4のベータ版から32ビットアプリを無効にできるブートオプションが追加されたので
試したみたらWineも32ビットで起動できなくなったわ。64ビットアプリは問題ない。
これは予想はできたがショボーン状態に。
337:login:Penguin
18/01/26 07:13:19.17 3aSucPyA.net
~$ wine --version
wine-1.8.7 (Debian 1.8.7-2)
~$ winetricks --version
20170101
で，Internet Expolorer 8 のインストールがWebページの404エラーにより失敗しました。
URLﾘﾝｸ(web.archive.org)URLﾘﾝｸ(download.microsoft.com)
どなたか ie8 が配布されているサイトに心当たりはないでしょうか。
欲を言えば winetricks から操作できると嬉しいです。
338:login:Penguin
18/01/26 11:30:37.56 2+tR6Py2.net
IEって再配布許可されてたっけ？
339:login:Penguin
18/01/27 20:54:12.80 giAfVQmq.net
なんかwine-stable入れなおしたらフォントがちゃんとWindowsみたいにアンチエイリアスなしでビットマップフォント描画するようになってて違和感
以前
URLﾘﾝｸ(i.imgur.com)
現在
URLﾘﾝｸ(i.imgur.com)
340:login:Penguin
18/01/29 01:59:02.40 7OnATKIe.net
>>330
へ～Jane Styleだとこうなるのか
ちょっと試してみるわ
341:login:Penguin
18/02/03 15:04:52.45 ELGdE4BJ.net
wine3.0にしたらadobe airがインストールできなくなった
air28だけでなく27も26もだめ
しばらく様子をみるしかないか
342:login:Penguin
18/02/03 15:28:55.73 Oo2vNWbE.net
qtもインストール出来なくなったね(´･ω･`)
未実装の関数がどうとか出てくる(´･ω･`)
343:login:Penguin
18/02/03 15:34:46.68 ELGdE4BJ.net
qtもなんだ
office2007とかすごく快適に使えてるからとりあえずはいいんだけど
郵便局のハガキデザインキットで暑中見舞い作りたいからそれまでにはなんとかしてほしいわ
344:login:Penguin
18/02/03 18:46:41.23 Kel5QXve.net
3.1出とるで
345:login:Penguin
18/02/03 18:54:14.00 ELGdE4BJ.net
Developmentだからなあ
基本Stableを第一に考えてるので3.0が優先かな
まずは他に方法がないかいろいろ探してみようと思う
346:login:Penguin
18/02/03 19:23:04.64 ELGdE4BJ.net
>>332
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
URLﾘﾝｸ(i.imgur.com)
347:login:Penguin
18/02/03 19:23:15.46 ELGdE4BJ.net
>>332
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
URLﾘﾝｸ(i.imgur.com)
348:login:Penguin
18/02/03 19:23:43.89 2NmXANz5.net
>>332
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
URLﾘﾝｸ(i.imgur.com)
349:login:Penguin
18/02/03 19:24:33.28 ELGdE4BJ.net
あかん、３回も書き込まれてしまった
ごめん！
350:login:Penguin
18/02/03 19:35:54.19 GZq3v5kX.net
三回とは珍しい
351:login:Penguin
18/02/03 19:44:26.86 ELGdE4BJ.net
お恥ずかしい
書き込みエラーが出たので試しにプロキシの設定の書き込みの方にもチェックを入れてみたところ、いきなり３回書き込みになってしまいました
352:login:Penguin
18/02/03 19:45:03.20 ELGdE4BJ.net
あ、ちなみにJDです
353:login:Penguin
18/02/04 04:35:38.16 otRrUZsg.net
女子大生なら仕方ない
354:login:Penguin
18/02/04 05:23:51.13 z31m/4Dh.net
JCなら許したがJDじゃ許さない
355:login:Penguin
18/02/04 05:50:31.22 A0TCwoRK.net
JKがいいな
356:login:Penguin
18/02/04 08:45:53.53 b+VNmt3j.net
俺もJKがいいわ
357:login:Penguin
18/02/04 13:01:53.45 rnnaq26n.net
ここまでDKやDC、DSすらなし
358:login:Penguin
18/02/04 13:18:40.29 0SOx+W3z.net
女装男子だろJK
359:login:Penguin
18/02/04 15:28:23.45 GzGg78Tp.net
>>348
男子コリア人や男子中国人、男子シベリア人ですか
360:login:Penguin
18/02/04 16:30:27.26 uHhYoqNi.net
若いころは、JSがまさかここまで人気になるとは思わなかったな。
Javaに似せただけがとりえのスクリプトだと思ってたのに。
361:login:Penguin
18/02/04 16:36:15.18 fzkuBClS.net
いや全然Javaに似てなくないか
JSってかなり変わった言語だと思うけど
362:login:Penguin
18/02/04 16:42:19.83 uHhYoqNi.net
ごめん、名前の話ね。
JSリリース当初は、まさに全然違うのになぜLiveScriptからJavaScriptに変えたんだろう、と思ったんで。
363:login:Penguin
18/02/04 16:51:57.05 i7LhZGzA.net
あえて言おう、女子小学生と！
364:login:Penguin
18/02/04 17:03:59.12 Oj6myZBS.net
>>354
／￣￣￣￣￣￣￣￣￣￣＼
| おまわりさんコイツです！ |
＼＿ ＿＿＿＿＿＿＿＿／
∨ ＿＿＿
,r'つ＠＝,r'
.| （-＿- ）
（･ω･´）､/~У￣|ﾞｉ
ﾟこ､ つ |=◎＝∪
しー-Ｊ （＿（＿_）
365:login:Penguin
18/02/04 17:50:29.23 z6WochWF.net
逮捕！
366:login:Penguin
18/02/04 17:54:12.34 /nA3Cux+.net
>>351
大半が同じ感想のはず。
ajaxの手法が公開されてから一気に沸騰した。
367:login:Penguin
18/02/04 19:07:24.58 m27l3Bxn.net
JK=ジャパニーズ・コリアン ニダ！
368:login:Penguin
18/02/04 20:49:06.09 bJ63O2JQ.net
The Wine development release 3.1 is now available.
What's new in this release (see below for details):
- Kerberos authentication support.
- Window class redirection for Common Controls 6.
- Support for X11 ARGB visuals.
- DOSBox required for running DOS executables.
- Various bug fixes.
369:login:Penguin
18/02/05 02:08:15.28 O1Pwqk/s.net
とりあえず3.0stableで様子見決め込んでる
370:login:Penguin
18/02/05 19:21:01.05 Nv69ARvL.net
wine-staging2.21からwine-stable3.0にしたら
負荷とメモリ消費が素晴らしく改善されたから
開発版に手を出しかねてる
3.0で改善されたのか、stagingのものが足を引っ張ってたのか判別つかなくて
371:login:Penguin
18/02/05 20:00:31.17 EoTMajD6.net
chrootで試せばいい。
372:login:Penguin
18/02/07 03:18:13.01 EaQ8LavF.net
janeで書き込みてすと
373:login:Penguin
18/02/07 11:19:50.99 wf+3Oqyn.net
3.4のときは起動すらしなかったのにな
4.0になったら快調すぎる
374:login:Penguin
18/02/07 12:09:50.12 obK+oDJv.net
だったらいいんjane
375:login:Penguin
18/02/07 13:18:45.69 zs43/D2L.net
じゃあコンパイルすっかな
376:login:Penguin
18/02/08 05:29:46.28 awGx+2l1.net
結局のところwinehq-stableとwine-stableの差は何なのさ
377:login:Penguin
18/02/09 02:10:23.04 7CcbsDfN.net
winehq stableが公式サイトで公開されてるやつでwine stableは各ディストリから配布されてるやつだと思ってたけど違うのかな
378:login:Penguin
18/02/09 09:15:05.20 VkWK7O5C.net
wine-3.1-arm.apk
ExaGearより動くかなと期待して入れたんだけど、プログラムが一つも動かない…
まだ見てくれだけの未完成品ってこと？
379:login:Penguin
18/02/09 09:31:45.76 VkWK7O5C.net
あー Windows RT ARMのソフトしか動かないのかこれ
380:login:Penguin
18/02/09 10:40:32.53 PPTatEc4.net
違うだろ
ｽﾚﾘﾝｸ(market板)
381:login:Penguin
18/02/09 10:58:50.36 FuNSphmo.net
>>371
マルチポストにつきNG推奨
382:login:Penguin
18/02/09 11:54:48.43 uGFZgCuz.net
>>372
こいつMac関連のスレ狙ってる？別にそんな事ないのかな
383:login:Penguin
18/02/10 14:13:46.18 JX1fd7td.net
crossoverのベースになっているwineのバージョンってどこから調べたらいいの？
もう3.0ベースになってるのかな
384:login:Penguin
18/02/10 21:57:09.72 yxHJfpP2.net
>>374
/opt/cxoffice/changelog.txt
もしくは
URLﾘﾝｸ(www.codeweavers.com)
3.0はまだやね
385:login:Penguin
18/02/10 22:08:14.64 yxHJfpP2.net
ちがったかな
$ /opt/cxoffice/bin/wineserver --version
wine-2.8-8251-g8a457d1
386:login:Penguin
18/02/10 23:24:32.73 JX1fd7td.net
>>375-376
ありがとう
そっかまだかあ
387:login:Penguin
18/02/15 16:28:40.72 Adu/G50n.net
ubuntu studio 16.04LTS にwineを入れて、
JaneStyle を使える様にはなった。
書き込みテスト。
388:login:Penguin
18/02/15 22:20:39.99 feRq4tDS.net
>>369
まじかよ、Elonaさえ動けばいいのに。
389:login:Penguin
18/02/15 23:40:06.85 XEMKL93X.net
ARM機とかスマホしか持ってないわ
これから増えるんかね
390:login:Penguin
18/02/16 01:05:13.35 +Lqzmf2v.net
3DSとかもARMじゃないっけ
391:login:Penguin
18/02/16 08:01:15.26 TwuYLqrN.net
PS VitaもARMだしSwitchもARMだな
392:login:Penguin
18/02/16 08:03:04.95 8cWV/uet.net
最近のモバイル端末はだいたいARMだな
393:login:Penguin
18/02/16 08:03:51.98 8uACRqcY.net
ChromebookもARM機ある
394:login:Penguin
18/02/16 11:10:06.04 80vLUCQ5.net
WindowsもARM機が再登場する
395:login:Penguin
18/02/16 12:08:49.84 Q5rpQjEk.net
RTでコケて痛い目にあったからそれはないと思う。
ARMじゃない別のアーキテクチャで出す可能性はあるかも・・・
そしてまたコケるw
396:login:Penguin
18/02/16 12:24:21.66 Pj9ij8xw.net
>>386
いや出るから
HPとASUSがsnapdragon搭載Windows端末を発表済で春に発売予定
397:login:Penguin
18/02/16 13:41:56.11 QNuqSD5T.net
売れるとは限らないんだがなぁ
x86exeが何となくでも動くだけでいいのにな
398:login:Penguin
18/02/16 15:27:59.39 80vLUCQ5.net
x86が動くWin10のARMが出る
399:login:Penguin
18/02/16 16:20:26.93 1h3N4gI+.net
ちょっと調べてから否定しようよ
まあいいんだけどさ
400:login:Penguin
18/02/16 19:29:08.29 XuFK7/QF.net
古いけど、Ubuntu12.01 への Wine3.0のインストールに成功した。
git のソースから、./configure
途中、Font関連のファイルが見つからないエラーが出たので、
そのFontの「dev版」をapt-getでインストール。
その他、いくつかエラーが出るので、インストールしたりする。
その後、make, make
401:install。 でインストールには成功するが、今まで動いていたWinアプリを起動してみると 日本語で文字化けしてる。wintricks font や regedit などをいじってみたが、 ダメだった。しかし、apt-get remove wineとしたあと、再度、 apt-get install wineとすると、なぜか、すぐに成功した。 wine --versionとすると、なぜか、3.1のままだった。 不思議な事に、文字化けはすっきり解決した状態で、Ver 3.1のWineが動いているらしい。 実際、Windowsとの互換性は明らかに向上した。
402:login:Penguin
18/02/16 19:30:26.21 XuFK7/QF.net
3.1じゃなく、3.0でした。スマソ
403:login:Penguin
18/02/16 19:37:33.92 XuFK7/QF.net
Wzエディタで、検索やGrepのダイアログのStatic Textの表示が途切れてしまう
不具合があったのが、Wine3.0では修正されている。これは使える。
404:login:Penguin
18/02/16 23:10:05.44 XuFK7/QF.net
透明色と MDI Window を組み合わせた自作WindowsアプリをWineで動くように修正中。
MDI Child Widnow のタイトルバーをドラッグすると遅くなるので原因を調査していた。
PreTranslateMessage() にくるメッセージを、自前でWindowに表示していたところ、
システム全体が実質的にハングアップした。マウスは動くが、タスクバーも反応しない。
ちなみに、透明色とMDI Windowの組み合わせが必ず遅くなるわけではない事は、
単純なテストプログラムを作って分かっている。ではなぜ、このプログラムに限っては
遅くなるのかが分からないので調査中だった。
405:login:Penguin
18/02/17 14:20:45.23 SLFwTllY.net
The Wine development release 3.2 is now available.
What's new in this release (see below for details):
- Separate implementation of USER controls for ComCtl32 v6.
- Multisample texture support in Direct3D.
- Support for HID gamepads.
- More event support in MSHTML.
- Obsolete DOS code removed.
- Various bug fixes.
406:login:Penguin
18/02/17 16:25:52.12 XDWn7PKv.net
廃れたDOSコードを削除、か
407:login:Penguin
18/02/17 16:26:50.92 KjUUJ1nJ.net
Wineは、Desktopの直接の子であるような、Win32における「OVERLAPED WINDOW」
的な物しか、XWindow の Window を作らないのだろうか？？
Wineのソースをダウンロードして、FIXME(WARNでもいいはずだけど)で実行を調べてみた。
でも、良く分からない。ビルドとmake installに時間がかかるため、大変。
本当はもっと実験したいんだけど、時間的に難しくなる。
ソースを見ると、HWNDの親が Desktopの場合にだけ、XCreateWindowしているように
見える。これが、透明ウィンドウが遅くなる理由かもしれない。LinuxのNativeなWindowの
場合、実験した限り透明にしても速度が余り変わらない。でも、Wineがもし、自前で透明処理
をやっているとなれば遅くなるのも頷けるが。
1つのソースしか修正してないのに、ビルドが始まるまでに数十秒かかる。make installに
また数十秒。それに、wineserver -k などにも時間がかかるし。なんか、30年前のビルド環境
みたいだ。
408:login:Penguin
18/02/17 16:41:42.91 eqmjcJnH.net
>>397
>ソースを見ると
どこだかわからんからURLﾘﾝｸ(source.winehq.org)のリンク貼ってくれ
409:login:Penguin
18/02/17 17:12:51.37 KjUUJ1nJ.net
>>398
今回に関しては、以下を読んで、git でやってます :
URLﾘﾝｸ(wiki.winehq.org)
home directory (~) にて、
$ git clone git://source.winehq.org/git/wine.git [ret]
とすると、wine ディレクトリが作成されるので、
$ cd wine
とします。そこで、
$ git config remote.origin.url [ret]
と入れて
git://source.winehq.org/git/wine.gi
と出れば、大�
410:ﾌ DL 成功です。 ~/wine/ にソースが DL されており、dlls に Win32 の DLL 群の実装があります。 例えば、user32 などのフォルダがあります。~/wine/server に wine の中枢の プログラムが入っています。CreateWindow などは、dlls の方にありますが、 それを XWindowCreate に橋渡しするのは、server の方です。 オンラインで見たいなら、 https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/user32 の win.c に CreateWindow 系のソースが入っており、 https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/user32/win.c で見られます。win.c の右の「raw」のボタンを押すと、ローカルの Wz エディタ などでも見られます。
411:login:Penguin
18/02/17 17:16:25.31 KjUUJ1nJ.net
5ch からのアクセスは禁止されているらしいので、アドレスバーに上記の URL を
コピーしてアクセスしてください。
なお、make が遅い件は、make -j 4 などとして、マルチコア動作するとだいぶ良くなりました。
ただし、その場合、make にバグがあるので精密な神経の持ち主には、ストレスがたまります。
412:login:Penguin
18/02/17 17:19:14.92 KjUUJ1nJ.net
動きをトレースしたい場合、TRACE はデフォルトではメッセージが出ず、使い方を調べて
ないので、
FIXME( "Yamada Taro, CreateWindowEx, hWND=%08X", hWND );
みたいにやってます。
413:login:Penguin
18/02/17 17:23:11.12 KjUUJ1nJ.net
makeしたい人は、~/wine にて、
$ ./confiugre
$ make -j 4 2>build.log
$ make -j 4 install 2>inst.log
$ wineserver -k
で行けます。ここで、wz エディタを起動してみます。文字化けするようでしたら、
$ apt-get remove wine
$ apt-get install wine
で直ると思います。これは、一度やれば Ok のようです。
414:login:Penguin
18/02/17 17:40:09.90 KjUUJ1nJ.net
call set_window_pos()
--> wine/dlls/user32/winpos.c
--> X11DRV_WindowPosChanging()
--> X11DRV_create_win_data()
--> dlls/winex11.drv/window.c :
static void create_whole_window( struct x11drv_win_data *data )
--->
data->whole_window = XCreateWindow(
data->display, root_window, pos.x, pos.y,
cx, cy, 0, data->vis.depth, InputOutput,
data->vis.visual, mask, &attr );
という流れのようです。
415:login:Penguin
18/02/17 17:41:22.28 KjUUJ1nJ.net
以下を見ると、親が、DesktopWindow の時のみ、create_whole_window() が呼び出されている
らしいことが分かります。
static struct x11drv_win_data *X11DRV_create_win_data( HWND hwnd, const RECT *window_rect,
const RECT *client_rect ) {
Display *display;
struct x11drv_win_data *data;
HWND parent;
if (!(parent = GetAncestor( hwnd, GA_PARENT ))) return NULL; /* desktop */
/* don't create win data for HWND_MESSAGE windows */
if (parent != GetDesktopWindow() && !GetAncestor( parent, GA_PARENT )) return NULL;
if (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId()) return NULL;
display = thread_init_display();
init_clip_window(); /* make sure the clip window is initialized in this thread */
if (!(data = alloc_win_data( display, hwnd ))) return NULL;
data->whole_rect = data->window_rect = *window_rect;
data->client_rect = *client_rect;
if (parent == GetDesktopWindow()){
create_whole_window( data );
TRACE( "win %p/%lx window %s whole %s client %s\n",
hwnd, data->whole_window, wine_dbgstr_rect( &data->window_rect ),
wine_dbgstr_rect( &data->whole_rect ), wine_dbgstr_rect( &data->client_rect ));
}
return data;
}
416:login:Penguin
18/02/17 17:42:23.86 KjUUJ1nJ.net
>>403 の訂正：
CreateWindowExW()
--->
WIN_CreateWindowEx()
call set_window_pos()
--> wine/dlls/user32/winpos.c
--> X11DRV_WindowPosChanging()
--> X11DRV_create_win_data()
--> dlls/winex11.drv/window.c :
static void create_whole_window( struct x11drv_win_data *data )
--->
data->whole_window = XCreateWindow(
data->display, root_window, pos.x, pos.y,
cx, cy, 0, data->vis.depth, InputOutput,
data->vis.visual, mask, &attr );
417:login:Penguin
18/02/17 18:08:08.76 KjUUJ1nJ.net
ちなみに、
1. ~/.wine
2. ~/wine
は別物です。1は、binary をインストールした際に出来るデフォルトのフォルダ
ですよね。2. は、git からソースを持ってきた時にできるディレクトリです。
まずは、バイナリをインストールして動作してから、ソースを持ってきてください。
418:login:Penguin
18/02/17 18:27:32.24 1JDlaACg.net
半透明化はWin32API側でどうやっているの? Linuxネイティブなアプリでは?
SetLayeredWindowAttributesであれば、user32.dllからUSER_Driverを介してwinex11.drvが呼ばれて、
window.c内のsync_window_opacityで_NET_WM_WINDOW_OPACITYにα値を設定している様子が見て取れる
URLﾘﾝｸ(github.com)
TRACEで表示しているメッセージを確認するには環境変数WINEDEBUGを使って、
WINEDEBUG=win,x11 みたいにカンマ区切りで指定する。細かくは
URLﾘﾝｸ(wiki.winehq.org) に書いてある。
あとは、dlls配下の各ディレクトリでもmake && sudo make instlallできるので
特定のDLLファイルしか変更しないのであれば、この方法でビルド時間を短縮できるぞ。
419:login:Penguin
18/02/17 18:42:48.23 cvAP0C15.net
デバッグ大変だな。めんどくさそう。
仕事じゃないと俺はやらないだろうな。
420:login:Penguin
18/02/17 19:41:54.60 J9G7l4mf.net
自分はimm32関連(日本語入力)APIを修正しようとeclipceでコンパイル環境作ったはいいけど
ネイティブのウィンドウマネージャ関連の知識不足でソースの意味がわからず寝かせてある・・・
421:login:Penguin
18/02/17 19:54:02.08 Tf7u8zkg.net
>>407
Linux Nativeアプリの場合、32BIT COLOR にすると、A,R,G,B の 4つの値を
ドットの「色」として指定できます。Aがα値です。このようなことは、Windows
では出来ないと思います。Windowsの場合、CreateWindowExのdwExStyle に
WS_EX_LAYEREDを指定すると透明、半透明が扱えるようになります。
1.完全に「透明になる色」を24BIT値で1色指定できます。この色で描いたドットは、
デスクトップまで透けて見えるようになります。見た目だけではなく、Windowメッ
セージも下のWindowに伝達されてしまうことになりますが。
2.ドットごとではなく、Window全体のα値を1つ(1BYTE)だけ指定できます。
ドットごとでは無いので、全体的に透明度が決まってしまいます。
1と2は完全に別の概念です。
LinuxのARGB値は、ドット毎に指定できるので、Windowsの機能を包含していると
言えます。逆に Windowsでは、同じ事は出来ないはずです。
422:login:Penguin
18/02/17 19:57:46.46 Tf7u8zkg.net
/wine/dlls/winex11.drv/x11drv.h
に次のような構造体があり、この whole_window というのが大事らしい：
/* x11drv private window data */
struct x11drv_win_data {
Display *display; /* display connection for the thread owning the window */
XVisualInfo vis; /* X visual used by this window */
Colormap colormap; /* colormap if non-default visual */
HWND hwnd; /* hwnd that this private data belongs to */
Window whole_window; /* X window for the complete window */
Window client_window; /* X window for the client area */
RECT window_rect; /* USER window rectangle relative to parent */
RECT whole_rect; /* X window rectangle for the whole window relative to parent */
RECT client_rect; /* client area relative to parent */
XIC xic; /* X input context */
BOOL managed : 1; /* is window managed? */
BOOL mapped : 1; /* is window mapped? (in either normal or iconic state) */
BOOL iconic : 1; /* is window in
423:iconic state? */ BOOL embedded : 1; /* is window an XEMBED client? */ BOOL shaped : 1; /* is window using a custom region shape? */ BOOL layered : 1; /* is window layered and with valid attributes? */ BOOL use_alpha : 1; /* does window use an alpha channel? */ int wm_state; /* current value of the WM_STATE property */ DWORD net_wm_state; /* bit mask of active x11drv_net_wm_state values */ Window embedder; /* window id of embedder */ unsigned long configure_serial; /* serial number of last configure request */ struct window_surface *surface; Pixmap icon_pixmap; Pixmap icon_mask; unsigned long *icon_bits; unsigned int icon_size; };
424:login:Penguin
18/02/17 20:00:42.49 Tf7u8zkg.net
>>407
後半の二つ。自分に取っては、かなり貴重な情報です。助かります。
425:login:Penguin
18/02/17 20:11:22.91 Tf7u8zkg.net
>>407
XWindow で透明化。これはやってみて実際に出来ました：
URLﾘﾝｸ(stackoverflow.com)
how-to-create-semi-transparent-white-window-in-xlib
子ウィンドウを入れてみても、ちゃんと出来ました。
ただし、子ウィンドウには、Win32のような、タイトルバーは付ききませんでした。
XWindow に詳しい人によれば、XWindow の Window Manager は、
Win32 の MDI のような事は、サポートしていないらしいです。絶対か
どうかは分かりませんが。
実験してみると、子ウィンドウも、親ウィンドウも、ABI で、XMoveWindow
でスムーズに動かせました。
ただし、Wineの場合、子ウィンドウに直線や文字が書かれていて、かつ、背景が透明な場合、
スムーズには動かせません。
426:login:Penguin
18/02/17 21:31:43.98 cvAP0C15.net
Win32APIだけじゃなく、X Windowについても知っておかないといけないのか
面倒臭っ・・・
普段使ってるだけでずいぶん楽してたんだな。
427:login:Penguin
18/02/17 22:08:41.04 eqmjcJnH.net
面白そうだけど時間ねえな……
>>411を見る限りだとuse_alphaは持ってるけどAlpha値自体はもうX11の構造体にいれてるのかな？
まあ遅くなる理由とか検討つかんけど……
428:396
18/02/18 01:13:22.20 DznsC7ZZ.net
WINEにおいて、
1. MDIのCMDIChildWndのCViewのCLIENT領域全体(子ウィンドウの
中全体と言ってもよい) に >>410の1.の色を塗って、完全透明
にしている時は、CMDIChildWndのタイトルバー(子ウィンドウの
タイトルバー）をドラッグしても高速に動かせる。
2. 1のCViewの中に、pDC->LineTo()で直線を一本描いた状態にしてから
同じ事をしようとすると、とても遅くなる。
3. 2.は、直線の代わりに pDC->TextOut() で文字を描いても同様に遅く
なる。
4. 推定では、Wineは、Win32のCreateWindow系で、Parent Window が
Desktop 以外の場合、XWindow の Window を使わず、自前で
Parent Window の中に画像を合成して子Windowを模倣している。
5. 4.の様にしている理由は、推定だと Window Manager の種類による
挙動の違いに患わされずに安定して Emulation するためかも知れ
ない。
6. その結果、XWindow の ARGB 値による高速な透明処理を利用できな
くなり、低速になる。
7. しかし、なるべく低速にならないようにするため、少なくとも、
子ウィンドウの中全体が完全透明な場合については、対策が取ら
れており、高速にドラッグできるようになっている。
8. その結果、2, 3 のような条件の時のみ遅くなると推定される。
429:login:Penguin
18/02/18 01:24:45.49 smHwezpH.net
推定じゃなくて直接聞いたら？
430:login:Penguin
18/02/18 01:56:23.18 HH6qVqdM.net
>>417
どうやって？
431:406
18/02/18 02:29:31.78 dARugMLm.net
>>416
すまん、ウィンドウの半透明化処理(LWA_ALPHA)と勘違いしてた。
ウィンドウ領域内の特定色で書いた箇所を透過させる場合(LWA_COLORKEY)ね。
ソースを調べたら、WineではX11のShape Extensionを使ってウィンドウの形状を変更することで、
「見た目だけではなく、Windowメッセージも下のWindowに伝達すること」を実現しているようだ。
具体的にはupdate_surface_region()で1ピクセルごとにピクセル値を比較して、
XShapeCombineRectanglesに指定する矩形領域を作っている。
URLﾘﾝｸ(github.com)
415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
StackOverflowの記事はShape Extensionを使っていないので筋違いだ。
432:login:Penguin
18/02/18 04:20:47.62 HH6qVqdM.net
>>419
なるほど。
1つ質問です。
はっきりとは書いてなかったのですが、>>416の遅くなる条件であるところの 2,3 の場合
においても、CMainFrame、つまり、アプリケーション全体の Main の Window のタイトルバーを
ドラッグした場合は、遅くなりません。いたって高速にドラッグできます。
>>419 が正しいなら、どうして、X は、この場合だけは速く、CMDIChildWnd の場合だけは
遅く動作するのでしょうか？？？
433:login:Penguin
18/02/18 04:57:21.33 HH6qVqdM.net
↓の構造体の dc_rect の矩形が子ウィンドウを模倣するために使われているかも知れません：
/* X physical device */
typedef struct {
struct gdi_physdev dev;
GC gc; /* X Window GC */
Drawable drawable;
RECT dc_rect; /* DC rectangle relative to drawable */
RECT *bounds; /* Graphics bounds */
HRGN region; /* Device region (visible region & clip region) */
X_PHYSPEN pen;
X_PHYSBRUSH brush;
int depth; /* bit depth of the DC */
ColorShifts *color_shifts; /* color shifts of the DC */
int exposures; /* count of graphics exposures operations */
} X11DRV_PDEVICE;
BOOL X11DRV_LineTo( PHYSDEV dev, INT x, INT y ) {
X11DRV_PDEVICE *physDev = get_x11drv_dev( dev );
POINT pt[2];
GetCurrentPositionEx( dev->hdc, &pt[0] );
pt[1].x = x;
pt[1].y = y;
LPtoDP( dev->hdc, pt, 2 );
add_pen_device_bounds( physDev, pt, 2 );
if (X11DRV_SetupGCForPen( physDev ))
XDrawLine(gdi_display, physDev->drawable, physDev->gc,
physDev->dc_rect.left + pt[0].x, physDev->dc_rect.top + pt[0].y,
physDev->dc_rect.left + pt[1].x, physDev->dc_rect.top + pt[1].y );
return TRUE;
}
434:login:Penguin
18/02/18 05:32:50.78 HH6qVqdM.net
/wine/dlls/user32/painting.c の中の、
// Set the visible region and X11 drawable for the DC associated to a given window.
static void update_visible_region( struct dce *dce )
の中に、
USER_Driver->pGetDC( dce->hdc, dce->hwnd, top_win, &win_rect, &top_rect, flags );
とあって、
void CDECL X11DRV_GetDC( HDC hdc, HWND hwnd, HWND top, const RECT *win_rect,
const RECT *top_rect, DWORD flags )
が呼び出される。引数に hwnd と top、win_rect と top_rect が対になっているらしいことに注意。
この関数の中で、x11drv_escape_set_drawable escape; の
escape.dc_rect に、win_rect の top_rect の (left, top) からの相対座標が入れられる。
そして、ExtEscape( hdc, X11DRV_ESCA
435:PE, sizeof(escape), (LPSTR)&escape, 0, NULL ); と ExtEscape() が呼び出される。 escape = X11DRV_ESCAPE; escape.code = X11DRV_SET_DRAWABLE; in_data = &escape; の状態で、 X11DRV_PDEVICE *physDev = get_x11drv_dev( dev ); const struct x11drv_escape_set_drawable *data = in_data; physDev->dc_rect = data->dc_rect; となる。physDev->dc_rect が、>>421 の dc_rect に他ならない。 つまり、HWND hwndのwin_rectの、HWND topの左上座標からの相対座標が、 physDev->dc_rect に入ることになると思われる。hwndの「最上位の親」が topだとすると、topだけが XCreateWindow()された本物のWindowであって、 hwnd は 擬似Windowであるとして辻褄が合う。hwndへの描画は、 実は座標だけを修正して top の(本物の X )Window に書き込まれているだけ かも知れない。
436:login:Penguin
18/02/18 12:58:43.05 HH6qVqdM.net
結論的には、Wine では、完全透明色が設定されている全ての LAYERED_WINDOW に
対して、Idle状態の時か、または、50(ms) 毎に、Windowアプリのメッセージループ
の中から自動的に、>>419 の update_surface_region() が呼び出されるようになっ
ているらしいです。この条件のWindowがあって、かつ、update_surface_region() の
処理が重い場合に、動作が遅くなる可能性が高いです。Dirty Bitのようなものは、
今のところ見つかっていませんので、何もしなくても常に重くなるのでしょうか。
【詳細】
flush_window_surfaces() なる関数が、定期的に呼び出される。
典型的なタイミングは、PeekMessage() の中からであり、GetMessage()では、
check_for_driver_events() を介して呼び出される。
flush_window_surfaces() の中に次のようなマクロ呼び出しがある :
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
ここで、
/* iterate through the list using a list entry */
#define LIST_FOR_EACH_ENTRY(elem, list, type, field) \
for ((elem) = LIST_ENTRY((list)->next, type, field); \
&(elem)->field != (list); \
(elem) = LIST_ENTRY((elem)->field.next, type, field))
であり、上記は、window_surfaces リストに登録されている全ての
window_surface *surface について、window_surface_funcs *funcs の
関数ポインタ flush の関数を呼び出すことになり、結局、
関数 x11drv_surface_flush() が呼び出されることになる。
関数 x11drv_surface_flush() の中に
if (surface->is_argb || surface->color_key != CLR_INVALID) update_surface_region( surface );
とある。update_surface_region() は、>>419 に書かれている関数。
437:396=422
18/02/18 13:53:01.38 HH6qVqdM.net
該当の条件の時、新たには何の描画もしていない静止状態でも、Linuxのシステム・モニターで
CPUパワーが膨大に消費されていることを確認しました。このことは、>>423 を裏付ける物です。
だとすると、Dirty Bit を導入して、update_surface_region()の頻度を下げれば、この低速化
は修正できる可能性が出てきました。LineTo, TextOut, MoveWindow, SetWindowPos,
ShowWindow などを使ったときだけ、DirtyBit を 1にして、1の時だけ update_surface_region()
を呼び出し、呼び出した後には 0 にすれば良いのではないかということです。
条件は：
1. WINEを使用して Windowsアプリを走らせていること。
2. アプリ内で CreateWindowEx() のdwExStyle に WS_EX_LAYERED を指定して Windowを作成
済みであること。
3. さらに、SetLayeredWindowAttribute() に LWA_COLORKEY を指定して「完全透明色」を
指定していること。
4. その Window の背景を「完全透明色」で消去していること。
5. その Window 内部に通常色で、LineTo() や TextOut() によって図形や文字を
描いた後であること。
です。
MDIを使っている事や、CMDIChildWnd 動かすかどうかは関係ない様です。
CMainFrame をドラッグした時には遅く感じないのは、その動作についてはシステムが CPU
の優先順位を上げているからではないかと思います。
438:396
18/02/18 14:19:00.83 HH6qVqdM.net
>>419 さんの指摘は凄く役立ちました。有難うございます。
ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>416の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
>矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
「X側の描画性能の低下」が原因ではなく、「ピクセル値を比較する処理」自体が、
実は「静止状態」でも、常時、大幅に増加していた、ということです。
何の変化がないときにでも、百万ピクセルを比較し、ランレングスを導き出す処理を、
原則的には秒間20回もやっています。
また、図形が複雑だと、システムコールを呼び出す回数がランレングスの変化の回数倍
されます。例えば、直線をN本引いた場合、システムコールの回数が原則 3N (倍)になります。
縦方向が500ドットのWindowで、1本の直線を引いた場合、一回の処理で、最低でも
6,000回のシステムコールが呼び出されます。これが秒間20回も行われますので、
最低で、秒間12万回のシステムコールとなります。1回のシステムコールは、5(μs)
くらいはどうしてもかかるので、これだけで、0.6(秒)もかかってしまいます。
つまり、1秒間に0.6秒も無駄なシステムコールに時間を取られていると見積もれます。
直線を2本にすると、これだけでCPUがフルパワー状態になります。
439:396
18/02/18 14:38:25.11 HH6qVqdM.net
【厳密化】
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) で処理時間が
増えます。
10. 文字を描いた場合、大体、文字の複雑さに比例して処理時間が増えます。
440:396
18/02/18 15:25:59.15 HH6qVqdM.net
>>426
【訂正】
「6.」のランレングスの個数は、3N個ではなく、2N+1 個でした。
お騒がせしました。
441:login:Penguin
18/02/18 16:08:39.77 dARugMLm.net
>>426
update_surface_regionの方が効率悪そうなので、X側の描画性能が原因と推測した部分は撤回する。
Shape Extensionの仕様を見ると、
矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
あと、MDIウィンドウがXのWindowではないことは、xwininfoコマンドの結果でも確認できる。
442:396
18/02/18 17:01:36.91 hqeoLLBF.net
>>428
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。
443:396
18/02/19 12:40:07.08 v4nZjJQ1.net
特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。
444:396
18/02/19 15:28:56.74 v4nZjJQ1.net
調べてみると、/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 */
const char *get_dlldir( const char **default_dlldir )
{
*default_dlldir = DLLDIR;
return dlldir;
}
となっているが、DLLDIR が全ての拡張子の全ファイルを全文検索しても
どこにも定義されておらず、参照されているのも唯一この関数だけだった。
これだと、WINEDLLPATH で「Override」できないのも当然だけど、
そもそも、DLLDIR がどこで定義されているのかが分からないので
誰かの教えをいただきたいです。
445:login:Penguin
18/02/19 15:47:21.84 qkc2SRTD.net
見つかりました。wine/libs/wine/Makefileの中で、
config_EXTRADEFS = \
-DBINDIR='"${bindir}"' \
-DDLLDIR='"${dlldir}"' \
-DLIB_TO_BINDIR=\"`$(MAKEDEP) -R ${libdir} ${bindir}`\" \
-DLIB_TO_DLLDIR=\"`$(MAKEDEP) -R ${libdir} ${dlldir}`\" \
-DBIN_TO_DLLDIR=\"`$(MAKEDEP) -R ${bindir} ${dlldir}`\" \
-DBIN_TO_DATADIR=\"`$(MAKEDEP) -R ${bindir} ${datadir}/wine`\"
というのが。単語検索していたのが鬼門でした。
446:396
18/02/19 19:22:56.55 WuPPo4Ry.net
loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。
447:396
18/02/20 03:10:39.77 nCkYsCc8.net
surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。
448:396
18/02/20 05:59:07.45 nCkYsCc8.net
DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。
なお、>>434は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。
なぜ遅いままなのかは謎です。
449:login:Penguin
18/02/20 06:05:44.26 AmaI1OSV.net
2ch(5ch?)は人は多いけど基本的にユーザーレベルの人ばかりだから技術的な書き込みしても反応は鈍いね
Qiitaにでも書いてみたらどう？
450:login:Penguin
18/02/20 18:28:22.71 QMmYbOOf.net
本家にパッチ投稿もお願いしますw
451:396
18/02/20 18:49:16.00 nCkYsCc8.net
遅い原因の1つは、Onldle の中にあることが分かりました。
1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
それがとんでもなく重い事が判明。
2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
10*N 回 呼び出されるような感じです。タイマーメッセージがくる度に、
メニューなどを更新するためのメッセージが来ているような気がします。
多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
ならないんじゃないかと思います。 通常、OnCmdMsg は頻度が低いことが
前提になっているので、その中で多少重い処理をしていると、とんでもなく
重たくなる。
なお、透明色を使っている場合、update_surface_region の中の処理の軽重に
よって、描画速度が大幅に変わることも確認しました。
ランレングスを数えてリージョンを add_row している箇所を、単純に何も
数えずに行全体で、1個だけ add_row するように
452:修正してみると、描画が だいぶ速くなりました（透明にはなりませんが。）。
453:login:Penguin
18/02/20 18:56:15.10 nCkYsCc8.net
>>437
そうしたいんですが、何かと大変なんです。
1. メールアドレスの登録するのが、Linuxからだと大変。
2. git の仕様が良く分からない。
3. 回線が遅いので、Project を Fork して、git が Tree 全体を
アップロードしようとしてしまったりなんかすると大変な事になる。
4. だから、一部のファイルだけを UL したいが、コミュニケーションの
問題から事情を伝えて、そこまで行くかどうか分からない。
5. だから、独自にオーバーライドしようとしたのが、先日からここでも
書いていたことです。loader を修正して、かつ、環境変数を変えて
やれば、本家と統合しなくても、部分書き変えのような事が出来る。
454:login:Penguin
18/02/20 18:59:20.15 TT83z4l8.net
>>439
githubからでもプルリクエスト受け付けてるよ
455:login:Penguin
18/02/20 19:09:08.87 LN/W3cN7.net
先にURLﾘﾝｸ(bugs.winehq.org)に書いた方がいい
報告してあるとパッチ送る時説明が楽になるから
456:login:Penguin
18/02/20 19:12:23.54 hMkWg0ue.net
描画が早くなるならありがたい
素のWindowsより異様に遅いゲームとかあるし
457:396
18/02/20 20:06:46.63 ErFPSqeX.net
結論だけ書いておくと、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[] 配列と共通らしい。
つまり、Linux の描画関数は全く使わずに自前で画像をpixel配列に合成してから、
定期的に、XPutImage() などで実が面に描き込む、というようなことをやっているらしい。
458:396
18/02/21 16:48:35.77 SJPTXnf1.net
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()内 の両方にかかる時間 :
94 (us)
4. MDI Child Wnd をドラッグするときに、x11drv_surface_flush() が
呼び出される時間間隔 :
3～100 (ms) ---> 秒間 10回～330回
5. 肉眼で描画が更新されるまでに x11drv_surface_flush() が呼び出される回数 :
数10回 以上あることが多い。
1.～4. だけみると、高速に処理されている様に見えるけど、5. だけが理解できない。
カウンタを設けて数えてみると、実際に目では更新が起きてないのに、
ちゃんと、1～3 の全ての関数が数十回も呼び出されている。
ちゃんと「XFlush()」されているのに、なぜだろう？？？？
459:login:Penguin
18/02/21 17:03:51.93 SJPTXnf1.net
XSync() を追加しても、XShmPutImage() を XPutImage() に修正しても、
何をやっても見た目だけが更新されない。
460:login:Penguin
18/02/21 17:09:56.25 iuEniYB2.net
>>444
> update_surface_region() が遅いんだと思って、
> XShape の作成を、XShapeCombineRectangles() を使う方式から、
> XCreateBitmapFromData() と XShapeCombineMask()
> を使う方式へと変えた。
こうするとなんで速くなるの？
461:396
18/02/21 17:35
462::51.39 ID:SJPTXnf1.net
463:login:Penguin
18/02/21 17:39:34.11 SJPTXnf1.net
X の同期の問題ではなく、MDI Child Wnd の TITLE BAR をドラッグするとき、
なぜか、数秒経ってから、x11drv_surface_flush() がまとめて何十回も呼び出されている
可能性があるかも・・・。
デバッグ表示をリアルタイムで見ていると、見た目が変化する直前までデバッグ表示が
全く出ず、見た目が変化する直前に、どどっと、数十回分の x11drv_surface_flush()
がまとめて出てくる、という現象が起きている。
464:login:Penguin
18/02/21 17:56:34.37 iuEniYB2.net
>>448
flushしてないだけではなく？
465:396
18/02/21 17:57:13.78 SJPTXnf1.net
以下のコードが気になる。
message_count を減少させるのは唯一、wait_message() しか見つからなかった。
後は、check_for_driver_events() の中で単調増加してしまう。
メッセージがたまって初めて、flush_window_surfaces() が呼び出されるような
コードにも
/* check for driver events if we detect that the app is not properly consuming messages */
static inline void check_for_driver_events( UINT msg )
{
if (get_user_thread_info()->message_count > 200) {
flush_window_surfaces( FALSE );
USER_Driver->pMsgWaitForMultipleObjectsEx( 0, NULL, 0, QS_ALLINPUT, 0 );
}
else if (msg == WM_TIMER || msg == WM_SYSTIMER) {
/* driver events should have priority over timers, so make sure we'll check for them soon */
get_user_thread_info()->message_count += 100;
}
else get_user_thread_info()->message_count++;
}
static DWORD wait_message( DWORD count, const HANDLE *handles, DWORD timeout, DWORD mask, DWORD flags )
{
DWORD ret = USER_Driver->pMsgWaitForMultipleObjectsEx( count, handles, timeout, mask, flags );
if (ret == WAIT_TIMEOUT && !count && !timeout) NtYieldExecution();
if ((mask & QS_INPUT) == QS_INPUT) get_user_thread_info()->message_count = 0;
return ret;
}
466:396
18/02/21 17:58:18.49 SJPTXnf1.net
BOOL WINAPI DECLSPEC_HOTPATCH PeekMessageW( MSG *msg_out, HWND hwnd, UINT first, UINT last, UINT flags )
{
MSG msg;
USER_CheckNotLock();
check_for_driver_events( 0 );
if (!peek_message( &msg, hwnd, first, last, flags, 0 ))
{
DWORD ret;
flush_window_surfaces( TRUE );
ret = wow_handlers.wait_message( 0, NULL, 0, QS_ALLINPUT, 0 );
/* if we received driver events, check again for a pending message */
if (ret == WAIT_TIMEOUT || !peek_message( &msg, hwnd, first, last, flags, 0 )) return FALSE;
}
check_for_driver_events( msg.message );
/* copy back our internal safe copy of message data to msg_out.
* msg_out is a variable from the *program*, so it can't be used
* internally as it can get "corrupted" by our use of SendMessage()
* (back to the program) inside the message handling itself. */
if (!msg_out)
{
SetLastError( ERROR_NOACCESS );
return FALSE;
}
*msg_out = msg;
return TRUE;
}
467:396
18/02/21 18:24:27.09 SJPTXnf1.net
>>449
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。
468:login:Penguin
18/02/21 18:32:33.53 SJPTXnf1.net
GetMessage() の方もほぼ同じような感じかも。。
とにかく、flush_window_surfaces() がとてつもなく長い間、呼ばれないことが
あるコードになっている様に見えて、実際、実験してもそう思える。
469:login:Penguin
18/02/21 18:38:45.85 SJPTXnf1.net
そうか、もともとは、dirty bit 方式じゃないから、flush_window_surfaces() を呼ぶと、
再計算する必要が無いのに必ず再計算されてしまうから、呼び出す頻度を下げるしか
高速化する方法が無いために、そんな風なコードになっているのかもしれない。
470:login:Penguin
18/02/21 18:41:37
471:.14 ID:SJPTXnf1.net
472:396
18/02/21 18:58:29.00 SJPTXnf1.net
元々の Windows では、LineTo などを実行すると瞬間的に実画面に反映される。
だから、そもそも Flush せずに見えないままの描画が残っているなんて時間は
ほぼ 0。
そう考えると、。Wine のこの実装はおかしいな・・・。
1. そもそもメッセージループを回している時しか flush される可能性が全くない
実装になってしまっているらしい。
2. メッセージループを回していても、メッセージがキューに残っている時は、
100回程度メッセージを読まない限り、flush されない。
Windows を「エミュレート」するのであれば、例えば、描いてから 50(ms) 経てば、
必ず flush する、という実装でなくてはならないはず。
Linux では、タイマー処理が難しいのかな？？？
473:login:Penguin
18/02/21 19:03:48.84 SJPTXnf1.net
1. Windows (もちろん、NT系) の場合は、メッセージ・ループ長く帰ってこないプログラムも
絶対ダメというわけではない。
2. そういうプログラムの場合、Wine 側は、描画を、一定時間間隔で、別スレッドの
タイマー割り込みの中などで flush するようにしないと、 正しく、Emulation 出来
ないはず。
474:login:Penguin
18/02/21 19:05:31.10 SJPTXnf1.net
割り込みなら、別スレッドを起こす必要が無かった。スマソ。
あと、誤字訂正：
誤： メッセージ・ループ長く帰ってこないプログラムも
正： メッセージ・ループに長く帰ってこないプログラムも
475:login:Penguin
18/02/21 19:13:35.32 iuEniYB2.net
うーん
これがボトルネックになっているようには見えない
申し訳ないんだけど描画が遅くなる条件をもう一度書いてもらっていいですか？
476:396
18/02/21 23:23:31.14 4g3iPm6d.net
うーんと。それはまあちょっと置いておいて、、、。
MDI Child Wnd の TITLE BAR を Drag している最中、メッセージループは一つも
回ってないんじゃないかと思う。
だから、>>456 の「1.」に書いた「flushされる必要条件」が満たされてない。
そのため、surface の pixel配列の内容が実画面に反映されないのではなかろうか。
477:396
18/02/21 23:38:56.14 4g3iPm6d.net
ドラッグ中にマウスを静止させてしばらく待っていると、 x11drv_surface_flush() と
flush_surface_region() の両方が呼び出された事が FIXME 出力で確認できた。
静止させずにマウスをドラッグし続けると、FIXME 出力が全くでない。
しかも、それを行った時間が長いと、マウスボタンを離した後も、非常に長い間
システム全体がハングアップした様な状態になる。そして、長い沈黙の後、FIXME出力が
出る。
この沈黙の時間は、それまでドラッグしていた時間に比例しているように思える。
なぜだろう？？？ これはどこかに「何かが溜まっている」時の現象の様に思える。
しかし、>>450 を見ると、message_cnt は、減らされるときは、一期に 0 になるのであって、
少しずつ減らされるわけではない。
謎だ・・・。
478:login:Penguin
18/02/21 23:42:58.43 iuEniYB2.net
単にイベントを送信する側でバッファリングしてるんじゃないの？
479:login:Penguin
18/02/21 23:50:18.32 iuEniYB2.net
まあ最初からマルチスレッド意識して書いた感じではないなと思うけど90年代から開発されてるわけだしそのへんはご愛嬌じゃない
480:396
18/02/22 00:35:51.88 9+xI5ulA.net
>>450-451 辺りのソースを見ていて、背理法で語ってみたい。
仮定1：「Drag 中でも、PeekMessage されている。」 と仮定する。
仮定2. 透明化した際に重くなるのは、flush_window_surfaces() と、
そこから呼び出される update_surface_region() のみだと仮定する。
補足： update_surface_region() は、透明化のための Shape の作成の処理が
されるので、重い。
flush_window_surfaces() は、update_surface_region() を呼び出す
以外にも、XPutImage() 系の処理が入るので、さらに重い。
仮定2については、透明化時に、それ以外に重い関数が出現する可能性を否定は
できない。なぜなら、surface の処理は、透明化しない時には行われないかも
知れないからである。その場合、LineTo の関数が切り替わる。
1. FIXME で見ている限り、ドラッグ中は、それらの関数は全く呼び出されない。
2. >>451 を見ると、PeekMessage した際に、キューにメッセージが残ってないなら、
flush_window_surfaces() が呼び出されるはず。
3. 「仮定2」 の関数は呼ばれてないのだから、キューのメッセージは、透明化され
てない場合と同程度に高速に処理されてもおかしくない。
4. もしそうであれば、キューのメッセージはあっという間に「空」になるはず。
5. 空になったとしたら、「2.」の通りに、flush_window_surfaces() が呼び出されるはず。
6. しかし、「1.」で述べたように、実験的には、flush_window_surfaces() は呼び出されてない。
7. 矛盾である。
8. 背理法により、これは、仮定の少なくとも一方が間違っている事を意味する。
481:396
18/02/22 00:45:26.84 9+xI5ulA.net
あるいは、Peek されるだけで、一部のメッセージは取り残されるなら・・・。
482:396
18/02/22 01:30:28.67 9+xI5ulA.net
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()
最後の関数は、タイトルバーをドラッグを開始直後に一回だけ呼び出される事
を確認した。その後のドラッグ中は呼び出されず、この関数の内部でドラッグ
の処理がされている可能性が高い。
この最後の関数の中に、次のような、メッセージ・ループがある：
if (!GetMessageW( &msg, 0, 0, 0 )) break;
if (CallMsgFilterW( &msg, MSGF_SIZE )) continue;
/* Exit on button-up, Return, or Esc */
if ((msg.message == WM_LBUTTONUP) ||
((msg.message == WM_KEYDOWN) &&
((msg.wParam == VK_RETURN) || (msg.wParam == VK_ESCAPE)))) break;
if ((msg.message != WM_KEYDOWN) && (msg.message != WM_MOUSEMOVE)) {
TranslateMessage( &msg );
DispatchMessageW( &msg );
continue; /* We are not interested in other messages */
}
483:396
18/02/22 01:32:06.83 9+xI5ulA.net
さらに次のような、枠だけを書くか、実際に動かしてしまうコードが続く :
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 );
}
484:396
18/02/22 02:01:49.71 9+xI5ulA.net
あー。
FIXMEを消してしまっていただけだった・・・。
update_surface_region() や、flush_window_surfaces() は、
ドラッグ中でも、マウスを静止してしばらくすると呼ばれるようです。
マウスを動かしつづけていると呼ばれないらしい。
485:396
18/02/22 02:44:50.36 9+xI5ulA.net
【やっと原因判明】
CMainFrame を WS_EX_LAYERED で透明化していて、今回の条件に当てはま
486:る時に、 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 -->USER_Driver->pMsgWaitForMultipleObjectsEx() -->X11DRV_MsgWaitForMultipleObjectsEx() の最後の関数の中で停止してしまう。 正常なら、WM_NCMOUSEMOVE メッセージが到着することによって、関数から 戻って来るはずだと思われる。
487:396
18/02/22 10:45:19.02 9+xI5ulA.net
>>469
2つ目の WaitForMultipleObjectsEx() の中で停止してしまっていることが判明。
本来、先頭に Msg が付く方の API は、メッセージと HANDLE の両方を同時に
監視するようなコードでなくてはならないハズなのに、そうなってないらしい。
process_events() が、MotionNotify の XEvent が来ていたら WM_MOUSEMOVE
メッセージをキューにポストするらしいが、最初に一度だけ調べて XEvent が
来ていない場合は、以後、全く XEvent を調査せずに他の HANDLE 群の変化だけ
を待機してしまうらしい。
DWORD CDECL X11DRV_MsgWaitForMultipleObjectsEx( DWORD count, const HANDLE *handles,
DWORD timeout, DWORD mask, DWORD flags )
{
DWORD ret;
struct x11drv_thread_data *data = TlsGetValue( thread_data_tls_index );
if (!data) {
if (!count && !timeout) return WAIT_TIMEOUT;
return WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
}
if (data->current_event) mask = 0; /* don't process nested events */
if (process_events( data->display, filter_event, mask )) ret = count - 1;
else if (count || timeout) {
ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
if (ret == count - 1) process_events( data->display, filter_event, mask );
}
else ret = WAIT_TIMEOUT;
return ret;
}
488:396
18/02/22 10:46:53.05 9+xI5ulA.net
【通常時、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 );
---> __wine_send_input( HWND hwnd, const INPUT *input )
---> send_hardware_message( hwnd, input, 0 );
SERVER_START_REQ( send_hardware_message ) {
switch (input->type)
case INPUT_MOUSE:
}
---> wine_server_call( req );
---> DECL_HANDLER(send_hardware_message)
(send a hardware message to a thread queue)
---> queue_mouse_message( desktop, req->win, &req->input, req->flags, sender );
messages[MOUSEEVENTF_MOVE (1)] = WM_MOUSEMOVE
---> queue_hardware_message() : WM_MOUSEMOVE
list_add_tail( &input->msg_list, &msg->entry );
set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
--->
if (!always_queue || merge_message( input, msg )) free_message( msg );
else {
msg->unique_id = 0; /* will be set once we return it to the app */
list_add_tail( &input->msg_list, &msg->entry );
set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
}
489:396
18/02/22 10:47:48.18 9+xI5ulA.net
【WM_NCMOUSEMOVE は WM_MOUSEMOVE から修正される】
PeekMessageW() または GetMessageW() の中で、hittest が HTCLIENT 以外
の場合は、WM_MOUSEMOVE が WM_NCMOUSEMOVE に修正される :
PeekMessageW() または、GetMessageW()
---> peek_message()
---> switch(info.type)
case MSG_HARDWARE :
---> process_hardware_message()
---> process_mouse_message() {
if (hittest != HTCLIENT) {
message += WM_NCMOUSEMOVE - WM_MOUSEMOVE;
wparam = hittest;
}
490:login:Penguin
18/02/22 15:16:45.32 9+xI5ulA.net
頭に Msg が付かない方の WaitForMultipleObjecstEx() も
挙動がおかしい。 timeout に 0 を指定しても、無限に
待機してしまうことがある。
491:396
18/02/22 16:31:11.62 9+xI5ulA.net
Msg が付く方の WaitXxxx で、usleep() で、0.3�
492:bほど停止しながら、 Polling (Loop) するようにしてから、FIXMEでメッセージを観察してみた。 普段は、usleep() 命令は、呼び出してから 0.3 秒で戻ってくる。 ところが、先日からの遅くなる条件でドラッグし続けた場合、単純な usleep() の 1命令が、呼び出してから、永久に戻ってこなくなる。ドラッグをやめると、 人間が長く感じるほどの長い時間が経過してから戻ってくる。 これは、WINEの問題ではなく、Linux Kernel の問題だろうか？？？
493:396
18/02/22 16:45:23.34 9+xI5ulA.net
やったことをもうちょっと詳しく書いておくと、
>>470 の X11DRV_MsgWaitForMultipleObjectsEx() の関数の2番目の
WaitForMultipleObjectsEx() の呼び出しの箇所を次の様に修正してみた。
(FIXME はもっと付けてあるが省略):
if ( timeout == INFINITE ) {
//*中略*
for ( ;; ) { // 苦肉の polling loop :
ret = WaitForMultipleObjectsEx( count, handles, bWaitAll,
0, // (ms) (指定しても上手く行かないので0にしてみた)
bAlertable );
if ( ret == WAIT_TIMEOUT ) {
if ( process_events( data->display, filter_event, mask ) ) {
ret = count;
break;
}
}
else {
break;
}
FIXME( "call usleep\n" ); //(1)
usleep(1000 * 300); //(2) 仕様上は、300(ms)後に戻る。
FIXME( "returned from usleep\n" ); //(3)
}
}
else {
ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
}
該当の条件の時にマウスを動かし続けると、(1)のメッセージが出た後、
(3)のメッセージが、事実上、無限に待っても出てこなくなった。ドラッグして
ないときには、usleep()の仕様通り、300(ms)後にメッセージが出てくる。
494:396
18/02/22 17:29:11.00 9+xI5ulA.net
かなり色々やったつもりだけど、ちょっとこれ以上深入りは難しいので、もう諦めようかも。
以下の上京からするとLinuxカーネルの問題かも知れない：
1. タスクバーも操作不能になる。
2. 単純な usleep() も無限に帰ってこない。
495:396
18/02/22 17:39:46.66 9+xI5ulA.net
Wineでは、昔の MSDN Library の CD もインストールは出来ただが見られなかった。
hh.exe が xxx.COL ファイルを開けないと言ってくる。
yyy.CHM ファイルは、開くことはできたが、右のペーンだけが見えて、左側の目次や
検索のぺーンには何も表示されない。
今回 WINEのソースを見て思うのは、意外とちゃんと書かれていないということ。
MsgWaitXxxx にも、戻り値が明らかに間違っている部分を発見した。
また、TRUE (1)を引数に渡す必要があるところで、1ではない非0 の値を渡している
箇所も見つかった。そのようなコードは後々問題を来すかも知れない。
それに、MsgWaitXxx もちゃんと書かれていない。同時に待機するのは、アプリ・プログラマ
がどんだけ頑張ってもかけないから API が用意されているのだが、そこに明らかな
ロジックの間違いがある。
有名なアプリだけはちゃんと動作するが、実は模倣の程度が意外と低いかも。
有名なアプリだけは動くように調整されている・・・。
496:396
18/02/22 18:45:28.30 9+xI5ulA.net
usleep() の部分を setitimer(), pause() に変えてみたら、そこは指定した
時間でちゃんと帰ってくるようになった。でも、Linux全体が停止に近い状態に
なる症状は変わらない。端末内の FIXME の表示が途中の文字まで書かれた状態で
改行までいく前に長い間停止する現象が起きてしまっている。
497:396
18/02/22 23:32:51.41 9+xI5ulA.net
X Window System は、Server と Client で通信を行っているから、Client側では処理が
一瞬で帰って来ているように見えても、Server側では処理に凄く時間がかかっている可能性
があるかもしれない。だから Client側で、関数の呼び出しの前後の時間を計測をしても
それは単にServer にコマンドを送る処理の時間を計測しているに過ぎないのかも
知れない。イメージのバイト
498:数が多いいときには、通信時のデータ・コピーに時間がかかる から多少時間がかかるかも知れないが、それはまだ表面上の時間に過ぎず、Server 側は Shapeのくり抜き処理(?)や重ね合わせの処理に膨大な時間がかかっている可能性も否定できない。 だから、XCreateBitmapFromData(), XShapeCombineMask(), XPutImage() の前後の時間を 計測しているだけでは速く見えても、見えない場所でCPUパワーを全開にしてがんばっても まだ処理を終えてないのかもしれない。 だから、Linux Kernel は、X Serverに CPU パワーを全開まで与えようとしている・・・。 Client側で計測した時間は見せかけの時間であって、処理全体の時間ではない・・・。 だから、タスクバーなども動かず、デバッグ表示の端末の文字も中途半端な場所でWAIT 状態になってしまう・・・。 これが真相だろうか？
499:396
18/02/22 23:41:51.80 9+xI5ulA.net
そういえば、update_surface_region() が呼び出されたことを示すデバッグ文字列は、後からまとめて
ドドッと出てくる。それは、文字列が「出てない」間には関数が呼ばれてないことを意味する
訳ではなく、実は呼ばれてはいるが、文字列が flush されてないか、または、flush
されていても、端末に CPU リソースが割り当てられないから、文字表示だけが行われずに
文字列がバッファに溜まった状態になってしまっている・・・・。
こう考えれば辻褄が合うかも。
500:396
18/02/23 00:00:03.49 rGoiNTvu.net
本家の Windowsでは、描画処理が重いときには、OnPaint や OnDraw の関数が終わるまで
の時間も長い。だから、メッセージがたくさんたまっているのに描画が追いついていない事は、
メッセージ・キューに残っているメッセージの個数が多い事で大体の判断が付く。だから、
InvalidateRect(NULL)をしておけば、描画が追いついてない場合は、メッセージループ
が WM_PAINTメッセージを送るタイミングを自動的に後回しにしてくれる。
ところが、X Window System の場合、実際の描画がまだ終わってない場合でも、
「描画関数」自体は一瞬にして戻ってきてしまうから、上記のアルゴリズムが「勘違い」を
起こしてしまうことがある・・・。
そらに悪い事に、WINEが、内部で Surface を持っているときには、LineTo 関数自体は高速に
処理を終えるのに、アプリが予想もしないタイミングで、時間の掛かる flush の処理が行われ
てしまう。
そうすると、OnPaint は高速に終わったと勘違いして、WM_PAINT メッセージが、マウス・メッセージに
完全に連動して大量に生成されてしまう。すると、Pending 状態の X Window の処理がどんどん
待ち行列に溜まっていってしまう。
ドラッグ中は、WM_PAINT が秒間20回も送られるのに、Server が実際の描画を終えるのは、
その何十倍も時間がかかってしまう。
こんな感じだろうか。
501:396
18/02/23 00:09:19.71 rGoiNTvu.net
さらに、>>466-467, >>469 に書いた、WINPOS_SysCommandSizeMove() は、
CWinApp などとは別の、独自のメッセージループを持っている。
そこでは、さらに、WM_PAINT が不適切に大量に発生してしまっている
可能性がある。
だんだん分かってきたかも。