今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
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のテンプレ使用を推奨。 >>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になってそう ■ このスレッドは過去ログ倉庫に格納されています
