[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  VTDOS v1.22 置換でテンポラリファイルエラー - めざら 10/01/26-00:23 No.4917
 ┣ VTDOS v1.22がClpPst.defで落ちます - konno 10/01/26-00:59 No.4919
 ┃┃┣ Re: VTDOS v1.22がClpPst.defで落ちます - 文太 10/01/26-01:16 No.4921
 ┃┃┣ 当方では VTDOS v1.22でClpPst連続使用OKです - めざら 10/01/26-07:46 No.4922
 ┃┃┗ Re: 当方では VTDOS v1.22でClpPst連続使用OKです - konno 10/01/27-00:47 No.4926
 ┃┃┃ ┗ pagefile & memory - 文太 10/01/27-11:45 No.4931
 ┃ ┗ Re: VTDOS v1.22がClpPst.defで落ちます - 10# 10/01/26-19:49 No.4924
 ┃ ┗ Re^2: VTDOS v1.22がClpPst.defで落ちます - konno 10/01/27-01:01 No.4927
 ┃ ┃ ┗ Re^3: VTDOS v1.22がClpPst.defで落ちます - 文太 10/01/27-01:10 No.4928
 ┃ ┃ ┗ Re^4: VTDOS v1.22がClpPst.defで落ちます - konno 10/01/27-01:20 No.4929
 ┃ ┃  ┣ Re^5: VTDOS v1.22がClpPst.defで落ちます - 文太 10/01/27-11:40 No.4930
 ┃ ┃  ┃ ┗ Re^6: VTDOS v1.22がClpPst.defで落ちます - konno 10/01/28-01:37 No.4934
 ┃ ┃  ┃ ┗ pifは何をしてる? - 文太 10/01/28-23:46 No.4935
 ┃ ┃  ┃ ┃ ┗ Re: pifは何をしてる? - konno 10/01/31-02:40 No.4939
 ┃ ┃  ┗ Re^5: VTDOS v1.22がClpPst.defで落ちます - 10# 10/01/27-23:00 No.4932
 ┃ ┃   ┗ PIFの亡霊? - konno 10/01/28-01:24 No.4933
 ┣ VTDOS v1.22 出ました - 文太 10/01/26-01:11 No.4920
 ┣ Re: VTDOS v1.22 置換でテンポラリファイルエラー - konno 10/02/01-00:02 No.4940
 ┃ ┗ Re^2: VTDOS v1.22 置換でテンポラリファイルエラー - 文太 10/02/01-01:51 No.4945
 ┃ ┗ Re^3: VTDOS v1.22 置換でテンポラリファイルエラー - としき 10/02/01-10:00 No.4947
 ┗ VTDOS v1.22 でファイルオープンエラー? - めざら 10/02/02-23:50 No.4954
  ┗ VTDOS v1.22 で分割画面で異常 - konno 10/02/05-01:01 No.4962
   ┣ Re: VTDOS v1.22 で分割画面で異常 - 文太 10/02/05-01:45 No.4964
   ┗ Re: VTDOS v1.22 で分割画面で異常 - 10# 10/02/05-23:09 No.4967
    ┗ Re^2: VTDOS v1.22 で分割画面で異常 - konno 10/02/07-00:09 No.4979
     ┗ Re^3: VTDOS v1.22 で分割画面で異常 - 10# 10/02/09-01:10 No.4993
      ┗ Re^4: VTDOS v1.22 で分割画面で異常 - konno 10/02/09-01:57 No.4994
       ┣ Re^5: VTDOS v1.22 で分割画面で異常 - 文太 10/02/10-00:05 No.4996
       ┃ ┗ Re^6: VTDOS v1.22 で分割画面で異常 - konno 10/02/10-01:13 No.5000
       ┗ Re^5: VTDOS v1.22 で分割画面で異常 - 10# 10/02/10-00:59 No.4999
        ┣ Re^6: VTDOS v1.22 で分割画面で異常 - konno 10/02/10-01:48 No.5001
        ┃ ┗ Re^7: VTDOS v1.22 で分割画面で異常 - konno 10/02/12-02:05 No.5008
        ┗ Re^6: VTDOS v1.22 で分割画面で異常 - としき 10/02/13-00:30 No.5010
         ┣ Re^7: VTDOS v1.22 で分割画面で異常 - 10# 10/02/13-20:13 No.5011
         ┃┃┣ Re^8: VTDOS v1.22 で分割画面で異常 - konno 10/02/13-21:55 No.5012
         ┃┃┗ Re^9: VTDOS v1.22 で分割画面で異常 - としき 10/02/14-11:37 No.5014
         ┃┃┣ Re^8: VTDOS v1.22 で分割画面で異常 - としき 10/02/13-22:35 No.5013
         ┃┃┗ Re^9: VTDOS v1.22 で分割画面で異常 - 文太 10/02/14-12:05 No.5015
         ┃ ┗ Re^8: VTDOS v1.22 で分割画面で異常 - 10# 10/02/22-23:34 No.5030
         ┃ ┣ Re^9: VTDOS v1.22 で分割画面で異常 - konno 10/02/23-00:52 No.5033
         ┃ ┗ DR-DOS と freedos の 4Ah 周り - - あじゃ - 10/03/02-15:18 No.5058
         ┃  ┗ Re: DR-DOS と freedos の 4Ah 周り - としき 10/03/02-21:52 No.5062
         ┃   ┣ Re^2: DR-DOS と freedos の 4Ah 周り - konno 10/03/02-23:28 No.5063
         ┃   ┃ ┗ Re^3: DR-DOS と freedos の 4Ah 周り - としき 10/03/06-15:28 No.5082
         ┃   ┃ ┣ Re^4: DR-DOS と freedos の 4Ah 周り - konno 10/03/07-00:01 No.5083
         ┃   ┃ ┃ ┗ Re^5: DR-DOS と freedos の 4Ah 周り - としき 10/03/07-16:49 No.5099
         ┃   ┃ ┗ Re^4: DR-DOS と freedos の 4Ah 周り - 文太 10/03/07-14:28 No.5097
         ┃   ┃  ┗ Re^5: DR-DOS と freedos の 4Ah 周り - としき 10/03/07-16:31 No.5098
         ┃   ┃   ┗ Re^6: DR-DOS と freedos の 4Ah 周り - 文太 10/03/07-21:25 No.5100
         ┃   ┗ Re^2: DR-DOS と freedos の 4Ah 周り - - あじゃ - 10/03/06-13:40 No.5080
         ┗ Re^7: VTDOS v1.22 で分割画面で異常 - 文太 10/02/14-12:13 No.5016
          ┗ ファンクションコールのエラーコード - konno 10/02/16-00:07 No.5018
           ┗ Re: ファンクションコールのエラーコード - としき 10/02/16-06:25 No.5020

(4917) 4917VTDOS v1.22 置換でテンポラリファイルエラー  投稿者:めざら   2010/01/26(火) 00:23
参照先:http://homepage3.nifty.com/mezala/
   コメント数 4

 環境は,Win XP pro + Shell=PC-DOS6.3 です。
 350KBほどの,そこそこのサイズのファイルのほぼ全部をブロック指定し,
結構文字数の増える置換を行って,常時テンポラリファイルエラーが発生しました。
自作のタブ区切りテキストをHTMLの表組にするマクロでの処理です。
所期の動作の場合,最終的にファイルサイズは500KB超に増加します。

置換手順は次のとおりです。(トレースモードで確認)
(1) #56 "\x ^\(.\)" #m "<tr><td>\1" #m "y"
(2) #56 "$(9)" #m "</td><td>" #m "y" ;;$(9)はタブの文字列中での表現
(3) #56 "\n" #m "</td></tr>\n" #m "y"

(1)〜(2)は特に問題がなく処理が行われ,(3)で処理しきれずにマクロは停止します。
マクロの停止後に,#^ でテキストの先頭に移動すると,テンポラリファイルエラーで,
先頭から数百バイト失われているのが確認できます。
なお,マクロでの実行でなく,手作業で同様の置換を行ったところ,
(1)は問題なく,(2)の段階でテンポラリファイルエラーが出ました。

実は,v1.22 の導入直後の最初の実行では問題が生じませんでした。
2回目以降の実行でエラーになるため,マクロ側を疑ったのですが,
その後は常時エラーになり,無手順でもエラーを確認しました。
エラーの都度,vtdos を再起動しています。

また,v1.22 だけの問題ではないようで,以前の版でもいくつか試したところ,
同様のエラーが再現されることを確認しました。

      - No.4917 -    このTreeへ           [リストへもどる] soft

(4917) 4919VTDOS v1.22がClpPst.defで落ちます  投稿者:konno   2010/01/26(火) 00:59
    4917 番 めざら さんへのコメント    コメント数 3

このツリーにぶら下げてしまいますが

VTDOS v1.22でVZでファイルを開いて、ClpPst.defを使用するとVTDOSが落ちます。
コピーとか貼り付けしたあと、カーソルを動かすといきなり落ちます。
「問題が発生したため終了します。」というダイアログは出ます。
エラーログには何も記録されてないです。

Ver1.21以前では問題ないです。

ダイアログの内容です。
ModName:ntdll.dll
ModVer:5.1.2600.5755
Offset:0001b21a

      - No.4919 -    このTreeへ    コメント元:4917 へ [リストへもどる] soft

(4917) 4921Re: VTDOS v1.22がClpPst.defで落ちます  投稿者:文太   2010/01/26(火) 01:16
    4919 番 konno さんへのコメント

>VTDOS v1.22でVZでファイルを開いて、ClpPst.defを使用するとVTDOSが落ちます。

 ああ、やっぱり、何かあるのですか。僕のところでも「送信できない」ことが
あり、 古いファンクションコール絡みで、WinAPI のほうに何か影響がでちゃっ
たのかな、と思ったのです。
 落ちるところまで経験していませんが、何か不具合があった感触がこちらでもあ
りました。

      - No.4921 -    このTreeへ    コメント元:4919 へ [リストへもどる] soft

(4917) 4922当方では VTDOS v1.22でClpPst連続使用OKです  投稿者:めざら   2010/01/26(火) 07:46
参照先:http://homepage3.nifty.com/mezala/
    4919 番 konno さんへのコメント    コメント数 1

> コピーとか貼り付けしたあと、カーソルを動かすといきなり落ちます。

 うちでは特に問題は発生していないですね。
 軟体補完計画の元データをいじっているのですが,LXで編集していた64KB超のファイルも含む8個の小分けファイルをひとつにする作業にクリップボードを使ってみましたが,Clppst.exe(v06d)+Clppst.def(v05c) で問題は発生しませんでした。

> Ver1.21以前では問題ないです。

 うーむ。前バージョンで再現性がないとなると,どこに問題があるのでしょうね。

 ntdll.dll ってネットで調べてみると,山のように不具合報告があって,いずれも解決していないような雰囲気がぷんぷんしてます。ちょっとハマっちゃうかもしれませんね。

      - No.4922 -    このTreeへ    コメント元:4919 へ [リストへもどる] soft

(4917) 4926Re: 当方では VTDOS v1.22でClpPst連続使用OKです  投稿者:konno   2010/01/27(水) 00:47
    4922 番 めざら さんへのコメント    コメント数 1

>  うちでは特に問題は発生していないですね。

職場のPCでは問題が出ませんでした。XP Proです。
自宅のXP Home の環境がおかしくなっているのかなぁ。

>  ntdll.dll ってネットで調べてみると,山のように不具合報告があって,いずれも解決していないような雰囲気がぷんぷんしてます。ちょっとハマっちゃうかもしれませんね。

これはむちゃくちゃあやしいですね。ぐぐった中にこんなページが。

「情報科学屋さんを目指す人のメモ」
http://did2.blog64.fc2.com/blog-entry-125.html

これを見て、ページファイルを入れなおしてみたところ、PCの動作が見違えるように
サクサクになりました。特に最近ブラウザのページ読み込みが異常に遅くなっていた
のが解消されたようです。これが原因だったのか〜?

と思ったけど、VTDOSの状態は変わらないですね。残念。(++;

      - No.4926 -    このTreeへ    コメント元:4922 へ [リストへもどる] soft

(4917) 4931pagefile & memory  投稿者:文太   2010/01/27(水) 11:45
    4926 番 konno さんへのコメント

「Windows 7 64bitに行って、たくさん(といっても8GBで十分)メモリを積んでみたい」
 くらくらするような話ですねぇ。

      - No.4931 -    このTreeへ    コメント元:4926 へ [リストへもどる] soft

(4917) 4924Re: VTDOS v1.22がClpPst.defで落ちます  投稿者:10#   2010/01/26(火) 19:49
参照先:http://vtdos.web.fc2.com
    4919 番 konno さんへのコメント    コメント数 1

clppstは僕の環境では若干挙動に違和感がありましたが、
クラッシュには至りませんでした。
1.21と1.22はほとんど違いがないので、
1.22固有の問題では無いと思われます。
clppst.def以外の部分が関係しているのではないか?とも思いますが、
現状チャイルドプロセスの起動に不具合が見つかっていますので、
その影響かも知れません。

      - No.4924 -    このTreeへ    コメント元:4919 へ [リストへもどる] soft

(4917) 4927Re^2: VTDOS v1.22がClpPst.defで落ちます  投稿者:konno   2010/01/27(水) 01:01
    4924 番 10# さんへのコメント    コメント数 1

> clppstは僕の環境では若干挙動に違和感がありましたが、
> クラッシュには至りませんでした。

そういえば、zcopy 互換の32ビットコンソールアプリのzcpy32.exeも最近
挙動が不安定になったようでした。32ビットコンソールアプリ関連で問題が
出ているような気がします。

> 現状チャイルドプロセスの起動に不具合が見つかっていますので、
> その影響かも知れません。

そうなんですか。そういえば、USECMD=1 にしたら、VER コマンドでVTDOSが
落ちました。やっぱり1.22だけ不安定で、1.21では問題ないようです。
うちの環境に問題があるのかなぁ。

VER でのエラーログです。
2010-01-27 00:31:08 COMMAND(10C6) 1793:D7D3 '致命的エラー: アクセス違反 0x00000031 0x7C95B21A'
      - No.4927 -    このTreeへ    コメント元:4924 へ [リストへもどる] soft

(4917) 4928Re^3: VTDOS v1.22がClpPst.defで落ちます  投稿者:文太   2010/01/27(水) 01:10
    4927 番 konno さんへのコメント    コメント数 1

VTDOS|C:\VT>ver			;落ちないようです。
Microsoft Windows XP [Version 5.1.2600]

VTDOS|C:\VT>zcpy32		;やっぱ持ってなかったか
Bad command or file name

      - No.4928 -    このTreeへ    コメント元:4927 へ [リストへもどる] pre

(4917) 4929Re^4: VTDOS v1.22がClpPst.defで落ちます  投稿者:konno   2010/01/27(水) 01:20
    4928 番 文太 さんへのコメント    コメント数 2

> VTDOS|C:\VT>ver			;落ちないようです。
> Microsoft Windows XP [Version 5.1.2600]

うちも、1.21ではそういう表示になるんですけどねぇ。(++;

> VTDOS|C:\VT>zcpy32		;やっぱ持ってなかったか
> Bad command or file name

あのう、RCP32 は問題ないですか。VTD_NRDR.CFG とか、VTD_CMD.CFGに登録する
必要があるのかどうか、このへんがよくわからないもので。

      - No.4929 -    このTreeへ    コメント元:4928 へ [リストへもどる] pre

(4917) 4930Re^5: VTDOS v1.22がClpPst.defで落ちます  投稿者:文太   2010/01/27(水) 11:40
    4929 番 konno さんへのコメント    コメント数 1

 子プロセス全般という感触ではないような…。

k07t メモリに常駐しました.(-zで解放)
VTDOS|C:\VT>rcp32 c:\aaa.txt c:\tmp
Reading dir(s) .....
C:\ --> C:\TMP
  AAA.txt
       1 File(s) found
       1 File(s) copied


 以下は行けるときもあるのです。

VTDOS|C:\VT>C:\DEF\CLPPST.EXE /R C:\DEF\CLPPST.TMP


 こちらはデフォルトのままで、とりわけ触ってないようです。

VTDOS|C:\VT>type vtd_nrdr.cfg
cmd.exe
cat.exe
vtdos.exe
telnet.exe
ci.exe
co.exe

VTDOS|C:\VT>type vtd_cmd.cfg

telnet.exe

* msdos.exe

mg.exe
p2enc.exe
lcc.exe


 うーん、konnoさんのレポートをみてると、どこに原因があるのかぜんぜん
分からない感じですねぇ…。マシンやdef環境とかではないのじゃないかなぁ、
とあてずっぽですが。

      - No.4930 -    このTreeへ    コメント元:4929 へ [リストへもどる] pre

(4917) 4934Re^6: VTDOS v1.22がClpPst.defで落ちます  投稿者:konno   2010/01/28(木) 01:37
    4930 番 文太 さんへのコメント    コメント数 1

> マシンやdef環境とかではないのじゃないかなぁ、

まさに、その通りでした。やり方が悪いのか、わけがわからないような原因でした。
仕切り直しです。m(__)m

      - No.4934 -    このTreeへ    コメント元:4930 へ [リストへもどる] soft

(4917) 4935pifは何をしてる?  投稿者:文太   2010/01/28(木) 23:46
    4934 番 konno さんへのコメント    コメント数 1

konnoさん(ちょっとまたぎますが)

 こういうことというのはあるものなので、とりあえず解決したら忘れてしまう
というのが一番ですが(僕は覚えてても仕方のないタコミスの常連)、ちょっと
不思議なので、メモ書きを。

>これを見て、もしやと思って確認したら、作成日が 1/17になってました。あれぇ?
 ってことは、exeがちゃんとver upされてなかったのは間違いないのでしょうね。

 ですが、

>そうか、これって、古いVerに上書きしたからか。・・・
 僕はいつもそうしてます…。

>まさかと思いながら、上書きしてないVTDOS.EXEからショートカットを作り直して
>起動してみたら、問題なく動いてしまいました。(++;
 はい、ショートカットも更新していません。
 デスクトップの「VT へのショートカット」(c:\vt\ フォルダ行き)でそのフ
ォルダを開けて、VTDOS.EXE と VTDOS.TXT だけ更新して(旧版は、VTDOS.121
とかするときもあるけど)、今までうまくいっていたのですが…。
 起動するときはもちろん、一度も更新されたことのない「VTDOS.EXEへのショート
カット」@デスクトップからです。VTDOS.CFGも試したいオプションがなければ、
そのまま−−別窓のVTDOSなしVzから、VTDOS.CFGを編集してから起動することも
あるけど。
 (うむ、.pifって何してんでしょうね。リンク先のファイル名が同じなら互換性
あり、と読んでいるのですが…)

>もしかして、上書きは駄目なんでしょうか。
 ってことはないのじゃないかなぁ。

 何かどっかで手動操作ミスがあったのではないか、と想像しております。

      - No.4935 -    このTreeへ    コメント元:4934 へ [リストへもどる] soft

(4917) 4939Re: pifは何をしてる?  投稿者:konno   2010/01/31(日) 02:40
    4935 番 文太 さんへのコメント

> >これを見て、もしやと思って確認したら、作成日が 1/17になってました。あれぇ?
>  ってことは、exeがちゃんとver upされてなかったのは間違いないのでしょうね。

いや、XPとかNT系ではファイルが作成された日が作成日になるということで、上書き
コピーしてもこの日付は変わらないのだと思います。なので、exeはちゃんとver up
されていたと思っています。

> >そうか、これって、古いVerに上書きしたからか。・・・
>  僕はいつもそうしてます…。

うう、ということは、普通は問題無いということですよね。やはりうちの環境が
何かおかしいところがあるのかもしれません。裏口が開いているのかも。(++;

      - No.4939 -    このTreeへ    コメント元:4935 へ [リストへもどる] soft

(4917) 4932Re^5: VTDOS v1.22がClpPst.defで落ちます  投稿者:10#   2010/01/27(水) 23:00
参照先:http://vtdos.web.fc2.com
    4929 番 konno さんへのコメント    コメント数 1

一応…

ElleFileInfo 2.46 [2010/01/27 22:59:26]


ファイル名: VTDOS.EXE
ファイルパス:C\VTDOS.EXE
ファイルサイズ: 207.5 KB
ファイルバージョン:
更新日時: 2010年1月23日 02時05分00秒
著作権:
読み取り専用 X 隠しファイル X

CRC32:b618edb2
MD5 :609014f7c94d6e5dcd610ade011b81e3



      - No.4932 -    このTreeへ    コメント元:4929 へ [リストへもどる] soft

(4917) 4933PIFの亡霊?  投稿者:konno   2010/01/28(木) 01:24
    4932 番 10# さんへのコメント

> ファイル名: VTDOS.EXE
> 更新日時: 2010年1月23日 02時05分00秒

これを見て、もしやと思って確認したら、作成日が 1/17になってました。あれぇ?
そうか、これって、古いVerに上書きしたからか。・・・

まさかと思いながら、上書きしてないVTDOS.EXEからショートカットを作り直して
起動してみたら、問題なく動いてしまいました。(++;
もしかして、上書きは駄目なんでしょうか。

う〜む、そういえば、以前にも、似たようなことがあったなぁ。
うまく起動しないVZのアイコンがあって、他の、うまく動いている環境の設定と
同じにしても、何をやっても動かないんですね。で、そのアイコン(PIF)を破棄して
新しくショートカットを作り直してみたらアッサリ動いたという。(++;

とにかく問題は解決したようです。お騒がせしました。m(__)m
      - No.4933 -    このTreeへ    コメント元:4932 へ [リストへもどる] soft

(4917) 4920VTDOS v1.22 出ました  投稿者:文太   2010/01/26(火) 01:11
    4917 番 めざら さんへのコメント

10#さん(と、ここの掲示板でいいですよね。失礼します>めざらさん)

#04893 VTDOSインストチェック
#04900 クリップボード送信
#04901 GET CLIPBOARD DATA SIZE

 VTDOS 1.22で、上記の発言に含まれる3つのマクロが、正常動作しました。

      - No.4920 -    このTreeへ    コメント元:4917 へ [リストへもどる] soft

(4917) 4940Re: VTDOS v1.22 置換でテンポラリファイルエラー  投稿者:konno   2010/02/01(月) 00:02
    4917 番 めざら さんへのコメント    コメント数 1

めざらさん

>  350KBほどの,そこそこのサイズのファイルのほぼ全部をブロック指定し,
> 結構文字数の増える置換を行って,常時テンポラリファイルエラーが発生しました。

これはその後、何か進展があったでしょうか。別のエラーの話を割り込ませてしまって
話題がそちらにそれてしまい、申し訳ないです。m(__)m

> 所期の動作の場合,最終的にファイルサイズは500KB超に増加します。

短いファイルで試しても問題が出ないので、巨大ファイル編集の問題のような気が
します。
VZのVerを変えても同じでしょうか。もしかしたらこの辺が関係したりするかも
しれないなぁという気がしたもので。

素のDOS窓では問題ないんですよね。

      - No.4940 -    このTreeへ    コメント元:4917 へ [リストへもどる] soft

(4917) 4945Re^2: VTDOS v1.22 置換でテンポラリファイルエラー  投稿者:文太   2010/02/01(月) 01:51
    4940 番 konno さんへのコメント    コメント数 1

>短いファイルで試しても問題が出ないので、巨大ファイル編集の問題のような気が
>します。
 僕はEMSのテキストバッファがらみだろうと空想してます。EMSドライバ
を作るのはものすごく大変だそうです。

      - No.4945 -    このTreeへ    コメント元:4940 へ [リストへもどる] soft

(4917) 4947Re^3: VTDOS v1.22 置換でテンポラリファイルエラー  投稿者:としき   2010/02/01(月) 10:00
参照先:http://www.hinocatv.ne.jp/~toshiki/
    4945 番 文太 さんへのコメント

>  僕はEMSのテキストバッファがらみだろうと空想してます。EMSドライバ
> を作るのはものすごく大変だそうです。

大変は大変ですが。
ものすごく、というほどではないですよ。
サポートするファンクションをどこまでにするか、という点で大変さは変わって
きますがね。でも、デバイスドライバなり常駐ソフトなりを作れる程度のスキル
のある人なら、リアルモード用のEMSドライバであれば十分作成可能でしょう。
これが、仮想86モードのEMSドライバだとか、ある特定のメモリボード用に
特化したEMSドライバ、ということになると、その対象の動作を把握する必要
があるので、もしかしたらものすごく大変になるかもしれませんが。
      - No.4947 -    このTreeへ    コメント元:4945 へ [リストへもどる] soft

(4917) 4954VTDOS v1.22 でファイルオープンエラー?  投稿者:めざら   2010/02/02(火) 23:50
参照先:http://homepage3.nifty.com/mezala/
    4917 番 めざら さんへのコメント    コメント数 1

 環境は,Win XP pro + Shell=PC-DOS6.3 です。
 エラーが出たときの表示は,うちのアップロード掲示板「海豹牧場」に置きました。
http://homepage3.nifty.com/mezala/upload/file/26.jpg
 左側がエラー画面で,右側が所期の画面展開です。

 エラー前後の動きは,v1.17 のときのように,カーソルが飛んで意図しない編集結果になるとか,分割画面でファイルをオープンしたらバイナリのような表示になるというところです。
 再現性がいまひとつ解りません。
Clppstを使った直後でも,右のように大丈夫なときは大丈夫。
      - No.4954 -    このTreeへ    コメント元:4917 へ [リストへもどる] soft

(4917) 4962VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/05(金) 01:01
    4954 番 めざら さんへのコメント    コメント数 2

うちの職場のPCでも似たような現象が出ました。環境は
AMD Athlon64 X2 Dual Core 3800+ 1.79GHz, 960MB RAM XP Pro SP2
Shell=MSDOS6.2

このPCは今までVTDOSが安定して動作していたと思ったんですが・・・

filer.asmを読んでいる時に、[ESC]M でマクロメニューを出し、[TAB]で、vz.defを
オープンさせ、[F04]で分割画面にし、[F02]で行ったりきたりとかいろいろやって
いたら、vz.defの先頭から54%まで ^@ になってしまいました。
これは、表示上ではなく、中身が入れ替わってしまいました。

vz.defのサイズは 29798bytes で、その54% だと、16090bytes くらいでしょうか。
ちょうどEMS1ページ分ですね。う〜む・・・


      - No.4962 -    このTreeへ    コメント元:4954 へ [リストへもどる] soft

(4917) 4964Re: VTDOS v1.22 で分割画面で異常  投稿者:文太   2010/02/05(金) 01:45
    4962 番 konno さんへのコメント

konnoさん

>filer.asmを読んでいる時に、
 笑。
>ちょうどEMS1ページ分ですね。う〜む・・・
 たぶん、VTDOS1.00からなんじゃないかなぁ…?

      - No.4964 -    このTreeへ    コメント元:4962 へ [リストへもどる] soft

(4917) 4967Re: VTDOS v1.22 で分割画面で異常  投稿者:10#   2010/02/05(金) 23:09
参照先:http://vtdos.web.fc2.com
    4962 番 konno さんへのコメント    コメント数 1

再現困難な問題に関しては、それを調査すること自体ままならないので、
直接それを解消することはありません。
直接は無関係な問題を解消した結果、解消されることはあるかも知れません。
しかしこの場合、当初の再現困難な問題が解消されたことを立証することが
出来ないので、解消されたとすることはありません。
再現困難な問題を直接解消することはありませんが、間接的に解消される
ことはありえます。
そういった類の問題がある可能性が常にあり、理屈上0でないことを
ご理解の上でご使用下さい。

      - No.4967 -    このTreeへ    コメント元:4962 へ [リストへもどる] soft

(4917) 4979Re^2: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/07(日) 00:09
    4967 番 10# さんへのコメント    コメント数 1

10#さん

> 再現困難な問題に関しては、それを調査すること自体ままならないので、
> 直接それを解消することはありません。

それは承知しております。こんど現象が出たら再現できるように心がけます。
ところで、今回の異常の時にエラーログが記録されていました。

2010-02-04 12:18:55 VZIBMJ(167D) 167D:14A2 'ストリング命令ラップアラウンド'

このエラーは今回が初めてですが、特に変わった外部コマンドやマクロを使用した
覚えは無いんですよね。ラップアラウンドって、64kの中でループするんですよね。
EMSがらみだとしたら、何か変?


      - No.4979 -    このTreeへ    コメント元:4967 へ [リストへもどる] soft

(4917) 4993Re^3: VTDOS v1.22 で分割画面で異常  投稿者:10#   2010/02/09(火) 01:10
参照先:http://vtdos.web.fc2.com
    4979 番 konno さんへのコメント    コメント数 1

正常なプログラムであれば、movs/lods/stosでは出ないですが、
scas/cmpsではセグメントレジスタに異常があれば出ます。
子プロセスの起動時にds/esを破壊する不具合があるので、
それを疑っています。
おそらくバッファにテキストを入れて子プロセスを起動した場合と、
そうで無い場合で結果が違ってくるのではないか?と推測しています。
clppstなども該当します。
僕自身は編集中のコマンド実行を無意識に避けていたりしてますね。
あと、Ver.1.2xあたりから、SW3が若干安定してきているようにも見えます
(非推奨)

      - No.4993 -    このTreeへ    コメント元:4979 へ [リストへもどる] soft

(4917) 4994Re^4: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/09(火) 01:57
    4993 番 10# さんへのコメント    コメント数 2

> 僕自身は編集中のコマンド実行を無意識に避けていたりしてますね。

私もこの辺にVZのバグがありそうに思えるので、たまに異常が出たときは諦めています。
ところで、VTDOS上での異常の再現が出来ました。

1. 20〜30kbytes以上のファイルを2つ開いて、並べます。
2. [ESC][E]でコマンドラインに降りる。
3. 小文字vmap、大文字VMAP、小文字vmap 実行。
4. [ESC]で編集画面に戻る。
5. [ESC][E]でコマンドラインに降りる。
6. 小文字vmap、大文字VMAP、小文字vmap 実行。
7. [ESC]で編集画面に戻る。

だいたいこのくらいで片側のファイルが異常になります。
VTDOS114、121、122 で常駐VZで確認しました。
VZk07t、VZt で同じでした。
素のXPDOS窓常駐VZでは出ませんでした。
異常時にはエラーログが出ます。
2010-02-09 01:22:27 VZIBMJ(171C) 171C:14A2 'ストリング命令ラップアラウンド'
2010-02-09 01:24:32 VZT(1692) 1692:149A 'ストリング命令ラップアラウンド'

> あと、Ver.1.2xあたりから、SW3が若干安定してきているようにも見えます

最近のVerではcodex.defも動くようになりましたので、CPUエミュレートの精度が
上がっているようですね。
ところで、MEU.COM が1.22でエラーログを出すようです。
2010-02-09 00:25:58 MEU(267C) 268C:222F 'HMA REP MOVSB'

      - No.4994 -    このTreeへ    コメント元:4993 へ [リストへもどる] soft

(4917) 4996Re^5: VTDOS v1.22 で分割画面で異常  投稿者:文太   2010/02/10(水) 00:05
    4994 番 konno さんへのコメント    コメント数 1

10#さん、konnoさん

>ところで、VTDOS上での異常の再現が出来ました。
>1. 20〜30kbytes以上のファイルを2つ開いて、並べます。
(以下略)

 一発で再現しました。確かに分割画面がキーのようで(だとするとVz側?)、
画面分割しないと発生しませんでした。僕の場合、下画面の上部に化け文字が入り、
↑すると、 ステータスラインが2%位置という表示になり、その上に1Ah(^@)
がずらっと並ぶ状況でした。
 尚、VTDOS環境でないと、やはりこの不具合は発生しない模様でした。

 しかし、分割画面にすると、メモリの使い方が違うの?

 ファイルは、2,372,914、1,686,908とやや大きめで、最初にファイル末尾への
ジャンプをして全部読み込ませています(EMS使用)。SW=2。

      - No.4996 -    このTreeへ    コメント元:4994 へ [リストへもどる] soft

(4917) 5000Re^6: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/10(水) 01:13
    4996 番 文太 さんへのコメント

>  一発で再現しました。確かに分割画面がキーのようで(だとするとVz側?)、

出ましたか。なんとなくVZ側に問題ありそうな感じですね。

> 画面分割しないと発生しませんでした。僕の場合、下画面の上部に化け文字が入り、

これも同じです。wb のファイルが壊れるようですね。分割は縦でも横でもなります。

>  尚、VTDOS環境でないと、やはりこの不具合は発生しない模様でした。

職場のXP pro のDOS窓では不正な処理で落ちました。そういえば、このPCでは
常駐VZのコマンドラインが不安定なのでした。

>  しかし、分割画面にすると、メモリの使い方が違うの?

今試したら、分割画面でなくとも、ファイルを2つ開いていると、裏のファイルが
壊れますね。この辺の処理とスワップの絡みのような気がしますね。


      - No.5000 -    このTreeへ    コメント元:4996 へ [リストへもどる] soft

(4917) 4999Re^5: VTDOS v1.22 で分割画面で異常  投稿者:10#   2010/02/10(水) 00:59
参照先:http://vtdos.web.fc2.com
    4994 番 konno さんへのコメント    コメント数 2

konnoさんの報告を元に僕の方で再現手順を絞り込みました。
(画面分割はしていません)

1. 複数ファイルを開く(ファイル数6・総サイズ約8k)
2. [ESC]Eでコマンド
3. Ms (スワップ実行)
4. [ESC]でVZ
5. ms (非スワップ実行)
6. [ESC]でVZ

この手順でバッファクラッシュが再現しました。
これを、SW2/SW3/EM/EM0でそれぞれ追試しましたが、
どの設定でも再現しました。(おそらくEMMはシロ)

---------------------------------------------------------------------

SWAP.ASMを漁っていると F_REALLOC が出てきたので、
DOSのメモリ管理コールをログに落として追試。
VZからのシェルエスケープ終了後のスワップイン処理時に
VZによる空きメモリーに対するF_REALLOCが検出されたので、
F_REALLOCでgrep。
該当ソースはDOS.ASM/MAIN.ASM/SWAP.ASM
F_REALLOCの呼び出し状況からDOS.ASMと推定。ソースレビュー。

該当箇所・DOS.ASM 1100付近
> expandfar proc
>         mov     ax,gtops
>         tst     ax
> _ifn z
>         push    es
>         call    checkmcb
>         mov     bx,-1
>   _if e
>         msdos   F_REALLOC
>         msdos   F_REALLOC
>   _else
>         msdos   F_MALLOC
>         msdos   F_MALLOC
>         mov     gtops,ax
>   _endif
>         add     ax,bx
>         mov     gends,ax
>         pop     es
> _endif
>         ret
> expandfar endp

gtopsのMCBを検査して割り当て済みならF_REALLOC、
未割り当てならF_MALLOCを呼び出して、
コンベンショナルメモリーを最大サイズ取得している模様。
F_REALLOCが未割り当て領域エラーを返した場合の処理は省略されている模様。
検査用のローカルサブルーチンcheckmcbをレビュー。

該当箇所・DOS.ASM 1250付近
> checkmcb proc
>         push    ax
>         dec     ax
>         mov     es,ax
>         mov     al,es:[mcb_id]
>         cmp     al,'M'
> _ifn e
>         cmp     al,'Z'
>         jne     chkmcb9
> _endif
>         mov     ax,cs
>         tstw    es:[mcb_psp]	; ## この2行が
>         jz      chkmcb9	; ## 不要と思われる
>         cmp     es:[mcb_psp],ax
> chkmcb9:pop     es
>         ret
> checkmcb endp

呼び出し仕様「割り当て済みチェック」に対して、
「未割り当てを含む有効なMCBチェック」であることが判明。
この論理ではexpandfarが空き領域に対してF_REALLOCを
呼び出しうるため、不具合であると仮定。
問題箇所をコメントアウトしてVZをリビルド。

パッチ済みのVZで追試を行いました。
結果、SW3の時に画面分割を行っている場合は再現しましたが、
それ以外の場合は改善されている様子です。

---------------------------------------------------------------------

他のDOS環境で正常に動作する理由は不明です。
空き領域へのF_REALLOCはF_MALLOC様に動作するのか?と思い、確認したのですが、
記述が見あたりませんでした。

>    This function is used to increase or decrease the size of a memory
>    block allocated by Function 48h. ES contains the segment address of
>    the block whose size will be changed. BX contains the new size of the
>    block, in paragraphs (16-bytes units).

> This call is used to change the size of an allocated block.
> On entry, es must contain the segment address of the allocated block
> returned by the memory  allocation  function.
> Bx must contain the new size of this block in paragraphs.
> While you can almost always reduce the size of a block,
> you cannot normally increase the size of a block if other blocks
> have been allocated after the block being modified.
> Keep this in mind when using this function.

未割り当て領域へのF_REALLOCはF_MALLOCと同じ動作をするという記述を
見つけられた方はVTDOSの仕様に反映させますのでお知らせ下さい。

また、もし可能であれば、パッチ済みのVZを他のDOS環境でテストして
いただけないでしょうか?
それで問題が出なければ、正規のパッチ(?)として採用されることをお勧めします。

      - No.4999 -    このTreeへ    コメント元:4994 へ [リストへもどる] pre

(4917) 5001Re^6: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/10(水) 01:48
    4999 番 10# さんへのコメント    コメント数 1

10#さん

> >         tstw    es:[mcb_psp]	; ## この2行が
> >         jz      chkmcb9	; ## 不要と思われる

おお、やはりVZの問題だったのですか、ソースまで特定していただいて。m(__)m

> パッチ済みのVZで追試を行いました。
> 結果、SW3の時に画面分割を行っている場合は再現しましたが、
> それ以外の場合は改善されている様子です。

おお、改善されましたか、さすがプロですね。鮮やかなお手並みに脱帽です。
私は所詮素人で、こういう解析は無理なので、とても助かりました。

> また、もし可能であれば、パッチ済みのVZを他のDOS環境でテストして
> いただけないでしょうか?
> それで問題が出なければ、正規のパッチ(?)として採用されることをお勧めします。

はい、追試してみます。問題なければ、新版としてアップさせていただきます。

      - No.5001 -    このTreeへ    コメント元:4999 へ [リストへもどる] pre

(4917) 5008Re^7: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/12(金) 02:05
    5001 番 konno さんへのコメント

パッチ済みのVZで追試を行いました。

Win98のDOS窓及びDOSモードと200LXで試してみましたが、問題はなさそうです。
不安定なXP Pro のDOS窓では不正な処理で落ちる前に、フリーエリアがCOMMAND.COM
に占められてしまう状態になりました。(^^;

> 他のDOS環境で正常に動作する理由は不明です。
> 空き領域へのF_REALLOCはF_MALLOC様に動作するのか?

ドキュメントに無くても、c.mosさんなら、こういう動作を知っていて、利用していた
ような気がしますね。
もう暫らく使って見て、副作用とかがなさそうだったら、アップしようと思います。

      - No.5008 -    このTreeへ    コメント元:5001 へ [リストへもどる] soft

(4917) 5010Re^6: VTDOS v1.22 で分割画面で異常  投稿者:としき   2010/02/13(土) 00:30
参照先:http://www.hinocatv.ne.jp/~toshiki/
    4999 番 10# さんへのコメント    コメント数 2

> 未割り当て領域へのF_REALLOCはF_MALLOCと同じ動作をするという記述を
> 見つけられた方はVTDOSの仕様に反映させますのでお知らせ下さい。

いくつか資料を当たってみました。結果、妖しげなものが出てきました。

幸田敏記著「MS-DOSデータブック」ラジオ技術社
ISBN4-8443-0181-0

初版が昭和62年のこの本は、DOS2.11を対象にしています。また、この本には、
マイクロソフトの承認を得て、各ファンクションのフローチャートが掲載されて
います。各フローチャートには、全て、マイクロソフトのコピーライトマークが
くっついているという念の入れよう。
さて、この本に掲載されているFunction 4Ahのフローは、概略、以下の通りです。

 MZブロックチェック
  → エラーならAL=7で終了
 無所属のMCBをまとめる
  → エラーならAL=7で終了
 CXに割り当て可能なブロックサイズ代入
 BXとCXを比較
  BXが大きい → Function 48hのメモリ不足ルーチンにジャンプ
          (AL=8を返す)
  CXが大きい → Function 48hのメモリ獲得ルーチンにジャンプ

これだと、たまたまメモリが汚れていたとか何とかいう理由でMZチェックを通過
してしまうと、その後がかなり危険なような気がするのですが、気のせいでしょ
うか。

あと、ちょっと気になったのが、エラー時のリターン値。
この本では、AXは7と8しか返さないようになっている模様。
AX=9ってどうなったんだろう。
      - No.5010 -    このTreeへ    コメント元:4999 へ [リストへもどる] soft

(4917) 5011Re^7: VTDOS v1.22 で分割画面で異常  投稿者:10#   2010/02/13(土) 20:13
参照先:http://vtdos.web.fc2.com
    5010 番 としき さんへのコメント    コメント数 3

なんと!
この資料を見る限りはファンクション4Ahは必ずしも割り当て済みであることを要求せず、
未割り当て領域にも処理が可能ということになりますね。
前回の調査での結論としてのVZの不具合は不具合で無く、パッチも施すべきでは無くなります。
VTDOS側にこの対応を実施すると多くのファンクション4Ahの説明とは食い違うことになります。
(一般に流布されている情報が間違っていることになる)
ここはVTDOSで対応することにして、VZでの対応は止めておいた方が良いと思われます。

      - No.5011 -    このTreeへ    コメント元:5010 へ [リストへもどる] soft

(4917) 5012Re^8: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/13(土) 21:55
    5011 番 10# さんへのコメント    コメント数 1

10#さん

NEC PC-9800シリーズ用の、SoftwareLibrary MS-DOS3.1プログラマーズリファレンスマニュアル P-4 にこうありました。
-------------------------------------------------------
プロセスがファンクション4AHを使って、メモリブロックサイズを拡大させたときは、MS-DOSはメモリブロックを割り当てるときと同様に扱いますが、このときはゼグメントアドレスは返さず、たんに追加メモリブロックとそれまでのメモリブロックをチェインします。
-------------------------------------------------------

これを読んで、私も4AHが48Hと同じような動作をするのではないかと思ったのですが、としきさんの資料が決定的だったようですね。

> ここはVTDOSで対応することにして、VZでの対応は止めておいた方が良いと思われます。

私もそう思います。VZの他のVerにはパッチを当てられないですし、結構致命的な異常なので、対応は必要、となれば、VTDOS側での対応がよさそうですね。

それにしても、VZのこのコメントにしたルーチンがどういう場面を想定していたのかが気になりますね。

      - No.5012 -    このTreeへ    コメント元:5011 へ [リストへもどる] soft

(4917) 5014Re^9: VTDOS v1.22 で分割画面で異常  投稿者:としき   2010/02/14(日) 11:37
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5012 番 konno さんへのコメント

> NEC PC-9800シリーズ用の、SoftwareLibrary MS-DOS3.1プログラマーズリファレンスマニュアル P-4 にこうありました。

NEC PC-9800シリーズ用の、MS-DOS5.0プログラマーズリファレンスマニュアルの
3ページにも、同様の記述がありました。
なるほど、失敗条件を満足しないものは基本的に成功させてしまう、というのが
このファンクションのロジックなんでしょうね。
      - No.5014 -    このTreeへ    コメント元:5012 へ [リストへもどる] soft

(4917) 5013Re^8: VTDOS v1.22 で分割画面で異常  投稿者:としき   2010/02/13(土) 22:35
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5011 番 10# さんへのコメント    コメント数 1

> この資料を見る限りはファンクション4Ahは必ずしも割り当て済みであることを要求せず、
> 未割り当て領域にも処理が可能ということになりますね。

確かにそうなんですが。実は私、この資料のほうの信憑性を疑っていたり。
なぜというに、#5010の末尾にも書きましたが、AX=9を返す部分がないからです。

あとは、Undocumented本とかAh!Skiのうらわざ手帳あたりを確認したいですね。
      - No.5013 -    このTreeへ    コメント元:5011 へ [リストへもどる] soft

(4917) 5015Re^9: VTDOS v1.22 で分割画面で異常  投稿者:文太   2010/02/14(日) 12:05
    5013 番 としき さんへのコメント

>あとは、Undocumented本(中略)を確認したいですね。
 特に記載はないと思います。ブラウン・リストに同じ情報です。

      - No.5015 -    このTreeへ    コメント元:5013 へ [リストへもどる] soft

(4917) 5030Re^8: VTDOS v1.22 で分割画面で異常  投稿者:10#   2010/02/22(月) 23:34
参照先:http://vtdos.web.fc2.com
    5011 番 10# さんへのコメント    コメント数 2

VTDOS側でファンクション4Aを調整して、
一通りテストしてみましたが、問題が解消されたように思われます。
(断言はしませんが)

このファンクション4Aの仕様はUndocumented中のUndocumentedですね。
他の互換DOSはどうなってるんでしょうかね?
      - No.5030 -    このTreeへ    コメント元:5011 へ [リストへもどる] soft

(4917) 5033Re^9: VTDOS v1.22 で分割画面で異常  投稿者:konno   2010/02/23(火) 00:52
    5030 番 10# さんへのコメント

> VTDOS側でファンクション4Aを調整して、
> 一通りテストしてみましたが、問題が解消されたように思われます。

おお、これは嬉しいニュースです。(^_^)
10#さんお忙しそうなので、VZのパッチ版を上げたほうがいいのかなぁ、と思っていたところでした。m(__)m


      - No.5033 -    このTreeへ    コメント元:5030 へ [リストへもどる] soft

(4917) 5058DR-DOS と freedos の 4Ah 周り  投稿者:- あじゃ -   2010/03/02(火) 15:18
参照先:http://aja.seesaa.net/
    5030 番 10# さんへのコメント    コメント数 1

 #05030 10# さん

関係がありそうな記述を見つけましたが、わしには詳細はわかりません (^^;

DR-DOS System and Programmers Guide (私訳)より抜粋
http://hp.vector.co.jp/authors/VA003720/lpproj/drdos/progdoc/sysprog/chap4j.htm
------------------------------------------------------------------------
●割当メモリサイズ変更 (4Ah)
Modify Allocated Memory Blocks 	
	
入力パラメータ 	
AH 	4Ah
BX 	パラグラフ数
ES 	メモリブロックのセグメント
戻り値 	
AX 	キャリーフラグがセットされている場合、エラーコード
BX 	使用可能なメモリブロックの最大サイズ(エラー時)

メモリブロック配置を、指定のサイズに変更します。 入力時、ES は割当済み
メモリブロックのセグメントアドレスを格納し、 BX は要求するメモリブロッ
クサイズをパラグラフ(16 バイト)単位で格納します。DR-DOS は BX の内容
にしたがい、割り当て済みメモリブロックのサイズを増加、もしくは減少させ
ます。

DR-DOS が割当済みブロックのサイズを大きくできない場合、 サイズ変更可能
な最大ブロックサイズを BX に返します。キャリーフラグがセットされている
場合、エラーコード 7, 8 もしくは 9 を AX に返します。 エラーコードの定
義については Chapter 5 を参照してください。

(訳注 : BX のパラグラフ数だけ増減するのではなく、 BX のパラグラフ数そ
のものに変更する、という点に注意してください。また、C言語ライブラリの
realloc などと異なり、メモリブロックの起点は移動されません。したがって、
たとえばサイズ変更するメモリブロックの直後のメモリがすでに割り当てられ
ている場合、他の位置に空きメモリがどれだけあってもサイズ増加は失敗しま
す。) 
------------------------------------------------------------------------

Freedos 開発者のMLから抜粋
http://www.mail-archive.com/freedos-devel@lists.sourceforge.net/msg04881.html

[Freedos-devel] Kernel incompatibility between FD and MS-DOS makes QB4 cry
Michael Devore
Thu, 17 Aug 2006 19:26:13 -0700
------------------------------------------------------------------------
While testing out a users bug report, I found a terribly obscure difference 
between the way MS-DOS kernel works and FreeDOS kernel works.

(中略)

Here's the situation, running under QB 4.0.  The code is found in 
BRUN40.EXE and duplicated in the application's executable files:

1. QuickBASIC (I assume) frees a block of memory via INT 21h function 49h 
that it previously allocated.  Success in FreeDOS and MS-DOS.

2. QuickBASIC resizes a second block of memory via function 4ah with value 
0FFFFh to determine all free memory available to the block.  The function 
fails, as designed, but returns the maximum possible block size.  Success 
in both.

3. QuickBASIC resizes the second block of memory via function 4ah with the 
amount returned in last 4ah call, as expected.  Success, again.

4. QuickBASIC tries to re-free the first block of memory via function 
49h.  Tsk, tsk.  Naughty, but not too naughty under normal 
conditions.  Here MS-DOS and FreeDOS differ: while both will allow 
re-freeing the same block without error under some circumstances (which I 
don't know what they are since I'm not a kernel guy), the intervening 
resizes of the second block apparently flush out FreeDOS's memory of the 
first block, so it returns an error code.  MS-DOS still remembers that the 
block was recently valid and does not return an error code on the second free.
------------------------------------------------------------------------

      - No.5058 -    このTreeへ    コメント元:5030 へ [リストへもどる] pre

(4917) 5062Re: DR-DOS と freedos の 4Ah 周り  投稿者:としき   2010/03/02(火) 21:52
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5058 番 - あじゃ - さんへのコメント    コメント数 2

> 関係がありそうな記述を見つけましたが、わしには詳細はわかりません (^^;

DR-DOSの記述された仕様は、MS-DOSとほとんど同じですね。
ということは、記述されていない部分でどんな差異が生じるかはわからない、と
いうことでもあると思いますが。
freedosのほうは、MS-DOSとは違う挙動を示している、という現象を記述している
ことはわかるのですが、英語がわかりません。4Ahでサイズを変えたあと、49hで
開放する時の挙動が異なる、ということをいっているような気もするのですが、
何せ英語の偏差値33の人間ですから、思いっきり正反対に理解しているかもしれ
ません。
      - No.5062 -    このTreeへ    コメント元:5058 へ [リストへもどる] soft

(4917) 5063Re^2: DR-DOS と freedos の 4Ah 周り  投稿者:konno   2010/03/02(火) 23:28
    5062 番 としき さんへのコメント    コメント数 1

> Freedos 開発者のMLから抜粋

niftyのテキスト翻訳に放り込んで、翻訳してみました。(^^;
顰蹙もの、かな。(^^;;

-----------------------------------------------------------------------

FDとMS-DOSの間のFreedos-強打カーネルの不一致はQB4叫びマイケルDevoreを木曜日、2006年8月17日の19:26にします:13 -0700
------------------------------------------------------------------------
ユーザバグを徹底的に試している間、報告してください、と私はMS-DOSカーネルが働く方法とカーネルが扱うFreeDOSのものすごく不鮮明な違いがわかりました。

(中略)

ここに、QB4.0で実行されて、状況があります。 コードは、BRUN40.EXEで見つけられて、アプリケーションの実行可能なファイルにコピーされます:

1. QuickBASIC(私は仮定する)はそれが以前に割り当てたINT 21h機能49hを通して1ブロックのメモリを解放します。 FreeDOSの成功とMS-DOS。

2. QuickBASICは、ブロックに利用可能なすべての無料の記憶を決定するために値の0FFFFhと機能4ahを通してメモリの2番目のブロックをリサイズします。 機能は、設計されているように失敗しますが、最大の可能なブロック・サイズを返します。 両方の成功。

3. 量がある機能4ahを通したメモリの2番目のブロックが最後の4ahで返したQuickBASICリサイズは、予想されるように呼びます。 再び成功。

4. QuickBASICは機能49hを通してメモリの最初のブロックを再解放しようとします。 チェッ、チェッ。 いたずらですが、正常な状態の下でそれほどいたずらではありません。 ここで、MS-DOSとFreeDOSは異なります: 両方で誤りなしでいくつかの状況で同じブロックを再解放する、(私がカーネル奴でないので、どのIが、それらが何であるかを知らないか、)、2番目のブロックの介在するリサイズはどうやらFreeDOSの最初のブロック(それがエラーコードを返すそう)のメモリを洗います。 MS-DOSは、ブロックが最近有効であったのをまだ覚えていて、無料で2番目のエラーコードを返しません。
------------------------------------------------------------------------


      - No.5063 -    このTreeへ    コメント元:5062 へ [リストへもどる] soft

(4917) 5082Re^3: DR-DOS と freedos の 4Ah 周り  投稿者:としき   2010/03/06(土) 15:28
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5063 番 konno さんへのコメント    コメント数 2

> 顰蹙もの、かな。(^^;;

あじゃさんにウケたようなので、よろしいのではないでしょうか。
また、この直訳のおかげで、私も自分の英語力に自信が持てました。


[Freedos-devel]FreedosとMS-DOSのカーネルの非互換性によるQB4の叫び
Michael Devore
Thu, 17 Aug 2006 19:26:13 -0700
------------------------------------------------------------------------
バグレポートを試している間に、私はMS-DOSカーネルの挙動とFreeDOSカーネルの
挙動の間の恐ろしく微妙な違いを見つけてしまいました。

(中略)

QuickBasic4.0の動作する環境があります。このコードはBRUN40.EXEに見られる
もので、アプリケーションの実行ファイルにも複写されます。

1. QuickBASIC(を前提とします)はINT 21h function 49hを使って、以前に確保
したメモリブロックを解放します。 FreeDOSもMS-DOSも成功します。

2. QuickBASICは、function 4ahを使って、メモリの2番目のブロックのサイズを
変更しますが、このときに、そのブロックで利用可能な全ての空きメモリを決定
するために0FFFFhを指定します。このファンクションは、仕様どおりにエラーを
返しますが、利用可能な最大のメモリブロックのサイズも返します。いずれのOS
も同じ動作です。

3. QuickBASICは予期したとおり、先ほどの4ahで返ってきたメモリサイズで再び
function 4ahを呼び出して2番目のブロックをリサイズします。やっぱり成功。

4. QuickBASICはfunction 49hを使ってメモリの最初のブロックを再解放しようと
します。おっとっと。なんか変ですが、通常であれば極端に変ではありません。
ここで、MS-DOSとFreeDOSは異なります: 多くの状況では、いずれもエラーなしで
同じブロックを再解放します(私はカーネルではないので、よくわからない)が、
FreeDOSではサイズを変更した2番目のメモリブロックと最初のメモリブロックの
隙間が開放されているように見えるし、エラーコードも返ってきます。MS-DOSは、
ブロックが最近有効であったことを覚えていて、エラーコードを返さずに2番目の
ブロックを開放します。
------------------------------------------------------------------------

日本語としては直訳よりはましだと思うけど、内容というか書き手の意図を伝え
られているかは全く不明。むしろ直訳のほうが良かったりするかも。
      - No.5082 -    このTreeへ    コメント元:5063 へ [リストへもどる] soft

(4917) 5083Re^4: DR-DOS と freedos の 4Ah 周り  投稿者:konno   2010/03/07(日) 00:01
    5082 番 としき さんへのコメント    コメント数 1

> > 顰蹙もの、かな。(^^;;
> あじゃさんにウケたようなので、よろしいのではないでしょうか。
> また、この直訳のおかげで、私も自分の英語力に自信が持てました。

ウケ狙いのほうは狙い通りですが、としきさんのお役にも立てたようでなによりです。
いやあ、いいですね、実に自然で違和感の無い納得のいく翻訳ですね。

> [Freedos-devel]FreedosとMS-DOSのカーネルの非互換性によるQB4の叫び
> Michael Devore

なるほど、ここはこうなるわけですね。(^^;

> FreeDOSではサイズを変更した2番目のメモリブロックと最初のメモリブロックの
> 隙間が開放されているように見えるし、エラーコードも返ってきます。MS-DOSは、
> ブロックが最近有効であったことを覚えていて、エラーコードを返さずに2番目の
> ブロックを開放します。

なるほど、ここが肝ですね。メモリ開放の挙動の違いということですか。
互換DOSは数多くありますが、挙動の違う部分というのは必ずあるのでしょうね。

> 日本語としては直訳よりはましだと思うけど、内容というか書き手の意図を伝え
> られているかは全く不明。むしろ直訳のほうが良かったりするかも。

いやあ、としきさんの訳で本来の意図がバッチリわかったように思えます。
あの機械翻訳は頭の中で再翻訳しないとまったくわけわかですから。

      - No.5083 -    このTreeへ    コメント元:5082 へ [リストへもどる] soft

(4917) 5099Re^5: DR-DOS と freedos の 4Ah 周り  投稿者:としき   2010/03/07(日) 16:49
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5083 番 konno さんへのコメント

> 互換DOSは数多くありますが、挙動の違う部分というのは必ずあるのでしょうね。

仕様書に明記されている部分なら、それほど問題はないでしょう。
問題があるのは、Undocumentedな部分。
それと、今回あじゃさんが英語で掲載された部分は、元の発信者自身が
「a terribly obscure difference」
「but not too naughty under normal conditions.」
と表現しているくらいなので、通常では問題にならないようなものなのでしょう。
多分、略されている部分にはコードが掲載されていたのだろうと推測しますが、
「ふつ〜、こんなコードはかかねぇよ」というようなものかもしれません。
      - No.5099 -    このTreeへ    コメント元:5083 へ [リストへもどる] soft

(4917) 5097Re^4: DR-DOS と freedos の 4Ah 周り  投稿者:文太   2010/03/07(日) 14:28
    5082 番 としき さんへのコメント    コメント数 1

> since I'm not a kernel guy
> (私はカーネルではないので、よくわからない)
 たぶん、「カーネルの専門家ではないので」でしょう。

      - No.5097 -    このTreeへ    コメント元:5082 へ [リストへもどる] soft

(4917) 5098Re^5: DR-DOS と freedos の 4Ah 周り  投稿者:としき   2010/03/07(日) 16:31
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5097 番 文太 さんへのコメント    コメント数 1

うれしいなぁ、少なくとも日本人の平均よりは英語の得意な方のお出ましだ。

>  たぶん、「カーネルの専門家ではないので」でしょう。

なるほど、そういうことでしたか。
最初は、「FreeDOSのカーネル作成チームの一員」を意味しているのかと思ったり
したのですが、そうだと言うにはFreeDOSの開発体制を知らなさ過ぎて。もしや、
カーネルを擬人化して、自分をカーネルになぞらえているのかな、と思ってあの
ような訳語にしてみました。

文太さん、もしかして今後、コンピュータ系の英語のサイトをたくさん読まれる
ことになるのでしょうか。そうならば、そちらで得られた知見を、いくばくなり
とも日本語でフィードバックしていただけると、ありがたいと思う人が多いかも
しれません。
      - No.5098 -    このTreeへ    コメント元:5097 へ [リストへもどる] soft

(4917) 5100Re^6: DR-DOS と freedos の 4Ah 周り  投稿者:文太   2010/03/07(日) 21:25
    5098 番 としき さんへのコメント

 いえ、としきさんががんばっているなと思い、そうそう、そうやっていくしか
ないんだよ、と僭越ながらエールを送らせていただいただけです。

>最初は、「FreeDOSのカーネル作成チームの一員」を意味しているのかと思ったり
>したのですが、そうだと言うにはFreeDOSの開発体制を知らなさ過ぎて。
 これは可能性としてはあり得るでしょう。

>文太さん、もしかして今後、コンピュータ系の英語のサイトをたくさん読まれる
>ことになるのでしょうか。
 ええ、レイ・ダンカンその他の方々の本をばっちり入手してしまったので。とし
きさんを見習って、コツコツやります。Encyclopaediaの日本語は、どうも苦手。
というか、読んでいてワクワク感がない。

>そうならば、そちらで得られた知見を、いくばくなりとも日本語でフィードバック
>していただけると、ありがたいと思う人が多いかもしれません。
 そんな人が生き残っていれば。いや、「日本語でのフィードバック」はないな。
訳してみなよ、と相変わらず冷たいでしょう。

 あ、4Ah近辺のmemory allocation, free, resizeの文献は、今回のも含めてま
ったく読んでません。どうも文脈その他がうまく頭に入ってこないのです。MとZ
な話なだけなはずなんですけどね。なんだか心に壁があるみたい。

---------------------------------------------------------------------------
 (で、少し読んでみました。)

>3. QuickBASICは予期したとおり、先ほどの4ahで返ってきたメモリサイズで再び
>function 4ahを呼び出して2番目のブロックをリサイズします。やっぱり成功。
 なるほど、それで2回呼ぶのね。そういう風に使うものだって、ナツメ本、教え
てよ。1回呼んで、2工程やってくれるのかと思ってた。「思ってた」ほど強く
考えてませんでしたが。(^^ゞ


 「隙間」ってなんだっけ? という素朴な疑問から。

the intervening resizes of the second block apparently flush out FreeDOS's
memory of the first block, so it returns an error code.
FreeDOSの場合、途中行なわれる第2ブロックのサイズ変更が(サイズ・ゼロへの
変更)、第1ブロックについてのデータ(記憶)を消去してしまう【ようで】、
エラーコードが返ります。(困った仕様だ)
 ※なぜ「途中行なわれる」のか。たぶん、第0ブロックのMCBの書き換えの作業が
  残っているからか、第1ブロックの消去作業が完了したわけではないからなのか
  不明。消去っていったって、3つのMCBの書き換えですよね。

MS-DOS still remembers that the block was recently valid and does not
return an error code on the second free.
一方、MS-DOSの場合、第1ブロックがさっきまで有効であったことをきちんと記憶
していて、第2ブロックの解放でエラーコードを返すことはない。

-----------------------------------------------------------------------------
 メモリサイズを拡大をしたあと、その拡大されたメモリを解放するときの振る舞い。
拡大されたメモリは、元メモリ+増加分メモリの2つのブロック。それぞれが、
第1ブロック、第2ブロックと表現される。解放(再解放と呼ばれてる)は、この2つ
の両方をなしにするのだけど、そのとき、FreeDosでは、失敗が起こる(ことがある、
あるいはエラーが返る)。
 M-M-Z --> Z とするときのこと。
 こんな感じですか。【ようで】の強調は、としきさんあて。

 Vz, VTDOS関連の、話の最初からの繋がりは見えてません。

-----------------------------------------------------------------------------
under some circumstances (which I don't know what they are)
ある状況ではうまくいく(どんな状況なのかは分からないが)
「多くの場合」で、いいのでしょう。

      - No.5100 -    このTreeへ    コメント元:5098 へ [リストへもどる] soft

(4917) 5080Re^2: DR-DOS と freedos の 4Ah 周り  投稿者:- あじゃ -   2010/03/06(土) 13:40
参照先:http://aja.seesaa.net/
    5062 番 としき さんへのコメント

 #05062 としき さん

> DR-DOSの記述された仕様は、MS-DOSとほとんど同じですね。

そうなのか (^^;

> freedosのほうは、MS-DOSとは違う挙動を示している、という現象を記述している
> ことはわかるのですが、英語がわかりません。4Ahでサイズを変えたあと、49hで
> 開放する時の挙動が異なる、ということをいっているような気もするのですが、

これはその通りです。ただ、わしにはその挙動の詳細がわかりまへん (^^;

 #05063 konno さん

> FDとMS-DOSの間のFreedos-強打カーネルの不一致はQB4叫びマイケルDevoreを木曜日、
> 2006年8月17日の19:26にします:13 -0700

(大笑)

      - No.5080 -    このTreeへ    コメント元:5062 へ [リストへもどる] soft

(4917) 5016Re^7: VTDOS v1.22 で分割画面で異常  投稿者:文太   2010/02/14(日) 12:13
    5010 番 としき さんへのコメント    コメント数 1

>NEC PC-9800シリーズ用の、MS-DOS5.0プログラマーズリファレンスマニュアルの
>3ページにも、同様の記述がありました。
 同じくNEC PC-9800シリーズ用の、MS-DOS『3.3A』プログラマーズリファレンス
マニュアル vol.1, p.4にも同じ記述があります。ただ、どうも全体の像が頭に
描けていません。
 どっかで、4Ahの返り値AX=9が『ない』ものを見たはずです…。

      - No.5016 -    このTreeへ    コメント元:5010 へ [リストへもどる] soft

(4917) 5018ファンクションコールのエラーコード  投稿者:konno   2010/02/16(火) 00:07
    5016 番 文太 さんへのコメント    コメント数 1

>  どっかで、4Ahの返り値AX=9が『ない』ものを見たはずです…。

単なる抜けのような気がします。エラーコードが省略されている場合もあるようですし。

NEC PC-9800シリーズ用のMS-DOS3.1プログラマーズリファレンスマニュアル P-21 には
AXのエラーコードの一覧がありました。
これを見る限りでは、エラーコードはきっちり決められているように思えます。

      - No.5018 -    このTreeへ    コメント元:5016 へ [リストへもどる] soft

(4917) 5020Re: ファンクションコールのエラーコード  投稿者:としき   2010/02/16(火) 06:25
参照先:http://www.hinocatv.ne.jp/~toshiki/
    5018 番 konno さんへのコメント

> 単なる抜けのような気がします。エラーコードが省略されている場合もあるようですし。

資料のほうの抜けであればまだましですが。
資料上ではAX=9を返すことになっているのに、実際のコードにはそのような部分が
丸ごと抜けていた、ということだとかなり笑い話になってしまいます。
      - No.5020 -    このTreeへ    コメント元:5018 へ [リストへもどる] soft