lstrcmpの"l"って何?

The Old New Thingの記事 What does the "l" in lstrcmp stand for?をてけとー訳。
(16ビット時代のことは知らないのでてけとー訳したものの意味が分からないところ多数。)
↓ここから

これをMichael Kaplanに聞いたら、きっと「lameの事だね」って言うと思う。
彼の記事にある L-関数対応一覧表はとってもいいね。
だけど、この疑問のポイントは彼のリストに載ってない関数にあるんだ。

lopen, lcreat, lread, lwrite, lclose, llseek

これらは次の"l"なし関数に対応してる。

open, creat, read, write, close, lseek

これを見るだけでよくある別の疑問も謎が解けるよね。
「なんでllseekはLが2つもあるの?」ってやつ。
最初のlがプリフィクスで、次のlはlseekで1つになってるんだ。

じゃあ、最初のlはなんだろう?
同じ名前のH-関数があることをご存知だろうか。

hread, hwrite

H-関数のhはHugeの事で、Hugeポインタを扱うことを意味していたんだ。
Hugeポインタってのは16ビット時代に64KB以上のメモリブロックにアクセスするためのポインタの事。
16:16ポインタを1バイトずつインクリメントしていくとしよう。
まずは下位の16ビットをインクリメントしていく。
そのまま続けていくと、0xFFFFの次はまた0に戻ってしまうから、どっかにキャリーを置かないといけない。
ポインタがHugeポインタの場合は通常 S:0xFFFF (S+__AHINCR):0x0000の次にくる。
ちなみに__AHINCRってのはWindowsカーネルがエクスポートしている値。
64KB以上のメモリを確保しようとすると、GlobalAlloc関数は__AHINCRを使ってセレクターをインクリメントしながら64KBごと割り当てを行うんだ。
さて、本題に戻ろう。
"l"プリフィクスはlongの事なんだ。
L-関数はfarポインタを扱うことができる。
これは16ビットWindowsプログラミングにおいて、メモリモデルに依存しないコーディングができるというメリットがある。
逆にstrcpyやreadといった標準関数ではメモリモデルの影響を受けてしまう。

(中略)

そんなこんなで、Windowsが内部で使用していた関数をエクスポートすることにしたんだ。
OK、lameの疑問に戻ろうか。
Michael Kaplanのリストを見ると lstrcmp と lstrcmpi は strcoll と strcolliに対応する関数ってことが分かるよね。
じゃぁ、なんでlstrcoll、lstrcolliというネーミングにしなかったんだろうか。
答えは簡単、lstrcollが作られた時代にはstrcoll がなかったのさ。
アポロ13を救出するのになんでスペースシャトルを使わなかったの?」って聞くようなもんだね。