またPSO2は･･･

･･･ヤらかしか。


DirectX9使ってる時点で 既に難儀なわけだが、アレだけ複雑になったプログラムを
今時32bitビルドでしか提供していないのだ、お察しである。


と云うか、

未だに 64bitビルドの必要性が無い とかブラフるバカが多くて困る。

確かにWindows10アプリケーションを プロセッサが32bitの低スペタブレット向けまで視野に入れ
全プラットフォーム対応ビルドするともなれば仕方がない面はあるだろう。

だが、今時タブレットどころか ヘタすればスマホのプロセッサも64bitだ、32bitでアプリケーションをビルドする理由がない。

そもそも "32bitでいい" なんて云ってるヤツは 短時間しかアプリケーションを稼動させない連中だ。

しかし現実には、一寸複雑なプログラムとなっているだけで、
小一時間以上連続稼動させる場合、変数で扱えるビット数の影響が顕著に出始める。


プログラム自体と云うより、総じて時間の値を扱えなくなるのだ。

そもそもコンピュータにとっての時間とは、

人間のような 時分秒 と云う識別構造にはなっていない、1/1000秒毎に 1 加算し続ける仕組みだ。 

たったの1分で 60000加算されるコトになる。

値の見た目は異なるが、"シリアル値" と呼ばれているモノが ソレに該当する。
1日につき 1 加算されるのがシリアル値だが、実は小数点以下の値があり、
それが 23:59:59.999(86399999)の値を含むものとなっている。

つまりシリアル値の 1 は、その小数点以下に 86400000 を含んでいるコトになる。
ただ、単にシリアル値で動作しているのなら、意外に支障はなかったのだ。
問題は その扱われ方、Windows含むOS や アプリケーション 毎に異なっている事が問題の要因となっている。

ハードとしてのコンピューターは

前述の通り シリアル値と同様の構造を持つシステム時刻で稼動している。
そして その加算の開始は Windowsだと 1900年1月1日0時0分0秒000を基点としている。

昔は確か 1980年1月1日が基点だったと思ったんだが･･･
システム時刻 - [Wikipedia] 記憶違いではなかったようだ。

だがソレとは別に OS や 各アプリケーション を起動した時から開始される時間のカウンターがあり、
コッチを扱う場合の変数型の指定で問題を起こすのだ。

プログラムで値を扱う為に用いる 変数 は、使用開始時に型を宣言する。

その昔なら 時間を代入したければ Long型を指定して用いたものだ。

しかし、今現在のように長い時間アプリケーションを連続稼動させるシーンが増えたことで、
Long型では 使い方を誤ると時間の値すら収まらなくなってしまうケースも発生する。

32bitビルドでは Long型に割り当てられるデータ長は 本来なら 4byte(32bit)でしかないが、

64bitビルドを設定すると、Long型に 8byte(64bit) を 割り当てる開発環境も少なくない。
LP64準拠であれば そのように動作すると考えていい。

ただ、Microsoft VisualStudio は、ソレに準じていない。

64bitビルド時でも、Long型は あくまで4byte(32bit長)扱いとなる。

代替として 64bit長の time_t と云う日時を扱う専用の型などが実装されている。

その為 時間データ処理に Long型は必要なくなっているのも事実としてある。
もし仮に64bit長のデータを扱いたければ、元々LongLong型を用いていた点も踏まえると、
データ型の互換性担保の為、明示的に切り分けた。と認識すべきだろう。

ツマり、同じLong型を指定していた場合でさえ、
使用している開発環境のビルド時に どう扱われるか で 結果が異なると云う状況だ。

利用されている開発環境で その点 どのように作用するのか、確認しておく必要があるのは間違いがない。


当然 システムとしてはソレに対応するよう動作するのだが、該当するアプリケーションでのその値の扱い方によっては、
データの構造起因でソレが適わず、アプリケーションのクラッシュや OS全体の不安定要因となってしまう。

もしそのような症状が顕著なアプリケーションであるとしたら、恐らく 何れかのルーチンで
1/1000秒毎に 小数点以下ではない 1を遥かに超える値を加算する処理が含まれているのだと推察出来る。

蛇足となるが･･･

動画再生やゲームなら3hくらいはそう長い時間でもないだろう、その時点で 10800000ms
業務なら優良企業と仮定して8hは連続稼動しているだろうから 28800000ms ブラック企業なら まぁ更に･･･


時間を扱う部分が

システムの安定性に大きく影響するのは、Windows95/98時代にあった問題でも判るかと思う。
そうした問題に関しては ココが ひと通り纏めてあり、参考になるだろう。

この問題は今は 然ももう無い様に云われているが、複雑なプログラムになればなる程 事情が変わってくる。
トクに プログラム内部で累積時間を扱う場合には、充分な配慮が必要となるのだ。

また、Windows95/98まではアプリケーションのデータ型は16bitが主流だった時期があり、
雑な造りのアプリケーションでは 40分チョイで同じ状態に陥っていたのも著名なトコロだ。

専門的な内容を列挙するだけなら 他に文献も多いだろうから省くが、

敢えて判り易く云うなら、

IPv4だとアドレスが枯渇してしまったが、IPv6だと全然余裕がある。
のと理屈は似ている。

時間を扱うだけ のコトを取り上げても、32bitビルドでは 相応に大きな問題となる可能性があるのは理解頂けたと思いたい。

■ 結論として、

少なくとも、オープンソースアプリケーション群では、64/32bit別にビルドを行い、
利用者の環境に合わせた選択が可能な様、配慮するのが当たり前となっている。

･･･にも関わらず、未だ無神経に 32bitビルドのみを提供し続ける 日本国内の大手ベンダ諸兄、
そろそろ そう云う良いトコロも模倣する癖をつけたほうが 身の為だと思うがね?