問題はどこへ引っ越すかですけど、githubかなぁ
リリースシステムがtag直結なのがこれじゃない感があり、
ダウンロード数とかもわからないし、アクセス数は2週間？だけわかる感じ
もっと良さそうなところありますか？
sf.netのトラッカーの情報とかどうやって引っ越すんだろう

64bitビルドした単体物は大抵ここにあります。
https://sourceforge.net/projects/sakura-editor/files/wiki/
相変わらずBeta版です。
今回のバージョンから2GB以上のファイルを開こうとしたときに強制的にエラーになっていた仕様が変更されて、
64bit版ではファイルを開こうとするようになりました。

制限としては、1行のデータ長や行数は32bit長までしか扱えません。(Grep時の行数は除く)
範囲選択したときのbyteカウントも32bitを超えるとどうなるか分かりません。2GBを超えての全選択コピー/貼り付けなども動かないと思います。

ただ、2.2.0.1にもGrep置換の正規表現が1行に2つ以上置換対象があると置換されないバグなどがあります。

(自分用メモを兼ねています)
Vista対応はたぶんこの辺からです。
Vistaは実機を持っていないので確かめられず、そういう細かい情報は助かります。
http://www.shuiren.org/chuden/teach/ms-ime2010/ime2010-8.htm
Mery はblogによるとTextOutらしいけれどIVSはVista以降対応と記載されています。
http://www.haijin-boys.com/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
Unicode IVS Add-in for Microsoft Officeの動作要件がVista,7なので、紛らわしいことになっているのだと思います。
http://internet.watch.impress.co.jp/docs/news/20121112_572392.html
>そのドキュメントで使用する異体字をテンポラリ領域に外字として割り当てて処理
なので実際は外字みたいですけど。

色々詳しいAlphaの日記
http://alpha-olddays.tumblr.com/post/33143480833/54-sip-ivs

情報ありがとうございます。
なにやらフォントファイルvsレンダリングエンジンの複雑な事情があるんですね。
VistaからOSはIVSに対応とか書いてあるのを見たんですが、そう簡単にはいかないのですね。

UTF-16にしたせいかおかしくなってますね。
zipに変更しました。

構成プロパティ->全般->[プログラム全体の最適化]を「リンク時のコード生成を使用」から「プログラム全体の最適化なし」にすると直りました。
cl /O1 /GL test.cpp のように /O1 /O2 /Oxなどと GL(/LTCG) を組み合わせると発生して、 O1, O2単独やGL単独では発生しません。
VC 2008 SP1/CL 15.00.30729.01 for 80x86/LINK: 9.00.30729.01 x86版
includeヘッダは以下のとおり。
#include ＜windows.h＞
#include ＜stdio.h＞
#include ＜tchar.h＞

x86版バイナリが600K位なのに同じソースをIA64向けにコンパイルすると2M越えになってびびったのが懐かしいです。
2003年9月でした。
それから待てど暮らせど、一般に降りてこないし、Itaniumは速くならないし、.NET 1.1の64bit版もない。
そのうえでx86エミュレーションが遅いと。
その状況だと、.NET 1.1で書いたものをItaniumで走らすより、x86系CPUのほうが速いし安いということになりかねない。
(たぶん)その後、.NET2.0で64bitもできるようになったら、AMD64がでてきて安いし .NET1.1 32bit, .NET 2.0 32/64bit 全部普通の速度で走る。
WIN64ネイティブアプリは対応製品がない。64bitに対応したと思ったらAMD64版だけだったとかもありそう。
ItaniumはOracle専用マシンならHP-UXでいいきがするし、どっち向いてもWindowsの出番があんまりなさそう。
kb924449の MSのコンパイラが吐くコードがおかしい問題だって、話題にならなかったみたいだから、ほとんど誰も使ってないということでしょう。
こんな感じに情報だけ拾い続け、結局クロスコンパイルするだけで、私は実行することが一度もないまま消えていくのですね。

#ハイエンドサーバー系は完全に外野なので突っ込み歓迎

># これはがくっときてしまう人多そう…。
確かにIPAの存在も忘れてましたが、法人ではなくて個人を想像したコメントでした。
IPAがまとめてくれているので、個人でまとめる必要はないわけですね。
プログラミングガイドとかも、そういえばIPAでした。

脆弱性でデータ流出とかは話題になって(個人的には)記憶に残りやすいです。
一方「IPAが仕事しました」というのは、内容がおかしかったら話題になるけど、内容がまともすぎて、話題・記憶に残りにくいのかもしれません。
blogとかで紹介するときも、「IPAがまとめています→リンク。参考になります。」という感じで触れられるだけですから、
後で読もうと思ってリンクをたどらず、つい読み飛ばしてそのうち忘れます。

現場で、「IPAのこれ読んで」とか上に言われて渡されたりするのか、もしくは上の人は、渡したり確認したりしているんでしょうか。

#ここはひとつ、萌えキャラで擬人化してみんなに覚えてもらうというのはどうだろう。

携帯対応・変なファイヤーウォールを無視できるとして、今回の件では関係ないものもありますが、対策はこんな感じでしょうか。
専門家の方もxxはyyが悪いというばかりで、対策をまとめてくれないのでよくわからんのですよね。
ベーシック認証、クライアント証明は考慮外です。

step0: ログインIDとパスワードをURLに含めて持ち歩くのをやめる
step1: パスワード送信をPOSTにしてPOSTのみ受け付ける
step2: ログイン画面以外は、パスワードを利用せずにcookieを使う
step3: 全コンテンツでTLS・有効で信頼済みの認証局発行のサーバー証明書を使う
step4: cookieにはsecureフラグを立てる
step5: cookieには基本的にセッションIDのみを保存する
step6: セッションIDをjsessionidやphpsessionidなどでURIに含めない。受け付けない。(NG例:ぐぐる)
step7: セッションIDには推測されない一時的に生成されるIDのみを使う(NG例:JVN#07468800)
step8: ログイン前後でセッションIDを共有しない
step9: パスワードを変更したら、サーバー側で古いセッションIDを無効にする(NG例:twitterのidのっとり事件)
step10: パスワード再確認などを併用してセッションIDのサーバ側有効期間を短くする(例:yahoo)
step11: ログインIDとユーザーIDを分離する(例:mixi/ねとげ)
step12: ログイン追跡機能をつける(例:unixのlast login/yahooの履歴)
その他1: サーバー側のDBでのパスワード保存は、saltつきのハッシュ値などにする
その他2: CSSXSS/CSRF/XSS対策、正しいエスケープ処理をする
その他3: 簡単ログインを実装しない
その他4: メールでのパスワードリセット・確認はメールアドレスの生存期間を考慮した仕様にする(NG例:iTunes)
その他5: 脆弱性が公表されているバージョンのソフトウェアを使わない

>画像サイズが果てしなくでかい白画像
元コメの人はファイルサイズではなくて、展開後のサイズのこと言ってるんでしょう
PNG圧縮してあっても、IE6 / Firefox 3.5.8どちらも、表示するときは普通にメモリ上に展開するようです
果てしなくでかいのは、32bit Windows ならすぐあきらめてエラーを返すだけだと思いますが、 64bit OS/アプリだとアドレス空間が余ってる分大変かもしれないです