続・エラい身近にあった2010年問題。

 SEPトラブルの続報。

 どうやら8日午後ぐらいに?Symantec本社のLiveUpdateサーバには2010年の日付のパターンファイル(2010/1/7)も設置されるようになった模様。
 これで、SEPM経由でUpdateをかけていない野良端末では、きちんと2010年の日付のパターンファイルが表示されるようになりましたよ、と。
 ・・・SEPM下にある管理端末では、未だに2009/12/31のままだけど。

 つまり今のLiveUpdateサーバには、中身は一緒でも日付が正しいものと2009/12/31のものと、2種類設置されているってことね。
 
 ・・・さて、SEPMのパッチ、いつ出て来ますかね。

Share

エラい身近にあった2010年問題。

 海外ではカード端末が誤動作したり、ケータイがコケたり、タクシーメータがリセットされたり、と色々な話が聞こえてきましたが。
 まさかこんな身近に2010年問題があったとは、という話。

 というのは、企業クライアントではメジャーなSymantec Endpoint Protectionで、2010年の日付のウィルスパターンファイルを読み込めないという話。

 >Security Content for Symantec Endpoint Protection clients and Symantec Endpoint Protection Managers are dated Dec 31 2009 even when using the latest definitions
 >http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348

 日本語速報版の訳はこちら。
 >SEP クライアントと SEPM のウイルス定義ファイルの日付が最新版に更新後も2009/12/31 のままとなっている
 >http://service1.symantec.com/support/inter/entsecurityjapanesekb.nsf/jp_docid/20100105094746949

 要するに、2010年の日付の入った最新パターンファイルを配信したら、受け取る側のバグで古物だと勘違いして捨ててしまうため、いつまでたってもパターンファイルが更新されません、と。
 仕方ないから、2009年12月31日の日付のまま、通し番号だけカウントアップしたパターンファイルを当分配信し続けますよ、と。

 実は当方も会社支給の端末ではモロに該当していたのだが、Symantec本社のフォーラム辺りでは年明けて間もなく話題になっていたので、「あれまあ」としか思っていなかったのだが。

 本日の出先で、この件が思わぬ大騒ぎになっていたので、思わずメモ。
 ・・・まぁそりゃ積極的なアナウンスはされていないし、そもそも日本語説明文章はUSAよりだいぶ遅れてから出たとはいえ、仮にでもIT部門名乗るなら、せめてベンダのKBぐらい確認しろよな・・・。

 #Symantecは不具合情報を出したがらない(出したとしてもKBの隅っこにこっそりとか)上に、日本語リソースが少ない&出ても激遅なのでも有名な会社の一つ。
  あそこが日本語リソース出すのを待つということは、Globalから周回遅れになるということとほぼ同義。

 まあしかしこうなると、個人的には「あたふたしているウチに今度は通し番号がさくっと桁溢れ」なんてオチを期待してしまったり・・・え?黒い?

 #通し番号は元々同一日付内に複数回更新された時にカウントアップされる性質のもので、普段2桁しか使っていないのに、今回は非常事態ということで3桁番号を使っているんだし。慌てついでにsignedとunsignedをミスってみたりとか・・・

Share

超個人的2009 PCトピック。

 さて、今年最後の更新となりました。
 ということで、今年を振り返って、超個人的PC関連トピックを5つ+α挙げてみようかと。

1◆64bit OSへの乗り換え。

 今年一番のトピックはこれでしょう。
 ついにクライアントOSが64bitになって、メモリ4GBの壁を突破。久々の「余裕のあるメモリ空間」を満喫しております。

 ・・・の筈が、最近ではVMwareが何故かいつも動いているせいで、8GBが窮屈です、はい。
 4GBメモリモジュール、もう少し頑張って値段下がってくれないかな・・・。
 
2◆SeagateのダメHDD騒ぎで大迷惑。

 Win7が無ければコレが今年の断然トップ。
 いやぁエラい目に遭いましたよ、ホントに。
 あと、コレのせいで当方の管理下HDDが「原則Seagate」から「原則WD」に切り替わったということもあったりとかしました、はい。

3◆Intel帝國の侵攻。

 Core i7、X58、そして41110。
 ミッドレンジより上に製品が存在しないという、AMDのあまりの不甲斐なさのため思わず買ってしまった、10年ぶりのIntel CPUはBloomfieldでした、と。

 今となっては単発ベンチではLynnfieldの方が価格性能比は上・・・に見えるが、足回りを考えたら正直ライバルにはなり得ない、ですな。

4◆eSATAが海を越えた。

 個人購入モノのサポートで海外まで荷物を送ったのは初めてですよ。
 AsusのGlobal Supportとメールで相談したのも初めてですよ。

 まあ結果的にどう頑張っても動かないというオチがついたのは・・・ねぇ。
 ちなみにブツはIntel Orientedなユーザの手に渡っていきました、はい。

5◆はぢめてのSSD、XPモバイル。

 そして最後にはコレ。LOOX Uの衝動買いとSSD換装。
 現在も普通に使っていますし、普通にプチフリってますが、やはり「振動を気にしなくて良いモバイル」というのは「本来これが当たり前」だということをホントに思います、はい。

番外◆ツクモのすったもんだ。

 去年から引っ張られたネタだが、これはメモっておこうかと。
 何故かあまり言われていないが、ヤマダ傘下に入って仕入方法が変わった影響、販売戦略と品揃えに確実に出ていますよ。
 具体的に言うと、価格対抗戦略で値引きが増えた、エッヂな(ヘンテコな)品物が入らなくなった、メーカプロモーション陳列※が増えたということ。
 ヤマダ電機vsビックカメラvsヨドバシカメラの(一部)代理戦争が、ツクモvsソフマップvsヨドバシカメラで繰り広げられております。

 ※特定ジャンルで特定メーカの製品ばかりを圧倒的多数で陳列する手法。ヤマダの各店舗では定番な、メーカから販促費を搾り取(以下略。

 ◇

 ま、こんな感じですかね。
 それなりにイロイロとあった1年だと思います、はい。

 さて、それでは来年は・・・
 まあ、「来年の事を言うと鬼が笑う」ということで。

 それでは、よいお年を。

Share

Wow64のお約束。

 知り合いが何か悩んでいたらしいネタなので、取り敢えずメモ。

 アプリがVista以降のWindows上で動作する場合、UAC絡みもありファイルアクセスがシステム側によって強制的にリダイレクトされる状況がしばしば発生する。
 そこで気をつけないといけないのが、リダイレクト先やアクセス先が、各種条件によって複数に分かれるということ。これとか。

 ¥User¥ユーザ名¥AppData¥Local¥VirtualStore 以下
 ¥User¥ユーザ名¥AppData¥Local¥Roaming 以下

 まあ、これは32bit版でも64bit版でも共通だから良いとして。
 64bit版OS上で32bit版プログラムを動かす時は、レジストリアクセスがリダイレクトされることもお忘れなく。
 プログラム側で開く→実際のアクセス場所で、こんな風に。

 HKEY_LOCAL_MACHINE¥SOFTWARE
 →HKEY_LOCAL_MACHINE¥SOFTWARE¥WoW6432Node

 32bitモノは引っ込んでろとばかり一段下にまとめられてしまいます、えぇ。
 更に、システムフォルダについても64bit版には一部ハードリンクが存在するんですな。
 ハードリンク元 → ハードリンク先、と書くと。

 ¥Windows¥SysWOW64
 → ¥Windows¥System32

 要するに、SysWOW64内のファイルはSystem32 というPathでも見える、見えてしまうということ。

 ◇

 まぁこんなこと、かなりシステム側に近いプログラムを相手にする場面でしか役に立たない知識だし、そういう情報が必要な人なら大抵はとっくに常識だろうが。
 古いソフトでは時々あるんですよ、この辺りのリダイレクトが原因で動かないって話が。

 何しろOS側が2000~2003/XPと殆ど変わらないまま長い間続いてしまったこともあり、この辺りのリダイレクトの存在を全く考慮しないままPath等を決め打ちにしている、ソースの中で直書きしている、そんな「ダメプログラム」が未だに結構存在して、しかもあちこちで動いているようなんですよ、これが。

 折角下逸が「SDK的に正しいアクセスをしていれば自動的にリダイレクトされて、アプリ側はそのことを意識する必要もない」ように、色々と面倒な仕掛けを仕込んでいるのに、ねぇ。
 やれやれと言うか、何と言いますかね。

Share

Vista x64から続くWin7 x64のファイル共有周りのバグ。

 ネットワーク経由でファイルハンドルを短期間に大量に開け閉めしていると、いつの間にか巨大ファイルがコピー出来なくなる「ことがある」。
 具体的なエラー番号は0x800705AA。システムリソース不足ってヤツが出てエラーになります。

 これ、Vista x64の頃から言われているバグなのですが。
 無事?Windows 7 x64に引き継がれております。

 面倒なのは、この症状が一定しないんですよ。

 ・大きなファイルをいくつか扱っても症状は出にくい
 ・バックアップツール等で小さなファイルを短時間に大量に扱った後は症状が出易い
 ・共有先にローカルのファイルをコピー或いは操作されても症状は出にくい
 ・ローカルのファイルを共有先にコピーと症状が出易い
 ・再起動すれば確実に直る
 ・暫く放置するだけでも直る、但し「暫く」の時間は運任せ
 ・エラーが出た時、共有先のPCから同一ファイルを一度開くと、何故かエラーが直ることがある

 ・・・ん~。
 根本的にシステムリソースが足りないということではなく、内部のシステムリソース取得・解放のタイミングが間に合っていない、という風にしか見えませんな、この症状は。

 ちなみに他にも、IPv6スタックが暴走してブリッジアダプタが無限に増殖し、起動しなくなることがある、なんてかな~りとんでもないバグもWindows 7はVistaの頃から引き継いでいたりとか。

 まあ、所詮Vista SEですよね、というのが良く分かる話でした、はい。

Share