73736
SusieプラグインAPIには、下記の記述があります。(x86の頃なのでポインターをDWORD型に格納しても欠落しない前提)

[http://www2f.biglobe.ne.jp/~kana/spi_api/spi_issupported.html](http://www2f.biglobe.ne.jp/%7Ekana/spi_api/spi_issupported.html)

> DWORD dw  
>  上位ワードが0 ファイルハンドル  
>  上位ワードが非0 ファイル先頭部(2Kbyte以上)を読み込んだバッファへのポインタ。
> ファイルサイズが2Kbyte以下の場合もバッファは2Kbyte確保し、余分は0で埋めること。

このようなことが行えるのは、

  * `0x00000000`から`0x0000FFFF`にヒープやスタックが割り当てられない
  * ハンドル(`HANDLE`)の値が`0x00000000`から`0x0000FFFF`の範囲内となる

という仕様が必要だと思うのですが、マイクロソフトのサイトでは見つけることはできませんでした。  
特にハンドルの値に関して、どこかに規定されている仕様なのでしょうか？
CC BY-SA 4.0
2021-01-31T14:49:25.830
73723
2021-02-01T11:01:58.657
9113
question
windows winapi
ハンドルの値が0x00000000から0x0000FFFFとなる仕様はどこで定められている？
紹介されている資料は、その目次へ戻ると、「LastUpdate:
1998/11/22(Sun)」とあるので、その時点では32bitウィンドウズしか無かったために正しい情報だったのでしょう。

* * *

ハンドルに関しては、おそらくこの記事およびそこから紹介される資料が参考になるでしょう。  
ただし直接記述されているのではなく傍証ですね。(何処かにはあるかもしれませんが)

[What is the number of open files limits?](https://superuser.com/q/1356320)

> Theoretically in 64-bit Windows the maximum number of handles that a process
> can open is 2^32, because handles have 32 significant bits. However in
> reality it has been limited to 16 777 216 (2^24) per process. On 32-bit
> Windows the limit is likely 2^16

[Why can't a 64 bit OS run a 16 bit
application?](https://superuser.com/q/140953)

> In Windows, programs pass around "handles" to the OS and vice-versa (which
> are numbers that the OS uses to uniquely identify a particular resource,
> such as a window).
>
> To support 16-bit programs, 32-bit Windows only generates a handles that
> have 16 significant bits -- the 16 upper bits are ignored by the OS (even
> though programs are not to be taking advantage of this fact). So no program
> can interact with more than 2^16 objects, which is actually rather low.
>
> However, in order to improve this, 64-bit Windows increased the number of
> significant bits in a handle to 32. But now that means that handles cannot
> be passed to 16-bit programs without loss of information. So 16-bit programs
> cannot run on 64-bit Windows.

上記には、16bitアプリケーションを動かす互換性のために、32bitウィンドウズではハンドルの下位16bitだけを使っていた。  
しかし64bitウィンドウズではそれをやめて32bitすべてを使うようになった。と書かれていますね。

傍証としてはこの記事の最後の部分でしょうか。  
[Running 32-bit Applications](https://docs.microsoft.com/en-
us/windows/win32/winprog64/running-32-bit-applications?redirectedfrom=MSDN)

> Note that 64-bit Windows does not support running 16-bit Windows-based
> applications. The primary reason is that handles have 32 significant bits on
> 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit
> applications without loss of data. Attempts to launch 16-bit applications
> fail with the following error: ERROR_BAD_EXE_FORMAT.

64bitウィンドウズではハンドルは32bitが有効なので16bitウィンドウズベースのアプリケーションは動作出来ない。と書かれています。  
逆に言えば16bitウィンドウズアプリケーションを動作させることの出来る32bitウィンドウズは16bitウィンドウズと互換性のあるbit数の範囲でしかハンドルを使っていない。とも読めるでしょう。

それから質問の紹介リンク先に書いてある `dwで渡されるファイルハンドルとは、Win32 APIの_lopenやCreateFileが返す値の事です。`
のうち、`_lopen`については16-bit Windowsと互換のために用意されています。と書いてありましたね。  
[_lopen function (winbase.h)](https://docs.microsoft.com/en-
us/windows/win32/api/winbase/nf-winbase-_lopen)

> The _lopen function opens an existing file and sets the file pointer to the
> beginning of the file. This function is provided for compatibility with
> 16-bit versions of Windows. Win32-based applications should use the
> CreateFile function.

* * *

日本語での傍証はこちら。

[第2回 Win32アプリケーションを実行するWOW64
(1/2)](https://www.atmarkit.co.jp/ait/articles/1007/01/news131.html)

> **WOW64の制限**  
>  16bitアプリケーション（Win16アプリケーション）を呼び出すことはできない。Win32やWin64
> APIで利用されるハンドル情報は16bit幅には格納できないので、16bitアプリケーションに渡したり、結果を受け取ったりできない。そのため、WOW64ではWin16アプリケーションを実行できない。

[第3回 アプリケーションの互換性
(1/3)](https://www.atmarkit.co.jp/ait/articles/1007/29/news109.html)

> **Win16プログラムを起動する場合**  
>
> だが前回述べたように、API呼び出しで使われるハンドルなどの情報を16bit幅に丸めて処理する適切な方法がないなどの理由により、Win16アプリケーションも64bit
> Windowsではサポートされていない。

* * *

他に最初の記事から紹介されているこの記事とか、  
[Pushing the Limits of Windows:
Handles](https://techcommunity.microsoft.com/t5/windows-blog-archive/pushing-
the-limits-of-windows-handles/ba-p/723848)

> **Maximum Number of Handles**  
>  In one of the rare cases where Windows sets a hard-coded upper limit on a
> resource, the Executive defines 16,777,216 (16*1024*1024) as the maximum
> number of handles a process can allocate.

こちらの記事で、具体的な数字はあまり記述されていませんが、Win16/Win32/WinNTで色々と違った制御が行われていると書いてあります。  
[Give Me a Handle, and I'll Show You an Object](https://docs.microsoft.com/en-
us/previous-versions/ms810501\(v=msdn.10\))

他にもこんな記事があります。  
[What is the range of a Windows HANDLE on a 64 bits
application?](https://stackoverflow.com/q/18266626/9014308)  
[32-bit and 64-bit Interoperability](https://docs.microsoft.com/en-
us/windows/win32/winauto/32-bit-and-64-bit-
interoperability?redirectedfrom=MSDN)  
[Interprocess Communication Between 32-bit and 64-bit
Applications](https://docs.microsoft.com/en-
us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN)
CC BY-SA 4.0
2021-01-31T17:06:25.107
73726
2021-01-31T18:02:09.990
2021-01-31T18:02:09.990
26370
26370
73723
answer
疑問の通りです。ファイルハンドルが`0x0000FFFF`以下であるという保証はありません。

既に指摘のある通り、SusieプラグインAPIは16bitコードから移植されたものです。16bit時代であればファイルハンドルも16bitなため`0x0000`～`0xFFFF`でした。32bitコードではファイルハンドルも32bitに拡張されているため、ファイルオープンを繰り返せば`0x0000FFFF`を超えます。

試しに次の無限ループを回したら普通に超えました。

```

    for (int i = 0;; i++) {
        auto f = _lopen("Text.txt", OF_READ);
        printf("% 8d: %08X\n", i, f);
    }
    
```
CC BY-SA 4.0
2021-02-01T11:01:58.657
73736
2021-02-01T11:01:58.657
4236
73723
answer