今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
Linux上でWindowsのアプリを動作させるソフトウェア
Wineに関する情報交換スレ。
前スレ
今夜も Wine で乾杯! - 20本目
https://mao.2ch.net/test/read.cgi/linux/1455088008/
Wine本家
http://www.winehq.org/
http://wiki.winehq.org/
動作報告Wikiや過去ログなど
http://www.2chlinux.org/index.php?FrontPage
ここにパッチをうｐするときはgzipやbzip2で圧縮した上で
base64などでエンコードしてください。おながいします。
動作報告は>>2のテンプレ使用を推奨。 ＝＝＝＝Wine動作報告テンプレv1.0rc1＝＝＝＝
アプリケーション名:
アプリケーションのバージョン:
Wineのバージョン:
ディストリビューションとアーキテクチャ:
レーティング：
動作の状態:
/*バグ回避方法など詳しく書いてください*/
動作には以下の作業が必要:
/*起動に必要なファイル名の変更やレジストリ編集など*/
以下のDLLオーバーライドが必要
[AppDefaults？？実行ファイル名.exe？？DllOverrides]
"DLL名1" = "native"
"DLL名2" = "native"
/*レーティングについて
http://appdb.winehq.org/help/?sTopic=maintainer_ratings より意訳
Pratinum： winecfg設定の変更やDLLオーバライドなしで完全動作
Gold： 完全動作するが、DLLオーバライドや、wineDoors,PlayOnLinux等設定ソフトの使用が必要
Silver： とりあえず基本機能は動く。 ゲームの一人プレイはできるがマルチプレイができない 等
Bronze： 起動はするが挙動がおかしい。画面表示の異常やfontの乱れ、動作が遅い 等
Garbage： インストールできない、起動できない、アプリケーションが使用に耐えない。*/ いちおつ
Mint17.3だけどwineを1.6.7からstagingにしたらexe起動用のランチャーが機能しなくなったでござる
homeにwinappフォルダ作ってそこに格納して使ってて、
デスクに置いたMeryのランチャーが起動しなくなったわ
Mery.exeを直接叩けば普通に起動するしランチャーもver下げれば動くんだけど DMMで買ったゲームをやろうとしたんだけど
ucx.ocx failed to register
というエラーでソフト電池が入れられなかった
VC++でプログラム書いてた頃もレジストリエラーとか全然わからなくて勘で解決してたのでこれもサッパリわからん
でも登録できたところでソフト電池みたいな常駐ソフト動かすのはさすがにキツそうだなー 仕方がないから久しぶりにwindows使ってるけどWindows Module Installer君が延々とCPU30%使ってるの本当に嫌 ソフト電池は無理やろ
へんなのがCPU食ってるのはWindowsUpdateを切ればいいんじゃないか 最近debian sid 32bitでMp3tagが死んでる……
debianのクリーンインスコしてみようかなぁ windows updateは手動にするのが鉄則だしね
テレメトリ回避のために適用するパッチの順番変えたり
インスコ短縮のために先にカタログから落としてローカルインストールにしたり
ほんと不毛なことしたもんだわ なんかメモリ食ってるなと思ったらwineで起動したエディタがゾンビになってたでござる
具体的にはMeryに表示された文字が消えて描画なんたらのエラー出て死ぬ Wine on Windowsの
BoxedWineの話題はNG？ ワイン2.16発売
2017年9月1日
Wine開発リリース2.16が利用可能になりました。
このリリースの新機能 ：
RichEditでメタファイルを貼り付けることができます。
グレースケールのPNG画像のサポートが向上しました。
ライブラリの読み込みにおける安全機能のサポート
GdiPlusでの変換の処理が改善されました。
DirectWriteのレンダリングの改善。
さまざまなバグ修正。
ソースは現在利用可能です 。 バイナリパッケージはビルド中であり、それぞれのダウンロード場所にすぐに表示されます 。 https://source.winehq.org/source/dlls/ntdll/heap.cのRtlCreateHeapにunknownとかいう引数があるがぐぐったら普通にドキュメント(↓)出てきたんだが
https://msdn.microsoft.com/en-us/library/windows/hardware/ff552159(v=vs.85).aspx
こういうのってドキュメントがなかった時に作ったのがそのままになってるんかな
それとも自分が何か勘違いしてる……？ wineでゲーム起動中にwinecfg起動したらジョイコンが認識しなくなってオワタ
jstest-gtkで確認しても見事に認識されない
USBポート変えてもPC再起動しても直らんし不用意なことはするもんじゃないな
Mint17.3でwine-2.16 (Staging) IE(っていうかIEコンポーネント)でamazonにログインしようとして、
正しいIDとパスワードを入力しても、パスワードが違うといって
はねられてしまうんだけど、原因分かる人いませんか。
他のサイトは大丈夫だけどamazonだけダメ。
Ubuntu 16.04.3 LTS + wine 2.16 + wine gecko 2.47 という環境です。 linux ネイティブのブラウザではログインできるの？ linuxネイティブ、win32、どちらのfirefoxでもログインできます。
wine上でAmazonで買い物したいわけではなく、Amazonアカウントで
oauth認証するアプリを使いたいんですよね。
ブラウザ立ち上げてくれればよいものを、自分でIEコンポーネント呼んでるんです。 一回windowsで認証した後コンフィグだけ移植できないの？ ログインできないことは確認できたけどweb知識ゼロなので原因とかサッパリですね……
勉強します…… >>24
なるほど。ファイルなのかレジストリなのか。。。
>>25
私の環境だけではないことが確認できてよかった。
公式に報告してみようかなあ。 ここに張れと言われました
Mint18.2cinnamonにwine18
ここに手持ちのoffice2000をインストールしてみた
oleaut32.dllのエラーが出たのでwindows7用のoleaut32.dllをダウンロードしてきてwindows/system32に入れた
http://www.filehelp.jp/dll/oleaut32-dll
元からのoleaut32.dllは先にoleaut32_old.dllとリネームしておいた
これでoffice2000をインストールできた
https://i.imgur.com/LtG5v53.png
合ってる？ >>28
手持ちのofficeが無いので2007enterpriseのフリー英語版と2013proのフリー英語版を探してきました
2013はisoのサイズが5.2Gもあるので２層のDVD-Rを買ってこないといけないので今日はパス
とりあえず2007を入れてみました
wineは2.16にアップデートして2013をインストールできるように設定を変えてます
レジストリエディタまで使って設定するのが笑っちゃいます
結果はOKでした
全部ちゃんと動きます
英語版なのはご愛嬌です
これから不具合を探してみます
https://i.imgur.com/A5MV8tM.png >>31
office2007はパワーポイントがちょっと難しいかもしれません
なかなか起動しなかったりセーフモードになったり
ここが鬼門かも
exelとwardはまったく問題なし
アクセスとパブリッシャー、アウトルックもOK
パワーポイントに目をつぶれば普通に使えると思います あと、先に入れてた0ffice2000が消されて2007に入れ替わってしまってました
あとからまた2000を入れれば共存できるのかもしれないけどそれは後日 東方の曲を聴くTHXXBGM使ってるけど曲を増やすwinmm.dllが認識されないや
追加されるはずの心綺楼と深秘録のパスが出てこなくて参る 俺メモ
wineでsandobox化したいならfirejail導入してこうやる
firejail --noprofile --net=none -- wine MyShitty.exe unity web playerって今でも動かせますか？
少し前までpipelightを使えば動かせましたが今はどうです？ >>34
.wineのwindows/system32にwinmm.dllはありますか？
もし無いようなら、下記からwinmm.dllをダウンロードして
.wine/drive_c/windows/system32に入れてみて下さい
それで大丈夫なはず >>37
system32の方のwinmm.dllはあったかな
verはwine-2.0.2でmd5は2d92cd12f7ee8de05e91f4c454be9422
ttp://resemblances.click3.org/product_list/index.cgi/detail/83
ただこっちが言った方はあくまで拡張だからね
自前で曲目ファイル作れば新たに追加は可能らしいけども >>39
実行ファイルと同じディレクトリにwinmm.dllを置くと書いてましたね
失礼しました Adobe AIRのアップデートが上手くいかん。
Wine 2.0.2 on Xubuntu 16.04.3
Adobe AIRは、Wine 1.6使ってたときにインストールした。
Wine 1.6だとインストールもアップデートもサクッと行くんだけど…
Adobe AIRをアップデートするときだけ、Wineを1.6に戻すとか? The Wine development release 2.17 is now available.
What's new in this release (see below for details):
- Better support for grayscale mode in DirectWrite.
- Per-application StartupWMClass in desktop files.
- Virtual memory compatibility improvements.
- Palette handling improvements in WindowsCodecs.
- Reply messages improvements in WebServices.
- Various bug fixes. >>32
いろいろ調べてみると2013でもPower Pointは動かないようで、修正部屋行きらしいです developmentバージョンだからもう少し待って安定版リリースを待つよ ワイン2.17発売
2017年9月15日
Wine開発リリース2.17が公開されました。
このリリースの新機能 ：
DirectWriteのグレースケールモードのサポートが改善されました。
デスクトップファイル内のアプリケーションごとのStartupWMClass
仮想メモリの互換性が向上しました。
WindowsCodecのパレット処理の改善
WebServicesの返信メッセージの改善。
さまざまなバグ修正。
ソースは現在利用可能です 。 バイナリパッケージはビルド中であり、それぞれのダウンロード場所にすぐに表示されます 。 もしかして：公開、発表
>>50
もうそんな時期なぬね 2.10以降ほっといたから久しぶりにコンパイルしるかな 何度も挑戦してみたがとうとうギブアップ
office2013がどうしても入らない
インストール途中何度もcinnamonが落ちまくる
やっと入って起動したと思ったらウィンドウがまっ黒のまま
回避設定してるはずなのに黒いまま
2007は何の問題もなくインストールできたから余計にもどかしい
Mint18.2cinnamonではいまのところoffice2013は無理みたい
誰か2013入れた人います？ ちなみにwineは安定版開発版をいろいろバージョンを替えてやってみたけどやっぱりだめだった
仮想だからダメなのかなあ
しばらくoffice2013から離れてみます どういうエラーで落ちてるの？
ターミナルの出力は？
(面倒だから検証したくない) >>56
エラーログ取ってなかった
すんません
たて続けにcinnamonが落ちてcinnamonを再起動しますか？と出てくる
で、cinnamonを再起動したら直ぐにまた落ちる、これの繰り返し
再起動しないで互換モードだと落ちなくなるけど今度はターミナルが使えない
でも最後までインストール完了したのはこの互換モードの時だけでした
それでもエクセルを立ち上げたらまっ黒、ワードでまっ黒、話にならないです
2013をサポートしてるとはいったい何だったのか状態
それともウチだけ？
安定版も開発版も関係ないですね
成功したのは開発版の2.16だったし
まあ、落ちついたらまたトライして今度はきちんと原因を調べてみます >>57
Wine 2.0の詳細リリースノートによると
>... Basic support for making SOAP calls is also included. This enables Microsoft Office 2013 online activation.
まともに動くとは言っていない >>58
だったらなおのこと、動かしてみたい今すぐには無理でも、近い将来動くのを信じたい
まあ、ボチボチトライしてみます ちゃんと動いてる人がいるんですね
やっぱり何かが間違ってるんですね
またやってみます windows7で偽装したいんだが設定が保存されない
どうすればいい？ winetricks → select the default wineprefix → change settings → win7 でいいんだよね？
起動すると保存されずに元にもどってしまうんだが wineserver再起動させてないんじゃない？winetricksでレジストリを書き換えてるから。
winetricksをテキストファイルとして開けば何が行われるかわかるよ。 / にアクセスできないようにする方法ありませんか？
.wine以下へのアクセスだけで閉鎖させたいんだけど dosdrive/z:のパーミッションを変えるとか？ >66
$ cd ${WINEPREFIX:-$HOME/.wine}/dosdevices; rm z:; ln -s c: z:
>67を参考にして試したけど、たぶんこれでいいんじゃないかな
c:とz:しか有効じゃない環境で、ln -s c: z: したらc:配下からアクセスできない場所ではexeが起動しなくなったよ virtualboxにMint18.1をインストールしてやっとoffice2013を入れることができた
https://i.imgur.com/qTVu65e.png WordもAccessもちゃんと起動していけそうです
でもoffice2007と同じくPower Pointは立ち上がらなかった
同じような報告が上がってるようでやはりPower Pointはダメみたい
他のもちゃんと使えるか試してみます
https://i.imgur.com/VKC4Y7N.png
https://i.imgur.com/Trjxfaf.png 動作報告は>>2のテンプレ使用を推奨
できればWineHQのAppDBに追加も
Microsoft PowerPoint
https://appdb.winehq.org/objectManager.php?sClass=version&;iId=34965 ＝＝＝＝Wine動作報告＝＝＝
アプリケーション名:Power Point
アプリケーションのバージョン:2013
Wineのバージョン:2.0.2
ディストリビューションとアーキテクチャ:Mint18.1 64bit（virtualbox）
レーティング：Garbage
動作の状態:office2013の他のアプリは立ち上がるがPower Pointだけは立ち上がらない
configuration progressが動作するがsafe modeでも起動しない
動作には以下の作業が必要:
/*winetricksでriched20.dllをインストール、それからwinecfgでdllをオーバーライド*/
riched20.dll＝native（windows）で設定
/*レーティング
現時点ではwineのバージョンが2.0.2のstableなので古すぎるのかもしれない
新しいバージョンを試してみようと思う
ただひとつ、実はoffice2007でもPower Pointは動かなかったのだが、上記の設定を試したところoffice2007 途中でごめんなさい
office2007では上記の設定でPower Pointは見事に動いた
https://i.imgur.com/phHtH9U.png
wineのバージョンを上げて再度office2013のPower Pointを試してみます ＝＝＝＝Wine動作報告＝＝＝＝
アプリケーション名:Power Point
アプリケーションのバージョン:office2007
Wineのバージョン:2.0.2 stable
ディストリビューションとアーキテクチャ:Mint18.2 64bit
レーティング：Gold
動作の状態:
office2007はオーバーライド等一切無しでインストールでき、ExelやWordは問題なく使えたがPower Pointは
起動せず
そこで以下のDllをオーバーライド
winetrickてriched20.dllをインストール
winecfgで設定をriched20.dll=native(windows)にしてオーバーライド、これだけで起動できた
サンブルのテンプレートを開いてみたところ、問題なく動作した
細かい不具合は確認中 >>78
乙
なんだかんだ言ってOfficeが動くと助かることはあるもんね >>67-69
dosdeviceのz:をc:にリンクしたり空のディレクトリにしたりは試してみましたが
そもそもドライブレター以前の段階で
explorerから見えてしまっています
デスクトップ？にドライブのアイコンと/が出てしまってる きのうは大ボケかましてました
wineを開発版に入れ変えようとwineを削除しようとしたけどどうしても出来ない
代わりにvirtualboxのスナップショットが何度も立ち上がる
当たり前ですね
virtualboxではwineのstableをいれて設定も全部完璧にした状態でスナップショットを作ってるからもうwine込みでOSと化してるわけで
それに気づかず格闘しまくって無駄な時間を過ごしてました
あ～あ >>70
wineのバージョンやMSのフォントとか作業手順を箇条書きにしてくれると嬉しい。 >>84
安定版の2.0.2できちんと設定すればoffice2013のインストールそのものは可能ですが、オーバーライドしてもPower Pointは動かないのといまひとつ動いてない感じがするので安定版ではまだ
office2013は厳しいと思います
開発版かバグフィクス版を試してみますがもう少し時間がかかりそうです
全部できたら詳細を書き出してみます >>86
ありがとう。助かる。マジで頼む。(^^)/
WineHQ - Microsoft Office (installer only) 2013 (32 bit)
https://appdb.winehq.org/objectManager.php?bShowAll=true&;bIsQueue=false&bIsRejected=false&sClass=version&sTitle=&sReturnTo=&iId=26323
wineのバージョンで動いたり動かなかったりするのが謎。
根本的な原因を突き止めていないのだろうか？ blueMSXが使えない
ウィンドウは出るしメニュー設定等のUI部分は動くけど
いざMSX開始ってボタン押すと完全に固まってうんともすんとも
終了もできなくなるからタスクモニターからkillしかなくなる
助言求む 「日本語版のwindows専用です」っていって終了するアプリ
「デバッガーがあるので終了します」っていって終了するアプリ
これらに対して偽装？する設定はありませんか
というか他のアプリあらだと日本語版windowsという扱いになってたし
デバッガーも使ってないんだが >>89
>日本語OS
レジストリだけではダメでパッチ必要だった気がする
このへんとか参考にしてみたら？
https://github.com/mattintosh4/osx-wine-patch/blob/8ca5fd874366029594a77ce79e73595b06f36c14/wine_changelocale.patch
>デバッガー
単なる誤動作なのでケースバイケースだしどのAPIが原因なのか調べないとなんとも言えない
ただ比較的難航することが多いように思う
両者ともデバッガでexeをいじるという手も考えられるがまあ最終手段だろうな…… The Wine development release 2.18 is now available.
What's new in this release (see below for details):
- Radial gradients in Direct2D.
- Asynchronous message support in WebServices.
- Virtual memory write watches improvements.
- FreeType 2.8.1 compatibility fixes.
- Various bug fixes. ＝＝＝＝Wine動作報告＝＝＝
アプリケーション名:Power Point
アプリケーションのバージョン:MS office2013
Wineのバージョン:2.0.2stable
ディストリビューションとアーキテクチャ:Mint18.2 64bit（virtualbox）
レーティング：Garbage
動作の状態:ExelやWordやAccessは立ち上がるがPower Pointは立ち上がらない
configuration progressが動作して起動はしない
winetricksでriched20.dllをインストール、それからwinecfgでdllをオーバーライド
riched20.dll＝native（windows）に設定したがやはりダメ
現時点ではwineのバージョンが2.0.2stableではやはりPower Pointが起動しない
wineのバージョンが安定版なのでPower Pointを使わないのであればこれでもいいという人もいるかもしれない
開発版の最新版2.18はMint18.2ではoffice2013自体エラーが出てインストールできなかった
もう少し設定を変えていろいろ試してみます 昨日今日といろいろやってみて限界が見えたのでこの辺で一段落させます
結論から言ってMInt18とoffice2013は相性が良くないです
Word、Exel、Accessは普通に使えます
問題はPowerpoint
はっきり言って全くダメでした
インストールはできますが起動しません
いろいろ試してみて立ち上がったのが１回だけ
セーフモードで２回
一応起動する片鱗は見せてくれましたがそれだけ
Mintでは全く使えません
office2007ならこんな感じでネットから落としたサンプルも問題なく動くんですが
https://i.imgur.com/Vcq0Ugp.png
でも、PowerPointはいらないという人なら、WordやExel中心なら十分いけると思います
一応詳細をここに書いておきます
Mintはダメでも他のディストリならPowerPointも普通に動くかもしれません 乙。
ディストリというかDEやディスプレイドライバのせいかもしれない。
chrootや仮想環境やi386アーキでやったらうまくいくかも・・・
仮想環境で動かすならWindows自体を動かせやってことになるけどw wineはstag版の2.4を使います
これが最新のようです
Mintではこれと安定版の2.0.2しかoffice2013はインストールできませんでした
wineをインストール
sudo add-apt-repository ppa:wine/wine-builds
sudo apt-get update
sudo apt-get install --install-recommends winehq-devel
そのまま続けてwinbindをインストール
sudo apt install winbind
さらにwinetricksをインストール
これも本体のを使います
Mintのリポジトリのはエラーで使えませんでした
wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks
sudo cp winetricks /usr/local/bin winetricksはadobeairが40xのは使わないでください
あとでエラーになります
wineを32bit環境にします
これでないとちゃんと動きません
export WINEARCH=win32 winecfg
MonoやGeckoもインストールします
それからwinecfgを立ち上げます
winecfg
windowsのバージョンは必ずwindows7にします
winetricksを立ち上げます
winetricks
ここからDLLのオーバーライドをします >>96
>結論から言ってMInt18とoffice2013は相性が良くないです
と言うから他でも試して上手く行ったのかと思ったら違うのか ごめんなさい、winetricksはこっちでした
WINEPREFIX=~/.wine/Office2013 WINEARCH=win32 winetricks
office2013をインストールするためのwinetricksです
select the default wineprefix→OK
install a windows DLL or component→OK
msxml6をインストール
会社名はselfでいいと思います
それから
riched20.dllをインストール
winetricksが間違ってるとここでrenameなんたらとエラーが出ます
これはPowerPointを動かすためのDLLなので必ず必要です
このあとレジストリエディタを立ち上げます
普通にインストールすると画面が真っ黒のままになるのでそれをレジストリで修正します HKEY_CURRENT_USER_Software_Wineに新しくDirect3Dというkeyを作り、MaxVersionGLという値でバイナリデータを30002（１６進数）にして終了
https://i.imgur.com/ldeMOvQ.png
ここでいよいよoffice2013のインストールです
インストールそのものは多分大丈夫だと思います
https://i.imgur.com/krkHcXs.png
https://i.imgur.com/rUzKS5y.png
https://i.imgur.com/Tbw6Bcn.png
でもPowerPointはダメでした
我が家のMintはダメでした
でもちゃんとPowePointが動いてる人もいるので方法自体は間違ってないはずです
以上がoffice2013のインストール方法でした
PowerPointが動いた人がいたらぜひ教えてください >>100
Mintしか持ってないのでMInt以外は試して無いです
Mint18.0、18.1、18.2は試しました
wineは2.17、2.18、2.0.2、2.4をそれぞれ試してみましたがインストールできたのが2.0.2と2.4だけでした
同じMintでもバージョンが違うとインストールすらできないのと、古いはずの安定版2.0.2が優秀なのにも驚いてます とりあえず疲れたのでしばらくはoffice2013はいいかな ＝＝＝＝Wine動作報告＝＝＝
アプリケーション名:MSOffice2013
アプリケーションのバージョン:MS office2013（インストールのみ）
Wineのバージョン:2.4Stag
ディストリビューションとアーキテクチャ:Mint18.2 64bit（virtualbox）
レーティング：Silver
動作の状態:ExelやWordやAccessは立ち上がるがPower Pointはやはり立ち上がらない
configuration progressが動作して起動はしない
winetricksでriched20.dllをインストール、それからwinecfgでdllをオーバーライド
riched20.dll＝native（windows）に設定したがやはりダメ
現時点で最新の2.4StagでもやはりPower Pointが起動しない
でも起動しないのはPowerPointだけであとはほぼ動きます（完動するかどうかはまだ確認できてない）
開発版の最新版2.18はMint18.2ではoffice2013自体エラーが出てインストールできなかった
古い安定版2.0.2が以外に優秀でインストールできたのが面白い
他のディストリでは開発版も動くかもしれない
開発版はMintには合わなかっただけだと思う
結論
PowerPointを諦めて使うならインストールする価値あり
将来性を考えれば2.4stagがいいと思う フォントに関しては、linuxで使うにはMSフォントはライセンス上問題があります
ホームに.fontsディレクトリを作ってそこにフォントを入れれば使えますが、
使えるのとライセンスはまた別の話
自分はIPAモナーフォントを代用フォントとして使ってます
PDFに埋め込んで使ってもライセンス上再配布も問題ないフォントだし
互換性という意味ではTakaoのほうが若干上かもしれないけどね 試してみようと思ったんだけど評価版をどっからダウンロードすればいいのかわからん
ライセンスはプリインストール版のしか持ってないしなあ そういや梅フォントも入れてました
使ってなかったけど
今度使ってみます >>97
仮想環境にインストールしたのは実環境にはすでにoffice2007が入ってるので、ヘタに上書きされたりちゃんと動くかどうかわからないソフトを入れたくなかっただけ、それだけです
office2013みたいな不安なソフトは仮想環境で試すに限ります
そのためにのみ仮想を使ってます
スナップショットでいつでも元に戻せますし kazesawa font入れてみたけどなかなか良いなこれ The Wine development release 2.19 is now available.
What's new in this release (see below for details):
- Support for 32-bit float audio on Android.
- Named pipes now fully handled by the Wine server.
- Support for a new Microsoft root certificate.
- More transform fixes in GdiPlus.
- Some heap allocation optimizations.
- Various bug fixes. The Wine maintenance release 2.0.3 is now available.
What's new in this release (see below for details):
- Various bug fixes
- FreeType 2.8.1 compatibility fixes qemuでwineが動かせるっぽいSDカードイメージを見つけたんですが、wineを動かすと
Warning: memory above 0x80000000 doesn't seem to be accessible. Wine requires a 3G/1G user/kernel memory split to work properly. wine: failed to map the shared user data: c0000018
上のエラーがでます。
Kernel 4.1.8 with 3G/1G user/kernel memory split:
https://forum.winehq.org/viewtopic.php?t=1905
ここに書いてあることを参考にして
zcat /proc/config.gz | grep VMSPLITをしたら、結果は
# CONFIG_VMSPLIT_3G is not set
# CONFIG_VMSPLIT_3G_OPT is not set
CONFIG_VMSPLIT_2G=y
# CONFIG_VMSPLIT_1G is not set
になりました。
解決方法のわかる方がいたら教えてくださいm(_ _)m
RPI-QEMU-x86-wine github
https://github.com/mikerr/RPi-QEMU-x86-wine >>123
書くの忘れてましたが、Raspberry Piでwineを動かす方法についてです。 >>123
違うイメージがSDにインストールされている。
ダウンロードからやり直しましょう。
それでも同じならそのgithubがハックされて
ファイルを別の物に置き換えられたのでしょう。
その場合はカーネルの再ビルドがんばりましょう。 >>125
でも、githubのほうに
Kernel 4.1.8 with 3G/1G user/kernel memory split:
https://forum.winehq.org/viewtopic.php?t=1905
のリンクがあるのですが… 旧式のgoogle photoのサポートがそろそろおわるらしいのだけど新しいbackupが使えないので困る
インストールの時点でネットワークに繋がらないとか言われて止まっちゃうんだよな
検索してもみんな同じところで止まっている情報ばかり
なんとかならんものかねえ 古いWindows95専用ゲームで256色モードが必要なやつは動かせない？ The Wine development release 2.20 is now available.
What's new in this release (see below for details):
- Improved event support in MSHTML.
- Preloader support on ARM64.
- Interpolation modes in Direct3D.
- Improved metafile support in GdiPlus.
- Initial version of Kerberos5 Authentication Package.
- OLE clipboard cache improvements.
- Various bug fixes. >>131
Xephyrを使えばできるみたい
ttps://wiki.winehq.org/256_Color_Mode に方法が書いてある ワイン2.20発売
2017年10月31日
Wine開発リリース2.20が公開されました。
このリリースの新機能 ：
MSHTMLのイベントサポートが改善されました。
ARM64でのプリローダのサポート
Direct3Dの補間モード
GdiPlusでのメタファイルサポートの改善。
Kerberos5認証パッケージの初期バージョン。
OLEクリップボードキャッシュの改善
さまざまなバグ修正。 Ubuntu Mate 16.04 AMD64
JaneDoe View α Build ID: 1507130036
Wine2.19（wine-staging 2.19）のときはcommand.datに↓追記してPlumaとかに引き渡せたけど、Wine2.20（wine-devel 2.20）だと動かない
Plumaでcommand.datを開く="/usr/bin/pluma" "command.dat"
↓とかのWebブラウザはWine2.20でも動くので⊂( ・∀・)ﾜｹ ( ・∀・)つﾜｶ ⊂( ・∀・)つﾗﾝ♪
Firefox="/usr/bin/firefox" "$TEXTI$LINK"
Wine2.19に戻して様子見 >>141だけどwine-staging 2.20にしてみた
問題なく動く
パッチの差かな
staging＞devel＞stable
補足
>>141のJaneViewのコマンドで本来はJane2ch.exeと同じフォルダにあるファイルを指定するには「$BASEPATHファイル」で記述
例：
command.datをメモ帳で開く=notepad "$BASEPATHcommand.dat"
Meryでcommand.datを開く="D:\Application\Mery\Mery.exe" "$BASEPATHcommand.dat"
（Meryはテキストエディタ）
＃ Linuxのアプリケーションでは「$BASEPATH」がいらないのはフォルダ内で端末開いたよーなものなんだろか？ 肝心なこと書き忘れ
Plumaの文字化け対策は以下を参考にしました。Ubuntuでもでけた
http://maguro.5ch.net/test/read.cgi/linux/1393660914/947
（ http://maguro.2ch.net/test/read.cgi/linux/1393660914/947 ）
947 名前：login:Penguin：2014/04/21(月) 16:21:34.38 ID:7ECvBhuY
Ｕｂｕｎｔｕ版はどうなってるかよくわからない、LMDE201403だと、dconf-editorインストールするのが楽かも
// ｇｓｅｔｔｉｎｇｓ 使う場合は下の方法
1. 現在の設定の確認 ['UTF-8', 'CURRENT', 'ISO-8859-15', 'UTF-16'] がデフォルト
gsettings get org.mate.pluma auto-detected-encodings
2. 書込可能か確認 ｔｒｕｅ が帰ってくることを確認する
gsettings writable org.mate.pluma auto-detected-encodings
3. 実際に書き込みする
gsettings set org.mate.pluma auto-detected-encodings "['UTF-8', 'CP932', 'EUC-JP', 'CURRENT', 'ISO-8859-15', 'UTF-16']" Watch Dogsが無料になってるみたいなんですけどwineで動きます？ ダメダメな感じですか
このスレで試した人いたらぜひレポートしてほしいです 普段ゲームとかしないしwineもあんま試したことないので素直にwindows使いまつm(__)m Watch Dogsって面白いの？
タダならやってみようかな wine-stable:2.0.3ですが日本語が盛大に文字化けしたので知恵貸してください
https://i.imgur.com/6YAg4oe.png
時期は不明ですがMeryの設定表示が豆腐になりました
ググるとtahomaが原因と出るので/opt/wine-stable/share/wine/fonts/内の
tahoma.ttfとtahomabd.ttfを退避させましたが直るどころか悪化します
https://i.imgur.com/ttKNxtE.png
Mery以外のソフトでも一部で日本語が豆腐になったのでフォントが原因だとは思うんです
共に最近までは正常表示だったので何も考えずwineを更新したのが原因だとは思うんですが >>151
最近でフォント周りだとfontconfig絡みだから
例えばfontconfigの設定でtahomaの置き換えしてみたらどう？ 誘導されたので再質問です
.NET Framework 2.0を入れようとして32bitじゃないため失敗しました
3.0とか4.0なら64bitに対応してるのでしょうか？
環境はUbuntu16.0.4、 wine1.6.2です
いろいろググっては見てるのですがこの方法でなら、というのがあればおながいします >>155
・wineticksを使いましたか
・WINEPREFIXは32bitと64bitのどっちですか
・必要な.NETのバージョンはいくつですか
わからないならわからないと答えてください まず、基本的にWineは32bit推奨。
64bitなLinuxでも32bitのWineは入れられるからggってみな。
.NET Frameworkはなくても動く可能性がある(Wineを入れるとMonoという代替品がインストールされる)
から、まずはそのまま試してみることを勧める。
それで動かなければwinetricksから.NETをインストール。2.0ならおそらくdotnet20だろうな。試してないからわからんが。 >155
winetricksでdotnet20入れました
PREFIXのverはわかりませんが(x86)が付いたのと付いてない両方のProgram Filesが.c:以下にあります
インストール要件はWindows 8 / 8.1 / 7 / Vistaで、「.NET Framework 2.0以上が必要 (なければマイクロソフトから自動インストールします)」とあります
>158
monoは入ってなさそう
$mono --versionと打つと
>プログラム 'mono' はまだインストールされていません。 次のように入力することでインストールできます:
>sudo apt install mono-runtime
と出ます。
もう少し調べたら入れてみます >>159
(x86)がある場合は64bitだ。
一度.wineを消去してターミナルから
export winearch=win32 winecfg
winecfg
叩け。このあたりは基本Lvだからこれぐらいはできないと満足にWine使うのは難しいと思うぞ。
monoは初回にWineを起動したときに見つからないからインストールするぞ？って聞かれたのを入れてればおｋ。 >>159
それなら
・monoだけインストールして現在の環境で動くか試す
・ダメだったら新しく32bit用のPrefixを作成して.NETをインストールする(4.5とかでよい)
というのがいいと思う
あと1.6.2はさすがに古すぎるのでもっと新しいのを使ったほうがいいと思う >>160
最初に試行錯誤してた時にmono一括で消したかもw
>>161
素性の変わったソフトでMacのwineでもうまく動かなかった
無きゃ困るというのでは無いけど動けばめっちゃうれしい
1.6.2は古いですか…
とりあえずその他の欲しいソフトは大体動いてる https://wiki.winehq.org/Ubuntu
公式サイトのubuntuインストールチュートリアル。
こういうのもちゃんと調べないと…。 >>151
とりあえずwineを2.0.2に戻してみる
ウチだと２.0.2で正常に表示されてるね >>164
Limt17.3のxfceだけど2.0.3~trustyから2.0.2にダウングレードできなかった
$ sudo apt-get install wine-stable=2.0.2~trusty
パッケージリスト略
以下のパッケージには満たせない依存関係があります:
wine-stable : 依存: wine-stable-i386 (= 2.0.2~trusty) しかし、2.0.3~trusty はインストールされようとしています
E: 問題を解決することができません。壊れた変更禁止パッケージがあります。
そこで一度1.6.2を入れるが消しても残ったままに
$ apt policy wine-stable
wine-stable:
インストールされているバージョン: 2.0.3~trusty
候補: 2.0.3~trusty
$ apt policy wine
wine:
インストールされているバージョン: (なし)
候補: 1:1.8.0-0ubuntu1
$ sudo apt-get remove wine
パッケージリスト略
Package 'wine' is not installed, so not removed
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 6 個。
removeやpolicyで1.6.2はないと出るがver確認やwinefogでは1.6.2が表示される
$ wine --version
wine-1.6.2
アホやったのは承知だけどこれ直るんだろうか？
消したはずの1.6.2が留まってstableにならない状態
1.6.2なんでMeryの文字化けこそされてないけども >>167
wine-stableパッケージとは別に、wine-stable-i386パッケージがあることには気付いている?
うまくいくか分からないけれど、2.0.3のwine-stable-i386とwine-stableを消してから2.0.2にするのはどうかな
本家から入れたwine-stableとかは、/opt以下にインストールされるから
PATHを通さないと立ち上がるのは1.6.2とかのまま 3.0は来年中に出そうだな。
しかし、0.x系時代に比べるとだいぶまともに動くようになった。
IrfanViewとかはネイティブのアプリよりサクサク動く。
デフォルトの画像ビューアにしても何も問題ないレベル。 Google backup syncがインストールできねえ…
使ってる人は居ないのか？ DropBox派なので……
よく知らんけどそのうちLinux版来るんじゃないの？ >>168
2.0.2入らないね
stable-i386をremoveしても1.6.2居座ってる
/usr/bin/wineと/usr/share/wineも残ってる
dpkg -lでもstable-i386があってWinソフトも起動した
今までは1.6.2消してstableを入れてたけど
/opt以下のstable2.0.2がちゃんと起動してたよ
stableだけの時は/usr/share/にwineはなくてwinetricksだけだった GUIのソフトウェアの管理の方でwineとstableを削除後に再度stableを入れたら1.6.2を消せました
.bashrcに/opt/wine-stable/bin/のパスを追記してなんとか戻せました
1.8も入っていたり自分でも何やらかしたか分からん The Wine development release 2.21 is now available.
What's new in this release (see below for details):
- Still more metafile support in GdiPlus.
- Indirect draws support in Direct 3D.
- Calling convention fixes on ARM.
- Improved serial port detection on Linux.
- Services fixes on WoW64.
- Better DPI scaling in the Shell Explorer.
- Various bug fixes. 南蛮妖術ボジョレーヌーボーｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! Wine上で既存のWindows用業務プログラム(.net3.5)動かそうとやってるWindows専技術屋ですが
どうしてもMySQL Connector/Netで、NetBios名の名前解決ができなくてDHCPネットワークでは無理みたい
（DHCP切れって話だけど、使ってるロケーションが10箇所以上あるからいちいち現地で作業できない）
そこでLinux上に別ソフトインストールしてそいつで名前解決したあと、localhostにマスカレードさせてつなげることできないかと考えたんだけど
どなたか何かいいルーティング用プログラム知りませんか？ 補足：winbindとlibnss_winsは入れてみましたがlinux上のPINGは通るのにWine上では取得できませんでした >>178
PCの性能が許すなら、WindowsもどきのWineじゃなくてVirtualboxで
本物のWindows を動かしたほうが…。Enterpsise評価版ならライセンス要らないし。 wineとvirtualboxと両方いれてるけど、両方とも捨てがたい面白さがあるな
なんで素のWindowsで動かすより楽しいんだろ 気持ちはわかるがなんでと言われると俺もうまく説明できんな 楽しくないからLinux Subsystem for Windowsが欲しい >>178
iptableｓなんかの設定見直してみれば
Sambaは動いているだろうにNetBiosでの名前解決が出来ないことから自体おかしい >>178
スレ違いだけれど、そういうときはstoneを使っていたな。
ttp://www.gcd.org/sengoku/stone/Welcome.ja.html wineでLINEを入れようとしたんだけどエラーが出る
今のwineではLINEは動かないの？ >>186
ありがとうございます。
うおおstoneすごい懐かしい
Win2000くらいの頃にSSHトンネリングで使った記憶があります linux mintの18.2のxfceだけど
LINEを起動させるとプログラムエラーのウィンドウが出ます ver 4.10.1.1256は最新版じゃないの？
起動出来てますが 起動出来ないのはMintなんていうチョン臭い盗人寄生虫ディストロ使うからだろう
Ubuntuがdebian使いなさい DebianはいいとしてUbuntuが言うか！ww Slackwareはまだバリバリやで
ちょっと興味ある Red Hatもまだバリバリだが、もう企業しか使ってない >>196,200,201
今、SlackwareベースのPuppy Linux、Slacko Puppyをイジってる。
でも、SlackwareのリポジトリーにはJDがないんだよなあ。
WineでJane Style 4.00が動くようになったから
それ使えばいいじゃんという話もあったりするが。
Red Hatのベータ版的な位置づけのFedoraがあるぞ。
こいつは一般人というか、一部のPCオタクも使ってる(はずだ)。 Slackwareはまだ1人でやってるのかな
がんばるなぁ~ WindowsXPからコピーしてきたMS UI Gothicのノーマルは表示できるのに
ボールドやイタリックが別のフォントになるのはなにか設定が悪いのかな >>204
窓厨がそれはライセンス違反だと激怒するぞ。 >>205
ぐぐったら8年前の過去ログでてきてまさにそれで文句言われてたわ デュアルブートしてるからWindowsのfontsディレクトリにシンボリックリンクで使ってるけどそれも駄目なのだろうか >>207
どんな言い訳をひねり出そうとしてもダメなものはダメです WSLでWine使う場合は問題ないと思う。
Windowsの中で閉じているわけだし・・・ フォント置換用レジストリ （優先される項目順）
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でフォントファイルを改造して偽造する wine-stableとwinehq-stableって違うんです？ >>210
サンクス
でもそれはフォントインストーラーSAKURAまかせでぜんぶやった
でもやっぱもともとボールドやイタリックを含まないフォントに関してはLinuxがわ任せなきがするよ >>206
前はそういう話しが出ると必ず突っ込みが入っていたが、
最近はどうしてかあまり言われなくなった。5chかwineが廃れたって事かな。 昔マイクロソフトのアプリケーションが個人情報を吸い上げている！
とか騒いでたのにFacebookGoogleだので特に気にならなくなってあまり騒がなくなったのと同じかな
それともWindows10で強引なアップデートされて流石に堪忍袋の緒が切れてフォローできなくなったのかな >>209
現状WSLじゃWineは使い物にならんぞ…32bitバイナリ動かないからWine64しか動かない。exe側も64bit用のバイナリじゃないと駄目。
BoxedWineってのもあるけど、まともにメンテされてないっぽい。 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. 前に1.6が残るって騒いでたけど>>211で解決した
1.6消してwine-stableとwinehq-stable入れたら直った
両方いるなんて分からん WineのIME関係はまだいろいろおかしいけど、今開発者にアジアの人いないのかな
履歴みたけど10年前くらいのログにdlls/winex11.drv/xim.cをちょこちょこいじってる日本人らしき名前があるけど >>218
wine-stableとwinehq-stableって両方入れないとイカンの?
winehq-stableしか入れてないんだけど。 むしろ別のWineは削除してくださいって一番最初に書いてあるよ
https://wiki.winehq.org/Ubuntu >>151＝>>167＝>>174＝>>218です
まぁエディタが豆腐になった時点で何かやったんだとは思う
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が出てくるし文字化けもなくなった wineでソフトウェアが動かない場合、wineだけでなくOSとの相性が悪いってこともある？ 理由は分からないけどlxdeだとWineのアプリからhtmlファイルが開けない
だからlxdeは嫌い >>226
可能性としてはあるかもしれない
Mint18.2にOffice2013入れたけど、Word、Excel、Accessは動いたけどPower Pointだけはどうしても動かなかった(一回だけ起動したけど直ぐにフリーズしてしまった)
でも他の酉では動いてる人が実際いるようなのでOSとの相性なのかも、と思ってしまう
ちなみに2007のPower Pointは同じ設定でちゃんと動いてる >>229
OSとの相性が問題としてあるなら
諦めるしかなさそうだ >>220
IME関係がおかしいところって、XIMのせいだったりしないの? >>231
ソースちょろっと見ただけだけど変換中のキーバッファをwine側で取得してなさそうだった
変換候補を表示する座標が変なのはWineに限らずJavaなんかでもおかしいからibusやFcitx側の問題かもわからん Linux上のブラウザはjquery.autoKana.jsで変換中のキーイベント取れてるからフリガナ表示できる
変換中のキーバッファはwinex11.drv側で取得してWM_KEYDOWNなんかで渡すべきなんだけど今はLunux側にフィルタされて一切取得不可能なのよね デスクトップ環境にMATEを使ってたが、気分転換にLXDEに変えたらWineの起動が早い気がする。 mateはかなりファイル開きっ放しだからな
GNOME3 KDE >= Xfce > mate >= GNOME2 > LXDE
しかしLXDEは色々と機能が足りなかったり（DE WM でのIME切り替えとか管理とかみたいな）
あと たいかんｗ でしかないけど、Win32のウィンドウサイズ関連が上手く動かない、みたいのが
LXDEだと多い気がする（BunBackupとかスプリッタで変な事してる様なのとか） fcitx-mozcだけどWineとIMEって相性悪いのか
テキストエディタと小物ソフトとゲームしかWIｎソフト入れてないけど
変換候補のずれもなくなってたな pkgで新しいwineをインストールすると、古いwineはどこに言ってしまうの？
ssdの容量が減りっぱなしなんだけど、どこかに残っているの？ システム入れ替える前に、wineのDLLのオーバーライド設定控えるの忘れた・・・
せめてどっかにwinetricksぶっこみまくっても無難に動く設定転がってないかな？
あれまたDLLのインスコ前後の差分取って、不安定要因を１個１個確かめてとか、
やりたくねぇ ＿／＞ ...〇 DLLOVERRIDEをexportするスクリプトを書いて実行していればそのバックアップだけで済んだのにな。
ご愁傷様 Fcitx, iBusどっちでもいいけれど、Wineだと文字入力以外のIME機能が使えないんだ
読み仮名とか、変換中の文字列を得るとか、再変換、
IMEのON/OFFステータスの取得や切り替え、IMEの無効化みたいな imm.c見たらわかるけど、ほとんどのAPI関数はエラーが出ない程度にSetLastError入れてスキップしてる
IME使うのはアジア圏だけだろうから深刻なバグがない程度に放置されてるんだと思う 有用な情報だ
年末時間あったらIMM関連のコードいじってみたいなあ winetricks 20171018-next
$WINEARCH win32
winetricks の kindle が起動しません。
ウインドウ枠だけが表示されフリーズしています。
動作されてる方いますか？ 俺の環境(wine2.22, arch linux)だと
WINARCH=32 インストーラーがabort
WINARCH=64 初期化時に無限ループして起動しない
という感じだった 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. 3.0-rc1にならないなぁ・・・
どうやっても2.22で止まり リリースされてもしばらくは反映されなかったりする
ちょっと時間をおけば反映されるよ ちなみに途中で止まってしまう時なんかもちょっと時間をおけば大丈夫だったりするね Macに3.0-rc1入れたけど、2.0-rcに比べるとインパクトがないな。
1.xに比べると劇的に早くなったと記憶してるが・・・ あ、2.0の前は1.8.xが安定版で、1.9.xが開発版だったな。 >>258-259
やっと3.0-rc1になったよ 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. もう、rc3かよ・・・
年明けには正式リリースか？ 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. Stableの2.0.2でまったく困ってないのでよほど大きく進歩しないかぎり入れ替えはしないなあ まあ動くソフトが増えれば進歩だから、増えたのかね
どうなんだ winegstreamerのバグはいつ治るのやら(´･ω･`) 昨日、uninstallerを起動しようとして
何か間違ったか知らんけど、偶然画面の解像度や色の深度などの設定画面が出て
「あったのか！ ラッキー」と思ったんだけど、
Whiskerのメニューでコマンド入力したので履歴に残ってないんですよね
何を入力したのかまったく覚えてない・・・
どなたか、その設定画面の立ち上げ方知りませんかね？
一応3.0-rc3 devだけど・・・ 271は解決しました
ただのDirectXコントロールでした 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
00570E2KI1 K-POPや韓国製品を賛美するコメントを書き込むだけの簡単なお仕事です 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. rc4ダウンロードできないね
サーバ落ちてるのかな 自己解決
https://repos.wine-staging.com/wine/ubuntu/pool/main/ から直接落としてきて
/var/cache/apt/archives に入れてupdateかけるか、dpkg実行すればいいみたい Debianだと、3.0-rcから.desktopファイルに書かれたexeの起動が遅いか全くできない。
Ubuntuなら問題なし。 でも、OSの根本的な部分はDebianが安定してるな。 3.0-rc4 だと.dotnet2.0のインストールに失敗する(COMの登録に失敗してる感じ
一旦1.6に戻して試したら普通行ける 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. 3.0-rc5 でaviutl EX gui(64bit版のx264)がエラー吐かなくなった winetricksがまともに動くまではstableで傍観しとこう wine amd64にdotnet4.0は入るんだけど
4.5.1が入らない．．．
悪戦苦闘中．．． 4.5sp1は自分も断念したな
たしかインストーラーが途中でファイルをダウンロードしようとして落とせなくて中止せざるを得なく
一度終了すると、winetricksのスクリプトが2.0sp1がすでにインストールされていると誤認して
そのWine構成では2度とスクリプトが続行できなくなる wine2.1で、4,5までははいるんだけど
使用したいソフトがカーネルエラーでおちる
wine3.0だとdotnetfx_cleanup_tool使っても4.0までしか自分では入れれなかった
archlinux x64 初心者なので断念 wineをインストールしてから数日はすぐ起動するのですが数週間経つとソフトが起動するまで3分程度かかります。ログファイルか何が原因かと思い探して見たのですが解決出来ませんでした。原因が分かる方いますか？
因みにwineで使っているのはfoobar2000です 流石に3分はないけどすごく起動が遅くなる時があるよね
最初はwineserverがFontキャッシュでも作成してるのかと思ったけど
すでに他のEXEが起動しているのに起動が遅い場合があってよくわからん
海外のフォーラムだと wineboot --update で治ると書いてあったけど眉唾すぎる よく分からん状態になったらwine関係のプロセスを粛正しまくってる。
これで大体解決する。 ubuntuクリーンインストール直後の更な状態でも遅いからおま環とかじゃないはずだよ システムのwineでも特定のアプリ用に保存してある1.7.55でも一回も遭遇したことがないなあ
本当ならfoovarとかいうので検証してみたいところだが先2週間くらいは暇がないし…… wine をバージョンアップするとなんとかを更新してますってダイアログが出て
少し時間がかかる時はあるがそれ以外で時間がかかったりかからなかったりと
挙動が変わるという経験は一度も無し。 バージョンダウンしないとPlayOnLinuxがだんまりになるのはいつ治るの？ wine2.0.2だけど最初の起動にやっぱり時間がかかる
aviutlは10秒くらいかかってる
でもまあ一度起動してしまえばあとはすぐに起動するから問題ないと思ってる 何度かOS起動しなおしてプロセス確認してみた感じ、winserverの起動時間で若干のオーバーヘッドがある
.NetFrameworkに依存しないソフトなら割と早いから
.NetFrameworkのためにservice.exeを起動するので時間かかってるソフトもありそう
あと>>292は外出でChromeやら何やらと起動放置した状態だったから、実際はWineのせいではないかも office2007のExcelやwordもやっぱり最初だけ起動に10秒くらいかかるね
でも最初だけであとはどのソフトを立ち上げても速攻立ち上がる Ubuntu16.04なんだけど、wine3.0のバイナリパッケージが
まだstableブランチに来てないみたい。
develブランチにもだけど。待ってるのになー。 >>304
そう云うのは仮想環境で試すものだよ
多分ltsのstableにくるにはそれなりの安定性が確保された後だから rc5くらいからはそれなりに安定してる気がするけど wineは複数ブランチとかないし新しいバージョンほど基本安定している
バックポートは甘え stableも3.0になったけどwinetricksでdotnetがインストール出来ない不具合治ったかな？
いちいち古いバージョンでwine環境作るのめんどくさいんじゃ stable2.0.2から3.0に
とりあえず.net2.0はインストールできた
あとはこれから
office2007もaviutlもhuffyuvも問題なくインストール出来た
とりあえず検証はこれから
https://i.imgur.com/sbEvST4.png 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. >>309
素→2.0 成功
素→2.0→3or4 失敗
素→3→4 失敗
素→3 成功
素→4 成功
上げていくと失敗する
他にも失敗条件があるから失敗したら素からやり直す
成功したら.netバージョン毎に.wineをバックアップを取る >>313
サンクス。それは1.6の頃と変わらないから3.0develのregsvr32のdll登録の失敗バグは治ってる
３と４やsp1なんかを全部入れるときはそれぞれ新規で環境作ってインストールさせてから
ファイルを一つの環境下にコピーしてレジストリゴニョゴニョしてやってる
winetricksで対応してくれないかな winetricksはどうだろう
あまり期待はしすぎないほうがいいと思う
adobe airなんかもいまだに2 .0だし
windows版のairはインストール時に文字化けしない2.8になってるってのに 3.0リリースおめ
しかし前から思うんだけど
wineて前進してるんだろうか
毎回物凄い数の修正してて凄いと思うけど
バージョンあがると、動いたり動かなかったり 2.0になってoffice2013がサポートされるようになったようにそれなりに前進してるとは思う
ただ今回のメジャーアップデートはDirectX10と11のサポートやアンドロイドのグラフィックドライバーなどグラフィック関係のサポートがメインで、多分ゲーム分野の取り込みと拡大が狙いなんだろう
ゲームをしない自分にはあまり関係のないアップデートかもしれないけど、他にどこが変わったかはこれからゆっくり見てみようと思ってる ttps://wiki.winehq.org/ARM
を見てて気づいたが、WineのAndroid用apkはここから落とせるんだね
ttps://dl.winehq.org/wine-builds/android/
CPUエミュレータはたぶん入っていないので、x86版をVirtualBox上の
Android-x86で試してみたけど、普通に動く な、なんと！
今日は雪で早く帰るけど、うまく家に帰れたら試してみるかな・・・ Macに3.0入れたら起動がスゲー遅い・・・
rc6までは問題なかったのに。 ChromebookならIntel入ってるしAndroidアプリ対応だから使えるかな そっか、Android用もあったか
Chromium系OS調べてみよっかな CrossOver for ChromeOSならGoogleアプリストアから入れられるよ
Pixelbookで重宝してる macOS 10.13.4のベータ版から32ビットアプリを無効にできるブートオプションが追加されたので
試したみたらWineも32ビットで起動できなくなったわ。64ビットアプリは問題ない。
これは予想はできたがショボーン状態に。 ~$ wine --version
wine-1.8.7 (Debian 1.8.7-2)
~$ winetricks --version
20170101
で，Internet Expolorer 8 のインストールがWebページの404エラーにより失敗しました。
https://web.archive.org/web/http://download.microsoft.com/download/WindowsInstaller/Install/2.0/NT45/EN-US/InstMsiW.exe
どなたか ie8 が配布されているサイトに心当たりはないでしょうか。
欲を言えば winetricks から操作できると嬉しいです。 なんかwine-stable入れなおしたらフォントがちゃんとWindowsみたいにアンチエイリアスなしでビットマップフォント描画するようになってて違和感
以前
https://i.imgur.com/33J6RXR.png
現在
https://i.imgur.com/S4LWJZS.png >>329
へ～Jane Styleだとこうなるのか
ちょっと試してみるわ wine3.0にしたらadobe airがインストールできなくなった
air28だけでなく27も26もだめ
しばらく様子をみるしかないか qtもインストール出来なくなったね(´･ω･`)
未実装の関数がどうとか出てくる(´･ω･`) qtもなんだ
office2007とかすごく快適に使えてるからとりあえずはいいんだけど
郵便局のハガキデザインキットで暑中見舞い作りたいからそれまでにはなんとかしてほしいわ Developmentだからなあ
基本Stableを第一に考えてるので3.0が優先かな
まずは他に方法がないかいろいろ探してみようと思う >>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
https://i.imgur.com/21NbqT3.png >>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
https://i.imgur.com/21NbqT3.png >>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
https://i.imgur.com/21NbqT3.png お恥ずかしい
書き込みエラーが出たので試しにプロキシの設定の書き込みの方にもチェックを入れてみたところ、いきなり３回書き込みになってしまいました >>347
男子コリア人や男子中国人、男子シベリア人ですか 若いころは、JSがまさかここまで人気になるとは思わなかったな。
Javaに似せただけがとりえのスクリプトだと思ってたのに。 いや全然Javaに似てなくないか
JSってかなり変わった言語だと思うけど ごめん、名前の話ね。
JSリリース当初は、まさに全然違うのになぜLiveScriptからJavaScriptに変えたんだろう、と思ったんで。 >>353
／￣￣￣￣￣￣￣￣￣￣＼
| おまわりさんコイツです！ |
＼＿ ＿＿＿＿＿＿＿＿／
∨ ＿＿＿
,r'つ＠＝,r'
.| （-＿- ）
（･ω･´）､/~У￣|ﾞｉ
ﾟこ､ つ |=◎＝∪
しー-Ｊ （＿（＿_） >>350
大半が同じ感想のはず。
ajaxの手法が公開されてから一気に沸騰した。 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. wine-staging2.21からwine-stable3.0にしたら
負荷とメモリ消費が素晴らしく改善されたから
開発版に手を出しかねてる
3.0で改善されたのか、stagingのものが足を引っ張ってたのか判別つかなくて 3.4のときは起動すらしなかったのにな
4.0になったら快調すぎる 結局のところwinehq-stableとwine-stableの差は何なのさ winehq stableが公式サイトで公開されてるやつでwine stableは各ディストリから配布されてるやつだと思ってたけど違うのかな wine-3.1-arm.apk
ExaGearより動くかなと期待して入れたんだけど、プログラムが一つも動かない…
まだ見てくれだけの未完成品ってこと？ あー Windows RT ARMのソフトしか動かないのかこれ >>371
こいつMac関連のスレ狙ってる？別にそんな事ないのかな crossoverのベースになっているwineのバージョンってどこから調べたらいいの？
もう3.0ベースになってるのかな ちがったかな
$ /opt/cxoffice/bin/wineserver --version
wine-2.8-8251-g8a457d1 ubuntu studio 16.04LTS にwineを入れて、
JaneStyle を使える様にはなった。
書き込みテスト。 >>368
まじかよ、Elonaさえ動けばいいのに。 ARM機とかスマホしか持ってないわ
これから増えるんかね PS VitaもARMだしSwitchもARMだな RTでコケて痛い目にあったからそれはないと思う。
ARMじゃない別のアーキテクチャで出す可能性はあるかも・・・
そしてまたコケるw >>385
いや出るから
HPとASUSがsnapdragon搭載Windows端末を発表済で春に発売予定 売れるとは限らないんだがなぁ
x86exeが何となくでも動くだけでいいのにな ちょっと調べてから否定しようよ
まあいいんだけどさ 古いけど、Ubuntu12.01 への Wine3.0のインストールに成功した。
git のソースから、./configure
途中、Font関連のファイルが見つからないエラーが出たので、
そのFontの「dev版」をapt-getでインストール。
その他、いくつかエラーが出るので、インストールしたりする。
その後、make, make install。
でインストールには成功するが、今まで動いていたWinアプリを起動してみると
日本語で文字化けしてる。wintricks font や regedit などをいじってみたが、
ダメだった。しかし、apt-get remove wineとしたあと、再度、
apt-get install wineとすると、なぜか、すぐに成功した。
wine --versionとすると、なぜか、3.1のままだった。
不思議な事に、文字化けはすっきり解決した状態で、Ver 3.1のWineが動いているらしい。
実際、Windowsとの互換性は明らかに向上した。 Wzエディタで、検索やGrepのダイアログのStatic Textの表示が途切れてしまう
不具合があったのが、Wine3.0では修正されている。これは使える。 透明色と MDI Window を組み合わせた自作WindowsアプリをWineで動くように修正中。
MDI Child Widnow のタイトルバーをドラッグすると遅くなるので原因を調査していた。
PreTranslateMessage() にくるメッセージを、自前でWindowに表示していたところ、
システム全体が実質的にハングアップした。マウスは動くが、タスクバーも反応しない。
ちなみに、透明色とMDI Windowの組み合わせが必ず遅くなるわけではない事は、
単純なテストプログラムを作って分かっている。ではなぜ、このプログラムに限っては
遅くなるのかが分からないので調査中だった。 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. 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年前のビルド環境
みたいだ。 >>397
今回に関しては、以下を読んで、git でやってます :
https://wiki.winehq.org/Git_Wine_Tutoria
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
と出れば、大体 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 エディタ
などでも見られます。 5ch からのアクセスは禁止されているらしいので、アドレスバーに上記の URL を
コピーしてアクセスしてください。
なお、make が遅い件は、make -j 4 などとして、マルチコア動作するとだいぶ良くなりました。
ただし、その場合、make にバグがあるので精密な神経の持ち主には、ストレスがたまります。 動きをトレースしたい場合、TRACE はデフォルトではメッセージが出ず、使い方を調べて
ないので、
FIXME( "Yamada Taro, CreateWindowEx, hWND=%08X", hWND );
みたいにやってます。 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 のようです。 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 );
という流れのようです。 以下を見ると、親が、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;
} >>402 の訂正：
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 ); ちなみに、
1. ~/.wine
2. ~/wine
は別物です。1は、binary をインストールした際に出来るデフォルトのフォルダ
ですよね。2. は、git からソースを持ってきた時にできるディレクトリです。
まずは、バイナリをインストールして動作してから、ソースを持ってきてください。 半透明化はWin32API側でどうやっているの? Linuxネイティブなアプリでは?
SetLayeredWindowAttributesであれば、user32.dllからUSER_Driverを介してwinex11.drvが呼ばれて、
window.c内のsync_window_opacityで_NET_WM_WINDOW_OPACITYにα値を設定している様子が見て取れる
ttps://github.com/wine-mirror/wine/blob/wine-3.2/dlls/winex11.drv/window.c#L435
TRACEで表示しているメッセージを確認するには環境変数WINEDEBUGを使って、
WINEDEBUG=win,x11 みたいにカンマ区切りで指定する。細かくは
ttps://wiki.winehq.org/Wine_Developer%27s_Guide/Debug_Logging に書いてある。
あとは、dlls配下の各ディレクトリでもmake && sudo make instlallできるので
特定のDLLファイルしか変更しないのであれば、この方法でビルド時間を短縮できるぞ。 デバッグ大変だな。めんどくさそう。
仕事じゃないと俺はやらないだろうな。 自分はimm32関連(日本語入力)APIを修正しようとeclipceでコンパイル環境作ったはいいけど
ネイティブのウィンドウマネージャ関連の知識不足でソースの意味がわからず寝かせてある・・・ >>406
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では、同じ事は出来ないはずです。 /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 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;
}; >>406
後半の二つ。自分に取っては、かなり貴重な情報です。助かります。 >>406
XWindow で透明化。これはやってみて実際に出来ました：
https://stackoverflow.com/questions/39906128/
how-to-create-semi-transparent-white-window-in-xlib
子ウィンドウを入れてみても、ちゃんと出来ました。
ただし、子ウィンドウには、Win32のような、タイトルバーは付ききませんでした。
XWindow に詳しい人によれば、XWindow の Window Manager は、
Win32 の MDI のような事は、サポートしていないらしいです。絶対か
どうかは分かりませんが。
実験してみると、子ウィンドウも、親ウィンドウも、ABI で、XMoveWindow
でスムーズに動かせました。
ただし、Wineの場合、子ウィンドウに直線や文字が書かれていて、かつ、背景が透明な場合、
スムーズには動かせません。 Win32APIだけじゃなく、X Windowについても知っておかないといけないのか
面倒臭っ・・・
普段使ってるだけでずいぶん楽してたんだな。 面白そうだけど時間ねえな……
>>410を見る限りだとuse_alphaは持ってるけどAlpha値自体はもうX11の構造体にいれてるのかな？
まあ遅くなる理由とか検討つかんけど…… WINEにおいて、
1. MDIのCMDIChildWndのCViewのCLIENT領域全体(子ウィンドウの
中全体と言ってもよい) に >>409の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 のような条件の時のみ遅くなると推定される。 >>415
すまん、ウィンドウの半透明化処理(LWA_ALPHA)と勘違いしてた。
ウィンドウ領域内の特定色で書いた箇所を透過させる場合(LWA_COLORKEY)ね。
ソースを調べたら、WineではX11のShape Extensionを使ってウィンドウの形状を変更することで、
「見た目だけではなく、Windowメッセージも下のWindowに伝達すること」を実現しているようだ。
具体的にはupdate_surface_region()で1ピクセルごとにピクセル値を比較して、
XShapeCombineRectanglesに指定する矩形領域を作っている。
ttps://github.com/wine-mirror/wine/blob/2936f3f9bb9dc01c595498a821d6adb6775b62cc/dlls/winex11.drv/bitblt.c#L1616
415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
StackOverflowの記事はShape Extensionを使っていないので筋違いだ。 >>418
なるほど。
1つ質問です。
はっきりとは書いてなかったのですが、>>415の遅くなる条件であるところの 2,3 の場合
においても、CMainFrame、つまり、アプリケーション全体の Main の Window のタイトルバーを
ドラッグした場合は、遅くなりません。いたって高速にドラッグできます。
>>418 が正しいなら、どうして、X は、この場合だけは速く、CMDIChildWnd の場合だけは
遅く動作するのでしょうか？？？ ↓の構造体の 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;
} /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_ESCAPE, 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 が、>>420 の dc_rect に他ならない。
つまり、HWND hwndのwin_rectの、HWND topの左上座標からの相対座標が、
physDev->dc_rect に入ることになると思われる。hwndの「最上位の親」が
topだとすると、topだけが XCreateWindow()された本物のWindowであって、
hwnd は 擬似Windowであるとして辻褄が合う。hwndへの描画は、
実は座標だけを修正して top の(本物の X )Window に書き込まれているだけ
かも知れない。 結論的には、Wine では、完全透明色が設定されている全ての LAYERED_WINDOW に
対して、Idle状態の時か、または、50(ms) 毎に、Windowアプリのメッセージループ
の中から自動的に、>>418 の 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() は、>>418 に書かれている関数。 該当の条件の時、新たには何の描画もしていない静止状態でも、Linuxのシステム・モニターで
CPUパワーが膨大に消費されていることを確認しました。このことは、>>422 を裏付ける物です。
だとすると、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
の優先順位を上げているからではないかと思います。 >>418 さんの指摘は凄く役立ちました。有難うございます。
ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>415の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がフルパワー状態になります。 【厳密化】
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. 文字を描いた場合、大体、文字の複雑さに比例して処理時間が増えます。 >>425
【訂正】
「6.」のランレングスの個数は、3N個ではなく、2N+1 個でした。
お騒がせしました。 >>425
update_surface_regionの方が効率悪そうなので、X側の描画性能が原因と推測した部分は撤回する。
Shape Extensionの仕様を見ると、
矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
あと、MDIウィンドウがXのWindowではないことは、xwininfoコマンドの結果でも確認できる。 >>427
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。 特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。 調べてみると、/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 がどこで定義されているのかが分からないので
誰かの教えをいただきたいです。 見つかりました。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`\"
というのが。単語検索していたのが鬼門でした。 loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。 surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。 DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。
なお、>>433は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。
なぜ遅いままなのかは謎です。 2ch(5ch?)は人は多いけど基本的にユーザーレベルの人ばかりだから技術的な書き込みしても反応は鈍いね
Qiitaにでも書いてみたらどう？ 遅い原因の1つは、Onldle の中にあることが分かりました。
1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
それがとんでもなく重い事が判明。
2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
10*N 回 呼び出されるような感じです。タイマーメッセージがくる度に、
メニューなどを更新するためのメッセージが来ているような気がします。
多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
ならないんじゃないかと思います。 通常、OnCmdMsg は頻度が低いことが
前提になっているので、その中で多少重い処理をしていると、とんでもなく
重たくなる。
なお、透明色を使っている場合、update_surface_region の中の処理の軽重に
よって、描画速度が大幅に変わることも確認しました。
ランレングスを数えてリージョンを add_row している箇所を、単純に何も
数えずに行全体で、1個だけ add_row するように修正してみると、描画が
だいぶ速くなりました（透明にはなりませんが。）。 >>436
そうしたいんですが、何かと大変なんです。
1. メールアドレスの登録するのが、Linuxからだと大変。
2. git の仕様が良く分からない。
3. 回線が遅いので、Project を Fork して、git が Tree 全体を
アップロードしようとしてしまったりなんかすると大変な事になる。
4. だから、一部のファイルだけを UL したいが、コミュニケーションの
問題から事情を伝えて、そこまで行くかどうか分からない。
5. だから、独自にオーバーライドしようとしたのが、先日からここでも
書いていたことです。loader を修正して、かつ、環境変数を変えて
やれば、本家と統合しなくても、部分書き変えのような事が出来る。 >>438
githubからでもプルリクエスト受け付けてるよ 先にhttps://bugs.winehq.org/に書いた方がいい
報告してあるとパッチ送る時説明が楽になるから 描画が早くなるならありがたい
素のWindowsより異様に遅いゲームとかあるし 結論だけ書いておくと、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() などで実が面に描き込む、というようなことをやっているらしい。 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()」されているのに、なぜだろう？？？？ XSync() を追加しても、XShmPutImage() を XPutImage() に修正しても、
何をやっても見た目だけが更新されない。 >>443
> update_surface_region() が遅いんだと思って、
> XShape の作成を、XShapeCombineRectangles() を使う方式から、
> XCreateBitmapFromData() と XShapeCombineMask()
> を使う方式へと変えた。
こうするとなんで速くなるの？ >>445
それは、
>>427-428
の部分と深く関係しています。 X の同期の問題ではなく、MDI Child Wnd の TITLE BAR をドラッグするとき、
なぜか、数秒経ってから、x11drv_surface_flush() がまとめて何十回も呼び出されている
可能性があるかも・・・。
デバッグ表示をリアルタイムで見ていると、見た目が変化する直前までデバッグ表示が
全く出ず、見た目が変化する直前に、どどっと、数十回分の x11drv_surface_flush()
がまとめて出てくる、という現象が起きている。 以下のコードが気になる。
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;
} 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;
} >>448
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。 GetMessage() の方もほぼ同じような感じかも。。
とにかく、flush_window_surfaces() がとてつもなく長い間、呼ばれないことが
あるコードになっている様に見えて、実際、実験してもそう思える。 そうか、もともとは、dirty bit 方式じゃないから、flush_window_surfaces() を呼ぶと、
再計算する必要が無いのに必ず再計算されてしまうから、呼び出す頻度を下げるしか
高速化する方法が無いために、そんな風なコードになっているのかもしれない。 そして、flush_window_surfaces() のコードでは、最低でも 50 (ms) の時間が経っていない場合には
処理をスキップするコードになっている。とことん、flush() しないコードになってしまっている。
これらが原因か・・・。
void flush_window_surfaces( BOOL idle )
{
static DWORD last_idle;
DWORD now;
struct window_surface *surface;
EnterCriticalSection( &surfaces_section );
now = GetTickCount();
if (idle) last_idle = now;
/* if not idle, we only flush if there's evidence that the app never goes idle */
else if ((int)(now - last_idle) < 50) goto done;
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
done:
LeaveCriticalSection( &surfaces_section );
} 元々の Windows では、LineTo などを実行すると瞬間的に実画面に反映される。
だから、そもそも Flush せずに見えないままの描画が残っているなんて時間は
ほぼ 0。
そう考えると、。Wine のこの実装はおかしいな・・・。
1. そもそもメッセージループを回している時しか flush される可能性が全くない
実装になってしまっているらしい。
2. メッセージループを回していても、メッセージがキューに残っている時は、
100回程度メッセージを読まない限り、flush されない。
Windows を「エミュレート」するのであれば、例えば、描いてから 50(ms) 経てば、
必ず flush する、という実装でなくてはならないはず。
Linux では、タイマー処理が難しいのかな？？？ 1. Windows (もちろん、NT系) の場合は、メッセージ・ループ長く帰ってこないプログラムも
絶対ダメというわけではない。
2. そういうプログラムの場合、Wine 側は、描画を、一定時間間隔で、別スレッドの
タイマー割り込みの中などで flush するようにしないと、 正しく、Emulation 出来
ないはず。 割り込みなら、別スレッドを起こす必要が無かった。スマソ。
あと、誤字訂正：
誤： メッセージ・ループ長く帰ってこないプログラムも
正： メッセージ・ループに長く帰ってこないプログラムも うーん
これがボトルネックになっているようには見えない
申し訳ないんだけど描画が遅くなる条件をもう一度書いてもらっていいですか？ うーんと。それはまあちょっと置いておいて、、、。
MDI Child Wnd の TITLE BAR を Drag している最中、メッセージループは一つも
回ってないんじゃないかと思う。
だから、>>455 の「1.」に書いた「flushされる必要条件」が満たされてない。
そのため、surface の pixel配列の内容が実画面に反映されないのではなかろうか。 ドラッグ中にマウスを静止させてしばらく待っていると、 x11drv_surface_flush() と
flush_surface_region() の両方が呼び出された事が FIXME 出力で確認できた。
静止させずにマウスをドラッグし続けると、FIXME 出力が全くでない。
しかも、それを行った時間が長いと、マウスボタンを離した後も、非常に長い間
システム全体がハングアップした様な状態になる。そして、長い沈黙の後、FIXME出力が
出る。
この沈黙の時間は、それまでドラッグしていた時間に比例しているように思える。
なぜだろう？？？ これはどこかに「何かが溜まっている」時の現象の様に思える。
しかし、>>449 を見ると、message_cnt は、減らされるときは、一期に 0 になるのであって、
少しずつ減らされるわけではない。
謎だ・・・。 単にイベントを送信する側でバッファリングしてるんじゃないの？ まあ最初からマルチスレッド意識して書いた感じではないなと思うけど90年代から開発されてるわけだしそのへんはご愛嬌じゃない >>449-450 辺りのソースを見ていて、背理法で語ってみたい。
仮定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. >>450 を見ると、PeekMessage した際に、キューにメッセージが残ってないなら、
flush_window_surfaces() が呼び出されるはず。
3. 「仮定2」 の関数は呼ばれてないのだから、キューのメッセージは、透明化され
てない場合と同程度に高速に処理されてもおかしくない。
4. もしそうであれば、キューのメッセージはあっという間に「空」になるはず。
5. 空になったとしたら、「2.」の通りに、flush_window_surfaces() が呼び出されるはず。
6. しかし、「1.」で述べたように、実験的には、flush_window_surfaces() は呼び出されてない。
7. 矛盾である。
8. 背理法により、これは、仮定の少なくとも一方が間違っている事を意味する。 あるいは、Peek されるだけで、一部のメッセージは取り残されるなら・・・。 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 */
} さらに次のような、枠だけを書くか、実際に動かしてしまうコードが続く :
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 );
} あー。
FIXMEを消してしまっていただけだった・・・。
update_surface_region() や、flush_window_surfaces() は、
ドラッグ中でも、マウスを静止してしばらくすると呼ばれるようです。
マウスを動かしつづけていると呼ばれないらしい。 【やっと原因判明】
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
-->USER_Driver->pMsgWaitForMultipleObjectsEx()
-->X11DRV_MsgWaitForMultipleObjectsEx()
の最後の関数の中で停止してしまう。
正常なら、WM_NCMOUSEMOVE メッセージが到着することによって、関数から
戻って来るはずだと思われる。 >>468
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;
} 【通常時、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) );
} 【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;
} 頭に Msg が付かない方の WaitForMultipleObjecstEx() も
挙動がおかしい。 timeout に 0 を指定しても、無限に
待機してしまうことがある。 Msg が付く方の WaitXxxx で、usleep() で、0.3秒ほど停止しながら、
Polling (Loop) するようにしてから、FIXMEでメッセージを観察してみた。
普段は、usleep() 命令は、呼び出してから 0.3 秒で戻ってくる。
ところが、先日からの遅くなる条件でドラッグし続けた場合、単純な usleep() の
1命令が、呼び出してから、永久に戻ってこなくなる。ドラッグをやめると、
人間が長く感じるほどの長い時間が経過してから戻ってくる。
これは、WINEの問題ではなく、Linux Kernel の問題だろうか？？？ やったことをもうちょっと詳しく書いておくと、
>>469 の 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)後にメッセージが出てくる。 かなり色々やったつもりだけど、ちょっとこれ以上深入りは難しいので、もう諦めようかも。
以下の上京からするとLinuxカーネルの問題かも知れない：
1. タスクバーも操作不能になる。
2. 単純な usleep() も無限に帰ってこない。 Wineでは、昔の MSDN Library の CD もインストールは出来ただが見られなかった。
hh.exe が xxx.COL ファイルを開けないと言ってくる。
yyy.CHM ファイルは、開くことはできたが、右のペーンだけが見えて、左側の目次や
検索のぺーンには何も表示されない。
今回 WINEのソースを見て思うのは、意外とちゃんと書かれていないということ。
MsgWaitXxxx にも、戻り値が明らかに間違っている部分を発見した。
また、TRUE (1)を引数に渡す必要があるところで、1ではない非0 の値を渡している
箇所も見つかった。そのようなコードは後々問題を来すかも知れない。
それに、MsgWaitXxx もちゃんと書かれていない。同時に待機するのは、アプリ・プログラマ
がどんだけ頑張ってもかけないから API が用意されているのだが、そこに明らかな
ロジックの間違いがある。
有名なアプリだけはちゃんと動作するが、実は模倣の程度が意外と低いかも。
有名なアプリだけは動くように調整されている・・・。 usleep() の部分を setitimer(), pause() に変えてみたら、そこは指定した
時間でちゃんと帰ってくるようになった。でも、Linux全体が停止に近い状態に
なる症状は変わらない。端末内の FIXME の表示が途中の文字まで書かれた状態で
改行までいく前に長い間停止する現象が起きてしまっている。 X Window System は、Server と Client で通信を行っているから、Client側では処理が
一瞬で帰って来ているように見えても、Server側では処理に凄く時間がかかっている可能性
があるかもしれない。だから Client側で、関数の呼び出しの前後の時間を計測をしても
それは単にServer にコマンドを送る処理の時間を計測しているに過ぎないのかも
知れない。イメージのバイト数が多いいときには、通信時のデータ・コピーに時間がかかる
から多少時間がかかるかも知れないが、それはまだ表面上の時間に過ぎず、Server 側は
Shapeのくり抜き処理(?)や重ね合わせの処理に膨大な時間がかかっている可能性も否定できない。
だから、XCreateBitmapFromData(), XShapeCombineMask(), XPutImage() の前後の時間を
計測しているだけでは速く見えても、見えない場所でCPUパワーを全開にしてがんばっても
まだ処理を終えてないのかもしれない。
だから、Linux Kernel は、X Serverに CPU パワーを全開まで与えようとしている・・・。
Client側で計測した時間は見せかけの時間であって、処理全体の時間ではない・・・。
だから、タスクバーなども動かず、デバッグ表示の端末の文字も中途半端な場所でWAIT
状態になってしまう・・・。
これが真相だろうか？ そういえば、update_surface_region() が呼び出されたことを示すデバッグ文字列は、後からまとめて
ドドッと出てくる。それは、文字列が「出てない」間には関数が呼ばれてないことを意味する
訳ではなく、実は呼ばれてはいるが、文字列が flush されてないか、または、flush
されていても、端末に CPU リソースが割り当てられないから、文字表示だけが行われずに
文字列がバッファに溜まった状態になってしまっている・・・・。
こう考えれば辻褄が合うかも。 本家の Windowsでは、描画処理が重いときには、OnPaint や OnDraw の関数が終わるまで
の時間も長い。だから、メッセージがたくさんたまっているのに描画が追いついていない事は、
メッセージ・キューに残っているメッセージの個数が多い事で大体の判断が付く。だから、
InvalidateRect(NULL)をしておけば、描画が追いついてない場合は、メッセージループ
が WM_PAINTメッセージを送るタイミングを自動的に後回しにしてくれる。
ところが、X Window System の場合、実際の描画がまだ終わってない場合でも、
「描画関数」自体は一瞬にして戻ってきてしまうから、上記のアルゴリズムが「勘違い」を
起こしてしまうことがある・・・。
そらに悪い事に、WINEが、内部で Surface を持っているときには、LineTo 関数自体は高速に
処理を終えるのに、アプリが予想もしないタイミングで、時間の掛かる flush の処理が行われ
てしまう。
そうすると、OnPaint は高速に終わったと勘違いして、WM_PAINT メッセージが、マウス・メッセージに
完全に連動して大量に生成されてしまう。すると、Pending 状態の X Window の処理がどんどん
待ち行列に溜まっていってしまう。
ドラッグ中は、WM_PAINT が秒間20回も送られるのに、Server が実際の描画を終えるのは、
その何十倍も時間がかかってしまう。
こんな感じだろうか。 さらに、>>465-466, >>468 に書いた、WINPOS_SysCommandSizeMove() は、
CWinApp などとは別の、独自のメッセージループを持っている。
そこでは、さらに、WM_PAINT が不適切に大量に発生してしまっている
可能性がある。
だんだん分かってきたかも。 原因は推定できてきたけど、さて、どうやってこれを解決すればいいか・・・。 ライセンスの関係でややこしいことに成る可能性が存在するから
５chへソースコードは書かないで
ｇｉｔｈｕｂ使ったほうがいい 粒度の低いパッチをちょこちょこアップすると良いのでは。
論理値のあやまりを直すやつとか。 >>483
それでは、日本人の自分に取って手も足もでない状況になってしまうので、とても
困ります。 >>485
なぜ？
ココに書けば問題が生じる可能性もあるのに 協力しにくくしにくくなるように仕向けられて、どうしようもない状態になってる気もする。
make時の表示の無駄が多すぎて、特に警告が出ていても見逃しやすいし、HDDも膨大に
消費するし、ダウンロードやアップロードにも莫大な時間がかかるし。
なんだか、アメリカと北欧の社会的環境以外ではとっても負担が大きいかも、 >>488
ここにソースコードを書けば5chが権利を主張する恐れがある
あなたが書いたものであっても
それは問題でしょう？ MSのやり方に困った人が集まってくるのがLinux。
でも、Linuxのやり方にもまた困る。UbuntuのUpdateも自分には出来ない。
なぜなら、HDDのパーティションの容量が足りないのと、DLに時間がかかりすぎるからと、
クリーンインストールしなきゃならないから、せっかく入れた Wine や Wz, VC++ などの再
インストールに莫大な時間がかかってしまうのとで。それでやっとの思いでなんとか協力
したいと思っているのに、また、ライセンスがどうのこうのとか。
わけが分からない。LinuxやUbuntuのバグに悩まされて、しょっちゅう Logout と Login
を繰り返しながら、やっとの思いでやってます。 MacでWine使ってるけど似たようんだもんだわ。 OSSやLinuxの問題ではなくて
5chのライセンス扱いの問題 >>489
そんな心配はないはずです。
自分は権利を放棄するつもりでやってますし、法的には Wine の LGPL が優先されて、
5ch は権利は主張できないハズ。もし、権利を主張するなら、5ch自体が人が来なくなって、
閉鎖されるでしょう。 >>493
OSSのソースコードを5chに書き写したらライセンスが移るかというとそうではないと思うけど
問題にされる可能性が存在する
新規のソースコードだった場合など、5chが権利を主張してOSSで扱えない可能性が出てくる >>490
Linux板でそういうこと言っても住人を不快にさせるだけだよ
誰も頼んでないのに愚痴言われてもさ
ブログか何かに書けば？ とはいっても、勝手に転載するな、の主張は現在進行でバンバンやってますからねえ… >>496
他所が権利を主張するコードの利用をOSS側が許すかという問題にかかわってきて
それは5chとは別になるね 【ついに出来た】
x11drv_surface_flush() の中で、
update_surface_region( surface );
を実行後、
XPutImage(・・・);
XFlush( gdi_display );
XSync( gdi_display, TRUE );
XSynchronize( gdi_display, True );
で関数が終わっていたところに、試しに
usleep( 1000 * 150 ); // 0.15(秒) の待機
を追加して見たところ、「改善（感覚的な速度アップ）」が見られました。
ちゃんと、ドラッグした時に「XOR反転枠」がマウスの動きに付いてきます。
今までは、「枠」が現れすらしなかったのに。試しに WAIT 値を「小さく」して、
usleep( 1000 * 100 );
とするとダメなままでした。WAIT 値が大きいほど、感覚的に速度がアップ
したような感じになります（一種の逆転現象）。
これは、X Window の Server の処理が終わってないのに、終わったと勘違いして
次々に新しいコマンドを X Server に送ってしまっていたことで、今回の不具合
が起きていたことを裏付ける物です。Linux が CPU パワーを X Server にばかり
与えてしまい、アプリ側のコードは停止する一方て、実際の画面には何の描画も
行われなくなり、タスクバーすら全く機能しなくなる。その結果、システムが
ハングアップしたようになる。 日本語でパッチの記述を書いてくれれば、英訳してくれる奴がスレにいると思うな。
最悪ぐぐる翻訳でも。
あとは日本人でwineにコミットしてる人を探してパッチを仲介してもらうとか… だいぶ前のレスだけれど、 >>439 は信じるなよ。
Wineに修正を送る方法はgit format-patchで整形したパッチを
wine-devel@winehq .orgにメールする方法だからな。(前近代的に感じるかもしれないけれど)
他にも要件がいろいろあるから、 ttps://wiki.winehq.org/Submitting_Patches を一読した方がいいと思う。 >>500
WINE 本家に正式採用されなくてもいいなら、github にプルリクエストを送る、なんて
事は可能なんでしょうか。
ライセンス上は、修正した箇所のソースの断片でも、どこでもいいからネット上のどこかに
アップロードしておけば良いんだと思うんですが。
ネットの回線が遅いから、自分が全く修正してない部分まで全部アップロードというのは
かなり困ります。 要は、著作権が発生するようなソースを書かなければいいんですね。
WINE で、WS_EX_LAYERED の場合に、現状の様に XShape を使わずに、
XCreateWindow の depth に 32 を指定して、ARGB カラーを使うようにして
透明化を実験して見たところ、高速になったようです。
まだ、中途半端ですが。 透明化、完全に上手く行きました。速度は劇的に向上。
システムの(事実上の)ハングアップも全く起きません。
現状で Windows との非互換な部分は、透明部分をクリックしても、下にある Window
にマウスメッセージが送られない、という一点だけです。 >>502
>要は、著作権が発生するようなソースを書かなければいいんですね。
そうそう
wine本家にマージさせるためにどこかにあげてというのでなく
自分のwebsiteでもgithubでもgooglecodeでも、問題がなさそうな場所へ >>506
Qiita にソースをULするのは、著作権的に問題ありそうですか？ Linux の X Window の XShape と、 Win32 の WS_EX_LAYERED は相性が悪いために
単に Win32 を Emulateしようとすると、多分、どうやっても遅くなってしまうと思うんです。
だから、Wine 専用に Windows には無いフラグや関数を定義して、ある新定義の
独自APIを呼んだタイミングでだけ、XShapeを呼び出す仕様にすればいいと思うん
です。それを呼び出さなくても、中の図形や透明部分は自由に変えられると。
で、メッセージが下(Desktopなど)まで届く部分を指定したい場合(外形を変えた
い場合等）だけは、その関数を呼ぶと。例えば、透明を使った一般のアプリでも、
輪郭は楕円にしておいて、中の絵だけを高速に変えたいような需要はあると思う
んです。それは、今の Wineでは出来ません。でも、今述べた方法なら可能になり
ます。
技術的には自分だけでも可能です。でも、この仕組みを本家Wineの人が納得して
くれるか分かりません。
なお、自分のアプリだと、「GroundWnd」なる「受け皿」を作ってそこでメッセー
ジを「せき止めて」下には透明部分であっても、敢えてメッセージが届かないよ
うにしているので、見た目だけ透明に出来れば十分なのですが。
でも、本家に統合してもらわないと、Wineのバージョンアップの度に、こっちで
その独自部分の追加作業が必要になったりして大変なんです。
なんとか話を付けることは出来ないものでしょうか？？？ >>510
早速、ここでの話を受けて、 Qiita に書いてみてます。 >>511
問題のアプリのサンプル(ソースコード込み)と修正した一連のコードをパッチにして
https://forum.winehq.org/
に送ってみたら？ >>513
>>511のような内容を英語で正確にやりとりするのに、とても精神的負担を感じます。
ちゃんと理解してもらえなくて、徒労に割りそうな予感も。 新定義の独自APIとか言い出したら正確に伝わっても賛同されるか疑問だ 結論的には、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 を配布
すれば、dll.so の検索パスも上手く「オーバーライド」できますので、以下のたかだか
18MB程度のファイル群を配布しさえすれば、標準の Wine を壊さないまま、独自の Wine を
特定のアプリにだけ適用し、両バージョンの Wine を共存できるのではないかと思えて
きたんです。
./libs/wine/libwine.so.1.0 1,933,464 # WINEDLLPATH 修正のため
./kernel32/kernel32.dll.so 5,526,999
./gdi32/gdi32.dll.so 2,655,524
./user32/user32.dll.so 4,267,471
./ntdll/ntdll.dll.so 3,256,245 >>516
その際、「wine server」の「server request」の仕様を変更さえしなければ、
標準の Wine を使ったアプリと、まさに同時実行も可能ではないかと。
実際、自分が実験する限り、標準の Wine を使った VC++ と Wz が、
特に問題なく独自 Wine の自前アプリと同時実行で来ているように見えますので。
なんというか、例えば、Wineの実装の構造体にメンバ変数を独自に追加した場合、
それが直接見えているソースは、同一の構造体の他のメンバの相対アドレス、構造体の
サイズが変わるために再コンパイルが必要です。しかし、それを直接見ているのは、
上の 4つの dllのdll.soファイルだけではないかと。そして、その他のdllは、その
構造体を直接見てないのではないかと。それで、カプセルの様にブラックボックスの
中に改造が閉じ込められてしまって、再コンパイルを全くしなくても外の dll 達に
は、その改造が破壊的な影響を与えずに、機能としての変化だけが伝達されるのでは
ないかと。 「dll.so」ではなく「drv.so」ですが、
/wine/dlls/winex11.drv/winex11.drv.so 1,797,340
も配布が必要ですので、合計20MB程度。圧縮すれば 10MB程度のはず。
だから、アプリ本体のバイナリと同時に 10MBを配布すれば独自修正 Wineが
配布できるかと。 >>515
やはり、そう思われますか。
一部の透明アプリに取っては、改造Wineの方がWindowsとの互換性がかなり上がりますが、
他の透明アプリに取っては下がる、見たいな状態になるので、意見が分かれるかな、と思って
たんです。でも、恩恵を受けるアプリもあります。 派生版みたいなのが乱立しそうで恐い
まあ、現状も最新版が必ずしも良いとは言えないから複数バージョンを使い分けるなんてことはやられているが これは大変更過ぎて厳しいだろ
フォークして勝手にやってと言われる可能性大 取り敢えず改変した物もしくはそれが置いてあるURLを本家に晒して反応を様子見かね MSDN Library の CD-ROM 版を、Wineにインストール出来ました。
https://qiita.com/Yutaka_Aoki/items/a83371ebf5c1e967a6f6
なお、確か、MSDN Library 2008 の ISO イメージは、無料で DL 出来たと思います。 wine下で動くspider.exeがやたらと速いんだが
delayが効いてないだけな気がしなくもない Ctrl+Insertでコピーできるようにしたいんだけど
何か方法ある？ そんなショートカットあったなあ
最近使ってなかったから忘れてた 155 名前：login:Penguin [sage]： 2018/03/01(木) 23:01:33.07 ID:fYfWMlBV
Ctrl+Insertでコピーしたいんだけどショートカット設定する方法ありますか？ 片山をReactOSの人と言うのはどういう悪意があってのことなのか 「片山 ReactOS」でGoogle検索した時に一番上に表示したページが、
ウイルス感染している事を、BitDefender Traffic Light が報告したので注意
してください。
これは煽りや虚偽ではありません。 virustotalで確認
アドレスは現状BitDefenderだけ
ソフトウェア全部は見たわけではないのですが
スクリーンセーバーでひとつだけ他のベンダーが反応＞CMC
ぐぐるとアドウェアとして
MZさん、面倒かもしれないけど全部virustotalにぶち込んで
反応してしまったら各ベンダーに報告をほねがいします
IPAに相談したほうが早いかも https://www.virustotal.com/#/domain/katahiromz.web.fc2.com
↑を見ると、ScreenSaver の他に、例えば、
Detect 6/55, Data Scaned 2014-08-29, calch_setup.exe
Detect, 9/55, Data Scaned 2014-11-19, file-7704712_exe
と出ます。他に roumaji.zip なども。
多分、BitDefender や CMC だけでなく、過去に(?)、9 つの Security Soft で検出されたということでは？ そのサイトには
「d4178884156e93779603fe5d33d3fc8f749fd2280a199b19d5d218bb8548b6b1」という変な名前のファイルがあり、
9つの Security Soft でウイルスを検知したようです。
https://www.virustotal.com/#/file/d4178884156e93779603fe5d33d3fc8f749fd2280a199b19d5d218bb8548b6b1/detection
9 engines detected this file
SHA-256 d4178884156e93779603fe5d33d3fc8f749fd2280a199b19d5d218bb8548b6b1
File name d4178884156e93779603fe5d33d3fc8f749fd2280a199b19d5d218bb8548b6b1
File size 668.72 KB
Last analysis 2014-08-25 00:08:58 UTC
1. Ad-Aware; Gen:Variant.Graftor.50154
2. BitDefender; Gen:Variant.Graftor.50154
3. Emsisoft; Gen:Variant.Graftor.50154 (B)
4. eScan; Gen:Variant.Graftor.50154
5. F-Secure; Gen:Variant.Graftor.50154
6. GData; Gen:Variant.Graftor.50154
7. Ikarus; Win32.SuspectCrc
8. Symantec; WS.Reputation.1
9. TrendMicro-HouseCall; Suspicious_GEN.F47V0818 The Wine development release 3.3 is now available.
What's new in this release (see below for details):
- Beginnings of Vulkan support.
- Direct3D multi-threaded command stream enabled by default.
- Multisample textures enabled by default.
- Support for game controllers through SDL.
- Support for loading CIL-only .Net binaries.
- Various bug fixes.
日本人っぽい名前が2つに増えているね Wine において HTML HELP (CHM) を表示時、リンク先へ飛べない場合の原因が分かって来ました。
https://qiita.com/Yutaka_Aoki/items/a83371ebf5c1e967a6f6
飛べる場合 : リンクに Java Script を使ってない。
飛べない場合 : リンクに Java Script を使っている。
Java Script の実行が上手く行ってないのではないでしょうか。どなたかにさらに原因を追求して
不具合を直していただければ幸です。 なお体験から言えば、リンク先のHTMLのファイル名に日本語が使われている場合も、
リンク先へ飛べないことがあるようです。 なるほど。CHMがセキュリティ的にまずい理由がなんとなくわかった [HTML HELP (MSDN Library) 関連]
nativeなDLLの組み合わせを根気よく実験したところ、上手く行く組み合わせが見つかり、
飛べなかったリンクへも飛べるようになりました。詳しくは、上のリンク先を見てください。 自分の環境(RTKernel)だとKindleを起動した時に
四角の枠だけ表示されて止まる
LowLatencyKernelだと正常に表示される OSで設定したカーソルのサイズとWineアプリ上のカーソルのサイズが違うけど
自動で設定同期してほしいわ The Wine development release 3.4 is now available.
What's new in this release (see below for details):
- More Vulkan support, including integration with the X11 driver.
- Better handling of privileged instructions on x86-64.
- Hex edit dialog improvements in RegEdit.
- Assortment of patches merged from wine-staging.
- Various bug fixes. >>486
pastebin.com にコード本体（と著作権者表示）を貼って、
そこへのリンクと解説などをこちらに書くようにすれば、解決しますよ。限定的だけど。 WineでMFCで書かれたアプリを実行した場合、MSに著作権的に何かモンク言われたり
するんだろうか？ ↑は、特に、static link している場合について。
mfc**.dll などに dynamic link (dll) している場合は、その mfc**.dll がクリーン開発
されていれば問題ないと思う。だから、Linux用には dynamic link でアプリをビルド
し直せば大丈夫のはずだとは思う。問題は、クリーン開発された mfc**.dll にちゃんと
互換性があるかということになる。mfcのソースを見ずに mfc をちゃんと実装するのは
意外に難しい。なぜならちゃんとドキュメントされていない事が多いから。だから、
困った事になるかも・・・。 https://wiki.winehq.org/Developer_FAQ
↑によると、MFCのソース(MS自らがVSに付属)を見た人は、MFCの互換ライブラリを
作る事はできないんだそうだ(Wine陣営の方針)。↓
Q: Who can't contribute to Wine?
A: Some people cannot contribute to Wine because of potential copyright violation.
This would be anyone who has seen Microsoft Windows source code (stolen,
under an NDA, disassembled, or otherwise). There are some exceptions for
the source code of add-on components (ATL, MFC, msvcrt); see the next question.
Q: Can I contribute if I've only seen the source to ATL, MFC, and/or msvcrt?
A: Yes, but not on those components. Also please state on the mailing list
that you have seen the source to these and that you will not contribute to
them. You are free to contribute to other areas of the Wine source code.
そして、Wine陣営によるMFCの実装(= builet-in タイプ)は今のところ存在してい
ないらしい。つまり、MFCのDLLは、MS純正のもの(またはソースからビルドしたもの）
を使う事になってしまうらしい。
Wine currently has no built-in MFC implementation. Most applications can run
using native MFC DLLs, so there is not a lot of incentive to work on one. It is
also possible (with a lot of work) to compile the MFC from source and thus
produce an mfc42.dll.so library.
Please refer to the Winelib User's Guide for how to do this. もし、MSが何か言ってきたら、既存のWindowsソフトは大部分が動かせない事になるかも。
プロは、ほぼ100% MFCを使っていたから。 制限が掛かるとすれば先ず作成とか配布だから実行は問題ないだろ それは、本当はそういうわけでもないはずだけど、みんなで使って無視してしまう手がある。
EU は、色々と著作権を制限しているらしいから、MSの主張は通らないかも。
https://www.infoq.com/news/2012/04/apis-copyrighted
Phipps argues that this would only affect America:
ヨーロッパでは、大陸全土にわたる法律で、プログラミング言語とインターフェースは、
著作権保護にふさわしくない(好ましくない、上手く行きそうに無い、ありえない）と断言
している。そして、たとえ、たとえ著作権的に守られる場合であっても、その法律には
例外が書かれており、もし、著作権を侵害する目的が相互運用性のためであるならば、
著作権を無視して良いとされている。
オラクルの勝利によってもたらされたいかなる先例も、アメリカのテクノロジー産業に害を
与え、競争相手にアドバンテージを与えてしまうかも知れない。 This would be largely an American phenomenon. In Europe, there is continentwide
law asserting that programming languages and interfaces are unlikely to be
copyrightable, and even if they are, an exception written into the law allows
copyright to be ignored if the purpose of infringing it is for interoperability.
Any precedent set by an Oracle win would likely just harm the American
technology industry and offer an advantage to its competitors. 「interoperability(相互運用性)」というものが、どういうものか分からない。
「WineでWindowsアプリを実行する」というのも、それに該当するのだろうか？
だとしたら嬉しいな。日本もその法律を作ろう。 （少し違うが）、EPSONが、互換インクを禁止する事はできない、と似た事で、
MSがどんなに著作権を主張しても、Windowsアプリの互換プラットフォー
ム(Wineなど)上の実行禁止は「無視」してよい、ということらしい。
だとすると、EUでは、MS Officeや、Visual Studio、MFCを静的リンクした
アプリなどなどをWine上で実行する事は、全て「合法」という事になる気がする。
やった！ ということはということは(笑顔)、WindowsのDLL(=EXEと同じ)をWineで勝手に実行する事も、
「Interoperability」のためだから、完全に合法なんだ！！！！ 1. アメリカでも、fair use (公平利用、独占禁止) のためであれば色々な権利が制限される。
GoogleとOracleのJavaの訴訟でも最後は、それが認められて、Googleが勝った。
2. これが判例になり、実際に裁判すれば、言語やインターフェース(関数やAPIなど)が
同じ「互換ライブラリ」「互換プラットフォーム」「互換言語」はほとんどの場合、合法であり、
真似された方は権利を主張出来ないだろう。
3. しかし、最終判決がどうであれ裁判を起こされること自体が負担であり困る側面がある。
大企業で無ければ、訴訟費用(弁護士料)やかかる時間で会社やプロジェクトが潰れかねない。
4. 対抗策としては、「みんなが使う/行う」事がある。みんながやっていけば、個々の組織が
訴訟される可能性は低くなる。なぜなら、「他のプロジェクトだってやってる」と主張すれば
良いから。どうしてかというと、裁判には、「公平性」が求められるから、そのプロジェクト
だけを狙い撃ちにするのは不公平、ということになるから。 誤：同じ「互換ライブラリ」「互換プラットフォーム」「互換言語」はほとんどの場合、合法であり、
正：同じだけの「互換ライブラリ」「互換プラットフォーム」「互換言語」はほとんどの場合、合法であり、
当然の事ながら、上の論理が通用するのは、クリーン開発した場合に限る。
つまり、言語やインターフェス（仕様や使い方、関数のプロトタイプ宣言や構造体の定義など）が
同じだけで、それを実現するための「実装」は自分の頭で考えて、自分でコーディングした場合。 スマン。実際は、アメリカでは訳が分からないらしい：
https://law.stackexchange.com/questions/4377/is-wine-illegal
連邦巡回区控訴裁判所(CAFC)が、次のような事を言っているらしい：
that the declaring code and the structure, sequence, and organization of the
API packages are entitled to copyright protection
「宣言コード、構造体、順序(並び方)、APIパッケージの構成の仕方（組織）は、
著作権保護の対象になっている。
しかし、こうも書かれている。
However, because this issue is outside the scope of the CAFC's exclusive jurisdiction (this is a copyright issue, not a patent issue), the holdings are not binding in any other circuit.
しかしながら、この問題は、CAFCの独占的な司法権の範囲の外にある（これは特許の
問題ではなく、著作権の問題だから）ので、この判決は、他のどんな(アメリカに
11区ある)巡回区とも結びつかない。
Each circuit is free to review anew the copyrightability of APIs when such a case comes up.
「それぞれの巡回区は、個別のケースが出てくるたびに、API群が、著作権
で保護されるべきかどうかを改めて再調査(再吟味、再審理）する事は自由
である。」
To address your fair use question would be simply speculation, because fair use is always assessed case-by-case, and even in WINE's closest analogy (Oracle v. Google),
あなたが提出したフェア・ユースの疑問に取り掛かる事は、憶測に過ぎなくなる。
なぜなら、フェア・ユースは、いつも、ケース・バイ・ケースで処理されるからで
ある。それがたとえ、Oracle 対 Google のような類似性の高い裁判が既にある
WINEの場合でさえも。 あ、またスマン。CAFCの主張は、最終的には覆されたのかも知れない。 誤：それがたとえ、Oracle 対 Google のような類似性の高い裁判が既にあるWINEの場合でさえも。
誤：それがたとえ、WINEと非常に類似性の高い場合(Oracle 対 Google)であっても。 【EUとアメリカのCAFCは、真逆の立場】
EU： >>556
In Europe, there is continentwide law asserting that programming languages
and interfaces are unlikely to be copyrightable, and even if they are, an
exception written into the law allows copyright to be ignored if the
purpose of infringing it is for interoperability.
USA: >>563
The CAFC held that:
that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection
つまり、EUは、プログラミング言語やAPIは、著作権保護にふさわしくなく、
仮に、一般論的には著作権保護されるべきような対象であっても、
（プリンタインクのような）相互運用性のためなら、著作権は無視
して良いという立場。
対して、アメリカの CAFCは、それらは保護される、という立場。
しかし、アメリカでも「Fair Use」のためなら、著作権保護されない、ということであり、
実際、Google vs Oracleでは、最終的には「著作権保護されない」事になった。 そもそも米国では判例が重視されないから過去の判決に大きな意味はない なぜ、アメリカが訴訟社会なのかが分かった。
例えば、「Fair Use」 ひとつとっても、法律には、細かい条件が書かれ
ていないらしい。だから、裁判起こしてみないと結果が分からないらしい。
困ったもんだ。 >>567
昔聞いたのは、アメリカでは、名文化された法律が少ないから、過去の判例の蓄積が
アメリカの法律体系そのものである、という事。 http://judiciary.asahi.com/corporatelaw/2013031400034.html
【海の向こうのコモン・ロー：「法律」がない国々】
世の中には「法律」が存在しない国もあると聞いたのは、大学生の頃であった。
そうした国での法は判例なのだと。
コモン・ロー(英米法)：イギリス、アメリカ、カナダ、オーストラリア、インド等々
シビル・ロー(大陸法)：フランス、ドイツ、オランダ、ベルギー、イタリア、スペイン、ブラジル、
アルゼンチン、中国、韓国、日本
最も伝統的な分野の一つである契約法についてみると、（一部の例外を除いて）アメリカに
おいては日本の民法のような制定法は存在しない。その代わりに、古くから続く判例により
形成されたルールが法として適用される。
まずもって、日本の法律とアメリカの法律では条文の数が違う。大抵において、アメリカの法律
の条文数は少ない。 100年前に文語体で書かれた法律が現役な国とは違ってるな・・・ 弁護士費用が、着手金0の、「完全成功報酬」なんだって。。。だからか。
あ、そうか、これで日本がライセンセス関係で怯えて何も出来なくなってしまう
のか・・・。なるほど、これではソフト開発でアメリカと差が開くばかりなハズ
だ。 WineとJavaでは事情が異なるかも。
JavaはそもそもWindowsに対抗するような意味もあったし、当初からマルチプラットフォーム
をかかげていた。だから、もともと他社が入らなくても「公平」性の担保がなんとなくあった。
そこに独占状態であるGoogleが入ってきて、Sun/Oracleの努力を台無しにしかねないような
事をし始めた。Oracleにはアイデア量や今までの努力が還元されないのに、Googleばかり
が儲かる。そもそも、Googleは何もしなくても莫大な金が舞い込んでくる。なんか、Googleの
方にこそ理不尽さを感じる人は少なくないはず。だから「Fair Use」が認められなかった可能性
がある。
一方、Wineの場合は、不公平の親玉なのは MS のほうであって、Wineは、それを除去すべく
現れた「公平の星」のようなもの。だから、Fair Use が認められる公算は大きい気がする。
というか、普通の感覚だと、MSより、Wineの方に公平さを感じるだろう。
Googleは企業自体がもともと不公平さを持っている感じがする。 ・MS：不公平 Wine：公平
・Google：不公平 Java(Sun/Oracle)：公平
というイメージが市民感覚としてあったのではないか。個人的には上記のように感じる。
MSがいやな事ばっかりしてきて困り果てていたところに、Wineが対抗してきた。
だから、Wineは市民のミカタな感じがする。
一方、実は、JavaもMSへの対抗みたいな位置付けも持っていた。だから、Javaが
反映すれば、MSも弱まるかも知れないし、市民にはJavaを応援している人が多かった。
ところが、そのJavaが壊れかねないことをGoogleがやりだした。兼ねてからGoogleが
民主主義に及ぼす悪い側面を市民は懸念していた事もあって、GoogleよりJava(Oracle)
を応援したい人が多かった。
こんな感じだろうか。 Androidのjava実装はGoogleが作った物ではなくApacheのjavaVMからのフォークなんだけどな Oracleを応援したい奴などいるのか？という感じだが Java開発元(Sun)を応援したい人は大勢いた。 BorlandとOracleってなんかあったっけ？ Sunファンはいっぱいいたな。かくいうオレもSolaris使いだった。家では86版使ってたし
でもｵﾗｸﾙ、ﾃﾒｰにファンなんかいるのかと小一時間(ry Solarisはデフォルトの日本語文字コードがShiftJISって聞いたな。 Wine 3.5 Released
https://www.winehq.org/news/
March 30, 2018
The Wine development release 3.5 is now available.
What's new in this release:
More Vulkan support, including the vulkan-1 loader.
Support for RSA and ECDSA cryptographic keys.
Improved manifest file parser.
Support for the Places toolbar in file dialogs.
Various bug fixes. >>583
10年くらい前のHPUXがcp932だったけど流石に今はUTF-8になってそう (´ε`;)うーん
https://wiki.archlinux.jp/index.php/Wine#DXVK
> 警告: DXVK は DirectX 11 の DLL を上書きするため、オンラインのマルチプレイゲームではチートとして認識されてアカウントが ban される危険性があります。自己責任で使ってください。 なんか、ここ数日の livedoor の記事に、日本の家電が駄目になったのは、英語が
出来ないからマネージメントできないからだとか、40才までコーディングばかり
していたからマネジメント能力がなくなるからだとかか、フィリピンなどにも
コーディングできる人はいくらでもいるとか書いてあったけど、なんか違うな。
一言にコーディングといっても、実際の能力の差は大きいし。
非常に難しい内容のコーディングが出来る人は希少種で、そういった人が
圧倒的に不足していると言われている意味が、記事を書いた人にはわかってない。
沢山いるのはレベルの低いプログラマ。レベルの高いプログラマは非常に足りない。 スレ違いごめん。元の記事読んで>>598に概ね同意なんだけど
欧米で言うマスターとかプロフェッショナルは一つのことを突き詰めて誰よりも上手くできることで
手広く平均的にやれることを評価するのが日本で、欧米は一つでも抜きんだ能力があれば変人でも重宝される
そういう意味でエンジニアの雇用の形態が日本と違うからレベル高い技術者が育たないのでは 日本の家電がダメになったのは著作権に縛られたからってのも大きい
携帯mp3プレイヤー →著作権無視の韓国および体制を確立したApple
DVD/BD → コピ1だのコピ10だの、DivXやらmp4再生やら何時になったら漬けるのよ個のバカ日本企業。
mp4再生だけで中華製しか選択肢ないわ
で、ものすご～く遅れて対応。 出揃うころには中華格安機に占領されている
SIMフリーやらとにかく対応が遅い、高い、無駄な機能てんこ盛り 初心者がLinuxとストレスフリーで生きる為の6か条
1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。 初心者がLinuxとストレスフリーで生きる為の6か条（訂正版）
1．Winとデュアルブートは可能ですが、Win側がコケたらWinの修復ツールは使えません。
2. 印刷時にはドライバーを自動的に探してくれます。でも最新プリンタでは見つからない事も有ります。
3. WifiはWindowsと違いドライバーを入れなくとも使えます。もしもの時はググれば解決できます。
4. 音楽・動画・画像の編集/制作はあきらめなくとも大丈夫です。
5. Nvidia製品の使用はドライバーが別途提供されてるのでそれを入れましょう。
6. 教本を買いましょう。Windows界でもググレカスは遠回りです。
7. Ubuntuを我慢して使い続ける必要は有りません。
他の鳥を選びましょう。 Windowsとの共存なんて、
・wineで試して動いたらラッキー
・動かなかったら仮想環境に入れたWindowsで動かす
で十分だわ
仮想の方はネット機能を切って隔離してる >>607
仮想環境のWindowsは、デスクトップも丸ごと「枠」の中に入って、アプリも
その範囲の中で「クリッピング」されるんだよね。使いにくそうだな。 >>609
それだと、Linuxのアプリとか端末(とかのWindow)と同時使用が難しいのでは。 別に難しいと感じたことはないなぁ
ディスプレイが小さいと不便に感じるのかな 同じく枠があって困ったことはないので
Virtualboxでシームレス(枠と壁紙部分を消す)とか出来ることになってても使ったことはないw
>610
枠を嫌悪するとしても、最悪、ホストで複数デスクトップ使うようにして、
そのデスクトップ一つにゲスト貼り付けてフルにするだけじゃね？ LinuxのDEの多くはデスクトップ画面を複数持てるので、仮想マシンを最大化して使っても、ホストの操作をしたければ別のデスクトップ画面に切り替えればいいだけ。 VMをワークスペース分けずに使ってるやつなんておらんやろなぁ 例えば、あるフォルダに a.txt というファイルがあったとして、それをVM内のWindowsで
書き換えて、Linuxから読み込む、という事は出来る？
a.txtが入っているフォルダのドライブは、NTFSとして。 a.txtがあるフォルダをWindows側で共有して、Linux側はそれをマウントすればできる。 ひとまず共有はできるとして、後はLinux自体の色々な不具合が問題になるかな。 LinuxのファイルマネジャーからWindowsの共有フォルダへアクセス出来るだろが 今UbuntuでFireFox使ってるけど、WheelMouseのスクロール量が多すぎて困ってる。
機能は少なすぎて困ってた。
調整するとそのページでは直るが、また、変になる。 間違って20の方にカキコしてしまったからここにも投下。
winfileがオープンソースになったとさ。
(p)https://forest.watch.impress.co.jp/docs/serial/yajiuma/1116188.html
winefile(Wineの実装)と見比べて見ると面白いかも・・・ Pentium G3220, GTX 650, メモリ6GB, という低スペックな環境
素のWine-Staging 3.5だとfpsが5未満で、まともに遊べなかったGTA5が
DXVKを試してみたら、fpsが20-30は出て普通に遊べる様になってびっくりした
明け方/夕方の太陽が眩し過ぎる問題さえ我慢できれば、充分にプレイ可能
以下、いくつかの問題回避策のメモ
・起動時のランチャーがcef関連で落ちる → WIndowsのバージョンをXPにする
・主人公や通行人等のキャラクターが描写されない → ドライバを最新にする（390.xx）
・影がおかしい → ゲーム内設定でソフトシャドウを"NVIDIA PCSS"にする >>623
winefileなんかと比べたらwinfile様に叱られるぞ(笑) クリーンルーム方式を使ってると、Windowsのソースを見たらwineの開発には参加できなくなるんだっけ？
公開されてるwinfile.exeのソースを観ても同様かな。 カーネルとかコアのDLLならまだしも、アプリ程度なら問題ないと思うけどな。 アイワナ系のゲームとか動かんなー、GameMaker（Pro）製のゲーム。
SteamのWindowsゲームも、MacでWine/CrossOver経由でもまともに動かんし、まぁ、しゃーないかなー。 DLL改変とみなされてネット認証が必要なものとかネトゲとかはBANされる可能性があるらしいがな windowsの進化が完全停止したらゴールは近い
だが、その頃には必要性が無くなる 完全停止しなくても、少なくとも昔のアプリは古いAPIしか使ってないわけだから大丈夫。
逆にWin10を見ていても「有用な」進化はできてないわけだから、もし追加されたとしても、
新しいAPIは使われない可能性は高い。 The Wine development release 3.6 is now available.
What's new in this release (see below for details):
- Support for PNG format icons.
- Support for 1D textures.
- More infrastructure for high DPI support.
- OLE data cache improvements.
- Various bug fixes. 最初は「とりあえず動いてくれればいい」で始まったプロジェクトなのに
これだけ完成度が高くなっちゃうといろいろ不満が出てきちゃうんだな
フリーソフトが絶滅した過程をそのまま再現してるようだ パソコンの性能も通信速度も昔とは大違いだから
開発にかかる時間的リソースは高効率となり
wineに限らず、オープンソース界隈は格段に進歩してる気はする The Oracle vs. Google Case Is Concerning Some Wine Developers
https://www.phoronix.com/scan.php?page=news_item&;px=Oracle-vs-Google-Wine-API
ふーむ？🤔 >>641
JavaのOracleとGoogleの抗争で、Wineの人もWinが今後どうなるか分からないから、
議論が始まり出して、FSFの人にも連絡を取った、みたいな話だよね。
でも、この裁判もまだ数年は本当の結論が出ないし、また、出たとしても、他の
裁判に影響するわけではない、というような事も書かれている。 誤：JavaのOracleとGoogleの抗争で、Wineの人もWinが今後どうなるか分からないから、
正：JavaのOracleとGoogleの抗争で、Wineの人もWineが今後どうなるか分からないから、 よく知らないけど、wineって法的な問題があるの？ よく知らないけどあるならこんなに発展してないんじゃないの？ >>644
結論的に言えば、アメリカには成文法が少ないので、問題あるかどうか分からないらしい。
EUでは、「相互運用性のためなら著作権を破って良い」という明文があるので、
大丈夫なんだそうだ。 アメリカでは陪審員が裁判を大体決めるので、多くの市民がMSよりWine
が大切だと思えば大丈夫。だから、Wineの場合は、まず大丈夫だと自分は
思ってる。 っていうかその理屈だとBash on Windowsも問題あることになるんじゃ そもそも、始まりからして、民主主義=「感情重視」なんだってさ。
だから、市民がどっちが正しいかを決めてしまうらしい。で、Googleとかは
市民から警戒されてるから負けやすい。マクドナルドとかも負けやすい。
恐らく、MSも負けやすい。そして、Wineは、市民の味方的な感じだから
勝ちやすいはず。
それと、無料な物は、「fair use」として認められるかの性が高まるらしい。
つまり、Wineは、大丈夫の可能性が高まる。だから、アメリカは無料が流行って
しまったのかも知れない。 裁判してみないと分からないから、訴訟社会なのかもね。やってみないと分からない。
なんとメンドクサイ国なんだろう。 ZorinでPlayOnLinux4.2.12を「$LC_ALL=C playonlinux」で起動して動かしてんだけど、どのソフト入れようとしてもエラーでて困ってる >>651
LC_ALL=Cを使うのは何かのおまじない? ゆずソフトのゲームどれもこれも致命的なエラー「""は対応していないメディアタイプです」と言われて起動出来ない……。吉里吉里が悪いのんか Windows Subsystem for Linuxみたいなみみっちいことせんと、
たったとWindowsのkernelをUnix系のそれにしてくれりゃーええんよな。 >>644
ないよ。問題があったらとっくに訴えられてる。訴訟社会のアメリカでそうなってないってことは問題ないってことだ
そもそもアメリカには成文法自体がほぼ存在しない。全ては裁判員が「これがアメリカだ！」って決定する社会 WineでPassmarkとHDbenchを試したところ、シングルスレッド性能はWindowsより若干高く、マルチコア性能は半分程度に留まった。
おそらくWine内部処理の都合と言うことにｗ
また、DirectXテストは通らなかった。GDIクラスのみ。 IrfanViewとか同じ機種のWindowsで動かすよりはえーなーってのがソフトは結構ある。
単純な奴ほど速い印象。 >>658
Wineの場合、どこからも大した金が入ってきてないだろうから、訴えても賠償金取れない
って事もあるかも。というか、そもそも無料の場合、「fare use」が適用されやすい、という
法則があるらしいし。 エロゲのムービー関係はwinetricksでwmp10辺りを入れればいけた気がするが、定かではない Xubuntu 17.10を18.04にアップグレードしたら
Wine上のePSXeのゲーム速度が
17.10の時より遅くなるようになってしまった
17.10の時は59～60fpsだったのが
18.04にしたら35～45fps… orz >>655
デスクトップ環境を英語にしたらUTAUはインストールできるようになっけど音が出ないし、7zipはインストールできなかった >>663
ePSXeはDX9に固定する設定ないの？ DEをLXDEに変えたら、これまでどおりの速度で動くようになった
でも、PCmanFMからePSXeを起動すると
ステートセーブしたデータを読み込んでくれない
仕方ないのでThunarからePSXeを起動すると
こっちはセーブデータを読み込める…(・・? マルチプラットフォームでlinux版もあるのに、なぜあえてWindows版をwineで動かそうとするのか linux 版をlinuxで動かすのって
普通でつまんないじゃん Linux使いこなせるなら、Wine程度ならどうにでも ワケ分からん。Wineでは動かないソフトがあるから、それを動かす方法を見出すのは
大変だぞ。 msが「著作権ガー」と言っても
mp/6→msdos
ロータス→excel
macgui→win
ネスケ→エクスプローラー
h264→vc1
を思い起こすと、あほらしくなる >>676
気持ちはわからなくもないけどいい意味でMSは囮になってくれてる
他の企業と違ってMSが法務に力を入れて主張しすぎて嫌なイメージが先行しているけど
模倣品でさえ知的財産権は保証される事を忘れるとUnixの模倣物であるLinuxも標的になって叩かれるからね でもそれ言い出したら表計算ソフトなんて・・・・・ｗ VisiCalcだっけ？名前しか知らない・・・
俺の親父はDOSの頃から一太郎使ってるらしい。 IEはSpyglass Mosaicのライセンス品がスタートやしw Macに関しては、スティーブ・ジョブスが復帰した時に真っ先にやったのが、ビル・ゲイツと会ってApple社がMicrosoft社を特許関係で訴えない代わりにMicrosoft社はMacintosh版のOfficeを出し続けると取り決めたこと >>671
ePSXe Linux版使ってみたが
メモリーカードを手動で切り替えなきゃいけなかったりするので
まだまだWin版は手放せないな .NET4.6をいれたいのだけど
なんか方法ある？ >>682
Wineが使えなくなるとMacのサードパーティ製ソフトが多数失われる
公に語られることは少ない、でも実態は把握してるだろう
だからWine絡みで損を被る事案発生とAppleが考えれば、対抗しそうではある
もしMSが動いてもMicrosoft VS ALLみたいな様相じゃないかな
今のMS、GPLにどっぷり漬かってて敵対行動するのかというのもあるし、勝ち目も薄いとなれば
MSがWineを今更訴えるメリット皆無、デメリットが勝る 初歩的ですみません。
ターミナルから、cmd 起動しつつパラメータ渡すことできますか?
wine cmd hogehoge.exe
みたいな。 >>691
>>692
ありがとうございます。
windowsと同じオプション使えるんですね。
帰ったら試してみます。 確か、例えば、Wz editor でも、Linux の端末からコマンドラインオプション渡して
起動できたと思った。ただし、DOSとLinuxでパスの表現が異なる事があるので、
スクリプト書いてパスの形式の変換はしてたと思った。確か、変換用のコマンド
ラインツールがあって、スクリプトの中に、
wine wz `そのコマンド`
みたいにした気がするけど。 The Wine development release 3.7 is now available.
What's new in this release (see below for details):
- MSI custom actions run in a separate process.
- Support for job files in the Task Scheduler.
- Improved viewport support in Direct 3D.
- Larger resolution version of the standard icons.
- Various bug fixes. 3.0あたりから全然変化を感じなかったけど
3.7からは今まで変わらなかった細かい部分が良くなってるねぇ https://www.winehq.org/pipermail/wine-users/2009-May/053012.html
Run program as background job
dtv版のLinuxでテレビ総合スレにも書いたのですが、wineでバックグラウンドで動かすのは
難しいのでしょうか？
どなたかできた方いらっしゃいますか？ 説明不足でした。すみません。
やりたいことはchinachu(Linux用テレビ録画アプリです）の録画終了後スクリプトで
closed captionをass字幕に変換するcaption2assCというWindows用ソフトを使いたいのですが、
コンソールが出るフォアグランドでwine caption2assCとやる分には問題なさそうですが、
chinachuの録画後スクリプトからwine caption2assCとやると起動しないようなのです。
バックグラウンドのシェルでwineを使うのは無理なのでしょうか？ >>699
レスありがとうございます。
環境変数DISPLAYってLinuxのx serverの値ではありませんか？
ぐぐったらLinuxの環境変数はwineにも引き継がれるって書いてありましたが、
この場合と何の関係があるんですか？
お教えいただけると幸甚です。 >>696
既存アプリを使ってる分には全く違いを感じない
実行速度も差異を感じない
具体的にどんな状況でなにが変わったと体感したんだ？ >>703
Common Source Projectのテープ名表示
ドラクエＸベンチマークの女の子の目の消え具合など 音源の遅れが目立つようになった気がする -> 3.7 >>700
解決していそうだけれど、
コンソールが出るフォアグラウンドの場合と、chinachuの録画後スクリプトでは環境変数が違う可能性を言いたいのかも?
あとは実行ユーザー? >>706
未だ解決していないので、pythonスクリプトのarib-ts2assというgithubにあるのを使用しています。
レスありがとうございました。 office2007って、wine1.6でも動きますか？ すいませんが、こちらにも告知させてください。
wimeが3.5.2→3.6.0と、バージョンアップをしていました。
またしても、FreeBSDでのwimeの導入体験を書きました。
詳細は以下のスレで。
FreeBSD での Office 環境を語れ! その2＠UNIX板
https://mevius.5ch.net/test/read.cgi/unix/1107211157/835-n
thomas氏は、最初の頃、このスレで告知してたんですよ。
Linuxのみなさんも使ってくださいよ、盛り上がってくださいよ……。 本気でwinからlinuxへ引っ越し考えてる
だからwineもお世話になりそう VMwareとか仮想環境で使えば？
スナップショット機能があるから事故ってもこれで巻き戻せる。
俺はMacのParallelsでWin10を飼ってる。 常用してる身からすれば
すぐ使えるんだから、すぐやればいいのにと思う
実機でな win10homeは自分でアプデ止められる情強が使うものだからな wineはいちいちパッケージわけててめんどくさい
全部ワインに詰め込んどけばいいのに MacのHomebrewはその通り、wineに詰め込んでる。
パッケージの分離はない。
だけど、次期macOSから32ビットが排除されてしまうので、32ビットEXEも当然動かない・・・ >>712
Winと違って端末操作の習得とコマンドの暗記はLinux利用者の義務なんでダメです >>717
それって具体的にどういうことなん、32bit無くすって The Wine development release 3.8 is now available.
What's new in this release (see below for details):
- Infrastructure for writing kernel driver tests.
- Support for showing file properties in the Shell browser.
- MP3 decoder as a DirectX Media Object.
- More support for the Task Scheduler.
- Support for COM aggregation in UrlMon.
- Various bug fixes.
Visual C++の64ビット版でインストール先がSyswow64配下になってしまう件が直ったそうだ(Bug 30713) >>684
dotnetfx_cleanup_tool スレチだけどmacの最近のmonoでWinFormsアプリがまったく動かなくなってるのはどうしてなの？ 順次ubuntu18.04に入れ替えているんだけど
リリース直後は正常に完了していた
winetricks allfontsが失敗するようになった
みんなはどう？ download.microsoft.com (download.microsoft.com)|104.127.193.64|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 404 Not Found
2018-05-16 21:30:54 エラー 404: Not Found。
Executing cd /home/doraemon/.cache/winetricks/PowerPointViewer
------------------------------------------------------
sha256sum mismatch! Rename /home/doraemon/.cache/winetricks/PowerPointViewer/PowerPointViewer.exe and try again.
こんな感じ >>725
ありがとう
しかしwinetricksを最新版に更新することで解決してた
wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks
sh winetricks allfonts
常に最新版にアプデされているものと思っていた xaudio2インストールするとWinアプリによってはサウンドおかしくなるのかな
普通になってたのにアプリによっては途切れ途切れになる
Xaudio2が犯人かは知らんけど入れてない別の環境だと問題は発生してないし >>728
パッケージマネージャーで入れた場合は上流で更新されてもメンテナが確認して更新するまでは変わらんよ
ソフトが勝手に最新版になったらライブラリ足りなくて動かないとかが起きる 僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
ZKYMQ Debian SidでPageOneがまともに機能しないのが悲しい……
aobookでも読めるけど作者さんとメールして機能追加してもらったりと思い出深いからなぁ
かといってWinには戻りたくない https://www.winehq.org/news/2018052501
Wine 3.9 Released
May 25, 2018
The Wine development release 3.9 is now available.
What's new in this release:
- OpenGL core contexts enabled by default in Direct 3D.
- Beginnings of Direct 3D 12 implementation using vkd3d.
- More support for the Task Scheduler.
- Some more Task Dialog support.
- Better arrow support in GdiPlus.
- Various bug fixes. Ubuntu18.04LTSで # apt install ~~~~
やったときってレポジトリリストに載ってるところからしかダウンロードしないんでしょうか？
そうじゃないとセキリティ的にやばいですよね？
あと、 winetricksって何？
Wine入れて文字化けするからググったらこれ入れろっていっぱい書いてあったから
入れたけど、
#apt install winetricks
でインストールした後、
$ winetricks allfonts
やったら
https://web.archive.org/web/2000/https://download.microsoft.com/download/E/6/7～
から何かダウンロードするぞ
しかも、
sha256sum mismatch!
Rename /home/ユーザー名/.cache/winetricks/PowerPointViewer/PowerPointViewer.exe and try again.
とか出る。
ウイルス・スパイウェア・ルートキットの類じゃないよね？ WineでJaneXeno動いた人いる？
Ubuntu18.04LTS使用中で文字化けひどいぞ JaneStyleは普通に動いてる
文字化けはフォントじゃないのかなー 内部Unicode化されたDelphi2009を使って開発されたXenoとそれ以前のDelphiを使って開発されたStyleの違いか？（知らんけど >>738
串何使ってる？
JaneXeno＋Fiddler+htmltodat使ってるが、
JaneXenoは起動しても、Fiddler+htmltodatが機能しないので2chスレが読み込めない
スレ一覧は読み込める >>741
Styleは自分でdat取れるから串要らない
wineとStyleだけで動く へぇ、そうなんだ。
Styleっていいよね。
みんな使おうぜ！！ >>744
>山下は銭ゲバすぎる
でもWineで使えるの放置してるからなあ
まあ単に技術の問題だろうけど Jane doeのコード自分の物にしちゃったって本当？ WxWidgeta/C++で新規に作ったXrossBoardってJaneクローンのがあるんだけど、恐ろしく知られてないね
Nativeアプリだから勧めておく API騒動の時にJaneクローンの開発止めて改名して汎用掲示板クライアントになったのがXrossBoard
そして改名直後に開発停止したから5ちゃん未対応だし誰も知らなくて当然 xubuntu18.04でkindle動かす方法教えてください
最新版のkindleを動かそうとするとインストール出来ても起動しない（最悪フリーズ）
入れたのはsynapticから入れた安定版？のやつです >>749
ttps://appdb.winehq.org/objectManager.php?sClass=version&iId=35955 によると、
Kindle 1.6入れてアカウント登録してから、最新版にアップデートすると動く >>750
そこで紹介されてるバイナリ入れて立ち上げてみたんですが
日本語で起動までは行くんですが、ログイン画面が真っ白でログイン出来ないので
もう少し調べてみます
ありがとうござました Wine 3.10 Released
June 11, 2018
The Wine development release 3.10 is now available.
What's new in this release:
- Swapchain support in Direct 3D 12.
- Vulkan support updated to the latest spec.
- Debugger support for Wow64 processes.
- Still more support for the Task Scheduler.
- Various bug fixes. メモ
トラブルがあって新規で.wine構築したけど、
.NETの最適化をするというmscorsvw.exeがなんかおかしなことして？、しばらく使ってると音飛びするようになった
まだソフトを立ち上げてないクリーンな状態（dotnet35・40インスト済み）で
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\clr_optimization_v4.0.30319_32
Startを2から4に変えて、サービス無効化して解決
※最適化（破壊？）が済んでから無効化しても効果なし mp2音声再生するには何入れればいいんでしょ……？ kindleを動かす最もベストな方法はなんでしょうか
今はplayonlinuxを使ってるけどsnapとかflatpakでwine動かす方法が流行りつつあるのでしょうか .Netの2とそれ以降の競合って、
例えば4が要るときは2消して2が要るときは4消してとかすればいいの？ >>760
入らないというか候補にないし、
そも2が消せない……wine uninstallerから確かに消したのに居ることになってる w_workaround_wine_bug-34803
とありますが、ググっても解決法らしきものは見当たらずただ報告ばかりのみ……
あとdotnet20の文字もありますね。wine uninstallerが解決したと感違ってるだけっぽい？
というかwinetricksにアンインストール関係のコマンド無いのが変な感じですね wineはパッケージマネージャーみたいな管理はしてない
入れたらログ吐いてログに競合するのがあったらインストールできなくするだけ なんか
w_do_call remove_mono
とか
Mono does not apper to be installed.
とか言ってるみたいですね
そういえば最近monoとgeckoのインストール画面を見ないような >>764
今winetricks list-installedすると
w_workaround_wine_bug-42170
w_workaround_wine_bug-34803
remove_mono
が所々に乱舞してます
なんでしょねこれ ここまで書いて理解できないならお前には使えないからやめとけ そうしますというかそうせざるを得ない(´・ω・`)
ちなみにwineのクリーンインスコしても.Net4系はどれも入りませんでした…… The Wine development release 3.11 is now available.
What's new in this release (see below for details):
- More debugger support for Wow64 processes.
- Support for sha256/sha384 hashes in ECDSA signatures.
- Better reporting of hyper-threaded CPUs.
- Improvements to the standard Task Dialog.
- Various bug fixes. 器用に出し入れ出来ないから
失敗したら最初からインストールやり直し
徐々にバージョンアップできないから最初から目的の4系入れろやって
前々から話でてたような wine3.11でFinal Fantasy XIの日本語入力できない・・・
ttps://bugs.winehq.org/show_bug.cgi?id=28861のパッチを当てないと起動しないし
パッチを当てると日本語入力が出来なくなる
imm32を上手く修正している方って居ますでしょうか？ wineと2chproxy.pl使ってJaneXenoで5ch見てるけど、
日本語入力が出来ないぞ
どこいじれば日本語入力出来るの？ >>775
Ubuntu18.04LTS、iBusでMozc使ってます。 XMODIFIERS="@im=ibus"
を環境変数に書く $ env | grep -i im
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
になってる。 fcitxで問題ないけどな。
ibusはもう使ってない。 wineで書き込めるようにほかにもやった覚えあるけど、何やったかは忘れたな。 >>774
Ubuntuが16.04LTSでfcitxなだけで後は同じ構成だけど何もせずに普通に日本語入力できてるよ
インライン入力ではないけど .Net周りは直す気ないのかね
ver2とver4.5共存させたいんだが prefix分けりゃいいじゃん
なんか問題あんの？ 4.5入らんのよっていうか4以降
2しか入らん
sidだからか？ >>782
Fcitxに変えたら日本語入力出来たわ
なんでiBusだとだめなんだろうな が、iBusの時もそうだが、書き込むと落ちる
書き込み後エラー吐いて落ちる あと、>>782に聞きたいんだけど、
スレ一覧のスレタイが全部表示されてない状態（スレタイが長すぎて尻切れになってる状態）で
スレタイをマウスオーバーでスレタイポップアップする？
うちのはレス番ポップアップとかはするのだが、スレタイのだけポッップアップしない >>785
sid関係ない
winetricks新し目の探してきて
4.5を入れればいい
2からアップしようとするな >>789
wineクリーンインスコしてgithubからとってきて2入れず4入れようとしてもダメっすよ >>790
~/.wine
捨てて新しく作ってるの？
4.0に対応したwinetricks拾ってきてるの？ Wine使ってていいことってある？
何か凝ったことをしようとするとVMのWindowsを起動せざるを得ない・・・ 4.0に対応したwinetricksか判断できないのでurlさえ貰えれば
~/.wineは消したか~/.wine_にしたような そのくらい探せ
なんで変わりにぐぐらなければいけんのだ Visual Studio 2017はいつwineで動くようになるのか >>788
スレ一覧のポップアップはしない
連鎖を含むレス等のポップアップはしてる
長すぎて読めないスレタイは一度スレタイコピーして書き込み欄に貼って確認してるわ
とりあえずXenoが使えるだけで助かってるわ >>800
やっぱ出来ないよな
俺は、スレタイ長いの確認するのめんどくさいから
スレ一覧見る時は、
お気に入り一覧（Janeのほんの5㎝ぐらい） ｜スレ一覧（Janeのほぼ全画面）
で見て、スレ一覧のスレクリックすると、スレ表示欄自動で開くようにしてる。
で、スレ一覧に戻るときは、マウスジャスチャーで（右クリック押しながら左）でスレ一覧全画面に戻れる。
また、スレ表示欄に戻りたい時は、マウスジェスチャー(右クリック推しながら右）でスレ表示欄全画面に戻れる。
これならポップアップしなくてもスレタイ全部見えて便利だぞ >>796
ターミナルから「winetricks」とだけ入力して実行すれば最新版かどうか教えてくれる。
最新じゃ無い場合は更新しろよ！ってメッセージも出してくれるから言葉通りに
「winetricks --self-update」って実行すれば更新してくれる。 インストール時に時間掛かってる所を
止まったと勘違いして終了してるんじゃね >>804
ターミナルは英語で「無理！」って言ってたので
暇なときに別の酉も試してみようかな ムリってなんだよ、正確にな
トリ関係あるのかよ、ちなみに俺はDebianで4.0問題なく入ってる 3.02をインストールしたら豆腐だらけになった。
フォントの追加でどうにかなった。 The Wine development release 3.12 is now available.
What’s new in this release (see below for details):
- Unicode data updated to Unicode 11.0.0.
- Proxy configuration dialog in the Internet control panel.
- Syntax fixes in the Cmd.exｅ command intepreter.
- Some more glyphs in the Wingdings font.
- Various bug fixes. やっと書き込めた
全部半角でCmd.exｅを書くと、CloudFlareに嫌がられるようだ wineで昔のエロゲーを起動させたいんだが、どうすればいいんだろうか。
ソフトはLast waltz。必殺痴漢人は起動できた。 >>813
あ、スレ間違えてるな。
おまいらすまん...。 取り敢えず.wine名前変えといて新しく32bitで作ったらwinetricks使って必要なランタイム入れる
エラーが出たらdllの名前とかでググってみる wineと2chproxy.pl使ってJaneXenoで5ch見てるけど、
書き込み後にエラー出てしまいます。
同じ環境の人書き込めてる？
俺は、書き込めるけど、書き込んだ後の再読み込みでスレの読み込みが止まるんだよ
そんでフォルダ見てみると～dat、～.idxともに消えてる
再起動後には普通にスレ再読み込みできて書き込みも反映されてるのだが 5chはGCPにrep2鯖建てて、家のラズパイのプロキシ経由でカキコしてる。
LinuxだろうがWindowsだろうがスマホだろうが同じ環境が使えて楽チン。 YAMAHAのアプリでMIDIも再生出来た。
Linuxのフリー音源より音が良い。 Linuxより優れてるものは認めない板だからな
そのくせWineは使う天の邪鬼
めんどくさいね>>820-822 foobar2000とMp3Tag愛用してます
BansheeとEasyTAGは不足
あと紙芝居ゲー Wine 3.13 Released
July 20, 2018
The Wine development release 3.13 is now available.
What's new in this release:
- Vulkan support on macOS using MoltenVK.
- Initial support for performance data in the registry.
- Mono engine updated with some bug fixes.
- Support for fetching BIOS information on Linux.
- GnuTLS also used on macOS when available.
- Improvements in the standard Task Dialog.
- Various bug fixes. >>824
bansheeってまだ開発してる？
俺のディストリだと入らないので
clementineに乗り換えた >>826
もう何年も使ってもチェックもしてないから分からん
bansheeは絞り込み時にandとorが融通が利いて重宝してたんだけど、
結局windowsの昔から育て上げてたfoobar2000の方が色々機能満載で乗り換えきれなかったんだよね
あとbansheeなにげにかなりの量のパッケージのインストール要求してきてたし クローン元？のWinampが開発終了したも同然だからね
ところで、パッケージングの問題なのかバージョンなのか、WinehqでUbuntuのWineパッケージを入れると、東方が動かなくなったんだがどうしたもんかね >>829
どのパッケージ入れたの？
stableか？
develか？
stagingか？ すげえ、ずっと動かなかったth145試したら完全動作した winamp？
bansheeなんてrhythmboxが停滞してた頃の代替品じゃねーの？ >>831
なんなのかわかんねえからググってみたけどわかんねw 1.6から3.0にあげたんだが
今まで動かなかったやつが動くようになって喜んでたら
今まで動いてたやつが動かなくなってて差し引きプラマイゼロかむしろマイナス なんで全部新しく作り直すんだ？
wineprefixあるのに いや、そういう場合はchrootでやったほうがいいかも。 >>830
どれも動かなくなったよ
パッケージングのミスだろこれksが UbuntuのWineは削除しないといろいろめんどくさかったよ
同居させたいならしらんけど
WinehqのUbuntuのページにも削除しろって書いてある
If you have previously installed a Wine package from another repository, please remove it メーラーで長いこと使ってるbeckyが動いただけで満足
ブラウザとの連携も出来てるし他は何にも要らないよ
普通に設定めどいのはVMwareでいいしな 正直インスコしたwinのエロゲがちゃんと動けば満足だが
未だに全てのエロゲが動く訳じゃない 昔のエロゲは動くけど、最近のは認証やらで駄目なの多い…
あと最近の吉里吉里うごかねぇ win10だと動かなくなった古いエロゲがwne だと動く減少が起きてる xubuntu18.04で使ってます
ショートカットをデスクトップに作る方法教えて草祭
windowsのアプリケーションのインストールのやりかたがよく
わからないので、いつもexplorerからCドラに入れて起動してます テキストファイルからでも作れるけど WLCreator (Wine Launcher Creator)使うとGUIで簡単に作れるよ
できたファイルのパーミッションを実行可能にすればいい >>847
ありがとうございます
なんか俺の環境では正常に動きませんね >>846
kde環境使うか
dolphinの右クリックメニューから作成すれば？ The Wine development release 3.14 is now available.
What's new in this release (see below for details):
- Support for DXTn texture decompression.
- Deferral support for MSI install actions.
- Support for Japanese keyboard in DirectInput.
- More improvements in the standard Task Dialog.
- A few more icons in Shell32.
- Various bug fixes. >>850
- Support for Japanese keyboard in DirectInput. んん macOSのWineならすでにできるんだけどね・・・ DirectInputってDirectXの入力APIのことか・・・ ubuntu18.04（wine３．０）でPPSSPPを動かすと物凄くカクつきます
スペックは十分に足りていてゲーム内スピードも100％出てるんですけどメニュー画面からカクカクです
16.04では問題なく動いていたんですけど windows版linux版で分けたら管理がめんどくせーだろ
無駄にPPAも入れたくない
出来るならwineで動かしたいんだよ
あと単純に重くなった理由が知りたいってのもある ではなぜ Linux でもともと使えるものを wine でわざわざ使う理由を述べよ。 nouveauだと動くから原因はnvidiaドライバーだな >>886
素敵な話だ
Wineの進化はこういうゲーマーの力もあるからエミュ厨だからと脊髄反射で否定できない
あとは放置状態のインライン変換だけど、、こういうのは業務システムで使ってる企業の力がいるんだよな
どこか、、、富士通とかやってくれんだろうか・・・ >>886
これが小学生のおっぱいかよ・・・
12歳の乳とは思えんな・・・ Wineの理由
バイナリイメージで欲しい
依存ファイルの確認が面倒(自動で勝手に落としてくる) ttps://cpplover.blogspot.com/2018/08/steam-playwindowsgnulinuxpython-2.html
"邪悪なSteam"で不自由なゲームを楽しんでるようだw もうすぐ>>886だからな？わかってるな？きちんとみんなが納得できるネタ用意しておくんだぞ？ ＿＿＿_
.ｎi 7 ／ ＼ ←壁に向かってしゃべってるバカ
l^l | | ｌ ,/) ／ ＼ .ｎ
', U ! ﾚ' / ／ ＼ l^l.| | /）
/ 〈 | | | U ﾚ'/／)
ヽ＼ ／ ﾉ ／
／´￣￣ノ ＼ｒニ | >>886
これマジで児童のおっぱいじゃない？
にしては結構ふくらみもあるけど。 DVDFab
10.1.xxまでは動くけど、10.2.xxから動かなくなった The Wine development release 3.15 is now available.
What's new in this release (see below for details):
- Support for DPI scaling on Android.
- HID device support in Raw Input.
- Many more new icons in Shell32.
- WinHTTP converted to use Windows Sockets.
- Syntax fixes in the command line interpreter.
- Various bug fixes. 落雷といっても信号設備の故障だったらしいので復旧は早かった。
送電や車両がやられたら5時間は止まってたな。現に数年ほど前にあった。 これが小学生のおっぱいかよ・・・
12歳の乳とは思えんな・・・ dxvkの開発者にsteamのvalveが資金提供してるらしいな フルスクラッチで自社開発するよりよっぽどいいだろうな JaneStyle書き込めなくなってね？
俺だけ？ https://www.phoronix.com/scan.php?page=news_item&;px=Blizzard-Banning-DXVK-Wine
DKVK使うとやっぱりチート認定されちゃうの？🤔 正規のDirectX使ってないんだからBANされても何も言えないが正しい
するかどうかは向こうの判断次第なので Blizzardのゲームはアンチチート強力だからな
報告すれば修正してもらえる可能性はあるが 無駄にチートに対応する手間が増えるだけだから、windows使えやって言われて
終わりだろうな。Linuxならチートツール動くよなんて状況になったらシャレならんし。 wine3.0.2で三國志12PKの体験版を動かしてみた
インストールできて、起動もできたが、ボタンを押すとかなりの頻度でハングアップ
Garbageですわ
なんで13は体験版がないんだろ The Wine development release 3.16 is now available.
What's new in this release (see below for details):
- Initial implementation of OPC Services.
- Support for rendering buttons from an ImageList.
- Better support for CSS properties in MSHTML.
- Namespace fixes in XML Writer.
- Various bug fixes. wineはWindowシステムの種類に影響を受けますか？
例えば、xfceではダメだけど、UbuntuのUnityでは動くとか。 X11のウィンドウへ独自にGUI描画してるから基本的にデスクトップ環境との相性は関係ないと思う なくはない
確か旧型静音PCにdebian stretch入れてLXDEにしてみたんだっけかな
何のアプリか忘れたけど（喉元まで出掛かってる）３回に２回はウィンドウの大きさが０扱いになった
（実際には一定以上小さくならないから例の横に細長い120x30位のウィンドウタイトルだけになった）
おかしいとおもって再インスコでDebian推奨の一番てっぺんの環境にしてみたら普通に動いた
そんなん滅多にないだろうけど皆無ではない 性能に差は出ると思うよ。
LXDEのほうがMATEより速くWineが動く感じはする。ベンチ取ってないけどw linux自体の画面描画にリソースを浪費したくないなら、fvwmとかopenboxだけの軽い環境にするのもありかも？ fvwmか・・・
15年くらい前にしょぼPCにFreeBSD入れて遊んだ時に使ったな。 そうとうしょぼいDE動かすのもやっとなくらいのPCじゃないと差は出ないと思うぞ xfceだと.exeクリックで起動できてたアプリがbodhilinuxだと.exeファイルのクリックから起動しなくなった
端末からだと普通に動くんだがコレも環境要因かね
de以外の環境は一緒 >>910
Z Orderやタイトルバー、透明色、デスクトップアイコン関連が違ってくるかも。 >>918
やっぱそうなのかなあ
他の鳥（ラズパイdesktopとか）だとPCManFMで何の問題も出なくてbodhiだけなんだよね
>>919
.exeはwineで開くように設定してあるよん Ubuntu18.04LTS、WineでJane Style動かしてるのだが、なんでウインドウ最小化出来ないの？
↑ボタンと、□ボタンと×ボタンしかついてないぞ >>924
Xfce入れて使ってるのだが、gnome-tweaks入れればいいの？ >>925
知るかボケ
お前の使ってる環境の質問はスレ違い
他所でやれ >>926
知らないなら知らないで黙ってればいいのに・・・ >>926
XfceだとGnome-tweak動かないわ
で、JaneStyleだとレス1000行ったスレが
「HTTP/1.1 501 Not Implemented」
になって読み込めないでレス1と2し表示されないのだが、これは仕様？
Styleだとdat落ちしてなくても1000行っただけでスレ取得できなくなるの？ >>931
ブラウザだと見えるね
この仕様ひどくね？
さらにdatが壊れたかと思って、再読込したらdatが死んだわ
2chProxy＋JaneXenoに戻ろうかと思うわ そして関係ない話題で荒らした連中は詫びも言わずに出ていくのでした リポジトリから切られたJDなんてもうめんどくさくて使ってられんだろ
仕様変更のたびにいちいちビルドとかアホかと まあJDにはもう未来はないというのは同意
野良の誰かの更新任せなんて他人に勧められたもんじゃない >>940
山下からしてみると>>937とか>>939なんだろうけど
俺らからすると仕様変更のたびにいちいちビルドでもJaneStyleより使い勝手良いし
野良の誰かの方が山下より信頼できるしスキルも上だ Wineだって更新情報見る度にソースからビルドしてるもんな。
昔みたいにビルドひとつで半日とかで無くなったから楽で良い。 snapかflatpakでwineを使ってkindleを動かすことって出来る？ Wine-1.8や2.0からWineHQの3.xに変更しても、
体感的に劇的に速くなるとかいうことはないよね？ よっぽど速くなるならいったん削除してでもWineHQの3.xに乗り換えるんだが。
上の方にIrfanViewが速いとか書き込みあるけど、
長年IrfanViewの起動がとにかく遅くて原因が知りたい。 起動にかんしてはIrfan iewに限らず、最初に起動するソフトはとにかく遅いよ
でもそのあとはどのソフトでも２秒程度で起動する
最初に起動する時、wineはまず先にWindows環境を展開して、それからソフトを起動しはじめるのでえらく時間がかかる
１０秒以上経って忘れた頃に起動する感じ
でも一度起動してしまえば、あとはどのソフトもすぐに起動するようになる
Irfan Viewも２秒くらい、MS Office2007のExcelでも３秒くらいだった
Irfan Viewはとてもサクサク動くし画像表示もとても綺麗でwineと相性がいい感じがする
https://i.imgur.com/y0uXRTh.png よくそんなゴミみたいなインターフェイス使ってられるなど 起動にかんしてはIrfan iewに限らず、多分ターボもNAも変わらないでしょ
個人的にはNAでも十分に速い やっぱりそんなものか。
WinではIrfanViewは軽量で瞬時に起動する印象だったから。
それにlinuxBean(Ubuntu14.04/Wine1.8)では初回起動も割と速く（2秒くらい）、
Kona(Debian8/Wine2.0)ではかなり遅い（3～4秒はかかる）。
linuxBeanは32bitでKonaは64bit（Wineは両方32bit）だから？
でも結局、Linuxで置き換えるほど便利な画像ビューアがないのも事実。 ビューアごときものに利便性など求めなくなった。
windowsユーザーの頃はそうじゃなかったんだけど・・・・・ｗ Linuxの画像ビューア沢山あるじゃん
irfanなんたらの何がいいのかさっぱりわからんがwineで使うほどはないと思う Windowsのicon取り出すときくらいだな。IrfanView使うの 何を使うかは好みの問題でいいけど、
Wineの起動が速くなってくれれば言うことはない。
本当に64bit環境（Wineが32bitでも）だと遅いのかな？ IrfanViewのいいところはビューアだけでなく、画像の編集もできるところなんだよ。
Linuxオンリーではそういったアプリがない。俺の知ってる限り・・・ 画像の一括変換、ファイル名の連番化も同時にできるな。
ImageMagickとかスクリプト書けばできるんだけどさ・・・ 画像の一括変換の為だけにIrfanView入れて使ってるわ Wineインストールしたら、速攻で入れるのがIrfanViewと7-Zipだったりする。
7-ZipはLinuxで解凍すると文字化ける古いzipファイルの対策用。 7-Zipもいいけど、最近は何でもunarで間に合わない？ 自分の場合はgthumb、eog、geeqieあたりを気分で使い分けてる。winのviewerをわざわざwineで使う必要は感じないなあ。
単体で簡単な画像編集機能を備えたものもあるけど、誤って変えたりしたくないのと、大抵gimpを呼び出せるので意図的に編集したいときも困らない。 画像ビューア増えすぎなくらいだから
好みのものあるでしょ >>962
7-Zipのほうが速いと思う。圧縮もできるし。 unarだとマルチボュームのRARが解凍できないと思ってたが、
今試したら普通にできたw
じゃあこっちでもいいか。 >>956
ウチは遅いね
64bitのせいなのかどうかは知らないけど、もうそういうもんだと気にならなくなった
遅いのは最初だけで、一度立ち上げてしまえばあとは普通に早く立ち上がるのでぜんぜん問題ない
MS OfficeやAviutlや一太郎ビューワーがlinuxで使えるというだけで十分満足してる WineHQのパッケージであえてdevelopmentを避けてstableを入れる必要ある？
これまでDebian/Jessieで少しでも新しいbackportsのdevelopmentを使ってたけど、
stableと同様問題はなかった。 あくまで好みの問題だけどね
MS Office2013を入れた時、2.0.2が意外に優秀ですんなりインストール出来たのでそのイメージが強いからかも
いつもstableを選んでしまうわ ありがとう。昨夜、考えた挙句development（wine-3.16）を入れてしまったけど、
今のところ問題はなさそう。Debian/JessieでもうLTSに移行してるので、
使えるものはなるべく新しいのを入れたかったりして。
うちでは既存のwineパッケージと依存パッケージをきれいに削除してから
インストールしようとすると、どうしても依存関係を解決できずエラーになる
（依存するパッケージを自動的に選択してくれない）ので、
backportsのdevelopment（wine-2.0）の上からWneHQのパッケージをインストールした。
ちゃんと既存のパッケージを置き換えてくれる。
で、システムを再起動してから計測してみたけど、IrfanViewの初回起動は8秒くらい。
上で書いた3～4秒は間違いで、これまでも初回はこのくらいかかってた。
以降は1秒以内に起動するので、結局これまで同様、特別良くも悪くもないという感じ。 うちはstableとdevelopment両方入れてる
3.14からeveonlineなどが動かないので
動かないソフトはstable3.0使ってる wine → wine XXX.exe
wine-development → wine-development XXX.exe
実行ファイルが違うだけだけ
インストールもaptで入れただけ Debian公式ではexecutableの実体はwine-developmentになってたけど、
WineHQのexecutableはdevelopmentもwineだったよ。
ただ/opt/wine-develみたいに個別のディレクトリにインストールされる。
Ubuntuとかにインストールすると違うのかな？ Debianでwine-developmentを単体で入れると
wine起動でwine-developmentが起動する
stableとdevelopmentを両方入れると
wine起動でstableが起動する
数年前は違ったんだけど The Wine development release 3.17 is now available.
What's new in this release (see below for details):
- Improved Shell Autocomplete support.
- More implementation of OPC Services.
- Improvements to the Pager common control.
- Various bug fixes. Ubuntu14.04(32bit)ベースの方も1.8からWineHQの3.17にしてみたけど、
やっぱり少なくとも速くなったという感じはないな。
ただ、非力な退役寸前のネットブックなのに、
IrfanViewは数段高速なPCのDebian(64bit)の半分の時間で起動する。
やはり64bitの環境で32bitのWineが遅いんだと思う。 今のWineってわざわざwinetricksでallfontsインストールしたり、
winecfgのDesktop Integrationでフォント変更したりしなくても割と平気なんだね。
間違ってcjkfontsとかインストールすると、
かえって著しく表示品質が損なわれる。 wine専用でフォントの個別設定ができたら良いのにって思う
せめてXFTのアンチエイリアスon/offくらい手軽に変更させてくれたらな >>983
regeditでアプリケーションごとにレジストリ弄れるから、出来るんじゃないかなー。
やったことないけど。 時間を費やして、ようやくゲーム内のMPEG動画が再生できる様になったのでメモ
1. LAV Filtersをインストール
https://github.com/Nevcairiel/LAVFilters/releases
2. winetricksでquartzをインストール
1.で映像"だけ"は再生される様になり、2.で音声も再生される様になった
以下は何も効果が無かった（ゲーム毎の再生方法の違いによって行ける場合もあるのかも）
・gstreamer1.0-plugins-ugly:i386パッケージのインストール
・winetricksでのffdshow, wmp9, wmp10, amstream, dirac, devenum, quartz…
…単体、組み合わせ、winegstreamerの有効/無効も交えて色々と試したが駄目だった Wine3.xにして起動が速くなったりはしなかったけど、
（うちの環境では）何だか他のアプリも安定して軽くなったような気がする。
でもきっとたまたま気のせいだろうな。
ただインストールをやり直したので安定したとか。 eTaxってIEが使えないなら動かないんじゃなかった？
Windows上でもまともに使えないのにLinuxに動作求めるのはもっと難しいよ webで入力してpdf印刷して郵送したらいいじゃない。 全国民があんなクソ仕様な e-TaxとeLTAXを使うのをやめれば、
日本は良くなる！
あんなクソなシステムはたったと無くしてほしい。 The Wine development release 3.18 is now available.
What's new in this release (see below for details):
- Subpixel font rendering with FreeType >= 2.8.1.
- Support for OAEP algorithm in RSA encryption.
- Array marshalling fixes in DCOM.
- Improved DPI scaling in the Wine console.
- Various bug fixes. GStreamerが上手く機能しない環境下でゲーム内のMPEG/WMV動画を再生する為のメモ
1. K-Lite Codec Pack - Basicをインストール（K-Liteを使う様にした理由は下記）
https://codecguide.com/download_kl.htm
2. winetricksでquartzをインストール
3. winecfgでwinegstreamerを無効にする（GStreamerが割り込んでデコードの邪魔をするのを防止）
4. 付属のCodec Tweak ToolでDirectVobSubを無効にする（再生開始までに20秒以上固まる場合の原因）
…Program Files/Program Files (x86)下、\K-Lite Codec Pack\Tools\CodecTweakTool.exe
…Codec and Filter Management → DirectShow (x**) → DirectVobSubにチェック
・K-Liteを使う理由
LAV Filtersだとwmaのデコードが標準でオフになっており、これをオンにしないとWMVを再生できないが
WineのバグなのかLAV Filtersの設定ウィンドウでの変更が保存されず、wmaのデコードをオンにできない
その点、K-Liteはwmaのデコードを標準でオンにしてLAV Filtersをインストールしてくれる
また、64ビットのWINEPREFIXだとLAV Filtersはインストールに失敗するが、K-Liteは正常に完了する
・クリーンなWINEPREFIXでの作業を推奨
・既にLAV Filtersをインストールしている場合は事前にアンインストールしておく
・K-Liteインストール時に表示される英文ダイアログボックスは全てEscキーでOK Wine HQのUpdateでいつのまにかmozcでの入力がWindowsのソフトでできなくなった。
Linux がわのソフトではmozcは機能し問題なし。
Debian 9での環境。わかる凄腕の人よろしく。 fcitx ibus uim scim全部試したの？ 995 です。fcitx とmozcの環境で、ibus mozcはうまく機能しないとweb情報にあったので
fcitx以外は入れていません。 まずは動くバージョンまで下げてみなよ
それでだめなら他に原因がある fcitxとibusはトラブル多いのに
なぜかみんな使おうとする謎 fcitxで問題ないと思うけどな。
UbuntuとDebianはこれでWineの日本語入力はできる。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 432日 21時間 43分 20秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
