2018/08/16

Edgeの「新しいウインドウで開く」で最大化される条件

Edgeを使っていて気になるのだが、時々「新しいウインドウで開く」を選択すると、あるいはShiftを押しながらリンクを選択すると、次のウインドウが勝手に最大化されて表示されることがある。常にそうだということではなく、時々そうなるように思われる。

どういう条件で最大化されて表示されるのか、調べてみた。

もともと最大化されていない状態で、「新しいウインドウで開く」を選択する。


この場合は最大化されずに表示される。


だがよく見ると、手前にある新しいウインドウは、奥にある元のウインドウより少し大きい。

色々やってみた結果、この少し大きくなる分の領域が確保できなくなると、要はウインドウが画面からはみ出すようになると、新しいウインドウが最大化表示になるらしい。

だから、ウインドウを縦に伸ばした状態で、「新しいウインドウで開く」を選択してみる。


すると、次のウインドウは最大化されて表示される。


2つのウインドウを重ねてみる。


幅は全く変わっていないが、高さは明らかに大きくなっている。

「新しいウインドウで開く」を続けてみるとこうなる。


だんだん大きくなってくる。

ウインドウサイズの上限は、タスクバーを除いたデスクトップ領域のサイズである。試しに、タスクバーを高くした状態でやってみる。


下半分が真っ黒だが、画像が切れているのではない。この状態で「新しいウインドウで開く」をやると、最大化される。


では、幅の方向はどうだろうか。新しいウインドウは、元のウインドウと同じ幅で表示される。ならば幅方向の不足による最大化は発生し得ないのか? ということで、ぎりぎりまで幅を広げた状態でやってみた。


すると、最大化されて表示された。


どうも、幅方向にはある程度の余裕がないと最大化されてしまうらしい。だから、多少(10数ピクセル程度?)の余裕があれば最大化されない。


それと、新しく表示されたウインドウは元のウインドウと同じ幅であるため、一度最大化されないで表示されたのであれば、(ウインドウサイズを変えない限り)それ以降は幅の不足による最大化は発生しないようだ。


2018/08/11

IntalのNUCを買ってみた

今使っているPC、Core i7-5930Kのマシンは、起動しているだけでディスプレイ込みで常時130W程度消費している。高い。電気代が高すぎる。


ということで、こんなものを買ってみた。



電気代よりもこれを買う金の方が高いだろうということは決して口に出してはならない。

CPUはCeleron J4005で2コアしかない。

外箱



開けてみた。



SSDを入れてみた。



SSDを入れるベイは裏蓋の内側についている。必然的に電源とSATAケーブルが蓋に接続されることになるから、開けるのにちょっと手間取る。

あと、入れるところはネジ等で固定するようになっていない。筐体に一部が内側にめり込んでいてバネ仕掛けで支えるようになっているだけだ。だから、上の写真のように厚さが薄いものを入れると、ふたを閉めた後もなんかカタカタ音がする。

それと、ここで使っているSSDはmSATAのものである。それを2.5インチのSATAディスク形状に変える奴を使って装着している。

上記の通り、はじめは薄い変換アダプタを使用していたが、落ち着きがないので、最終的にはこれを使っている。



蓋を開けた本体の方。




メモリはこれである。



タイトルでは「RAMMAX RM-SD2400-4GB DDR4 ノートPC用メモリ PC4-19200(DDR4-2400) 4GBx1枚 260pin 」と書いてあるのに、amazonの画像は思いっきりDDR3 1600となっている。どっちだよ、という気もするが、値段がそれっぽいことから思いきって注文してみた。

結局、こんなんが来た。



DDR4-2400だった。よかった。

多分、4GB DDR4メモリの最安値のレベルだ。


あと、動かしてみた感じでは、やはりシングルスレッド性能が結構高い分、動作の遅さを感じることはあまりない。また騒音は、アイドル中には相当耳を近くまで近づけてやってファンの回転音が聞き取れるかどうかといったレベルで非常に静かだ。

Prime95を実行中には多少ファンの音も聞こえるようになるものの、よほど顔の近くにでも置かない限り、気にするほどではないと思う。


あと、アイドル中の消費電力量は大体5wから6w程度だ。



Prime95の実行中だともうちょっと増えて、15Wから16w程度は消費する。



ベンチマークについては多数公開されているから検索した方が多分早い。

2018/07/28

I-O DATAの製品は買ってはならない。何があってもだ。

経緯は後で気が向いたら書く。自宅で使うブロードバンドルータとしてIODATAのWN-AX1167GR2を買ってみた。だが、あまりにもひどい。即日でゴミ箱行き確定である。

金を返せ。

何がひどいって、IPv6パススルー接続では、IPv6 SPIなる機能は使えないのである。このページを見る限り使えるようなことが書いてあるにもかかわらずだ。

http://www.iodata.jp/lib/manual/wn-ax1167gr2/index.html#p5_6

DoS/IPv6 SPIの項目に、申し訳程度に「※ IPv6インターネット接続時に表示されます」とあるが、これはどうやら、「IPv6インターネット接続時」に有効になるのではないらしい。自分で書いておいて何を言っているのか理解できないのだが、事実なのだから仕方がない。実際には、IPv6プラスなどを選んだ場合にのみ使えるもののようだ。

IPv6でインターネットへ接続できるようにしたときに使用できないものに対して、「※ IPv6インターネット接続時に表示されます」という但し書きを書く奴の精神構造はいったいどうなっているのか? いや、精神が破綻しているとかそういうことではないだろう。多分、わざとそうしているのだろう。

当たり前だが、何の工夫もなくIPoEで接続すれば、PCはインターネットに剥き出しとなり、いかなる保護も保証も得られない状態となる。フルチンで警察署の前を走り回るのと同じだ。

ついでに言うと、これはWAN側からLAN側にIPv6で接続できてしまうのかどうか確認してしてみたから気づいたものの、わざわざそんな確認をしなければ、それこそ変質者や性犯罪者に股間をまさぐられるまで自分が裸族であったことに気が付かないということになる。もっと言えば、IPv6パススルーはデフォルトで有効になっている。何もしなければ標準でぽんぽんすー

こういう構成で試してみた。




実写だとわかりにくいから漫画にしてみる。




もはや悪意をもって作っているとしか言えない。というか、悪意の塊だと言っていい。意図的に間違ったことを書き、客に買わせて金を吸い取り、かつ、何らかの情報を収集して中国だか北朝鮮だか知らないが、どこかの怪しい国に売り払うことを目的にやっているのに相違ない。そうとしか解釈の余地がない。

だってそうだろう? セキュリティ守りマス的な事を書いておいて、実はザルどころかマッパなのだから、どんなに好意的に解釈したって、遊ぶ金欲しさに客を売っているとしか解釈しようがない。

間違いなくこれは、というかこの会社の全製品は、絶対に買ってはならない。反社会的勢力に金を渡すことは、それ自体が犯罪だから。

2018/07/16

AVアンプを捨てた

暑い



マシンよりも人間の方が先にだめになる。

ところでこいつ、とりあえずこの状況でも、コア温度が50度そこそこだから、ファンレスでも結構頑張って放熱してくれているらしい。





ところで、買ったものの記録を残すのを忘れていたから、暇つぶしに書いておく。


(1)まず、AVアンプを捨てた。YAMAHA AX1400が常時50Wくらい電気を喰っていたから、やめることにした。その代わりに、以下の組み合わせで代用することにした。

a.光デジタルオーディオの切り替え機




b.光デジタルオーディオを音声に変えるDAC



c.学習リモコン



結局、AVアンプを何に使っているかといえば、リモコンで入力ソースを切り替えることと、光デジタルオーディオを音声に変換してヘッドホンに出力することだけだ。そう割り切れば、これで用を足すことができるはず。

ポイントは、リモコンで操作できることだ。

あと、消費電力量だが、稼働中でも0.6W程度、元のAVアンプと比較して約100分の1だ。素晴らしい。





(2)色々思うところがあって、HDMIの映像をキャプチャしたくて、こんなん買ってみた。

a.HDMIスプリッター



タテマエとしての機能は、HDMI信号を2つに分離するというものだ。だが、表立って記載されていない機能として、HDCPを解除することが可能だという物がある。

出力するHDMI信号のHDCPを解除できない機器でも、こいつを通してやると、HDCPが解除できるという便利な一品だ。


b.HDMIキャプチャ



PCがなくても、USBメモリにHDMIの信号を動画として保存できるという機械だ。

PCにつながなくても使えるのだから、当然PCに余計なソフトを入れなくてもいいということだ。リアルタイムに配信したいのではない人間にとっては、きわめて好都合な代物だ。


これを使って、今となってはだいぶ古くなったSONYのBDZ-T90で再生した映像をきっちり取り込むことができた。

ついでに言うと、HDMIスプリッターは、稼働中は結構温度が上がる。普段から刺しっぱなしにしておこうかとも思ったが、熱で壊れるという噂もあるようだし、やめておいた方がいいようだ。

使う時だけ接続する。これが正解のようだ。




(3)今は、OPNSenseをベアメタルで入れて動かしているPCだが、こいつの能力の有効活用を図るために、Windows 10を入れたいと考えている。

ということで、PCの補強パーツとして以下を購入した。

a.mSATAのSSD(120GB)



選定理由は安かったから。

色々と日本語は怪しいが、機能には問題ない。性能はそれほど気にしていない。SSDだし。というか、もとよりCPUがCeleron J1900だ。SSDの性能が問題になることは無かろう。


b.USB Audioのアンプ


こいつはどうも工業用というか、産業用を想定しているらしく、音声の出力がない。当然、光デジタルオーディオの出力もない。それだと、最終的には俺の頭の上に乗っているヘッドホンに出力してやらねばならないのだが、それができない。ということで、USB接続のオーディオ出力を行う機械を買ってやった。

これも見た目が怪しい雰囲気を感じるが、機能・性能に問題はなかった。とりあえずPCに繋いだら、何も考えなくても認識されて、何も考えなくても光デジタルオーディオで出力できた。当然、アナログでも再生できる。

しいて言うと、SONYのMDR-1RNCを直接接続すると、結構音が大きい。かなり絞ってやる必要がある。

2018/07/07

Kettop MI19W-S1をもうちょっとばらしてみた

これ



今はOPNSenseを入れて使っているが、もうちょっと有効活用しようということで改造を予定している。

その前に少し調べてみた。

まず気になるところで、CPUのヒートシンクは筐体に接しているのか、ちゃんと放熱されているのかどうか。



どうやら筐体に接しており、ちゃんと筐体表面から放熱する仕様になっているらしい。



手前にLANポートが2つ見えており、その奥にヒートシンクがある。画面下部に波打っているのが筐体の上面で、おそらく熱伝導シートだと思うが、何かを挟んで接していることがわかる。

梅雨も明けて室温も常時30度越えの状態になったわけだが、その状態でアイドル中のCPUの温度を確認すると、概ね50度を超えている。中々にして熱いわけだが、その分筐体の温度も高い。



※絵を張っているが、これをキャプチャしたときの室温は24度だった。

証拠がなくて申し訳ないが、USB扇風機で筐体外部から風を送ってやると、50度程度の状態から40度程度まではCPUの温度が下がることから見ても、これ見よがしに波打った筐体のデザインはただのこけおどしという程度以上の効果はあるようだ。



それと、使用しているメモリはなんだかよく分からないが、おそらくDDR3Lの奴だ。メモリのソケットにはDDR3とあるが多分違う気がする。



メモリを交換する際には注意した方がいい。

2018/05/05

ワットメーターを買ってみた

電気代は罪である。そんなものを払うのは人倫にもとる悪逆非道の行いである。

だから少しでも電気代をケチるべく、ワットメータを買って調べてみた。

買ったのはこれ。



節電対策といえばこれだろうという定番品だ。

いくつか調べてみた。

項番項目消費電力(使用中)消費電力(停止中)
1PC60w(アイドル中)2w
2ディスプレイ60w0w
3テレビ(Pioneer KRP-500A)200w30w
4Blu-rayディスクレコーダー(SONY BDZ-T90)30w30w
5AVアンプ(YAMAHA DSP-AX1400)50w0w
6ルータ5w-
7Raspberry pi 35w-
8フレッツ光用のモデム4w-
9Surface RT15w10w

PCとディスプレイの消費電力が大きいのは承知しているが、これについては当面はどうしようもない。

許せないのはこいつらだ。

・AVアンプ
・テレビ
・Surface RT

テレビの待機電力が30wとはどういうことだ。買ったのが10年前だから、1KWh当たり25円換算で10年×365日×24時間×30w×25円/1000で65,700円も使っていることになる。待機電力だけでだ。

AVアンプは待機電力は微々たるものだが、使用中の消費電力量が大きい。だが、現状ではヘッドフォンしかつないでいないのだから、もっと賢いやり方がある気がしてならない。いい加減古いし、リプレースするべきか。

でもって、最悪に許せないのがSurface RTの端末だ。全く役に立たないゴミであることを承知の上で買って、下馬評通りクソの役にも立たず、電源だけつないだ状態で転がしてあったのだが、スリープしている状態であるにもかかわらず常時10wも喰っていやがる。

Core i7-5930KのデスクトップのPCでも、スリープ中の消費電力量は6w程度だった。なのにだ、このゴミクズ野郎は何もしないで、何らの有効成分もないくせに、月額で180円、年額で2,160円もドブに捨てていたのだ。まさに極悪非道、鬼畜生の行い、言語道断許すまじ。

叩き割って捨てるしかない。

2018/03/21

共有メモリにInterlocked.Increment

共有メモリとして確保した領域に対して、Interlocked.Incrementで値を加算したい。

まず、共有メモリに対する値の読み書きは、MemoryMappedViewAccessorクラスMemoryMappedViewStreamクラスを用いてアトミックでないアクセスを行うか、全て自己責任で生のアドレスを使ってどうにかするしか方法は無い。

無論、アトミックでない方法を用いることはできない。

open System.Threading
open System.IO.MemoryMappedFiles

[<EntryPoint>]
let main args =
    // 共有メモリ
    let mmapFile : MemoryMappedFile =
        MemoryMappedFile.CreateOrOpen( "abc", 4L )
    let acc =
        mmapFile.CreateViewAccessor()
    
    // 値を取得して
    let mutable v = acc.ReadInt32( 0L )

    // アトミックに加算する!
    Interlocked.Increment( &v ) |> ignore
    
    // 書き込む
    acc.Write( 0L, v )

    0

ジョークにもならない。

だが、Interlocked.Incrementが取る引数はbyrefのintである。C#ならば「public static int Increment( ref int location )」、F#ならば「static member Increment : location:int byref -> int」だ。通常、共有メモリ上の領域を直接Interlocked.Incrementの引数として与える方法がない。

ならば、Win32APIにあるInterlockedIncrement関数を使えばよいではないか。環境依存ではないかという良心の呵責も聞こえてくるが、もとより.NETだと思えばもはやどうでもよろしい。

open System.Runtime.InteropServices
open Microsoft.FSharp.NativeInterop
open System.Threading
open System.IO.MemoryMappedFiles

[<DllImport("Kernel32")>] extern int32 InterlockedIncrement( nativeint p );

[<EntryPoint>]
let main args =
    // 共有メモリ
    let mmapFile : MemoryMappedFile =
        MemoryMappedFile.CreateOrOpen( "abc", 4L )
    let handle =
        mmapFile.CreateViewAccessor().SafeMemoryMappedViewHandle

    // 共有メモリ領域のアドレスを取得する
    let mutable p : nativeptr<byte> =
        NativePtr.ofNativeInt( nativeint 0 )
    handle.AcquirePointer( &p )

    // アドレスを指定して、アトミックに加算する
    InterlockedIncrement( NativePtr.toNativeInt p ) |> ignore

    handle.ReleasePointer()

    0

このコードは、一応想定通りに動作する。はずだ。InterlockedIncrementで加算している個所を複数のプロセスやスレッドでゴリゴリ実行しても、おかしなことにはならないはずだ。

だが環境依存ということを除いても致命的な欠陥がある。

32bitのコードでしか動作しないのだ。

64bit版でビルドすると、Kernel32.dllにInterlockedIncrementというエントリがない、と言って怒られる。



どういうことなのか、アンマネージドなC++のコードで試してみる。



こんなものをビルドしてアセンブラを確認してみると、



直接マシン語命令に展開されている匂いがする。

というか、こんなページもあった。

https://msdn.microsoft.com/ja-jp/library/2ddez55b.aspx

結局、32bit版では(互換性のためか?)Kernel32.dllにInterlockedIncrement関数(本物の関数だ)が用意されているが、今では呼び出し元に直接マシン語コードを生成するようになっているから、64bit版ではそんなものは提供されないのではないか。

となると、P/Invokeで逃げるという手段も塞がれる。.NETでは、共有メモリを使ってプロセス間でInterlockedIncrementはできないのだろうか。


そう思っていたら、なんとも都合の良いことに、Visual Studio 2017がこの間アップデートされて15.6が公開されたのだが、その中にこんな記述を見つけた

「NativePtr.ByRef のサポートの追加」

リンク先を辿っていくと、IntPtrの値を Interlocked.CompareExchangeに渡したいとか何とか、書いてあるように見える。

ということで、やってみた。

open Microsoft.FSharp.NativeInterop
open System.Threading
open System.IO.MemoryMappedFiles

[<EntryPoint>]
let main args =
    // 共有メモリ
    let mmapFile : MemoryMappedFile =
        MemoryMappedFile.CreateOrOpen( "abc", 4L );
    let handle =
        mmapFile.CreateViewAccessor().SafeMemoryMappedViewHandle

    // 共有メモリ領域のアドレスを取得する
    let mutable p : nativeptr<byte> =
        NativePtr.ofNativeInt( nativeint 0 )
    handle.AcquirePointer( &p )

    // 型を変える
    let pint : nativeptr<int> = NativePtr.ofNativeInt( NativePtr.toNativeInt( p ) )

    // アドレスを指定して、アトミックに加算する
    Interlocked.Increment( NativePtr.toByRef pint )

    handle.ReleasePointer()

    0


ここで、プロジェクトの設定を変えて、ターゲットF#ランタイムをFSharp.Core 4.4.3.0に変えてやらなければならない。



そうすると、NativePtr.toByRefが使えるようになる。

どうもこいつは、「nativeptr<'T> -> byref<'T>」なる関数の様で、Interlocked.Incrementの引数がbyref intであるため、指定するアドレスとしてはnativeptrでなければならない。なので、著しく見苦しいが事前に共有メモリ領域のアドレスとして取得したnativeptrの値をnativeptrにキャストしている。

恐ろしくばっちいが、コンパイラを騙しているだけで実行時に負荷にはならないと思えば、まぁいいか。とりあえず、これで32bit版でも64bit版でも動作するし、P/Invokeにも頼らずに、目的を達することができるようになった。