CLIP STUDIO PAINT EXのフィルタープラグインとVisual Studio Community 2017

はじめに

http://www.clip-studio.com/clip_site/download/clipstudiopaint/cspsdk にCLIP STUDIO PAINT EXのフィルタープラグインSDKと言うのがあって、 CLIP STUDIO PAINT EXにC++で独自のフィルターを書けるようになっている。 まあ、CLIP STUDIO PAINT EXとのインターフェイスの部分だけC++であれば、 別に全てをC++で書く必要はないだろう。

Visual Studio Community 2017でビルドしてみる

文書によると、フィルタープラグインはVisual Studio Expressではビルドできないそうである。 これは、実際に附属のサンプルをビルドしてみれば理由は簡単に分かった。 MFCが必要なのである。 なので、Visual Studio Community 2017ではMFCをインストールしておけば 問題なくビルドできる。

ライセンスの考察

SDKのライセンス上、自作のフィルタープラグインをオープンソースな ソースコードを再利用できるか、オープンソースで開発できるか考えてみる。

copyleftなライセンスだと、SDK付属のヘッダーファイルとは混ぜられないし、SDKの再発明は禁止されているので、copyleftなライセンスのコードは採用できないだろう。 copyleftなライセンスの場合には、フィルタープラグインの配布はセルシス社のプラットフォーム上に限定されているので、 そもそもソースコードの配布ができるのかを確認しておかないといけないと言う課題もある。 現実的に考えて、copyleftなライセンスなソースコードを再利用するのは無理であろう。 BSDライセンスやMITライセンス等であれば、外部のソースコードを再利用することも可能だろう。

ソースコードを公開するとしたら、SDK由来のコード(ヘッダーファイル等)は含めることができないのは間違いない。 その上で、セルシス社のプラットフォーム上でソースコードを公開できるのかどうかに、ソースコードを公開できるかは依存していると考えられる。 現実的ではないような気もする。

Git for Windowsでgit statusの表示中のパスの日本語文字列が文字化けする場合の対処方法

Git for Windowsは、Git bashのみで使っている。 基本的にはGit bashの内部で困ることはないのだが、 唯一パスに日本語の文字列が含まれている場合に文字化けしてしまって 判別できないのが不満だった。 ~/.gitconfigに、以下のように追加すれば文字化けはなくなった。


$ vi ~/.gitconfig
[core]
 quotepath = false

電話サービスの通話料の比較

NTT加入電話への通話料

SMARTalk
8円/30秒
みおふぉんダイアル
10円/30秒
ひかり電話
8円/3分
こう比較すると、自宅のひかり電話の回線から発信できるような仕組みを作りたくなってしまう。

Oracle OLEDB Provider Version 12.2.0.1.0 for Windows x86をインストールする際のエラー

Windows 7 Professional 32-bitに、Oracle OLEDB Provider Version 12.2.0.1.0をインストールするには、 例えば、C:\app\instantclient_12_2に必要なDLLを揃えて、PATH環境変数にこのディレクトリーを追加した後で、 regsvr32 C:\app\instantclient_12_2\oraoledb12.dllを実行すれば良い。 しかし、「指定されたモジュールが見つかりません。」のエラーが出ることがある。

こうなるとOLEDB Providerは登録されないので、OLEDB経由でOracle Databaseに接続することはできない。 これは、Visual C++ 2013 redistributableを インストールすることで解消された。

Is it time for open processors?

Is it time for open processors? を読んだので翻訳しておく。 ただし、正しく訳せているとは思わない。

これは、 Jonathan Corbet氏による2018年1月9日のlwn.netにおける記事で、 Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) で公開されている。

Is it time for open processors?

MeltdownとSpectreの2つの脆弱性の公開により、 ハードウェアレベルのセキュリティー上の問題が存在し得ることに、 改めて注目が集まっている。 ソフトウェアの脆弱性に関しては、まだ脆弱なソフトウェアのセキュリティー の解消のために非常に多くの努力がされているが、 ハードウェアな脆弱なままであれば、全て無駄な努力である。 私たちのシステムを動かしているCPUは、高度にプロプライエタリーであり、 嬉しくない驚きを内包していることが示されている (例えば、Intel Management Engine)。 そうなると、ソフトウェアがそうであったように、 オープンソースハードウェアに移行しようという動きがでてくるのは当然だろう。 オープンソフトウェアハードウェアへの移行は可能かもしれないし、 確かに利点はあるが、それで全てが解決する訳ではないだろう。

現代のCPUは複雑であり、販売されている市場は過酷な状況である。 オープンなやり方でCPUを開発しようと言うのは驚かれるかもしれない。 しかし、この分野でもオープンな開発を進める動きはある。 オープンなCPUと言う考えは、ファンタジーではない。 以下に、いくつかの事例を紹介する。しかし網羅的なものではない。

既に公開されているもの

POWERアーキテクチャーを元にしたOpenPOWERの事例を見てみよう。 これは真にオープンソースではない。 主体的に利用するのであれば、OpenPOWER Foundationに加盟しなければならない。 しかし、プロセッサーを共同作業として開発するという例ではある。 比較的オープンな設計に基づいた製品が出荷されている。 OpenPOWERは、ハイエンドに特化している。 この設計に基づいたチップが、近い将来携帯電話やノートPCに搭載される というのはありそうにない。

OpenSPARCという試みもある。Sun MicrosystemsがSPARC T1とT2の設計を完全に オープンにしたものである。 これらの設計を使おうとしたプロジェクトはいくつか存在する。 しかし、どこまで成功したのかは分からない。 オープンなSPARCの設計は10年前の設計であり、 SPARCに未来があるのかも疑わしい。 Oracleが最新のプロセッサーの設計を公開するのであれば面白いかもしれないが、 実現しそうではない。

OpenRISCは完全にオープンなプロセッサーであり、 組み込み用途をターゲットにしている。 OpenRISC 1000という完成したプロセッサーが1つ存在する。 商業化されたOpenRISC 1000も存在する。 mor1kxと行ったレファレンス実装も存在する。 Linuxカーネルは2011年にリリースされたバージョン3.1から OpenRISCをサポートしており、2014年にはDebianも移植されている。 しかし2016年にはDebianのサポートは終了してしまった。 LinuxカーネルにおけるOpenRISC関係の活動は減速してしまったが、 2017年にはSMPサポートが追加されている。 全体的に言って、OpenRISCはかつての勢いを失ってしまったようだ。

最近はRISC-Vアーキテクチャーに関連した動きが活発になっているようだ。 RISC-Vプロジェクトは、特定の実装ではなく命令セットアーキテクチャー(ISA)に 特化している。しかしハードウェアの実装は存在する。 Western Digital社は、ストレージ製品にRISC-Vプロセッサーを使用していく 予定であると、最近発表している。 これが実現すれば、何百万ものRISC-Vプロセッサーが出荷されることになる。 このプロセッサーを試してみたい人に向けて開発キットが入手可能であり、 いくつものコアの設計が使用できる。

OpenRISCと違い、RISC-Vは非常に新しい。 実際Linux Kernel 4.15で初めてサポートされる予定である。 開発は非常に活発で、ツールチェインとライブラリーのサポートも それぞれのプロジェクトに取り込まれつつある。 RISC-Vは商業的なサポートも存在する。 RISC-V Foundationには多くの会社が加盟している。 RISC-Vは、しばらくの間は、活発に開発が進むであろう。

ハードウェアの問題への答えは?

MeltdownとSpectreの回答として、RISC-V Foundationはより安全な代替案として RISC-Vを押し進めるプレスリリースを出した。 実際、RISC-Vは投機的なメモリーアクセスをしないため、これらの問題は存在しない。 しかし、RISC-V Foundationは、RISC-Vには特定の脆弱性がないということを越えて 利点があるとしている。つまり、開発モデルがオープンであると言うことである。 RISC-V Fundationは、幅広い開発者から最良のセキュリティーに関するアイディアを 迅速に集められると語っている。

これはますます説得力を持って来ている。 Linuxはカーネルレベルでハードウェアの脆弱性に対処しようとしているが、 プロプライエタリーなハードウェアとカーネルより下で動いているプロプライエタリー なソフトウェアを制御することはできない。 RISC-Vのようなオープンなアーキテクチャーの魅力は増して来ており、 いずれ全てを制御できるようになるかもしれない。 これは追い求めるべき夢だと思うが、その前に克服しなければいけない困難が 存在している。

1つ目は、当然だが、コンパイラーがフリーであるように、チップを製造する設備が フリーではないと言うことだ。特に、ハイエンドのプロセッサーを製造するには 高価な設備が必要となる。 シリコンのレベルで陳腐化が進めば、既に進んでいるという人もいるが、 製造設備はより小規模の顧客も使用できるようになり、 私たちがプロセッサーの設計を実験できるようになることも現実的になって来る。 しかしmakeコマンドを実行するように簡単で安価にはなりそうにはない。

誰でもプロセッサーを作れるようになるまでは、自分のプロセッサー を誰かに作ってもらうしかない。 これは私たちの多くが、自分のためのソフトウェアを他人にビルドして もらわないといけないのと同じように、良くない状況である。 ソフトウェアのレベルで、毎回同じバイナリーが生成されるようにビルドすることは、 重要であり、在も取り組みが続いている課題である。 ハードウェアレベルでも難しい課題になるだろう。 しかし、実際のハードウェアの一部となった設計を検証できないのであれば、 自分の使用しているチップの実装が、想定している設計通りかを確認することは できないだろう。

RISC-Vの仕様に限った話ではないが、実装の設計は公開されなければならない。 RISC-Vが市場で成功したとしても、私たちの実際に購入するプロセッサーが フリーなライセンスの設計になるとは限らない。 自分自身のデータセンターを構築するような大規模の事業者は、 フリーなライセンスのプロセッサーを使っていると確信の持てるかもしれないし、 自分自身でプロセッサーを作ってしまうかもしれないが、 私たちのほとんどは、それより不利な立場に置かれることになる。

最後に、もし完全にオープンなプロセッサーを手に入れたとしても、 脆弱性から無縁になるということはないだろう。 フリーなカーネルは存在するが、カーネルの脆弱性は存在している。 これと同じである。 オープンなハードウェアは私たちが自分自身のハードウェアを 制御化に置くのに不可欠ではあるが、問題を全て解決してくれる 魔法の杖ではない。

しかし、以上のことにより、私たちが、自分自身のハードウエアの設計を もっとオープンで自由なものにしようという動きが阻害されるとは思わない。 かつて、フリーなオペレーティングシステムを作るのは、非常に 困難なことだと思われていたが、私たちはいくつものフリーなオペレーティング システムを作り上げた。 プロプライエタリーなハードウエアの設計を使わないようにするのは、 私たちの自由を維持する最良のチャンスの1つである。 これを試すのはばかばかしいことではない。

2017年の25日間のまとめ

この記事は、 NetBSD Advent Calendat 2017 の25日目の記事です。 もうすっかり遅くなりましたが、勝手にまとめを書きます。

まとめ

自分の書いた記事は、とりあえず置いておいて、 簡単に振り返っておきたいと思います。

1日目は、furandon_pigさんの記事です。 /usr/share/examples/asmディレクトリー内にアセンブリ言語での Hello, World!を皮切りに、各アーキテクチャー向けの アセンブリプログラミングについて紹介していただきました。

2日目もfurandon_pigさんの記事です。 キングジムPomera DM20の内部ストレージをsd(4)として見てみる話を紹介して いただきました。

3日目は、ebijunさんの記事です。 Open Source Conferenceに1年間を通じて参加するのに合わせて、 Raspberry Pi向けのSDカードイメージファイルを作成され、 動作確認をされた話をご紹介いただきました。

7日目は、furandon_pigさんの記事です。 NetBSDでのnilfsというログ構造化ファイルのサポートについて ご紹介いただきました。

14日目は、jr9qnjさんの記事です。 Raspberry PiSCSIデバイスにするRaSCSIについて、 X68000の実機に接続し、NetBSD/x68kで使えるように された功績をご紹介いただきました。 ぜひNetBSD-currentに入れて欲しいです。

16日目は、nullnilakiさんの記事です。 bintime_add(9)をコメントアウトするところから始め、 カーネル内のタイマーについてご紹介いただきました。

19日目は、tisiharaさんの記事です。 pkg_rolling-replaceを使って便利にpkgsrcからインストールした パッケージをアップデートする方法をご紹介いただきました。

20日目は、610tさんの記事です。 SUNXIカーネルを、NanoPi NEO2で動かすと、現状どのようになるかを ご紹介いただきました。 早く本格的にNanoPi NEO2がサポートされると嬉しいですね。

21日目は、oshimyjaさんの記事です。 NetBSD/amd64でのUEFIブートについてご紹介いただきました。 もう何年かすると、UEFIしかなくなってしまうようですので、 早めに移行していかないといけないようですね。

22日目は、furandon_pigさんの記事です。 uuidgen(1)コマンドの実装について、ご紹介いただきました。 uuid_generate(2)というシステムコールがあるという話で、 大変おもしろいです。

まとめ

勝手にまとめさせていただきます。 ご執筆、ご閲覧いただきましたみなさまありがとうございました。 2018年もよろしくお願いいたします。

2018年に実現して欲しいことを夢想してみる

この記事は、NetBSD Advent Calendar 2017の23日目の記事です。 代わりに投稿できるようになっているので、勝手に投稿してしまいます。 すみません。 間に合っていませんが…

2018年に実現して欲しいこと

一ユーザーとして、あったらうれしいものを挙げておきます。

NetBSD

  • Amazon Web Service EC2のElastic Network Adaptorのサポート (FreeBSDで言うena(4))
  • Microsoft Hyper-Vサポート (第1世代の仮想マシン、第2世代の仮想マシン)
  • UEFIでの光学ディスクからの起動ができるように
  • もっと多くのArmのボードでfdt(4))対応が進むこと
  • MicroBlazeやNios2、RISC-VのようなFPGAに実装されるCPUへの移植
  • qemuのエミュレートする各種ボードへの移植
  • UEFIでのブートがもっと多くのマシンでできるように(少なくとも私の常用するdynabook R63/PSは駄目なので…)
  • VMware Workstation Playerの共有フォルダーをマウントできるように
  • VirtualBoxの共有フォルダーをマウントできるように
  • cramfsをマウントできるように
  • fdt(4)をMIPSにも
  • NFS 4/4.1対応
  • ugen(4)が常に使えるように
  • evdevの追加
  • VirtualBoxをNetBSD上で動かせるように
  • アイソクロナス転送をehci/xhciで可能にする

私はカーネルのこととかは分かりませんが、来年は良く勉強して上述の うち1つでも自分でできればと思ってはいます。

pkgsrc

  • GNU Hurdへの移植
  • ia16クロスツールチェーンのパッケージの作成
  • The pkgsrc guideのEPUB3版を用意する
  • pkg-vulnerabilitiesの効率的な作成を補助するツールを作成する
  • openSUSE 42.3ベースのcompat_linux用パッケージを作成する
  • Rump kernelの活用ができないか
  • Rust for earm
  • Chromiumウェブブラウザーの移植
  • mingw64に移植
  • Widevine CDMをwww/firefoxで使えるようにする
  • input/fcitxのアップデートとmozcを使えるように

どこまでできるか分かりませんが、進めていきたいと思います。

HP ProLiant ML110 G7に32GBのメモリーを搭載する

HP ProLiant ML110 G7 Server Maintenance and Service Guide の62ページ目には、以下のように記載されている。 General DIMM slot population guidelines Th...