名 前
件 名
本 文
暗証キー	（英数字8文字以内／修正・削除に必要です）

---

[1720] 祝 (^_^) 捌萬弐阡アクセス 投稿者：Mariya YAMADA 投稿日：2025/01/03(Fri) 19:22  

昨1月2日「捌萬弐阡アクセス」に到達致しました。ご訪問頂きました方々へ感謝申し上げます、有難うございました。

ご訪問頂きながら・・・な訳ですが、ついに「時代おくれ」復活の時が巡って参りました、今度こそ「カミングスーン」です。

　　詳細は「新春挨拶」とまとめてと思っていますが、諸般の事情に
　　より1月26日（以降）となる予定です。

時代おくれ、今後とも（今度こそ？）よろしくお願い致します m(_ _)m

> この1,000アクセスのトップカウンタ
この1,000アクセス、概ね2024年11〜12月は16.9人／日と明らかに「謎定数12」から増加しているが、Webalizerによる1日あたりの訪問者数は11月69人、12月62人と復活の兆しはない。
このアクセスカウンター値は何を反映しているのか (*_*)？

> この1,000アクセスのTop5（Webalizerのヒット数）
【11月】
279　/programming/language.html　フリーの開発環境
130　/pcat/pcat30.html　Windows95と必須パッチの確保
44 　 /pc98/waruagaki.html　PC-9801／悪あがき それでも捨てない
38 　 /pc98/desktop2.html　PC-9801 / デスクトップ 2
35 　 /pc98/epson.html　PC-9801 / Epson互換機

【12月】
325　/programming/language.html
209　/pcat/pcat30.html
59 　 /pc98/desktop2.html
44 　 /pc98/epson.html
42 　 /pc98/note.html　PC-9801活用講座 / ノート

圧倒的2強「プログラミング／フリーの開発環境」「Windows95と必須パッチの確保」と「PC-9801関連」がTop5で、番外に「Soft案内（の多分98絡みネタ）」が続く納得の並びである。

が、2ヶ月連続で番外ながらも「そこそこ上位」に「合法すれすれ研究所／マスク・わいせつ」が入ってきた。またリンクでも張られたかとリファラーを確認するもその形跡はない・・・管理者として思う、ここには「もっとまともで有用な情報」もありますけど、と (^_^;)

> この1,000アクセスの（突飛な）UA
【11月】
8.77%　Windows2000〜XP／IE6〜8
1.51%　Windows2000／FireFox12
0.04%　Windows7／FireFox55〜85、3.5.5
0.09%　Windows7〜8／Chrome57〜63
8.03%　Windows2000〜8／Opera9.80（Presto 12.02〜18）
　　　 ----- 計18.44％ -----
12.4%　fasthttp
0.02%　Go-http-client/1.1

【12月】
0.78%　WindowsXP〜8／IE6〜8
3.35%　Windows2000〜8／FireFox11〜76
0.40%　WindowsVista〜8／Chrome47〜79
20.7%　Windows2000〜8、Linux／Opera9.80（Presto12.02〜18）
　　　 ----- 計25.27％ -----
0.01%　fasthttp

前1,000アクセスで「MS IEが1％に迫る」と驚いたのだが、なんと11月は9％弱と世間一般の常識では有り得ない率、そして12月はまた1％を切った。この波は何だろう？
前回、理由のない（環境縛りでない）旧版FireFoxに？だったが、それに旧版Chromeが追加された。環境ごとの最終版ではなく、半端に古いブラウザを使う理由が思い当たらない。

8月の0.13％から右肩上がりで増加、ついに12月にはOpera9.80／Presto12が20％を超えた。雑多な環境が記録されているので1人の奇人変人（失礼 ^^ゞ）の痕跡ではなく「時代おくれ訪問者の5人に1人はOpera 12」と言う事になる。
世間に流布するUA優占率情報からは想像できない結果であるが、世間の統計が間違っているのか？ここがおかしいのか？って、それは完全無欠にここが俗世から乖離しているんだろう「時代おくれ」ここにあり！と。

辺鄙な旧環境を愛する皆様、差し支えなければ「その理由／思い」をお聞かせください、ここ伝言板でお待ちいたします m(_ _)m

> [1706] 祝 (^_^) 捌萬壱阡アクセス
> 11月1〜5日の集計であるが、
>　　1819（46.44%）　fasthttp
>　　　 2（0.05%）　 Go-http-client/1.1　
> と新たな謎UAと入れ替わっている。
> 「fasthttpもブロックリスト入り」にした

その翌日からワクワクしながらアクセスログを確認するも、その後なぜか途絶えてしまった。ブロックリストって、ブロックでForbiddenが増えるから楽しいのに・・・
来られると困るし鬱陶しいが、来ないとなんか寂しい。またおいでよ〜（そしてブロックされろ ^_^;）、っと我侭なワタクシ (^^ゞ

---

[1719] 賀正 (T_T) 2025（仮） 投稿者：Mariya YAMADA 投稿日：2025/01/01(Wed) 10:14  

2025年　巳年　あけましておめでとうございます、って世間では奇跡の大連休とかウカレテいるが、私は何の因果か12月28日〜1月4日の8連勤 (T_T)

正式なご挨拶は「私の正月」が来てからと言うことで・・・今日も只今より作業開始。できる人がやるのが当り前でしょ！って違う気がする。

---

[1718] ftp.riken.jp 投稿者：Mariya YAMADA 投稿日：2024/12/11(Wed) 13:10  

賽の河原から解放され、現在各OSの細かな設定中。

Debianのリポジトリには「信頼の（準）国家機関・理化学研究所／riken」を使っているが、ClamAV／ClamTKを導入しようとしたら「ダウンロードできないファイル」があって失敗になった。
偶々だろうと日を改めてトライするもさらに2度失敗。もしかしてとリポジトリを本家Debianに変更、一発で導入完了、100超のその他アップデートのおまけ付きで・・・

マルチ崩壊前のDebian7→12アップデート作業時、7月にはClamAV／ClamTK共に問題なく導入できたので、rikenサーバの不具合（ファイル欠損）はその後発生したと言うことになる。また、大量のアップデートからrikenの更新は本家より遅れていると推定される。

サーバの負荷分散で本家ではなく日本のサーバを使っているのだが、本家より遅れるのは（程度にもよるが）仕方がないとして、ファイル欠損は困る。

> 日本のDebianリポジトリサーバ
> https://www.debian.or.jp/using/mirror.html

サーバ負荷は分散せよと言うDebianの方針に従い、日本のサーバを使うとすれば次は「debian-mirror.sakura.ne.jp」かな？と考え中。

---------------------------------------
こうした不具合を何処に通知すれば良いのかわからない、のでしない。まぁ時期に気が付くだろう「くれいまぁ」さんもいると思うし (^_^;)

---

[1717] 六四天安門 投稿者：Mariya YAMADA 投稿日：2024/12/07(Sat) 08:42  

> 中国人留学生の入学阻害?
> 東京大学大学院サイトに閲覧しにくい細工
> https://news.yahoo.co.jp/articles/e83c8efa1aa7fd31270825a084a538f2b5b951a4

東大大学院の募集ページに、おそらく「中国からのアクセスを制限するため」HTMLソースに
> <meta name="keywords" content="六四天安門">
が追加されていたそうだ。

この事を褒める気はないが、この手の事件で何時も思うこと・・・見せない為のキーワード、これは思い付かなかった、カシコイ、と。なるほど、六四天安門とか新疆ウイグルとか習近平とか含んでいれば「中国政府が勝手にブロック」してくれる。

正直、中国からのアクセスを回避したいと思うことはあり、その場合「六四天安門の追加」は超お手軽。でもこれで制限されるのは一般の（善良な？）Net民で、問題の fasthttp や Go-http-client/1.1 な人達には効果ないんだよなぁ、残念。

---------------------------------------
> 魔法の呪文は「天安門事件」だけではない
> 中国からの無断転載を防ぐ「闇のライフハック」を考える
> https://president.jp/articles/-/61325

私が知らなかっただけで世間では良く使われる手法だったぽい。でも無断転載は人種国籍関係なし、そういう奴は何処にでもいる。
Googleで「OEM最終版＝OSR2.1＋ie4」を検索するとまぁびっくり、ここまでマンマだと清々（すがすが）しい？
これでは「出典のない引用＝パクリ」以外の表現はできない。少しは自分で考えて書き直せよ・・・その興味も知識もなければ「書かない」と言う選択肢もあるよ、と思う (~_~)

---

[1716] System Selector 3 投稿者：Mariya YAMADA 投稿日：2024/12/01(Sun) 19:31  

我家のハードウェア環境的には最新現行ソフトだが (^_^;) マルチブートの実現には20年物の骨董品を使っている。

　　マルチブート／パーティション管理ソフト「System Selector 3」
　　2003年4月18日発売
　　パッケージ版：7,800円　ダウンロード版：4,000円
　　製造：Acronis Japan
　　販売：キヤノンシステムソリューションズ株式会社

　　---- 以後 SysSel と省略 ----

伝言板を遡ると私は2010年頃からこれを使用している形跡があるが、積極的に選んだのではなく近所のリサイクル店で異様に安かった（500円？）と言う理由で使用している。

同等機能のCDとFD各1枚で構成され、
　　PC/AT（記載はないが32Bit？）専用
　　CPU：互換含みPentium 100MHz以上
　　メモリ：16MB以上（推奨32MB以上）
　　HDD：32MB以上の空き
　　ブート可能なCDまたはFD
　　PS/2マウス・キーボード（USB接続はBiosに依存）
　　DOS/Win3.1〜WinXPに正式対応（7も可能）
　　Linux／Unixと「超漢字」にも対応
　　Fat16〜Ntfs／Ext3に対応（つまり現行Ext4非対応）
　　PC Biosが対応していれば128GiB超のBigDrive処理可能

基本と論理の領域相互変換も可能、OS毎に表示するドライブが設定できるなど（王者Commander様を知らない ^_^;）私的には必要十分に高機能である。

----------------------------------------
今回のマルチブート環境構築では、これまでドライブ当たりOSは4が最多だったのを7まで増やした結果、明らかに難易度がアップ「あと一歩」のところでクラッシュ、やり直しが頻発「賽の河原状態」になった。
その主因は私がちゃんとマニュアルを読んでいなかったことだが、それ以外にSysSelとWindows（Setup）の謎現象も影響したと思う。

これまで適当に（想像で ^_^;）やっていたが、今回マニュアル片手に確認しながら操作した結果判明したこと≒正しい使い方＆謎現象。

　　SysSel本体はディスク上の位置は問わないがFat領域に導入する

　　SysSelを飛越して直にOSを導入してはならない、SysSel修正
　　インストールでそのOSは拾われるが、その以前のOS起動情報が
　　保存される保証はない（ほぼ保存されない）

　　　　これ↑に気づくまでに膨大な時間を浪費した (^_^;)
　　　　マニュアルには絶対にするな！と明記されていた (>_<)
　　　　まぁインストール作業を存分に堪能した、と納得しよう (^^ゞ

　　SysSel配下のFD起動で導入したOSはほぼ100％拾われる
　　しかし、Windows9xが拡張領域に導入できないなど謎現象が
　　起こる、その時全拡張領域を破壊してくれる (T_T)

　　WindowsはFD起動とCD起動で挙動差があり、さらにCD起動で
　　実行されるSetupとWindowsフォルダから手動実行したSetup
　　にも挙動差がある（システムチェックの項目が違う？チェックに
　　失敗している？誤判定でインストーラが頻繁に停止する）

　　直にCD／DVD起動で導入すると起動情報がほぼ100％破壊される
　　直に導入するとWindows間で干渉が起こる（被害甚大）
　　直に導入してもLinuxとWindowsは干渉しない（起動方式が違う
　　から？領域フォーマットが違うから？ほぼ無傷）
　　Windowsが壊した起動情報は修復インストールでの復旧率が低い
　　Linuxが壊した起動情報は（これまでのところ）100％復旧できる

　　USB接続のマウス・キーボードは他機種でも認識された経験はない
　　BigDrive対応と言うが現時点では微妙、さらに確認が必要
　　事故回避で同梱のFDISK.EXEをリネームして停止している

これらを踏まえ、ハードウェア縛り、手持ちOS縛りも反映した【Windows3.1、95、98、2000、XP、7とDebian12】を128GiBドライブに導入する最新手順＝数週間の試行錯誤の末に到達した現環境作業時のメモ。

■下準備■
256GiB 2.5"SSDの半分128GiBのみ領域確保して、残りは長寿命化期待で書込分散領域に充てる。この段階では128GiBなのでSysSel同梱のFDISK.EXEで作業し、下拵え完了後FDISK.EXEリネームで停止した。だからLinux領域がExt3で導入時にExt4変換をかけている。

　　基本1　Fat16　2GiB／SysSel本体、DOS、Windows3.1
　　　〃 2　Fat32　3GiB／Windows95（OSR2）
　　　〃 3　Fat32　4GiB／Windows98

　　拡張1　Ntfs　 6GiB／Windows2000（SP1→SP4）
　　　〃 2　Ntfs　30GiB／WindowsXP（SP1→SP3）
　　　〃 3　Ntfs　30GiB／Windows7（SP1）
　　　〃 4　Ext3　30GiB／Linux Debian12（インストール時にExt4へ）
　　　〃 5　Swap　 2GiB／Linux Swap

　　拡張6　Fat32 12GiB／OS間データ受渡用の共用領域
　　　　　 Windows3.1を除きアクセス可能

　　128GiBの残りの未使用領域が「拡張6」で、単純計算だと残りは
　　21GiBだが、各領域にヘッダー？が作られ目減りして合計は
　　119GiB＜128GiBになっている（と思う、多分正しいはず）

　　2024.12.04 追記：総枠で128GiB取ってそこ（内部）に領域を
　　次々に作っていく作業はSysSelでは難しい（できない？）ので、
　　下拵えの段階でGPartedを使っていた可能性が高い、気がする。

　　本当はSysSel／3.1のFat16領域のみ基本、残りは全て拡張に
　　したかったが、9xを拡張領域に導入すると全崩壊する謎現象が
　　解決できずこうなった。
　　9xや2Kの領域は小さいが「当時のHDDはこんなもん」だった

■OSの導入■
1) FD起動が難しいWindows7を普通にDVDからインストールする
2) SysSelをインストールして7を拾わせマルチブート有効にする
3) DVDからDebian12を通常インストール、SysSel起動情報はこわれる
4) SysSelをCD起動、修正インストールをかけると起動情報は復活する

　　Debianは随時導入で問題ない（ハズである）が、このタイミングを
　　選んだのは、後に回すとGrubにずらずらとその他OSが拾われ鬱陶
　　しい（リストアップ≠起動可能）ことと、起動情報復旧に失敗した
　　場合のやり直しを最小（Windows7のみ）にしたかったから

この後のOS導入の順序に都合はあるが縛りはないと思う
以下【SysSel配下のFD起動】で導入、起動メニューに自動追加される
FD起動であれば特定OSの個別再インストールもできる（事が多い）
他OSの存在が影響しないよう導入先以外の領域はSysSelでマスクした

5) FD起動でWindows2000 SP1導入（起動FDはCDに含まれる）
　 導入後、SP1からSP4にアップグレード
　 2000を先にしたのは2000から3.1 SVGA化、95の高速CPUや
　 512GiB超メモリ対応作業が行え楽だから (^_^)
　 これを7やDebianから行うと文字コード問題とか発生する（はず）

6) FD起動でDos／Windows3.1導入
7) FD起動でWindows95導入（95起動FDがCD-Driveを認識せず98用FD流用）
8) FD起動でWindows98導入

　 XP起動FDは現在無印用しか入手できないので、手持ちのSP1を
　 FD起動インストールすることができない、そこで
9) まず、FD起動でWindows2000をインストールする
　 その2000からCDのXP Setupを実行する
　 設定等は全て失われる、と警告されるのでそれをOK
　 領域初期化してWindowsXPを導入、メニューにリストされる
　 導入後、SP1からSP3にアップグレード

　 2024.12.03 追記：5)でインストール済の2000からXP Setupを起動し
　 インストール先にXP用の領域を指定しても直導入になってしまうハズ
　 ある領域に対しSysSel配下のFD起動でOSを導入することで「その
　 領域の起動情報が作られ、それをアップグレードする」作業が必要
　 だと予想（未確認）

これで全OSの導入が完了 (^_^)/

今回は手間を省き最初のOSとしてWindows7を普通にインストールしているが、この2000経由（場合によっては2000からさらにXP経由)であれば、7もFD起動扱いでピンポイント再インストールができるはず。

---------------------------------------
試行時には、気が付いたら起動しないOSが発生している、ある領域が無くなっている、NT系では「このドライブには互換性のある領域がない」「ドライブにOS/2がある」「ルートのファイルが多すぎる」など有り得ない理由でのインストール失敗や、マスクしてあるFat16領域にインストールされてしまう、など「謎現象」に悩まされた。確かに私が「直導入」を繰返したことも影響しているとは思うが・・・
インストールの順番を変えるなどしたが、なぜか全崩壊は最後の一つで起こる場合が多い（気がする、メンタルダメージMAX T_T）。

この賽の河原の試行錯誤、紆余曲折あってどうにか環境構築に成功したが、反復試行して再現性を確認していないので（多分大丈夫とは思うが）この方法で次もうまくいく保証はない。
また、個別OSクラッシュ時に再インストールで対応できる確証もないので、sda／システムのクローンを随時作成、システム全崩壊に備えることにした。これは「備えあるが出番なし」であって欲しい、と願う。

----------------------------------------
sda／システムのOS導入が済んだら、sdb／データドライブを接続する。これには128GiB縛りはなくBigDrive可、下拵えはDebian起動のGPartedで行う（SysSel同梱のFDISKはリネーム使用禁止にしてある）。

　　実はマザー／MS-6378はBigDrive非対応だが、Biosの制限を受けない
　　WindowsやLinuxが飛越してアクセスしている気がする。
　　だからSysSel同梱FDISK.EXEが128GiB超領域を破壊すると・・・
　　IDE BigDriveを使用した経験がないので良くわからない (^_^;)

試験的に512GiB 2.5"SSDを取り付けているが、128GiB Ntfsを3領域確保、残りは書込負荷分散領域として開けている。Ntfs領域としたのはBigDrive対応のNT系とLinuxのみアクセス可とするため。
Linuxでは厳密なセキュリティが保たれないNtfs使うな！と言う声もあるが、これまでNtfs常用で困ったことはないし、データ領域をExt4にしたらLinuxトラブル時に困るし、と。

----------------------------------------
構築完了から3週間ほどが経過、無意味にOSを切替つつSysSelであれこれ設定変更を繰り返しているが、システム／データの両ドライブに問題は発生していない。
これでSysSelによるマルチブート環境構築の最低限の目標は達成できた、と判断して賽の河原からリポートを終わります、Mariya YAMADAでした (^_^)

---

[1715] Windows3.1 SVGA化（改訂版） 投稿者：Mariya YAMADA 投稿日：2024/11/26(Tue) 18:43  

SVGA化成功の嬉しさで、不確かな情報のまま書いてしまいました。またもや1営業日で撤回、もはや「朝令暮改」君と呼ばれても仕方ありません、御免 m(_ _)m

2024.11.28 追記：先に[1714]にも目を通して頂ければ「なるほど」となる部分もあります、お手数ですがそちらもご参照下さい m(_ _)m

----------------------------------------
達成、成功とは言いながら、洞窟の暗闇を手探りで歩いて運良く遭難しなかっただけ、もやもやが残る。やはり地図と懐中電灯（今回の経験）をもって「危険の少ない最短ルート」を確認しようと、Windows3.1再インストールからやり直した。
なお、グラフィックはGeForce4 MX440 PCIを使用。

　　世間ではカス・ゴミ扱いのAthlonであるがWindows3.1の
　　感覚では超高速CPU、3分程度で再インストールができる。
　　毎回思うが1GiBメモリ搭載でエラーが起こらないのは謎、
　　素のままで main 64MB＋ems 1MB と認識している。

Windows3.1（Dell版）がデフォルトで持っているドライバ
　　VGA　←　最もベーシックな 640x480 16色
　　Super VGA (800x600, 16色)
　　Super VGA (800x600, 16色, 12 ドット システム フォント)
　　Super VGA (800x600, 16色, 20 ドット システム フォント)
　　- - - - - - - - - - - - - - -
　　COMPAQ QVision, 640x480x256, 16 ドット システム フォント
　　COMPAQ QVision, 800x600x256, 16 ドット システム フォント
　　COMPAQ QVision, 1024x768x256, 20 ドット システム フォント
　　- - - - - - - - - - - - - - -
　　Video 7 512k, 640x480 256色
　　Video 7 512k, 640x480 256色, 12 ドット システム フォント
　　Video 7 512K, 720x512 256色
　　Video 7 512K, 720x512 256色, 12 ドット システム フォント
　　Video 7 1MB, 800x600 256色
　　Video 7 1MB, 800x600 256色, 12 ドット システム フォント
　　Video 7 1MB, 800x600 256色, 20 ドット システム フォント
　　Video 7 1MB, 1024x768 256色 (12 ドット システム フォント)
　　Video 7 1MB, 1024x768 256色 (16 ドット システム フォント)
　　Video 7 1MB, 1024x768 256色 (20 ドット システム フォント)
　　Video 7 1MB, 1024x768 256色 (24 ドット システム フォント)
　　- - - - - - - - - - - - - - -
　　XGA (12 ドット システム フォント)
　　XGA (16 ドット システム フォント)
　　XGA (20 ドット システム フォント)
　　XGA (24 ドット システム フォント)
　　XGA (640x480, 16色)
　　XGA (640x480, 16色, 12 ドット システム フォント)
　　XGA (640x480, 256色)
　　XGA (640x480, 256色, 12 ドット システム フォント)
そして
　　その他の display (OEMのディスクが必要)...

> 　ET4000 xxx ・・・ Windows3.1がデフォルトで持っている
　　これは勘違い、generic_svga_driverで導入される。

このデフォ・ドライバで256色表示を試みると
　　COMPAQ QVision　→　画面崩壊（QVision専用）
　　Video 7　→　画面崩壊（Video 7は古いISA版カード？）
　　XGA　→　日本語環境では起動せず（IBM用？）
　　　　　 　（英米でも困っているので英語環境でも機能しないはず）

デフォ・ドライバで使用できるのは VGAとSuper VGA (800x600)のみで、当然、256色は非対応。
SVGA256.DRVを差換えれば動作するデフォ・ドライバが見つかるか？と期待するも、そもそもシステムにSVGA256.DRVが無かった。

ここで、SVGA環境を導入する、有益情報提供の両氏に感謝 m(_ _)m

> http://www.vogonsdrivers.com/getfile.php?fileid=836
> generic_svga_driver_(windows_3.1)_(3.5).7z
>(http://www.vogonsdrivers.com/files/downloader.php?fileid=836)
これをフォルダに展開（勿論、FD展開でも可）

　　7zを展開するとFDイメージ「disk1.img」が得られ、Linuxでは
　　普通にマウントして中身をフォルダにコピーできた。
　　Windows11では「ファイルが壊れている」でマウントできなかった。
　　調べたところ、Windows標準ではimg＝CD／DVDのisoイメージで
　　FDイメージを処理するには何かソフトが必要になる。
> 　https://www.vector.co.jp/soft/win95/util/se107750.html
　　このDiskExplorer（フリー／インストール不要）がお勧めかと。
　　あぁ〜ZIPぢゃない！とかまでは面倒見ません (^_^;)

> https://www.vogons.org/viewtopic.php?t=20130
> svga256.zip
>(https://www.vogons.org/download/file.php?id=5584)
これを展開して得られるSVGA256.DRVをgeneric_svga_driverフォルダのファイルと差換える（念のため旧ファイルはリネームして残す）。

　　このドライバはWindows[3.11]からの流用ではないかと想像する。
　　SVGA256.DRVの差替えなしだと「画面崩壊」で操作不能になる。

システムのセットアップで「その他の display」を選択、OEMディスクに「generic_svga_driverフォルダ」を指定して導入、再起動で問題なくSVGA化された。

> 　先にIBM版で失敗していることが成功の秘訣、超常現象の発生源
　　この一番手を焼く厄介な可能性が排除されて一安心。

　　Dosプロンプト（Dosモード）を起動し全画面からWindow表示に
　　したとき、Window表示にしなくてもDosプロンプトを終了した
　　とき、画面が崩壊し操作不能で要リセット再起動となる。
> 　https://www.vogons.org/viewtopic.php?t=20130
　　ここでも話題になっており「DOSアプリは避ける」とある。
　　差換えたSVGA256.DRVと無関係なSuper VGA (800x600, 16色)でも
　　発症し、NEC版PC-9801用でも記憶にあるので、このSVGA256.DRV
　　固有の問題ではなく3.1のバグだと思う。
　　Windows3.1の場合、DOSアプリも重要資産であるがVGA（640x480
　　16色）では発症しないので、切替えれば問題を回避できる。
　（つまりSVGA化していなければこの問題には遭遇しなかった、と）
　　DOSプロンプトのPIFファイル（起動設定ファイル）修正で解決
　　できそうな気もするが、それは宿題、と言うことで。

MS-6378オンボード（内部AGP）のTrident CyberBlade/i1での動作も確認できたので「SVGA256.DRV差換え」はNvidia系Trident系で使える汎用性の高い解決法と思われる。現時点では確率2／2でなんと成功率100％ (分母100以下に％使うな！誤差を拡大するな！って叱られた記憶があるなぁ ^_^;）。

　　なお、CyberBladeは明らかにMX440より遅く、起動に
　　もたつき「Windows3.1の青い起動ロゴ」を（一瞬だが）
　　久しぶりにみた。なつかしぃ〜 (^_^)

generic_svga_driver導入で
以下がWindowsのドライバリストに追加されている
　　Super VGA 640x480 256 colors
　　Super VGA 800x600 256 Large
　　Super VGA 800x600 256 Small
　　Super VGA 1024x768 256 Large
　　Super VGA 1024x768 256 Small
　　- - - - - - - - - - - - - - -
　　ET4000 640x480 256 colors
　　ET4000 800x600 256 Large
　　ET4000 800x600 256 Small
　　ET4000 1024x768 256 Large
　　ET4000 1024x768 256 Small

高速なゲームでは速度差などがあるかもしれないが、通常操作ではSuper VGAでもET4000でも問題なく動作している。
>　 https://ascii.jp/elem/000/000/698/698677/
　　Windows以前のPC／ATを（リアルタイムでは）知らないため
　　ET4000と聞いても？だったが、1989年Tseng Labs社発売の
　　DOS（特にゲーム）用のデファクトスタンダードで「超高速」を
　　売りに一世を風靡していたと言う。秘蔵コレクションの段ボール
　（物は言いよう (^^ゞ）にあるかもしれない。
　　ET4000はET6300まで継続するもWindowsのアクセラレータ機能
　　への対応が遅れ失速（墜落？）、ATI社へ（特許・工場・従業員
　　もろとも）事業売却され、それがRage 128を経て今のRadeonへ
　　発展しているそうだ。
　　この血縁から判断してNvidia系Trident系に加えATI系でも今回の
　　方法が使えそうな気がする（ET4000用ドライバがET4000系で
　　使えないというのは考えにくい）。

解像度変更時のリストに元々の使えないドライバが入り混じって表示され鬱陶しい。それっぽい情報がSYSTEMのSETUP.INFにあったので、Rem化したが消えなかった。
まぁ今はSVGA化の嬉しさで無意味に頻繁に解像度変更をしているから気になるが、時期に飽きて気にならなくなるでしょう、きっと (^^ゞ

----------------------------------------
不幸にして「SVGA256.DRV差換え」でうまくいかず、画面が潰れてしまった場合は、
　　Windows起動前のDosプロンプトからWINDOWSフォルダに移動
　　C:\WINDOWS > setup でDos版Setup起動
　（C:ルートのSetupだとインストールになるので注意）
　　素のVGA（640x480 16色）を選び復活させる

この「SVGA256.DRV差換え」を試された方、フィードバックを伝言板に頂けると助かります m(_ _)m
なお「ぶっ潰れたぞ、どうしてくれる！」はご遠慮下さい (^^ゞ

---

[1714] 祝 (^_^) Windows3.1 SVGA化 投稿者：Mariya YAMADA 投稿日：2024/11/24(Sun) 21:59  

前々回（2012年）のマルチ環境構築時、Windows3.1のSVGA化（高解像・256色）にかなり頑張ったが達成できず、デフォルトの640x480／800x600の16色モードしか使えなかった（グラフィックはMS-6378オンボードのTrident CyberBlade/i1）。

前回（2017年）はグラフィックがTridentからさらに新しいGeForce4 MX440 PCIになり、これは無理だろうと諦めモードで、あまり真剣に頑張らなかったので16色のまま。

今回はSSD化で盛り上がった勢いそのままに各OSセッティングに突入しているが、なんと「情報収集から1時間でWindows3.1、1024x768、256色を達成」できてしまった。
Web上には MX440では不可能、諦めろ、とする意見もあるのでこれはGeForce4だからではない。何か摩訶不可思議な力が作用した超常現象と思われ、その記録をここに残し末永く後世に伝える (^^ゞ

●私が取った手順
以下を展開して「OEMドライバを使う」でフォルダを指定
　　http://www.vogonsdrivers.com/getfile.php?fileid=836
　　generic_svga_driver_(windows_3.1)_(3.5).7z
　（http://www.vogonsdrivers.com/files/downloader.php?fileid=836）

何か一つ適当に選び指示に従いインストール
さらに指示に従いWindows再起動
この段階で画面はグチャって操作不能になる
　　ここでOKなら設定完了だが、30年前のVGAカード、それこそ
　　ISA版でも使っていない限りそんな幸運はないはず、ってか
　　その場合3.1インストール時点でSVGAになっていると思う

動作はしなくてもインストール時に
以下がWindowsのドライバリストに追加されている
　　Super VGA 640x480 256 colors
　　Super VGA 800x600 256 Large
　　Super VGA 800x600 256 Small
　　Super VGA 1024x768 256 Large
　　Super VGA 1024x768 256 Small
以下は（多分）上書きで追加されているはず
　　ET4000 640x480 256 colors
　　ET4000 800x600 256 Large
　　ET4000 800x600 256 Small
　　ET4000 1024x768 256 Large
　　ET4000 1024x768 256 Small

Windowsを終了（＝リセットPC再起動）

今回はマルチブートなので別OSから簡単に操作できたが、通常はCD起動Linuxとか何らかの方法で頑張って、以下を展開して svga256.drv を差し替える。なお旧ドライバは保険にキープしておくこと。

　　https://www.vogons.org/viewtopic.php?t=20130
　　svga256.zip
　（https://www.vogons.org/download/file.php?id=5584）

これでWindowsを再起動すると貴方をカラフルな世界が待っている、以降は上記リストのすべてが使い放題 (^_^) 夢の1024x768 256色！

よく考えると、展開したgeneric_svga_driverフォルダのsvga256.drvを先に差替えておけば「後から差替え」の面倒なく一発で終わる気がする。その場合でも、旧svga256.drvを事前に確保しておかないと不都合があった場合に元に戻せなくなるので注意。

　　署名はともにMicrosoftで年はCopyrightから推定
　　旧svga256.drv　4.0.0.52490　1992年
　　新svga256.drv　3.11　　　　　1993年

　　新しい方のバージョンが低く、それが新しいカードに対応する謎
　　　　新ドライバは英語掲示板でPatched Driverと表現されており
　　　　CopyrightからもWindows[3.11]用の修正版流用か？と思う
　　　　根拠はないが個人でパッチしたものではない気がする
　　この有力情報は2008.12投稿で初回構築時にあったはずであるが、
　　それが今まで見つからなかった謎、これが最大の超常現象かも

ET4000 xxx でも問題なく動作しているが、このドライバはWindows3.1がデフォルトでも持っているので、これを使うのであればsvga256.drvの差し替えだけで良かった可能性がある。これはWindows再インストールで素に戻さないと確認できない（からしない、何方かご確認を）。

●不幸な事故は起こるもの (^_^;) その場合は
　　自動起動ではなく C:>win で起動している前提
　　そうでない場合は Autoexec.bat の最終行 win を削る

DosプロンプトでWindowsに移動
　　C:\Windows > SETUP でDOS版のSetupを起動
　　　　C:ルートだとインストーラが起動するので区別する
　　素のVGAを選べば画面は復旧する（640x480 16色）
　　それで復旧できないなら指示外の何かをやらかしている、
　　自身でがんばって復旧されよ
　（次の作業に備え旧svga256.drvに戻しておくこと）

●IBM版ならこちらが都合よいかも／ 我家のDell版ではエラーが出た
　　https://diarywind.com/blog/e/generic-svga-driver-for-ibmw31.html
　　svga.exe
　（http://www.conradshome.com/win31/files/svga.exe）
　　サイトの指示に従いOEMSETUP.INFは書き直す、実機なら手順(3)不要

リストに追加されるのは以下のドライバ
　　Super VGA 640x480 256色 ゴシック 10pt.
　　Super VGA 800x600 256色 ゴシック 10pt.
　　Super VGA 800x600 256色 ゴシック 12pt.
　　Super VGA 800x600 256色 明朝 12pt.
　　Super VGA 1024x768 256色 ゴシック 10pt.
　　Super VGA 1024x768 256色 ゴシック 12pt.
　　Super VGA 1024x768 256色 明朝 12pt.

実際はこちらを先に試して（IBMのフォントがない？で）インストールに失敗するも、リストには追加されていた。その後でgeneric_svga_driverを導入したら、ナゼカ少なくともリストの2つはエラーなしで指定できるようになった。
鬱陶しいからリストから削除したいのでその方法を考え中。

先にIBM版で失敗していることが成功の秘訣、超常現象の発生源、と言う突飛な可能性はないと信じる、これ以上問題を複雑にしないでくれ (^_^;)

----------------------------------------
これは、3.1用PCI Sound Blasterドライバと並び「PC／AT」更新の目玉情報、早く書かねばって、この情報が貴重なことは確かだが、世間一般的には有益情報ではないだろうな、多分。

画像ビューワSusie16は256色以上が動作条件、以前からファイルは確保してあったが今回初めて起動した。右クリックメニューにびっくり、そうか当時はアプリで個別に対応していたんだ、と思い出した。

初回構築でネットワーク、2回目でサウンド、そして3回目でSVGA化、Windows3.1セットアップの3鬼門を制覇、気分爽快 (^_^)/

---

[1713] 容量の壁、突破？ 投稿者：Mariya YAMADA 投稿日：2024/11/22(Fri) 22:52  

マルチブートローダー／System Selector 3（以後SysSel）はドライブ先頭にインストールしてあり C:\BOOTWIZ にプログラムがある。

　　BOOTMENU.EXE　ブートマネージャ（起動メニュー本体）
　　EDIT.EXE　コンフィグレーションマネージャ（起動情報編集）
　　FDISK.EXE　パーティションマネージャ（ディスク情報管理）

このFDISKが非対応であるためBigDriveが使えない（使うと危ない）。

BOOTMENUはEDITで作られた起動情報を元に各OSを起動する。SysSelはOS毎にドライブのマスクが可能で便利であるが、その情報はEDITで編集する。その際にドライブ情報をEDITに提供するためにFDISKが全領域スキャンを行うらしく、128GiB超領域があると打首になる。

であれば、このドライブのマスク設定を触らなければ128GiB超ドライブがあっても問題はない・・・って、人間はミスをするから困っている。
このFDISK (~_~) コイツさえ居なければ大容量ディスクが自由に使えるのに、と思った所で閃いた「なら居なくなればいいんだ」とFDISKをリネームして起動不能にしてみた。

SysSelのメニューからFDISKを呼び出すと、エラー再起動になるが実害はない。EDITでドライブのマスク設定を触るとエラーメッセージなどは出ないが、反映される場合と無視される場合がある。その理由条件は不明だが、いずれの場合も128GiB超領域が破壊されることはない。

FDISKリネームでEDITに起こる不都合は、今のところこの「ドライブマスク設定の不安定化」のみで、他の機能に影響はないっぽい。流石の私も「勘違い」で「手間暇かけてFDISKのリネームを元に戻す」ことはしない（と思う ^_^;）。

FDISK削除にしないのはEDITに不具合が発覚した場合や、どうしても必要になった場合に備えているのだが、マスクをかけC:\BOOTWIZにアクセス出来るのは（常用はしないであろう）Windows2000のみに制限しているので勘違いで復活する確率は限りなく低い（はずだ ^_^;;）。

一番危惧される状況はSysSelの起動情報が破壊された場合に行う「CD起動の修正インストール」で、自動的にFDISKが生き返り修正時にBigDriveが接続されていると128GiB超領域が失われてしまう可能性大、ってかMAX！
これは要注意だが、これに気をつける、修正時に「確実にBigDriveをガードする」で問題は無い（よね ^_^;;;）。

と言うことで[1712]のBigDrive禁止令は1営業日であっさり撤回された。

----------------------------------------
改めて確認するとマニュアルには
　　System Selector 3にはこのような制限はありません（IDE137GBを
　　超えるいわゆるBig DriveについてはPCのBIOSに依存します）。
とある。が、なぜか実際には機能していない。

他のマザーや本物のIDE BigDriveでSysSelを使った経験がないので何とも言えないが、原因はMS-6378（マザー）との相性なのか？変換アダプタを挟んでいるのが気に入らんのか？

あるいは変換アダプタやSSD本体のチップが機能して128GiB超領域にアクセスできているが、実際にはMS-6378はBigDrive非対応であるとか、「そもそもIDEドライブではないから」も否定はできんかも、Windowsでは電送バスがSATA認識されているし。

未記入のユーザーカードがあるので「登録してCanonに質問するか？」って、20年前に終売した製品、しかもこんな変則環境、だれも回答できないだろう。そこに食い下がるのがカスハラモンスターの真骨頂であるが、私はそうではないので（ハズである ^_^;）。

まぁ、現時点では一応使えているので「良し」とする、深く考えない、リクツは要らん、動けば勝ちだ！って疲れて（or 飽きて）雑になってきた気がする (^^ゞ

----------------------------------------
SSD版マルチブート（Windows3.1〜7／Debian12）Athlonはほぼ完成形、早くPC／ATに反映したい！と盛り上がり中、新タイトルは「PC／AT貧乏録」予定、って狼少年の信用はゼロ (^_^;;)

2024.11.23 追記：
> PC-9801活用講座／デスクトップ 2
> https://h2dion.sakuraweb.com/pc98/desktop2.html
> 9801が認識できる上限は540MB（IDEの壁）ですが・・・IDEの壁は
> Biosの制限なので、Biosを経由せず直接ディスクにアクセスする
> Windowsにはこの制限は及びません。したがって、Windows上で
> フォーマットすればハードディスクの540MB超領域も使用可能です。

これは「変換アダプタやSSD本体のチップが機能して・・・」とか、そんな面倒複雑な問題ではなく「単にコレ」な気がしてきた。
つまり、6378がBigDrive非対応であると（マニュアルには記載なし）。その場合、Bios設定画面ではsda 256GB／sdb 512GBと正しく表示されており、サイズを認識できて管理はできないことになる。
なんか不自然な気がするが「PC9801で超過領域がBios上で表示されていたか？」はまったく思い出せず。98DOS Fdiskでは最大値として504MiB以上が提示されるが、それを指定すると起動不能になったような記憶もあるが定かではない。

忘却のための十分な時間が経ってしまったのか「単にボケ始まっているのか」若干不安な今日この頃 (^^ゞ

---

[1712] 容量の壁128GiB 投稿者：Mariya YAMADA 投稿日：2024/11/20(Wed) 19:46  

CHS方式（1983年？）の504MiB（メガ！）の壁に始まり、もう大丈夫、これで大丈夫と最大容量を拡張しつつ、IDE（ATA）規格はストレージの大容量化とイタチごっこを繰り返してきた。1994年に真打ち登場、全セクタに通し番号を振り一意的に管理する28ビットLBAで今後困らない（とその時は）言われたが、その理論最大値は1セクタ512Byte × 2の28乗。

　　512×2^28=37438953472Byte
　　2の10乗＝1024がデジタルで言うところの「セン」
　　1KiB＝1024Byte、1MiB＝1024KiB、1GiB＝1024MiB　なので
　　137438953472Byte÷1024÷1024÷1024＝128GiB

　　これを横着して実生活の1000「セン」で割ると
　　137438953472÷1000÷1000÷1000＝137.4GB

　　だから　128GiB＝137（.4）GB　で間違ってはいない（のか？）

　　最近（特にLinux系で）よく見かけるこの小文字の[i]が入った
　　表記は「これは正確ですよアピール／カッコつけ」だと思って
　　いたが、この混乱を静めるためにGi（ギビ）やTi（テビ）が
　　規格化されていたらしい。今後は正しく使いませう。

脱線したが、今にして思うとわずか128GiB、2000年過ぎには現実の製品／ユーザの要望に追いつかれ破綻した、それが128GiBの壁。それを踏まえて2001年に48ビットLBA、所謂BigDriveが策定され理論上は128PiB（≒13万TB≒1憶3千万GB）まで使用可能、さすがにこれは「まだ」飽和していない。

我家のMS-6378がBigDrive非対応だと勘違い、手持ちIDEディスクが最大128GiBだったこともあり常にその制限内で生活してきた。今回SATAディスクを取り付けて勘違いが発覚したが、システム（sda）は耐久性重視、256GiB 2.5"SSDを採用し128GiBを領域確保、残り128GiBは消耗を分散させるバッファとして使う「お大尽な作戦」をとる。

　　5〜6個の使用不能になったSATA SSDをチェックした経験が
　　あるが、記憶領域（チップ）の寿命＝不良セクタバリバリは1台
　　のみで、他は突如領域が消えるとかデータが飛ぶとかコントロール
　　チップの不良が疑われた。書込みを分散させてもコントロール
　　チップの負荷は同じなので、大容量の書込分散用領域を与える
　　ことで顕著な長寿命化が図れるかは謎だが、その答えは10年後に
　　出るでせう。

128GiBに拘らなければ、SATAのHDD／SSDは複数手持ちがあるのでデータ領域は贅沢に (^_^) と早速取り付けた。

512GiB 2.5"SSDをsdbに接続、大広間で暮らし慣れていないので、四畳半128GiB単位で領域を切り128×3領域＋書込分散領域128として旧HDDからデータをコピー。sdaのシステムセッティングも平行して行っていて、ふと気がついたらsdbの領域がなくなっている？

同じことが3度繰り替えされ、SSDの不良を疑い320GB 3.5"HDDと付け替える。領域設定やデータコピーは問題なくできるが、このHDDも領域が飛んでしまう。BigDrive対応のマザー＆OSなのに、なぜ？
設定作業ステップ毎にsdbを見張っていて発覚、ブートマネージャー／System SelectorがBigDrive非対応 (>_<)

付属のパーティションマネージャは128GiB超領域を半端に認識し、フォーマットなど操作は受け付けるが、実際には領域を飛ばすだけ。パーティションマネージャを使用禁止にしても、ブートマネージャで起動設定を触ると（あるタイミングで？）パーティションマネージャが全領域をスキャンして先頭の128GiB領域を残して他を打首にしてしまう。
認識されるからいけない、認識できない様に敢えて128GiB超領域を先頭にしたら全領域を飛ばされた。

sdaのシステム領域セットアップが完了するまで、sdb以降のデータ領域は取り付けない、データ領域取り付け後は設定を触らない、ピンポイント再インストールなどが必要になった場合は、システム領域以外は取り外すかBiosで隠す、これでBigDrive運用は可能ではある。
しかし人間のすることであり勘違いのセットアップ起動は防げず、私は人間の中の人間である自覚があり (^_^;) その度にデータを失っていては耐えられない。

折角のBigDrive対応であるが「全ドライブ128GiB制限」をかけることにした。512GiB SSDの75％を未使用とするのは流石に無意味そうだし、HDDでは明らかに無意味だし・・・データ領域用にも128〜256GiBのドライブを調達せねばならん。

　　【必殺パーティションずらし】以前はHDDに不良セクタが（大量）発生
　　したとき、その部分を使わないように領域を確保して凌いでいた。2GiBの
　　HDDに3領域取られているが合計でも1GiBない、とかあった。その要領で
　　HDDの領域を128GiB単位で確保、寿命に達したら次の領域（物理的に別
　　の場所）へ移動する。これを繰り返せば無駄なくHDDを使えるかもしれ
　　ない、が、今はそこまで頑張らない (^_^;)
　　
　　プラッター上のクラスタは連続ではないので無意味である、とその当時
　　も否定されることが多かったが、実際にやってみると「不良クラスタに
　　ヘッドが行かない」ためエラーでコケなくなりHDD延命には効果があった。
　　文章はちゃんと試してから書け！と思った、今も思う。

この128GiB縛りで最大でも128×3＝384GiB（DVD抜いても512GiB）までしか積めない。クラッシュ前は82（sda／主にシステム）＋128（sdb／主にデータ）＝210GiBで運用していたので、384GiBでもかなり大きくなるのだが、なんだか物凄く損した気分、さようならBigDrive、短い夢だった (T_T)/~~~

----------------------------------------
System Selectorを使ったMS-6378のマルチ環境構築は、今回が3回目（4回目かも）。何度思い返しても自分が128GiB超IDE HDDを所有した記憶はないのだが、過去にも同じ経験があって、マザーがBigDrive非対応と思い込んでいたのかもしれない。
最近記憶が本格的に怪しいので「頑張って外部記憶を残そう！」とせっせと書き込む今日この頃、って書いた事忘れるんだよね (^_^;)

----------------------------------------
2024.11.21 追記：Linuxのドライブ表記が間違っていたので修正しました。ここ暫くの書込は全滅だと思います。正しくはa、b、c・・・がドライブナンバー、次の数字はドライブ内のパーティションです。
ので　sda1→sda　sda2→sdb　と脳内変換をお願いします m(_ _)m

---

[1711] Nvidia-driver 投稿者：Mariya YAMADA 投稿日：2024/11/16(Sat) 13:14  

RyzenにDebianインストール後、non-freeなNvidia-driverではなくfreeのNvidiaドライバ／nouveau（ヌーボー）が適応されていることは把握していた。

特に困っていないのでそのままにしていたが、動画処理でcudaを使うためにNvidia-driver／cudaを導入、再起動したら解像度1024x768固定で画面関係の設定はグレイアウト全滅、Nvidia-driverが読み込まれていない。

情報収集の結果、Nvidia-driverはMicrosoftから署名を得ていないため「Secure Bootでブロックされる」事が判明。解決方法は「非UEFI／Secure Boot OFF」って、それは解決ではないだろう。

さらに情報収集、Nvidia-driver用に独自の署名と鍵を作り、それを（初期情報である？）shimに組込めばブロックされない事がわかった。

> [1701] 雷神、起動セズ・・・（未完）　Mariya YAMADA　2024/08/29
> 使用者の判断で例外が追加できる（リストの編集ができる）と便利
> なんだが、確実にそれは「穴」になるだろう。
うん、やはり方法はあった、ならGrubを各自で署名すればあの問題は解決ではないのか？と素朴な疑問が起こるが、それは置いといて・・・

> https://fedorakenken.doorblog.jp/archives/nvidia-driver-proprietary-dkms-secure-boot.html
ここを参考にNvidia-driverの組込みを行った、多謝 m(_ _)m

　　2024.11.17 追記：現行カード用Nvidia-driverの導入下準備として
　　既に組み込まれているnouveauの停止・無効化作業（結構面倒くさい
　　手作業）を指示するサイトも多い。
　　確かに32bit版では必要だったし、64bit版でも旧カード用のドライバ
　　では必要なのかもしれない。しかし現行カード用のNvidia-driverは
　　自動でnouveauを停止、再起動時に無効化してくれるので必須ではない
　　と思う。参考サイトにその指示はなかったし、現に下準備なしで問題
　　なく導入できている。
　　手作業nouveau打首のほうが安全確実な可能性はあるが・・・面倒は
　　避ける、省略可能なら省略する、その方向で (^_^;)

Nvidia-driverはリポジトリにnon-freeを追加すればSynapticパッケージマネージャなどで普通にインストール「は」できるが機能しない。この導入時に /var/lib/dkms/ にNvidia-driverがmok.keyとmok.pub（どちらかが署名でどちらかが鍵？見事に理解できておらず ^_^;）を準備しているので、これらを手作業で作成する必要はない。

管理者権限でこの署名／鍵を（shimに？）インポートする。
　　mokutil --import /var/lib/dkms/mok.pub
　　使い捨てのPasswordを設定し再起動

再起動後の青画面で何かキーを押し設定に入る（押し損ねて通常起動した場合はインポートからやり直す）
　　[Enroll MOK]→[Continue]→[Yes]→[Password]→[Reboot]

再起動時にdkmsサービスが実行されモジュール(shim？）をリビルド、Nvidia-driverが署名される。

　　情報元では「しばらく待っているとモジュールのビルドが実行されます」
　　となっているが、普通に再起動してしまい「失敗か？」と焦ったが確認
　　するとドライバは読込まれ正常に機能していた。雷神様が速すぎて一瞬で
　　完了／待ち時間なしだったらしい、少し嬉しい (^^ゞ

dkmsってG-mail遅延問題でも出てきた気がするが、これの本当の意味は分っていない。ネットワーク音痴／セキュリティ音痴な自分が最も不得意とする部分、そんな自分が触ってよい物なのか甚だ疑問であるが、とにかく解決はできた、と言うことでオワル (^_^;)

---