移動領域が大きくなればなるほどスクロール幅がアバウトになりますが、
スクロール上の１が画面全体のどのくらいに相当するかを換算して
処理していました。
この辺はスクロール幅が65536を超えなければ、１対１の対応にしておき、
超えたら１対２とかにして対応させれば何とかごまかせます。
まあ、微調整が必要なのでこの辺は組みながら調整するしかないですね。
いまだにWin16のときの仕様を引きずっているスクロールバーにも困り者ですが、
そういった方法をとるしかなさそうです。

ディスプレイの高さは 768 とか、大きくても 1024,ちょっと特殊でも2048程度ですよね。
普通のスクロールバーは１画面の収まるスクロール量しか使わないので、
65536もあれば、十分すぎる量なわけです。

あとはいっしょで、換算して使えばよいということですね。

MFC を使ってなくて WinXP の GDI に 16bit の制限があるということが良く判りません
スクロール範囲が 65535 を超えてどういう問題が出るのか示して下れませんか

適当な回答だったので（すみません）、きちんと調べてみました。

換算をしたくない場合
プラットフォームSDKの　GetScrollInfoで３２ビットデータ値が取得できます。
GetScrollInfoの解説を見ましょう。

GetScrollInfo使って解決しました☆
皆さん、ありがとうございました。

>普通のスクロールバーは１画面の収まるスクロール量しか使わないので、
すごいバカでかいデータをGUI表示するツールを作っていて、
部分的に拡大とかして詳細を見たりしなくてはいけないので、
そーなるとデータの範囲が65536なんて軽く超えてしまうんです。
Wordでも小説とかだったらページ数を考えると、
縦スクロール量は１画面なんて相手にならないと思いますが…。

>16bit の制限があるということが良く判りません
現在位置をWPARAMの上位ビットから得ていたからです。

もし2^32=4294967296を超えるようなことがあれば（無いとは思いますが(笑
換算することにします。←これ、良い方法ですね。