ゲームシステムの場合、普通は同時に複数のインスタンスの起動を抑制したいものです。
その場合にはカーネルオブジェクトのMutexを使いましょう。
Mutexは普通複数スレッドの同期を取る為に使用しますが、名前つきのMutexはプロセスを
超えて共有されます。これを利用します。まず、
などとしてMutexが既に存在するかどうかを調べます。ここではNotDoubleStartSystemという名前のMutex
が既に作られていないかを調べています。ここで、戻り値はmutex変数に代入していますが、このmutex変数の
値がNULLでは無かった場合には既にその名前のMutexが存在しているので そのまま帰ります。ここで、この
mutexは閉じなくても構いません。オープンしたmutexのハンドルは既に存在する物ですので、そのmutexを
作ったスレッドが責任を持って開放してくれる事でしょう。
さて、mutexはNULLだった、つまり最初の起動だった場合にはそれ以上起動しないようにmutexを作成する
必要があります。それは
として行います。ここでもmutex変数は保存しておく必要があります。今度は自分でmutexを作成したので
これを開放する必要があるからです。WinMainの先頭でCreateした後、WinMainを終わる前に
とします。これでMutexオブジェクトは開放され、またプロセスを１から起動する事が出来るようになります。
最近はＨＤの容量も増え、圧縮の必要性は大分薄れてきたようにも思いますが、それでも
例えばＨＤにフルインストールしないオプションを用意し、ＣＤからデータを読みながらゲームを
進行させる場合には、データ圧縮してあった方が読みこみが高速になります。ＣＰＵも今は
早いから余程の圧縮方法で無ければ展開で待たされるよりＣＤ読みこみで待たされる可能性
の方が高いのです。で、展開の早い圧縮方法と言えばやはりランレングスに尽くのですが、
画像データでも無い限りランレングスで圧縮出来る可能性はかなり低いでしょう(^_^;。
また、画像データでも例えば16Bit画像を1Byte単位のランレングスで圧縮しようとしても
無駄な努力と言わざるを得ません。ランレングスで16Bit以上の画像を圧縮するならその画像
用のBit数に合わせるか、或いは例えば（通常のランレングスよりもかなり複雑だとは思いますが）
ＲＧＢ各色夫々別々にカウントするという方法が考えられます、つまりＲの何が何バイト連続、
Ｇの何が何バイト連続、というような感じで、Ｒの2が10バイト連続、Ｇの5が4バイト連続、Ｂの3が
７バイト連続、Ｇの3が6バイト連続、Ｂの8が12バイト連続、Ｒの．．．．といった感じのデータに
なるでしょう。各色の値が必要になったらデータを取りに行き、その取りに行った丁度その時に
その色のデータが来るようにデータを配置する訳です。これなら昔の２５６色画像のランレングス
と同程度の圧縮効果は見こめると思います。また、画像圧縮で良く用いられるのがＬＺ77/78
ですが、こいつらは特許関係が非常にごちゃごちゃしてて下手をすると特許に抵触してしまう為
私はちょっと恐くて商用ゲームでは余り使う気になれません(^_^;。（ハフマンも同じ位ごちゃごちゃ
してるけどね）でもLZHのアルゴリズムは、（これも特許関係ですったもんだがあったけど）
今の所一応大丈夫っぽいのでゲームのバグ修正時の配布ファイルに使ってます。
トッパンから「データ圧縮ハンドブック」という本が出ていまして、その本に付属のarという
圧縮プログラムがLH5で圧縮/解凍してくれるのですが、そのＣ言語ソースがついてまして、
そこから改造して行って独自の圧縮/解凍ルーチンを作る事が出来ます。
結構便利なのでお勧めです。