おなまえ
Ｅメール　 表示 非表示
タイトル
メッセージ auto soft pre(図表、プログラム) ※折り返さずに改行を入れてね
> > > 2009年の #4640 の10＃さんの記事を引用すると > > > > とあるのですが、私も、その後のバージョンアップで変更されていたとばかり思って > > いました。ここで掲載されている、パッチを当てるアドレスはおそらく、その当時の > > VTDOSのバージョンに依存していると思うんですよね。 > > そうかもしれないですね。 > Windowsの更新が頻繁なのでコンパイラの仕様が変わっている可能性も考えられますよね。 > コンパイラを更新したら動かなくなった、という話も多いですし。 > > その関連で、MSDOS Player の問題も同根なのではないかという気がしてきました。 > > > MS-DOS Player for Win32-x64 謎WIPページ > http://takeda-toshiya.my.coocan.jp/msdos/ > > このページを読んでみたら、関連しそうな記事があったので引用します。 > > ------------------------------------------------------ > 2016/6/8 > COMMAND.COMでCOPYに失敗する問題、MORE.EXEでキーを受け付けない問題を修正しました。 > > MOREの方ですが、例えばTYPE (file) | MOREを実行すると、MORE.EXE上では、 > ファイルハンドル複製/多重化の果てに、ファイルハンドル0番にstderrが割り当てられいて、 > コンソール系のAPIが正しく動作しなくなっていたみたいです。 > ファイルハンドル0番がattyで入力なデバイスでない場合は、コンソール系のAPIではなく、 > _kbhit()や_getch()などの関数を使用するように修正しました。 > これらの関数だと、ファイルハンドルの状態によらず、キーボードを読んでくれるようです。 > > また、コンソール系のAPIで使用するハンドルは、起動時にGetStdHandle()で取得したものを > ずっと使いまわしていましたが、ファイルハンドル複製/多重化の影響を受けて、 > ハンドルが無効になってしまう場合があるようです。 > そのため、コンソール系のAPIを使うたびに、GetStdHandle()で取得するように修正しました。 > > ------------------------------------------------------ > > > MORE.EXEでキーを受け付けない問題を修正しました。 > > この EXE が16ビットかどうかはわからないですが > これって今回の問題と同じように思えます。 > この時修正済みだったのに、また同じ問題が出てきたとしたら > コンパイラの関数の仕様が変わってしまったのではと疑ってしまいます。 > > BIOSキーの取得も試してみたのですが、コントロールコードは一切使えないみたいで > Toolsのmore で "Q" キーで中断終了が出来たということは、文字は入力できるのかも。 > >
参照先
暗証キー (英数字で8文字以内)
プレビュー