堕天使の煉獄

相変わらず体調が微妙～

後鼻漏に花粉症？　単なる風邪？　が重なるとシンドイです。
延々と粘度ました鼻水を飲み続けることになるので。

もともと普通の人でも一日１リットル～の量を飲んでるらしいですが、本来前から出る分も後ろに出てるのと、慢性鼻炎なんかも絡んでいるので普通の人よりもやはり多くなるんでしょうね。

降り積もる雪のように、少しずつ胸のあたりがもやもや～っと。不快感が積もっていくんですよね。
んで、だんだんと胸やけに似た感じになって、気分悪くなってきて何にも手に付かなく……。
しばらく横になると楽になるんですけどね。なので寝起きはなんか元気だったりして。

んで、鼻水の量に影響するので、風邪も影響してる見たい。
昨日は某氏んところの同人イベント用のカットとか用意してたのですが、作業終わったあたりで不快感ＭＡＸな感じで。もう今日は寝ちゃおうって感じになったのですが、朝方あたりにお布団毛布二枚重ねでもブルブル震えるぐらい寒くなって、その後いきなり急に暑くなってきて汗ドバドバ噴き出してきたりで、あれ？　風邪で熱とかあったのかな。な感じだったりして。

そんな感じでいまいち調子がでなくて、全然やりたいことができてなーい。

まあ、数年前の、風邪でダウン→体力低下の抵抗力低下の所為？　で蓄膿→熱４０度ぐらいで、蓄膿の所為で膿混じりのものすごく粘度の高い鼻水が鼻と喉の間に居座って、寝ると喉の方に降りてきて、「ぼうぇっっ！！」と嘔吐く。すると少しだけ鼻方向に戻る。しばらくするとまた喉の方に垂れてきてまだ嘔吐く。という地獄の苦しみ……。粘度が高すぎて喉の方には落ちてこない
のでそれがエンドレス。

あの苦しみに比べればまあ全然ましなんですけどね。一月ぐらい寝込んでたし。

でもこの地味～に不快感が継続しつづけるのもシンドイわ……。

んでもいつまでも何もしないままってわけにもいかないので。
とりあえず騙し騙し、しんどくなったら横になるの繰り返しでやっていくしかないかな……。
集中してるときはまあなんとか大丈夫だったりするので。ただ作業の切れ目とか区切りのタイミングで一気にダウナーになっちゃう感じぽ。


まあ体調不良とか暗い話ばっかもアレなので。

上記の某氏んとこの同人イベント用のカット用意するときに、「既存絵からの流用でもええんやで」とは言われていたのだけども、個人的に２０１９年の目標は「妥協しない」を掲げていきたいと思っているので、新規で描くと決めてたのですが。現実的に〆切りという物があるので、保険としていくつか候補の目星はつけとくかなとおもって、ＨＤＤあさってたらば。



こんなクド目の塗りとか模索してた時期もあったんだなぁ。とかおもたり。

最近は、線画の処理から塗りから、根本的にいろいろと見直したいなとおもってたりするんですが。結局の所トライアンドエラーで枚数重ねて試行錯誤する意外に道はないと判ってはいるものの。結局どっちの方向に走り出したらいいのか判らない状態で足踏みしているわけで。

なにげに今回のカットは、一応新規でちゃんと描けたんですけど、普通に去年の冬コミ原稿以来の作画なんだよなぁと。
一月以上描いてない。てかその冬コミ原稿も、その前に絵描いたのは多分夏コミ原稿だったりするので、そりゃ画力は向上するわけもなく低下する一方だわなと。
色塗り作業の時に聞くことにしている深夜の馬鹿力なのですが。
今回の作業開始時に、既聴分はいつのだったっけかなーと見てみると……

伊集院光 深夜の馬鹿力 2017年03月06日 第1116回

……二年前だよオイ。
もう２年分も未聴分溜まってるのかよ……。
昔は大体数ヶ月分溜まってて、コミケ作業中にストック尽きて、昔の回を聞き直したりって感じだったのだけども。
確か今年の冬コミあたりはなんか耳が炎症とかなんかになって、お薬塗ってたりしてて、ヘッドフォンつけれなくて。
アマゾンで安かったのでポチッたＵＳＢ電源のミニスピーカーだと、小さい音量で音楽流す分には良いけど、ラジオの音声は聞き取れる音量にすると音がでかすぎて深夜とかには使えないかんじで。それで諦めて冬は馬鹿力聴けてなかった気がする。
にしても２年分もたまってるのかよ。と思うとちょっとやばいなと。
それだけ色塗り作業してないってことだもんな。

絵、描かないとな……。

なんて思ってるときにこんな感じの慢性的な体調不良だったりして。ままならぬぅ。

あと、田中久仁彦氏のラフ画集到着。
でもまだ梱包といただけで、まだ中を見ていなかったりする。
氏のラフ画集みて、自分も頑張ろうっとおもってたのだけども。
ダウナー状態だとそれもままならぬぅ。

とりあえず、少しづつでも絵を描かないとなぁ。
どんどん鈍っていくばかりだし。

ＰＧの方も、いまやりかけてる分は、ぺぺいとやっつけてしまいたい所なんですけど。

己の性器を引きちぎったら機械の身体をあげるよと言ったら、やるかもしれん（ぉ
まあそうなったらそうなったで、何にもやらなくなるんだろうけどさ。
抑圧こそがモチベーションを生み出すという考えからするとね。
体調不良の今だからこそ、アレやりたいコレが出来たはずなのにと言い出すけど、体調不良じゃなかったときにそれがやれてたのかというとねぇ、って話ですよ。

ああ、ままならねぇ。

トルクが全く無いんですかねこのエンジン。
ちゃんと走ってるときは割とガンガン進むんですが、一旦何かにぶつかって低速になるとエンストして。その後ちっともエンジンが掛かりやしない。

そんな感じの今週一週間。

風邪かな？　と大事を取って寝るを数日繰り返してたら、もう大丈夫っぽい？　って感じになってから全く何も手に付かなくなっちゃったりで。一度立ち止まると駄目だな……。

未来少年コナン全話見たりとか、アニメのからくりサーカス、しょうがないのかもしれないけど端折りすぎだよなーからの懐かしさから原作全43巻一気読みとかやり出したりして。なにやってんのって感じに我に返ったのが昨日あたり（ぉ

なにげにコナンって、ギガント乗り込むシーンあたりだけは何度も見たことあるんですが、一話からちゃんと見たことなかったりして。
小さい頃に夏休みスペシャルみたいな感じで再放送やってるようなときも、気づいたときにはこのギガントのシーンあたりの回で、最初から見る機会に出会えなかったんですよね。
うーん。色んなその後の宮崎作品の原型が散らばってる感じで、もっと早くに見るべきだったなとおもたり。


あといろいろ小ネタ。

なにかのゲーム画面かなにかのサムネで、３Ｄモデルの部屋があって。なんかレンダリングの感じがVidroっぽいなーとか思ったときに、そいや最近新しいｖｅｒとかチェックしてなかったなと見にいったらば。

Vidro
ttps://ja.wikipedia.org/wiki/Vidro

2010年7月、開発者の徳吉雄介はスクウェア・エニックスへと転職し[3]、vidroの開発は第100630版(2010年6月30日)で終了した。

開発終了してたのか。そしてスクエニに就職されてたのか開発者の方。
んで、手元にあるvidroのｖｅｒ確認したら100630版でしたｗ
普通に最新版まではちゃんと取得してたんやね。
ちょっとググればまだ普通にＤＬできるところもあったので、手に入らない～ってわけでもなさそうっぽい。現時点では。
でも一応最終版はバックアップしておこうかなとおもたり。
フリーのレンダラでは使いやすいし綺麗なので。あとメタセコと親和性高いので。

んでももう１０年近く前の話なのか……ここ最近３Ｄ関係さわってないものなぁ。

次～

更新が途絶えていた「FFFTP」の開発に後継者、v3.0が“GitHub”で公開される
ttps://forest.watch.impress.co.jp/docs/news/1115458.html

ぼちぼち最近の話ですが。
FFFTPの開発引き継ぎ版が出てすぐぐらいまでは私も使ってたのソフトだったのだけども。なんか妙に動作が重くなってストレス溜まる感じになっちゃったので以降はFileZillaを使ってたりする。

　今回開発を受け継いだKURATA Sayuri氏は、“艦これ”専用ブラウザー「艦これ 司令部室」の開発などで知られている。

このKURATA Sayuri氏って、結構ｃ++界隈のフォーラムとか掲示板とかでＫａｎｏｎのさゆりんのアイコンでよく見かけるひといるなぁって思ってたのですが、ずばりその人だったのでちょっと「おおっあの人か」って思っただけの話ですｗ

てかまあ、今年でＫａｎｏｎ２０周年だったりするんですが。
今時の若い人にはもうＫａｎｏｎとか知らんだろうな～とか思ったりしてたところで何となくタイムリーなネタだったので。

んで、なんでこの「FFFTP」の開発に後継者の記事にたどり着いたかと言えば、ちょっと前にOpenSSL関係でちょっと調べてたときに、この記事のなかの

「OpenSSL」や「JRE32.DLL」といった外部ライブラリへの依存が削除され、Windowsに付属するライブラリを利用するようになっている。

って部分で「おや？」と思ってぐーぐるの検索結果から記事を開いたところだったりする。
OpenSSL使わない方向でhttps対応とかできる他の方法が？　と気になったもので。
んまあその後いろいろ調べを進めてみたところ

素直になれない人のwindows SSL
ttp://d.hatena.ne.jp/rti7743/20130216/1360968993

windowsのcrypt32 secure32とかの使い方が複雑すぎて人間が理解できないぐらいになっているのです。

記事のコメント欄に

Win32 APIにSSL機能があるのでWindowsプログラミングでOpenSSLは本来不要。だが誰も使いこなせないので結局OpenSSL、という話。サンプルソースを読むと（主に行数で）なるほど使いこなせないと理解できる

うん。素直にOpenSSL使った方がいいねっ！
ほんと7zipの中のMS謹製のvariant型みたいなのもそうだったけど、ＭＳさんのライブラリの仕様とか変数名のセンスとか古い以前にいろいろひどくて読む気にすらならないもの大杉ぃ。
「だが誰も使いこなせないので」のくだりでワロタｗ

ＱＴ使う場合はちゃんとそっちでOpenSSL対応してくれてるので、あえて他の方法を使うメリットはなさそうぽ。

んまあ外部ライブラリへの依存関係を減らしたいのは山々なんですけどね……。

そんな感じで、ようやく再起動中。

悪寒です。おかん（母親）ではないですｗ

なんでこうやる気になった途端にこうなるのか。いや急にローギアからトップギアに入れる感じにやる気になったから、体力低下してこうなったのか。
そいや先日は妙に暖かかったんですが、その翌日に朝方雨とか天気悪くなったらまた一気に冷え込んだので、その急な寒暖の所為かな……。

なんか風邪の初期症状っぽい悪寒が。
一旦布団入っても、ガタガタブルブル。まずい……。

ってことで昨日はさっさと寝ることにしたので、作業は殆ど捗らず。

とりあえずやったのは、書庫ファイル名受け取ったら、7z.dll使用と自前処理用(zip専用)に切り分けるためのインターフェース作って、7z.dll利用版と自前処理の関数をオーバライド出来る様に7z.dll利用版の方のクラスを整えたりしたぐらい。
あとは以前組んだｚｉｐ関係のコード眺めて、「うわぁ」となったり（ぉ
数年ぐらい前に組んだってのと、zipのフォーマット調べながら作ったので、微に入り細を穿つ感じで、これ使わんだろ？　っていうフィールドまできっちりなんか処理してたりして。

その辺、今回はばっさりと必要な部分だけ取捨選択したら、処理もスマートかつ読み込み速度も稼げるようになるんじゃないかなと。

でついさっき起きて、とりあえず熱っぽくも無いようだし悪寒も収まった感じで。頭はぼーっとするのは寝過ぎかな。途中でちょいちょい目が覚めて、あ、携帯メールきてるーとかごそごそ起き出して、また寝たりと。あれは夢かな？　といま見たらちゃんとメール返信してるみたいなので、現実だったかと確認。

んで特に症状出てない感じなので追い打ちであっついお風呂に浸かることに。
なんか余計に頭はぼーっとするようになったけどｗ

最近は本格的に風邪をひくと一週間ぐらい寝込む事おおくなったので、なるべくならひき初めの段階でさっさと直してしまいたい感じなんですよね。

そんな感じで、しばらくはなんかまた調子が……とおもったら即ベッドインてなかんじの様子見運用で。

ここ数日、昼間は妙に暖かいですね。
でも夜は普通に冷えるのでこの寒暖は気をつけないと風邪ひいたりするので注意しないとな。

さて、昨日はfirefoxの面倒なレイアウト改変更新あって、それに時間取られたりしてあんまり作業進まず。あと病院にいったりもしてたので。
7z.dll利用ライブラリのエラーハンドリング周りまた弄ったり、利用側とどっちが何処まで処理するのかとか、データ構造はどっちが用意するのかとか設計的な事をぼちぼち考えてる間に終わってしまったり。

あとＧｙａｏでフィフス・エレメントやってたので見てしまったし(ぉ

てか吹き替え版しかみたことなかったので、字幕版で初見（だったとおもう）。

最近はめっきり字幕版でしか見たくない。吹き替え版しかない場合、その映画自体見ないってぐらい吹き替え版嫌いなのですが。
しかしフィフス・エレメント。吹き替え版のクオリティすごく高かったんだなと。クリス・タッカーのラジオ番組？　のＤＪっぷりは、むしろ吹き替えのほうがノリもテンポもハイテンションな感じが出てて良かったし。
他のキャラも、まさに「吹き替え」といったかんじで、雰囲気、声質までにかよってるし。もとの俳優さんの演技をトレースするような演技してるようなフィットぶり。

吹き替え版が嫌いになった理由は、なんか最近、もとの俳優さんの演技そっちのけの画一的な演技しか出来ない声優さんと、下手くそな俳優とかお笑い芸人起用とかで、映画自体を台無いしにされることが多い所為なのですが。
あと最近のは頓に声と俳優のキャラが合ってないと感じるキャスティングおおいし。もとの映画と俳優さんへのリスペクトが全くないのとちがうかと。

わりと昔の映画は吹き替えもしっかり作られてるんだよなと。
最近のがおかしすぎるんだよなと再確認。

そいやビルとテッドも吹き替えの方が初見でその後字幕版も見たけど、そっちも良い感じだったな。
なんか若者言葉というかブロークンな英語でしゃべってるみたいな話はきいてたのだけども、なるほどこれがああなるのかって感じで雰囲気でててこれも良い吹き替えだったなと。
ちな、そもそもそんな英語できるわけではないのですが、所々なんていってるのか全く判らない。日本語なら津軽弁レベルだろってぐらい発音がくだけすぎててわからないｗ　英語の方言とかてのを初めて意識したのもこの作品だった気がする。

初見はなんとなくつけてたテレビで途中から見たのですが（二作目の地獄旅行の方）お、なんかこれ面白そうだぞ？　と途中からだったものの録画ボタンを押し（まだVHSの時代です）最初に食いついたのはメガデスが流れて来たからだけど（メガデスとか色んなメタルバンドの音楽が提供されてる）その後もちょいちょいみてて、そのうち完全版ちゃんとみたいなー。でも日本ではマイナーっぽいからレンタルとかあるんかなー
したらその後、当時はそれが二作目だというのもしらず一作目があるのを知って。その後ネット時代がやってきて情報を集めやすくなると、海外ではアニメ版が制作されるぐらい結構ヒット作だったらしいことも知ったりで。
あと初見時はテッドがキアヌだとは知らない（ビルトテッドは1989年、二作目が1991年、出世作のスピードが1994年）で見てたんだよな。

んで、ＴＶで見てた時に、ＴＶの映画ではごくたまにそういう演出されることあったけど、ＣＭ前にアイキャッチが入るんですよね。
「またあとでね～♪」て言ってビルとテッドがてを振ってるの。
あれってもとの英語版でも「catch you later」っていっててそのまんまだったんだなとｗ
しばらく「またあとでね～♪」のフレーズが頭に残り続けてたっけ。

ビルトデット三作目ほぼ本決まりらしいので今から楽しみにしている一本です。

firefoxの更新きてたので更新かけたらば……。
まーたタブが一番上に移動してやがる……。

いい加減、勝手にレイアウト変更するような更新止めて欲しいわ……。
んでググってみると案の定、firefox65でタブを下にしたいんですけど的な記事がぽこぽこ。
いい加減、タブを下にしたい層が一定数要るって事を認識して、設定一つで位置変更出来る様にしてほしいわ。なんで執拗にタブを上にしたがるのか……。
てか今回の場合は、メニューバー周りのレイアウトを新しいＣＳＳの機能に置き換えたみたいで、firefox58ぐらいだったか？　からuserChrome.cssでタブを下に移動させてたのだけども、その辺書き直さないと行けない感じらしい。

てか更新の度にこんなんやらされるのめんどくさすぎだろ……。
なんかfirefoxって、バージョン番号急にあげ始めたあたりからおかしくなったよな。破壊的な変更最近多いし。
とはいえいくつかのアドオンが便利すぎて代替はなかったりするので……。

てか新しくなったcssのレイアウト方式っつっても、普通にそんな日本語の解説ページなんかないし、まずどう変わったのかとかから調べるのだけでうんざりですわ。
とりあえずいろいろやってるウチになんとかタブは下に下げれたんだけど、こんどは移動した分空白がのこってその空白が消えないｗ

個人的には

ツールバー（戻るボタンとか検索とかアドオンアイコンとか）
タブ

の二段のみでサイト表示部分は大きく取りたい派なのですよね。
メニューバーは最近のｖｅｒでは「三」ボタンから大抵のことは出来る様になったので必要無いし。
なのにタブは下に行った物の

空白（もとのタブの幅サイズ分の）
ツールバー
タブ

の三段構成にｗ
こんなんいやや。
メニュー表示にチェック入れるとちゃんと空白部分にメニュー表示されるし。
この空白消したいんや。どうすればいいんやー。
ここがcssではなんて要素なのかもわからんし。ググっても英語ばっかりだしぃ。
ってのでしばらく悩む。

結論
#navigator-toolbox {margin-top: -24px !important}

無理矢理力業すぎるｗ



んで、無事すっきり二段構成に。もうこれでいいや。

てかそろそろデフォルトで再起動ボタンつけてくれないかねfirefoxさん……。
cssの更新で再起動するんだけど、再起動ボタンはアドオンの所にuserChrome.xmlで追加してるんですけど、cssの編集でミスってその辺全部非表示になったりとかすると、再起動ボタンが使えないｗ
そこで毎度、「再起動ボタン普通に要るだろ。標準でつけとけよ」となんども脳内にこだまするｗ

そんな感じで、こんなんで時間取られてファッキン。


書庫ファイルのなかの画像ファイル整理整頓編集ツール。

今回は、いままでｃ++で例外って全く使ってなかったのですが。
基本的にゲームＰＧでは例外は使わないですからね。c++1x以降はとにかくどこでもnoexcept指定。それでも例外出るようなケースは(標準ライブラリとか)即std::terminateでアプリ終了。
例外出るようなケースはゲームの続行不可能の場合が殆どなのでそれで問題ないですしね。
noexcept指定することで最適化されやすくなるので実行速度も稼げるし。

なのですが、外部のdllとか使う場合、その部分だけは例外使った方がいいんじゃないかなーと。

今回のだと、7z.dllをロードして、そこから書庫フォーマットにあわせたアクセス用のオブジェクトを取得して、そこにコールバックを設定して～
みたいな流れなのですが、その過程のエラーハンドリングのメッセージが、例外使わない場合は結構面倒だなーと。
グローバルなエラーメッセージ保持するの用意するのは、結構用意しても実際にはめんどくさくて無視しちゃうケース多いしｗ

さらには、7z.dll利用部分は静的ライブラリとして別プロジェクトに別けてるんですが、例外つかうにしても、このライブラリの中だけで完結した方がいいのか(ライブラリのなかでtry-catchする)ライブラリ利用側でやった方がいいのか。
そこいらへんで、ライブラリの設計として、7z.dllのロード部分を完璧に隠蔽して、内部でロードするクラスを用意するとしたら、そのクラスを作成する部分をtry-catchするのか、それともそのクラス内の7z.dllのロード部分をtry-catchして、そのクラス内でエラーハンドリングするのが良い設計なのか？

と、長らく例外というものをシカトし続けてたツケが……。
まったくどうやるのが定石なのかとか、設計として良いのかよくわからん～。

とりあえず、今更ながらこの辺の解説サイトみてみると、やはりｃ++においてはコストがアレなので、なるべく範囲をしぼって、さらには利用するのはその後アプリケーションが継続不可能なタイプのものにだけにするのが、面倒はおこりにくいっぽいてのが一応の結論か。

いまいち例外のコストていろんなサイトみてもよくわからない。
正常系ならコスト0とか言うけど、tryは遅いとか書かれてるところもあるし。
とりあえずループの中でtry-catchはやっちゃ行けないってのはわかるんだけども。

un7z::InArchive_ptr in = nullptr;
try {
in = un7z::InArchive::create(filePath, fm);
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}
in->こっからなんかいろいろする

てのと

try {
auto in = un7z::InArchive::create(filePath, fm);
in->こっからなんかいろいろする 　
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}

で、try節の中でなにかの処理をずらずらとやるのって、そっちの場合てコストはどうなん？　try節の外でやった方がええのん？
あとtry節のなかで、noexcept指定の関数呼んだときは、その関数は最適化から除外されずにコスト的に問題なくなるのか？　とか。

知りたいところの情報がなかなか出てこなくて、いまいち世の中の多くの人もあんま例外って細かいところまで知らない人の方が大多数なんじゃないのかという気さえしてくるｗ

そんなかんじであんまわからんものは無闇に使う物じゃないなということで、多層的にエラーハンドリングが必要かつここで失敗したらもうその後の処理は何にも出来ないっていう7z.dllのロードまわりだけ例外を使う事に。

でもそうすることでまた、ライブラリの作り方的な方でもいろいろと考えることがでてきちゃったりで。
そんな感じで、設計自体見直しながら、このあたりをリライトしたり。

次回は、ｚｉｐ書庫だけは自前で処理する事にしたのでその部分を組む……てか以前組んだのを移植する作業に。

んでもこの部分を書庫関係用ライブラリとして7z.dll使用ライブラリと一纏めに追加しちゃった方がいいのか……。
でもこの辺、書庫内の画像ファイルのフォーマット解析とかもやるんですよね。画像フォーマットや画像サイズ（ピクセル数）色数とか。
そういった画像関係のコードもここに含めるのは違うなーと言う気もするし。
でもフォーマット解析だけなら一応範疇なのかな。書庫内ファイルの情報って意味では。

そこいらへんで、ライブラリ利用側とライブラリ側のどっちがどこまでやるのかってところの線引きも迷い出す～

更新頻度もやばくなってきてるので、ちょっと実験的なことをやってみようかなと。
今日やった作業の内容をここに書くって感じのを。

これだとサボって何もしてない日には、「サボってました」と書くハメになって自戒になるんじゃないかと。
あんま何もしてなさ過ぎるのもまずいと、作業も捗るかもしれん？

てな感じでスタート。

昨日はとりあえずアプリ開発環境の64bit化移行をしたのだけども、どうせそのうち使う事になるよなってことで、OpenSSLの64bit版を導入することに。

……あれ？　自前でビルドしなくてもインストーラあるじゃん。
でも自前ビルドの方法見てみると、見覚えのある手順。
あるぇー？　そうかhaxeだったかなにかの環境作るのも同じ様な手順だったからそれで記憶が混同してたのかな。

んで、だんだん他にも思い出してくる。
そうだOpenSSLて現在、v1.0.2系とv1.1.x系の２種あって、v1.0.2がunix系ではデフォルトで使われてるのとLTS（長期サポート）だってことでこっちのが問題は起りにくいてきな。

んで、Qtの方が、Qt5.7ぐらいまではv1.1.x系はまだサポートされてない状況だったとかで。
今ググってみると、フォーラムの記事でQt5.11はv1.1.1サポートしてるよって誰かがかいてるんだけど……いまいちQT公式のサイトからは対応状況の記事がみつからず。
フォーラムではなんか1.1.x系つかってトラブル起ってる感じの記事がぼこぼこ出てくるんだよな。
5.8～5.10あたりの古いｖｅｒだとサポートされてないからv1.0.2使うと良いよてきな記事ばかりがヒットしてるだけなのか……その辺みんな英語なのでいまいち確証が。

したらこんな記事も
「OpenSSL」のバージョンの付け方が変更 ～ライセンスは“Apache License 2.0”へ
ttps://forest.watch.impress.co.jp/docs/news/1155972.html

うーん。
どうもQt5.11移行はv1.1.1サポートしてる臭いんだけど、今度はｖｅｒ表記を3.0から新たに形式変えていくぜみたいな記事があったりして。
そうなるとv1.0.2系は２０１９年内までのLTSだったりするので、v1.1.x系いれたほうがいいのか。むーん。こういう過渡期にぶちあたると、どれを選択するべきか悩むぅ。

と悩んだあげくに、とりあえずいまのところそのまま置き換えるだけで動きそうなOpenSSLv1.0.2の64bit版を入れる事にする。

んで、漫画情報サイトからデータ拾ってきてリスト化するツールを64bitでリビルド～。
エラー。
SSL接続で転けてる～
普通にOpenSSLのdll(libeay32.dll ssleay32.dll)を実行ファイルのところにコピーし忘れてただけという凡ミス。
必要なファイルコピーして実行～
ちゃんと動いた～。

てかdllも64bit版なんだけどこっちもxxx32.dllと「32」の文字が付いてるのでややこしい。同じファイル名だけども中身は64bitだったりするので。
このへんなんとかならんかったのか。

てか大昔のwin3.1とかあの時代のころの、16bit→32bit移行あたりは、なーんにも気にも止めなかったうちに移行終了してた感じでしたけど、ＰＣの一般化にともなって影響範囲の拡大からの、32bitをすぐに切れないかんじのぐだぐだ感ｗ
まあ16bitとかあの頃って、そもosのbit数の影響を被るようなコードを書く人自体が極限られた専門家のみだったで状況もあるかな。
あの当時はそもそもコンパイラ自体も開発環境も今みたく無料で手に入らないわけだし。
しにても、32bit→64bitの移行ってそんなにスパッと移行しなかったですね。64bitＯＳ出た頃はすぐに全部なんでも64bitに置き換わっちゃうものだとおもってたんですけどね。かつての16bit→32bitのように。
いまでも多くのアプリがまだ32bit版だったりするし。
そしてそれでも困らない、逆に困らない仕組み(WOW64)を用意してしまったせいで、いつまで経っても移行出来ない状況になっちゃったんですかね。
んでもアップルのios11以降は32bitアプリ切り捨てる方針とかも出てきてるし、遅まきながらもそういう流れにはなってきてるのかなとも。

64bit出てきた当時は、まだ2GB縛りに抵触するようなアプリも稀だし32bitでも十分どころかハードウェア的には64bitの方が負担大きいみたいな状況もあったしね。
今では32bitアプリで2GBの境界で引っかかるケースが普通にでてきたし。
たとえば書庫ファイル扱うツールでも、ＨＤＤの大容量化にともなって、書庫自体が2GB越えってケースも普通に出てくるようになったし。

んでもdllの見た目は32bitっぽいのに中身は64bitっていうのはちょっと厄介ですね。
7z.dllの32とかの表記無いけど、中身は32bitと64bitどっちもあり得るってのもこれまた厄介ですが。

簡単に判別できないってのもアレだな「dumpbin」コマンドで確認ぐらいしかないっぽいし。
そもそもDLLは開発者とかが用意するものなので、そもそも利用者側で混同するケースを考えなくても良いってので、必要性がないということなのか。
んでも開発者側が、これどっちやねんと困ってるんですがｗ

まあそういうものなんだろうといえば、そういうもの何でしょうけど……。

そんな感じでOpenSSL64bit導入完了。

相変わらず月日流れるのはやすぎー

そして、いろいろと片付けたいことは山積しているのだけども、ちっとも片付かない。
てか、アウトレイジ1，2，3、龍三と七人の子分たち、ＪＭ、ホームアローン1，2にビバリーヒルズコップ1，2、それからなんかほかにも何本か……急に映画見るブームきてほげーっと見続けてしまったりと、あるいみ正月ボケ？

最初の切っ掛けは何だったろう……そうだ、ビルとテッド3の制作がいよいよ本決まりになったっぽい記事よんで、それからつべでＪＭの文字みかけて。昔ＴＶでみたなー。記憶屋ジョニー。キアヌって関根勤ばりに歳くわねーなー。むしろ昔が老けてた？　そいやビートたけしもでてたっけ。

ってとこから、そいやアウトレイジの最終章みてないな。
とおもったら間にもう一本「龍三と七人の子分たち」てのがあったのか。
てことでキアヌから北野武作品に流れ込む感じで。
「龍三と七人の子分たち」は面白かったけど、やっぱ893は893だよなーと。
んでもノリが初期作品っぽい感じで懐かしさもあったりして。

なにげに「その男凶暴につき」なんか久しぶりにまた見たくなったんだけどもみつからず。
脚本の野沢尚がその後、改変されまくるまえの原作ってことで「烈火の月」て作品だしてたけど、読んでもまったく別作品だったなーとか。
野沢尚いわく、映画が名作になったのは完全な偶然。
いろんなものが偶然絶妙にかみ合った故の奇跡みたいなこといってたっけか。
北野作品てその後もどこか危ういというか、ギリギリの線で成立してる、そんでそれがへんな緊張感生み出してる感あるよなーと。
その辺なにげに、画面に変な緊張感が漂うって意味ではキューブリックに近い印象あったりするぽ。

ホームアローンとビバリーヒルズコップはたまたまぱっとあったのでみてしまったｗ
どっちもまだ続編あるものの、ホームアローンはやっぱカルキンくんじゃないとな。てか遠い昔にみたっきりだったのだけども、序盤の家族からの冷遇ぶり、なんかみてて悲しくなるな。そういう脚本なんだとわかっていても。
んでビバリーヒルズコップの三作目は単純につまらなかったよなってことでスルー。
そいやなんでビバリーヒルズコップみたのか思い出した。
ビルとテッド3の制作の続報ぐぐったときにみた映画情報のサイトの関連リンクでビバリーヒルズコップ4の制作もちあがるも、エディーマーフィーが「脚本次第」と出演を見合わせているみたいなところで、三作目が脚本がひどくてもうあんなヒドイ内容の作品にはでたくない。というところで4作目のオファーにエディはネガティブだ的な記事があって。たしかに三作目はひどかった記憶がある。でも1と2はおもしろかったよね。ってところからの、久しぶりに見たいなとおもったんだっけか。


話はかわって。

書庫ファイルのなかの画像ファイル整理整頓編集ツール。
7zipのなかの7z.dll使うとzipだけでなく多種多様な書庫に対応できるのと、統合アーカイバにくらべ動作も軽そうってのもあって、そっちに乗り換えることにしたのだけども。
んでついでに、やっぱそろそろ64bitアプリ化も考えた方がいいのかなー。将来的にも。んでもwin32apiまわりがなぁ。64bit版完璧にすべてそろってるっているのか。その辺で面倒おこるんじゃないかってところと、開発環境も入れ直しメンドイ。ってのがあったりで。

んでもいつかはやらないと。
あとなにげに7z.dllさわってみて、rarとかrar5まで対応出来てるので、これ使えばマンガミーヤ的な物自分で作れるな。でもそうなると32bitアプリだとぼちぼちキツイかねぇ。
なんて思惑もあったりで。

んで64bit開発環境化よしやるかとなったわけで。
……したら以外にあっさりと出来てしまって拍子抜け。

てかvisual studio自体は32bit版しかないのね元々。
で、Qtの方をmsvc2017の64bit版に切り替える。

新規でテストプロジェクト作成。
msvc用のデバッグツール(WinDbg)がみつからねーとか怒られて、みたら64bit版ないやんと。windowsSDKのとこからダウンロード。
うん？　64bitとか選択するところないやん？
とりあえず入れてみると64bit版が新たに追加される。
？？
そいや32bit版のWinDbg入れたの随分前だけど、そのときは64bit版がまだなかった？　ちょっとググってみると、なんか以前は６４bitのWinDbgだけインスコ失敗するみたいな記事でてきたので、以前はインスコ失敗してたのかｗ
影響無いので気づかなかっただけっぽいｗ
そんな感じで一手間はさんで、実行。
タスクマネージャでみると*32の文字消えてる～64bitアプリ作成成功～
ってことでここまでは簡単でした。

問題はなんか内部でwinapiとかなんかＭＳ製のvariant型みたいなのからwin依存コードべったりだったりする7z.dll。
この辺でなんか一悶着ありそうなんだよなーて予感あったりしたのですが。
なんか元のプロジェクトの設定がのこってるのかなんなのか。
以前のプロジェクト読み込んでリビルドしてみたらエラーどばどば。
それも7z.dllつかうのに必要なoleaut32.lib user32.libあたりが見つからない感じのエラー。さらにはライブラリのほうがx86だから整合性とれんよてきなエラーまででてくる。
うーん。やっぱりすんなりいかなかったか。

てか7z.dllてそもそも64bitいけるん？　ダウンロードページみると「x86 / x64」てなってるし。ソースコードは「any」になってるので、両用なの？
とおもったのだけども。
dllの方を確認してみるとどうも32bitくさい。
7-Zipの64ビット版のexe（インストーラ）落してきて解凍したなかみの7z.dllみたらサイズ違うし64bit版はやっぱ別であるんじゃん……。

で、64bit版の7z.dllに置き換えてみたら、ビルド通る。
実行。書庫の中身もちゃんと取得出来てる～。

割と昔、QtのQDataStreamとか触り始めたころにqint8とかqint16とか使う用になってるので64bitアプリになってもコードはそのまま使える配慮になってんだなーってのを見たときからバイナリ操作まわりは意識してバイト長固定の型を使う用にはしてきたりと、一応将来的に64bit化は頭の片隅においとくコーディングはしてきてたつもりなので、その辺では今のところトラブルはないっぽい。

そんな感じでわりとあっさり64bit化はできてしまったっぽい。


それとは別に。
7z.dllはいろんな書庫に対応できていいんですが、どうもzipのunicodeファイル名には対応してないっぽい。というのも、unicode対応版なんてものを公開してる人がいるので。

てかこのzipのunicodeファイル名ってのが厄介で、以前その辺の対策込みのzip読み込み作ったときの記憶なので細かいところは間違ってるかもだけど

unicodeフラグというのがある。このフラグたってるときはファイル名やコメントなどはunicodeとして扱われる。
厄介なのは、macなどのＯＳ標準でunicode（unix系はutf8がデフォ）の文字セットの環境で作られたzipではこのunicodeフラグは立って無くてもファイル名やコメントはunicodeになる。

てな感じらしい。
んで、どのＯＳで作られたかというフィールドもあるのだけども
その辺ほんとにちゃんと入ってるのかなんて信用出来ないし、そしてバイナリで見た場合、その文字が入ってるとおぼしきバイナリ列からそれがunicodeなのかshift-jisなのかなんて見分けがつかないわけで。（条件がそろえば見分けはつくけど、確実性は無い）

で、7z.dllで取得出来る書庫内アイテムの情報にはこのunicodeフラグは含まれてないんですよね。なので7z.dll自体を改変してリビルドするしか対応できないので改造版7z.dllてのが出てきてるんでしょうけど。

んでもまあ、実際の所、そんな特殊なzipファイルに対応する必要あるんかいなという気もしないでもないのだけども。

それともう一つ、7z.dllのファイル個別解凍あたりのところ、これって非圧縮の場合なんかちょっと無駄がおおいかんじになっちゃわない？
てなところもあったりで。

さらにもう一つ。
zip以外→非圧縮zipに変換するのが用途的には必要なのだけども、7z.dllの機能つかって非圧縮ｚｉｐ作るのもなんかいちいち面倒（ほかの書庫用の設定も考慮に入れたつくりになっているので）だったりして。

なので、zip周りは今まで通り自前でやって、ｚｉｐ以外の書庫にだけ7z.dll使う感じの運用のがいいのかなーと言う感じに。
それだとunicodeファイル名の処理も一応できるしね。

前に作った奴は、ネックはrar書庫だったんですよね。
rarのファイル個別解凍、それもファイルにではなくバッファ（メモリ上）に。てのが統合アーカイバではできなかったので。
さらにはrarの内部バージョンでバージョン間に互換性がないってのでも対応が難しい部分あったりで（各バージョン毎のコードが必要になる）

7z.dllだとそれができるので以前はrarは一旦ｚｉｐに変換して、それから書庫内処理ってかんじだったのを、
7z.dllでrar開いて、ファイル単位でメモリに解凍、画像処理などおこなって、非圧縮zipに書き出し。
てのが出来る用に。

間にいったんｚｉｐに変換してから～でなく直で画像編集適用しながらｚｉｐに変換出来るようになって良い感じ。
オマケに7zにもlzhにも対応出来る様になったし。7z.dll様々やぁ。

なかんじで後はちまちま組むだけってかんじなのだけども。
その辺でなぜか映画みるブームきちゃって気がついたら二月だよ……。


またまた話は変わって。

田中久仁彦氏のラフ画集の第２弾が受注販売してたので即買い。
気がついたのが1/26で受注〆切りが1/28だったので気がついて良かった～。
氏のサイトは週1～月1ぐらいの頻度でなんか新しい絵とか上がってないかなと見る感じなので、タイミング悪ければ逃してるところでした。
んでもまあ、前作のもその後も何度か再販してたみたいなので、これを逃したらもう……って感じでもないっぽいですけど。
２月中旬以降到着とのことで愉しみ～。

んでも本のお値段、約100ｐで１２００円ぐらい。というのは安しぃ～と思うのに
送料５００円で計１７００円ていうと高けぇ～って思う不思議ｗ
なんかもう尼とかに慣れすぎて送料５００円高けぇって印象しかなくなっちゃいましたね。配達業者には不幸な事だろうけど。


んーなんか１月はあんまし実りのない無為に過ごす時間多い感じでダメダメだったなぁ。

やること、やりたいことは山積してるんだけどなぁ。

某所のpixivダウンローダが最近なんかChromeと連携して画像取得するようになって、しかたなくChromeいれたんだけど、なんか変なツールとか勝手に入れやがるしでChrome消したい……。
そんでもってこのツールやたらとChromeのプロセスが残りまくるので、メモリドカ食いなうえ、終了後にタスクマネージャで消えてないChromeのプロセスをプチプチ消すのもメンドイ……。
てかブラウザ経由で画像取得するぐらいなら、こんなん自作できるよなと。
Chrome消したい欲求からのツール作成欲求メラメラ。
とばっちりでChrome大嫌いになった最近。
この辺のツールはサイトの仕様かわったらまた修正要ったりするので面倒な部分もおおいのでアレですけど。それよりもChrome消したい（ぉ

そいやsslのサイト(https)にアクセスするにはOpenSSLとか必要なんですけど、以前作った漫画発売日情報サイトから情報取得するツール作った時に入れたのだけど、32bit版なんですよね。
OpenSSLも64bit版そのうち入れとかないとな……なんてことを思い出したり。
普通にｄｌするんじゃなくて、ソース落して自前でビルドしないと行けないのでメンドイ……。

むぐゆぁ～