「Visual Basic 6が未だに生き残っている理由」記事へのコメント

金が無い

[Anonymous Coward]

VB6で作った物を、ほぼそのまま.NETに移行するだけでも、安くない金がかかります。
かといって作った物を廃棄するのも大変です。業務プロセスを変更しないといけないですし。
お金があればリプレースしてくれますけど、お客さんも無い袖は振れません。

結局騙し騙し使うんですよ。
ウチも未だに、自分たちが作ったVB6のシステムの細かい変更／修正をしてます。

XPが入手不可になった時に多かった案件は、「VB6で作った○○を、Windows7で動くようにする修正」でした。
ほぼ何もしないで動いたので、ぼろ儲けでしたけど。

でも期限は迫ってる？

[Rodin (28411)]

和暦の表示をVBのFormat関数に依存している業務システムが多数あります。
システム側の設定でいつでも西暦に切替可能、または元号マスタの追加で新元号に
即日対応が可能、なんてシステムはあまり見たことがありません。
このままの状態で、もし近年中に改元を迎えたら、大混乱は必至です。

それでもMicrosoftなら・・・きっとなんとかしてくれる・・・えっ、ダメ？

以下、予想される展開。
「だったら、今のシステムに安価でCSV出力機能をつけてよ」
「日付だけ西暦に変えてさ。後はExcelで加工すれば提出書類はバッチリだ」
「画面の日付が平成のまま？　いいよ、平成99年末までは使えるんだろ？」

--
匠気だけでは商機なく、正気なだけでは勝機なし。

Re:でも期限は迫ってる？

[Egtra (38265)]

サポートするということは、（VB6ランタイム含め）新しい元号への対応も含まれるだろうと思います。

Format関数はどういう実装なのでしょうかね。oleaut32.dllのVarFormat関数 [microsoft.com]をほぼそのまま呼んでいるだけなら、VB6ランタイムの修正なしで対応できそうな気がします。

＃むしろ、改元に当たっての焦点は、延長サポートフェーズに入っている（あるいはそれすら終わっているかもしれない）XPやVistaへのアップデートが出るか否かだと思います。