先日は、
の中でクラスについて書きましたが、クラスでは、
■ 変数
■ 処理
をクラスで宣言して、 【 仕様書 】 を作ります。この時に、
■ 動き（メソッド）
■ 動きに必要な変数（インスタンス変数）
を指定する事になりますが、これは 【 枠組み 】 なので、
■ 何をするのか？ 【 確定した事象 】
■ 処理に必要な値 【 不確定な物 】
の構造になっていますから、この 【 不確定な物 】 の部分を個別のオブジェクトで指定して使い分ける事になります。
クラスの使い方ですが、 【 クラス 】 と言う仕様書を書きます。ここで前述の、実装する変数とその変数を使ってクラス内の関数であるメソッドを実行する事になりますが、関数と同じように、引数を使ってクラス内での処理を行う事になります。クラスの場合、
インスタンス名 ＝ クラス名（実装した引数）
で、 【 数値を所有したオブジェクトを用意する 】 必要があります。これを作る作業が 【 インスタンス化 】 と言いますが、実質的に変数があって、名前を付けて変数を格納したオブジェクトを用意しているので、 【 名称を付けてプリセットを作っている 】 ような感じになります。このプリセットを作る事で、
インスタンス名.メソッド名（引数）
という形で処理を実行できるようになります。
関数と変数については、
の中で触れていますが、基本的に関数を実行する時には、
【 関数名（引数） 】
で実行する事になります。その為、引数をタプル用の中たちで値を格納すれば、同じ関数に対して違う変数を使う事もできますが、この場合、 【 変数名 】 で数値を入れ替える事になります。と言う事は、管理が少し難しくなるのと、関数の場合、クラスで行える継承などの処理が出来ません。
その為、簡素な物だと変数と関数の組み合わせでも大丈夫なんですが、製作したクラスの引数を別のクラスで継承して呼び出して使用して、別の引数と組み合わせて、その引数を変数としてメソッドで使うような処理も行えるようになっています。
その為処理が複雑になると、関数で対応しようと思うと煩雑になるので、関数ではなくクラスを使う事になります。
また、クラスの場合、
【 どのオブジェクトで 】 . 【 どのメソッドを使っているのか？ 】
と言う形で処理を実行していますから、処理が何なのかを判断しやすくなっています。つまり、ここの部分で挙動がおかしい場合、
■ インスタンス変数がおかしい
■ メソッドの作りがおかしい
■ インスタンスの選択を間違えている
■ メソッドの選択を間違えている
など処理の構造から問題が発生していそうな場所を特定しやすくなります。
P ythonを使う
Pythonを使う場合、PythonをインストールしてIDLEを使ってもいいのですが、インターネット接続か尿がある場合だと、
■ VisualStudio Code
https://code.visualstudio.com/
では、Jupyter Note Bookが使用できるので、コマンド単位でソースコードを実行できるので、部分的にコードを書いて行って実行する事ができます。
■ Jupiter
その為、コマンドプロンプトとIDLEを往復するようなことがなく、その場でコードを書いてコードの枠の下で実行する事が出来るようになっています。なので、
のような処理もできますが、外部ライブラリも複数使用できるので、
のようにMatplotとかもコード内でimportをするだけで使用できるますし、
のようにnumpyもimportするだけで使用する事が出来るようになっています。
Jupytrer Noteについては、
■ Jupyter Notebook 【 Python&Visual Studio Code 】
で触れていますが、Jupiterのサイト自体にアクセスする方法もありますが、VisualStudioCodeでもサポートしています。
あと、VisualStudio関連だと、先日、VisualStudio 2022がリリースされました。IDE自体が、64bi化したので、メモリ―アドレスが4GBで頭打ちになるようなことがなくなりました。
今までは、メインプロセスの 【 “devenv.exe” 】 が32bitだったのですが、32bitのアプリケーションで発生する4GB以上のメモリーが使えないので、すが、これがなくなっただけでもかなりメリットがありそうです。
64bitの処理をしていても32bit版のアプリケーションは開発できるので、内部処理が既存のアーキテクチャの性能をスポイルしなくなったと考える事が出来ますが、メモリー不足の問題は減りそうです。
32bitのメモリ―アドレスですが、2の32乗の数値を1024で割って言った数値が4095MBになるので、それ以上のデータを扱えなくなるという問題が存在しています。この上限が、メモリ―アドレスではなく使用するデータ全てに影響を及ぼすので、FAT32では1ファイルが4GB以上のデータを作れませんし、32bit OSでは、仮想メモリー領域も１パーティションにつき4095MBまでしか使用できません。当然、メモリ―アドレスにそう言った制約がある場合、システムとOSとバックグラウンドサービスと常駐ソフトでメモリーを消費した条件で残りのソフトウェアの容量を扱う事になりますから、32bitノソフトウェアでは、1.5GBしかメモリーを使用できないという問題もあります。
あと、MVVMでは、XMLの拡張のXALMとC#を使っていたので、UIの実装は、XAMLの記述で行い、処理をコードで行うような仕様でしたが、Mono/XAMARINと統一された仕様の.NET MAUIが使用されているので、単一のコードの中でUIを記述できるようになりました。
ある意味、XAML+C#の記述は、HTMLでフォームを作って、そのフォームのウィジェットのアクションを受けてC#のコードを動かすという流れだったので、他のコードを書く場合でもフォームを使った操作だと見慣れた仕様でしたが、これをフォームを実装する―ブジェクトの記述を行って、そのオブジェクトに対してコードを書くことで、1つのファイルで指定できるようになっています。
また、.NET6をフルサポートし、C++20にも対応しているようです。
Pythonを使う場合に、コードを書くエディタを使う事になりますが、統合環境を使うと、
■ コーディング ： コードの作成
■ デバッグ ： コードの実行
■ ビルド ： 実行形式にする
と言う作業が行えるようになっていますが、殆どの統合環境では、ワープロソフトやスマホなどで見かける 【 予測変換機能 】 が用意されており、文字列の流れから 【 該当しそうなコード 】 を表示してくれる機能があります。この機能を 【 スニペット 】 と言いますが、これがあるので、入力がしやすくなっています。
スニペットについては、Powershellでコードを書くときにもPowershellのコマンドレットを使う場合もスニペットが使用できます。（ヘルプも右側に出す事が出来ます。）
また、オンラインでスニペットの追加などもできるので色々と使いやすい部分があります。そしてもう一つ、 【 プロジェクトファイルを扱っているフォルダーを表示して、そこを基準にファイルの管理が出来る 】 仕様になっています。
これは、殆どのツールがそうなっていますが、Visual StudioやVisual Studio Codeでもそう言った仕様になっています。
その為、 【 プロジェクトファイルを作成後には、その作業フォルダー内でファイルの追加や編集が出来る 】 仕様になっています。
■ 統合環境を使う場合
VisualStudioに限らず、殆どのソフトで最初にプロジェクトファイルを作って、そこから作業をすることになりますが、この方法を取った方が都合がいいので、最初にそれを行う仕様になっています。これもどのツールでも同じなのですが、 【 エイリアスの固定 】 をする為に最初に作業フォルダーの位置を決めて、作業をすることになります。
■ エイリアスの変化
エイリアスの固定と言っても解りにくいので、違う言い方をすると、パスの状態の確定になりますが、この作業では、
【 ファイルの場所の確定 】
を行います。その為、最初に作るファイルをファイルの形で作業フォルダーの位置に固定して配置する事で 【 そのファイルのアドレス 】 が決まります。つまり、ツリー構成の中のどの場所に存在するのかが確定する訳です。
PythonでIDLEを開いてコードを書いている段階だと、ファイルの保存がされていませんから、この段階で動いているのはIDLEなので、実質的にPythonのアドレスが現在のエイリアスになります。
流石に、Pythonの改造をしたり、PiPで機能を追加する以外だとこんな場所を使う事は殆どありませんから、自作でPythonのアプリケーションを作ろうと思った場合、その場所とは全く違う場所にフォルダーを作るはずです。
そうなると、 【 その作業フォルダーが指定されている必要がある 】 ので最初にでフォルダーが作られます。その後、ファイルでそのフォルダーをルート階層としたツリー構成を作る必要があるので、その場所に空の新規ファイルを作る事で、その場所をルート直下の階層のファイルにすることができます。
HTMLでこの状態はどう言った感じになっているのか？と言うと、
アカウント直下に空の ” index.html ” を置いたのと同じ状態
になります。
この時に新規作成をしたファイルから見た時のツリー構成は、HTMLを使ったコンテンツ制作時のツリー構成と考え方は同じなので、
■ 同一の階層 ： ファイル名
■ 下位の階層 ： フォルダー名/ファイル名
のようなフォルダー単位で 【 / 】 が入り階層が決まっていく形になります。この状態だと、 【 相対パス指定 】 で制御できるので、階層が近く、プログラムの入ったPC名で管理されたストレージであれば、相対パスで移動ができます。
ただし、コンピューターその物が違う場合には、ルートとなる部分が違うので、絶対パス指定になります。この条件が、汎用バスによる外部ストレージへのアクセスと別のサーバに対してTCP/IPを使ってアクセスして接続する必要がある事例に違いになりますが、この二者の違いが
■ ローカルでオフラインでも使えるファイル
■ LANやWANでの接続が必要になるファイル
の違いになります。つまり、前者がUSBなどの汎用バスで繋がるストレージ内のデータと同じなので、特にTCP-IPなどの必要がありませんが、これが、ルーターを使ったファイル共有を考えると、そこにコンピューターを用意してルーティングをする必要があります。現在はこうした処理をするのに負荷がかからないほど高速なCPUが存在するので、エガシーなCPUをNASのコントローラーとして使う事もできるようになっている訳ですが、その当時と比較すると、製造プロセスが全く違うので、チップレベルでも昔のCPUを実装できるようになっています。その為、ストレージにはPowerPCのような仕様の物が使われている物もありますし、単体で動くNAS製品はLinuxをインストールしてサーバとして運用できる物もあります。
その為、ネットワークを使う場合には、ルーティングや接続においての処理を行う為にコンピューターとして機能するシステムを実装しなければ制御できないので実質的に、ルーターを通る段階ですら、コンピューターにアクセスしている事になります。
と言う事は、相対パスと言う 【 コンピューターの個体だけで通用する物 】 だとハードウェア自体が異なるので、相対パスではアクセスできないので、絶対パス指定が必要になる訳です。
その為、WANの場合にはドメイン名があり、その中の何にアクセスするのか？を指定してファイルにアクセスする仕様になっています。
この条件で考えると、 【 ローカルで動作するプログラム 】 を考える場合、必要になるのは、 【 プログラムの存在するフォルダー 】 になりますから、 【 エイリアス 】 の指定が必要になる訳です。
■ エイリアスを指定するメリット
エイリアスを指定するメリットですが、これはやはり、作業がしやすくなることでしょうか。
HTMLを使うと、ツリーの構造や階層について学習できますから、
■ 作業フォルダーを作る
■ フォルダー内に 【 index.html 】 を作る
■ 別のHTMLファイルを作って相互リンクを作る
まで、行った後に 【 画像 】、【 音楽 】、【 動画 】 のファイルを配置してぺージをを仕上げる事にします。この時にindex.htmlと同じ階層でいいのですが、ここで 【 src="" 】 のような形でタグ内に記述をしてファイルを読み込むことになります。これが 【 外部参照 】 になりますが、プログラミング言語を使ってアプリケーションを作る時に、アイコンなどを画像ファイルで作る場合も外部参照をしますから、
単一のファイルでプログラムが完成する訳ではなく、素材などを
外部参照する場合がある
事も学習できます。この状態で外部参照をする事を体験した後に、この
■ 音楽
■ 映像
■ 画像
を個別に分けてアクセスしやすいように管理するようにページ単位で分けて処理をするような構造にします。スクリプトを学習していない状態だと、この場合、 【 ページ数を増やす 】 しかありませんが、そのまま配置すると訳が分からなくなります。仮に、任意のファイルを5個ずつ用意して15個のファイルを個別に15個のHTMLファイルに配置するようにした場合、同じ階層に30このファイルが並ぶことになります。これだと管理しにくいので、この三つの項目に分けて
■ 📁Music
■ 📁Video
■ 📁Image
のようにします。この中に5個のファイルを入れてHTMLと紐づけをすることになりますが、この場合、HTMLとマルチメディアファイルが混ざっ
ていると管理しにくいので、
のようにした方が管理しやすくなります。この時に、index.htmlからコンテンツにアクセスるる場合、htmlファイルにアクセスする事になりますから、 📁●●/📁●●/📄●●html になりますから、
と言う指定で動作する事になります。
これに対してコンテンツのHTMLファイルからマルチメディアファイルを見た場合、全く違う場所にあるので、階層を上に上げる必要があります。この時に、 【 ../ 】 で一つ階層を上に上げる必要がありますが、この場合、index.htmlと同じ階層まで上げる必要があるので、ルートフォルダーの階層まで上がってから選択する必要が出てきます。階層は、
のようになっていますから、先頭に 【 ../../../ 】 を付ける事になるので、
のように一旦上の階層に上がってからその階層の最上位のフォルダーからファイルを選択するような流れになります。
この状態ですが、画像のHTMLファイルから見た場合、
のように階層を上げる事が出来ます。ツリー構成は、下層フォルダーにアクセスする場合には、そのままフォルダー以下のツリー構成を書けばいいので、そのファイルの配置場所までの構成を書けばその指定ができます。その為、基本的には、ルートとなる場所からの階層を指定する事でその場所にアクセスできます。
基本的に階層については、こんな感じで指定できますが、これを行うと、 【 ルート以上の場所が変わっても、ルートフォルダ内での相対パス指定のリンク構造が破綻しない 】 と言う利点があります。つまり、ドメインが変わったとしても同じHTMLのコンテンツをそのまま使用できると言う利点があります。
絶対パスの場合、ドメインが違う場所のリンクなどになりますから、ルートに該当する場所が、 【 グローバルIPで固定され、DNSでドメイン名が決まったサーバ 】 ですから、この名称で固定されている場合だと、ドメイン名が変わってしまうと全く違ったアドレスになってしまいますから機能しなくなります。
その為、Aと言うサーバでフリースペースを借りてホームページを運用していた時に、コンテンツのリンクの指定が全て絶対パス指定だった場合、Bと言う別のドメインのサーバにコンテンツを移さなくてはならなくなった場合、上位フォルダーに該当する部分の名前が変わっているので使えなくなります。
個人がフリースペースを借りてアカウントを取得してホームページを運用しようと思った場合、
■ ドメイン
■ アカウント名
が組み合わさった物が 【 ルート階層以上の場所 】 に存在する事になります。この場合、リンク先を指定する場合、
■ 絶対パス指定 ： ドメイン名＋アカウント名まで含まれる
■ 相対パス指定 ： ルートフォルダ以下の階層の状態
ですから、絶対パス指定の場合、内部のコンテンツではなく、外部参照をするようなリンク以外では使わない仕様になっています。
この条件ですが、 【 フォルダの範囲内 】 で見た場合で、相対パスと絶対パス指定になりますが、絶対パス指定については、
■ 絶対パス指定をする場合
■ ローカルファイルでドライブが違う場合
■ コンピューターその物が違う場合
だと、絶対パス指定になります。その為、ドライブ内やフォルダ内の階層の指定だと、対象となっている階層から考えて使いやすい物を使う事になりますが、プログラムを書く場合に、ソースコードを書いて、外部参照で、CSSやECMA Scriptなどを外部参照する場合にも相対パス指定になりますし、フォルダー内に外部ライブラリを追加してローカルで動くようなHTML5のコンテンツを作る場合でもアプリケーションのフォルダー内に入れる事になりますから、ルートフォルダ内のファイルになりますから、相対パス指定で指定する事になります。
この階層ですが、Pythonの場合、テキストファイルを作成してCSVを読み書きしたり、読み込んだデータの集りを変数として使う事もできますから、 【 読み書きをする先 】 を指定する必要が出てくる場合もあります。また、標準モジュールでは、読み書きやドライブ参照などもできるので、ツリー構成をそのまま使って処理が出来るので、ファイルの住所を指定する作業が発生します。
その時に、この 【 相対パス 】 や 【 絶対パス 】 の概念が必要になります。
このように 【 ファイルから見た時の対象のファイルの住所 】 を指定する場合、 【 基準となるファイルの住所が決まっていると便利 】 なので、最初に 【 ファイルの住所 】 を決めておくことになります。
その為、Pythonでファイルを新規作成をして保存をすると、そのファイルの場所がエイリアスになるので、保存先のフォルダ内のそのファイルが基準となるので、保存後だと、外部参照をするファイルについては、HTMLと全く同じなので、外部に用意したクラスモジュールや関数を参照しようと思うと、呼び出す指定をしているコードを基準として、どう言った階層にあるファイルなのか？を指定するだけで呼び出す事が出来ます。この時に、tkinterを使って画像を配置して使うような処理をする場合に、 【 そのコードの入った📁内から読み込む 】 と言う条件の場合、配置した階層を相対パス指定で設定すれば、そのフォルダを移動しても適正に動作するようになります。
HTMLの場合、保存しないとファイルが出来ないのでブラウザで実行できないので、通常は保存後に実行すると思いますし、メモ帳だとそうするしかありませんから、ファイルが確定した状態で実行しているはずなので、あまり気にしないかもしれませんが、IDEを使ってPythonでコードを書く場合、 【 デバッグ 】 が出来るので、エイリアスがPyhonの場所にある状態でもコードの実行をコンソールで行う事が出来てしまいます。これでツリー構造を学習しようとすると、物凄く難易度が高くなる（と言うか、なぜ、記録後にエイリアスが変わったのかが解らないし、何よりも、最初のエイリアスは何だろうか？という話になります。）ので、 【 どこから読めばいいのだろうか？ 】 と困惑するかもしれません。ただし、VidualStudio Codeのように最初にプロジェクトを作って使用する📁がツリー構成で開いてある場合だと、作業がしやすいですし、エイリアスが決まった状態でその📁が出ているので、その見えているツリーの中にファイルを追加していくだけで作業が出来るという利点があります。
その為、Pythonをインストールして、IDLEを使う場合だと、エイリアスがファイルが確定するまでそのファイルが基準になりませんから、
■ エクスプローラーで作業用フォルダを開いておく
■ PythonのIDLEを開く
ようにして、おきます。IDLEは
■ コードを書くコードエディタ
■ Pythonの実行用のコマンドプロンプト
が表示されます。IDEの場合、PowerShellもそう言った構造になっていますが、ふぉるあを作ってファイル配置する場合に、IDEだけだと、エイリアスが決まった状態であれば、mkdirなどでフォルダを作ってcdでそのフォルダに移動して、そこをエイリアスにしてファイルを追加したり、ディレクトリの作りをコマンドだけで打ち込んで対応する方法もありますが、
【 流石に、始めたばかりの人には敷居が高すぎる 】
ので、PythonをインストールしてIDLEデコードを打ち込んで作業をする状態だと、エクスプローラーを開いておいて作業をする方が作業効率は高くできそうな気がします。
VIsualStudio Codeなどのエディタだと、プロジェクトで指定したフォルダが常に表示できるので、作業に集中してその📁でツリー構成を変化させながら作れるのですが、iDLEだけだとそう言った組み合わせで作業をすることになります。
ツリー構成をコントロールする場合だと、コマンドを使った制御ができますが、こうした処理に慣れてくると、コマンドプロンプトでftpでファイルをサーバにアップロードする時のようにコマンドでツリーの状態を確認しながらファイルの移動や複製などを行った方が一つのソフトだけで行えるので楽になる場合もあります。
デスクトップアプリの場合でも、
【 フォルダをユーザーが選択して記録できる仕様 】
を作ろうとすると、ディレクトリやファイルのコントロールは必要になりますし、キャッシュファイルを作って変数を格納しておいてバックアップを取ったり、キャッシュに変数を記録しておいて、必要な部分だけ読みだして使うような使い方（この場合、ディスクキャッシュなので、キャッシュ後には変数は消えなくなります。）をする場合にもそのキャッシュの置き場をどこにするのか？を指定する場合にはディレクトリの管理が必要になります。
記 記録方式と結果
コンピューターの処理の基本部分は電気の信号の変化なので、オンとオフの1bitのデータになります。これは、パンチカードの穴と同じで、用紙を紐でつづる場合、パンチ穴で穴をあけてから紐でつづり春日、この穴の状態の有無も 【 二値 】 ですから、この状態も1bitのデータを記録できるので、自動織り機などでも使用されていました。
このデータも量が増えると扱いにくくなるので、 【 8bit=1byte 】 として、16進数の2桁を1セットにした物を扱うようになりました。バイナリエディタを開いた時に00～FFまでの数値で埋め尽くされていますが、コンピューターが解る言語を効率的にまとめて表示した物がバイナリーになります。この状態だと、1bitのデータの塊がアドレスで固定されているのでコンピューターは間違いようがないのですが、バイナリーにするとこうしたメリットがあります。
ちなみに、1980年代の8bitパソコンではBASICがあり、これとは別にマシン語モニターが使用できていたので、マシン語の記述でコードを書いてSコマンドでセーブしてプログラムを記述する方法もありましたが、
【 バイナリエディタで十六進数を打ち込んでコードを書く 】
と言うアセンブラよりも敷居が高いようなことが可能になっていました。流石に、これだと無理がありすぎるので、BASICの高速化の方法として、POKEやPEEKと言うマシン語モニターにダイレクトに記述する事で速度を出す方法が存在しています。Pythonのデータの読み書きをテキストデータやCVSで行うと遅いので、バイナリにすると高速化が出来るのですが、対応した物については、バイナリに変換してファイルを作って、メモリーにデータの塊として書き込んで、それをバイナリーのデータの塊として読み込んで、それをオブジェクト化してテキストとして扱うようにすると、速度が上がります。データ数が膨らむ条件でタプルを使うような内容を考えると、 【 3DCGのバーテックスの座標 】 などが考えられますが、こうした3つのデータの値を格納する場合に、通常のモデルでも結構なポリゴン数になりますが、座標はそれよりも多くなるので、その数を3倍したデータが必要になります。つまり、頂点数が1万あった場合だと、数千ポリゴンですから、現在だとそれほど多くないポリゴン数のモデル （PS2で使うレベルのポリゴン数になりますが、ポリゴン数が密集するキャラの頭部のモデルだと、PS3のゴッド・オブ・ウォーで5700ポリゴンですが、PS4のゲームになると、1万ポリゴンをこえる状態になっています。） になりますが、この状態でも座標を指定する時に用意する変数の数は3万に達します。
シーン内のポリゴン数を100万ポリゴンにして、それをソリッド表示で全て読み込むことを仮定すると、座標データは300万に達しますからデータの読み書きの方法が文字列の状態だと速度がかなり遅くなってしまいます。その為、タプルをタプルと言う文字列で読み込むのではなく、バイナリで書きこんで、バイナリで呼び出して変数として代入したほうが速度が出ます。
その為、データの扱いについても基礎学習の段階だと、変数と記録の方法を学習して 【 知識を使って物を作れるようにする 】 必要がありますが、その時に 【 速度が遅い 】 と感じた場合に、軽量化や高速化をするアプローチをもさくすることになります。
ちなみに、openとかでファイルを作って読み書きする時にもバイナリを使った場合には速度が出るので、規模が大きくなってくるとバイナリ方式での読み書きも選択肢に入ってきます。
現在は、アセンブリ言語よりも難しい記述のバイナリエディタで十六進数を使用してコードを書くというようなことはありませんが、PC98シリーズの時代にはそう言うのが存在しており、そんなコードが公開されている時代もありましたが、メモリ―アドレスにアクセスする方法はBASICインタプリタのコマンドにも用意されていたので、バイナリを使うという概念は結構昔から存在していました。
変数の場合ですが、メモリーに記録する際にはバラバラになるのですが、バイナリーを使うとこの弊害がなくなり、少し特殊な形になるので、ファイル自体を開いても確認できなくなるもののバイナリ形式でのファイルの読み書きをすると速度が結構変わってきます。そのファイルへの読み書きの処理ですが、
■ 読み込み ： ファイル ➡ 変数への追加
■ 書き込み ： 変数 ➡ ファイルへの追加
ですから、メモリー経由の処理になりますが、データ数が増えるとバイナリとテキストだと倍以上の速度差が出るので、データの総数が肥大化するような物だと、バイナリで保存してデータのやり取りをしたほうが速度を稼ぐことができます。
P Cの仕様の変化
PC8001辺りだとROM BASICが標準実装だったのですが、この時代にはBIOSと言う物が存在しないので、ディスプスイッチと言う物が実装されていました。
流石に、設定項目を二値で設定するというのは無理がある（これだと、ブートの設定をする場合だと、何番を選ぶのか？と言うドライブの数分だけスイッチを割り当てる必要が出て来るので、標準構成だけにすると、動く物の、外部ストレージ駆動のような条件でドライブ数が増えると対応できなくなるので、必然的に消えていきました。）ので、BIOSと言う起動プログラムに入れ替わる事になりました。OSを実装しているPCの場合、BIOSがブートローダーを読み込んで制御しているので、マスターブーレコードを探して起動している訳ですが、その後、ブートセサクターでブートの対象を選択して、先頭セクターにあるプログラムを実行しています。つまり、OSの実行が先頭セクターの読み込みをして実行する形になっています。
これはHDDもSSDも同じですが、MachintoshやAMIGAの場合FDD駆動だった時代もありますが、この場合、マスターブートレコードと言う概念がないので、いきなり先頭セクターを読み込むような流れになっていました。と言う事は、ブートセレクターすらない時代なので設定の変更はROM BASICやテープレコーダーやFDD駆動の物でも問題がなかったという話になります。
先ほどのMBRの仕様が各ドライブレベルで存在しているので、OSにはマルチブートの選択肢がある訳ですが、ハードウェアにネイティブで接続した状態のOSをブートローダーで選択して起動する仕組みが使えるのもブートの仕組みが存在している為です。
この辺りは、WINDOWS 2000でもLinuxとWINDOWSの共存は可能でしたし、WINDOWS 7のように64bitが当たり前に販売されている状態だと、
■ WINDOWS XP
■ WINDOWS 7 ｘ86-32
■ WINDOWS 7 ｘ86-64
■ Ｆｅｄｏｒａ
■ Ubuntu Studio
■ Lubuntu
をインストールして切り替えて使う事も出来ていましたし、ライセンスがあれば、XPはブートローダーでも動きましたが、もう一つの選択肢として 【 仮想化 】 を使う方法がありましたから
■ XEN Server
■ Xenoppix
などを使って、艦船にサーバ化した場所で仮想化環境を動かす方法とクライアントサイドに
■ VIrtualBox
■ XEN
■ QEMU
■ ＫＶＭ
■ Virtual PC
などをインストールして、ローカル環境にVMを作って動かすという事も可能になっていました。その為、エミュレーションとは異なり、ハードウェアの構成を決めてそのリソースの中でマシンを作って動かす事が出来るという仕様になっているので、スレッド数やハードウェアの構成が変更できない 【 ソフト動かすアプリケーションレイヤーソフト 】 とは異なる仕様になっています。
この仕様があったので、実質的に 【 OSの差異によるアーキテクチャ依存はなくなっていた 】 ので、WINDOWS環境でLinuxを使う時に、C++の環境構築では、 【 MinGW 】 をインストールすると最小構成でLinuxのようにC++の困憊折るやアプリケーションのビルドが出来るようになりますが、WINDOWSでビルドを行うと、バイナリーがWINDOWSになってしまいますが、実機だとどうなるのかはよくわかりません。
挙動を確認する為にハイパーバイザー型の仮想化環境でLinixを立ち上げて動作させると、 【 ハイパーバイザー分のロス 】 が発生するもののアプリケーションレイヤーソフトやホスト型よりも軽く機能する事になりますが、マルチブートの場合だと、ネイティブ環境で動作する速度を確認する事ができます。
こうした作業は2010年代にはこういうのが出来ていたのですが、下層か自体はシングルスレッドの時代にはVM Wareなどもありましたから、サーバとかワークステーションのようにスレッド数の多いアーキテクチャに対して使用する事で、シングルスレッドのマシンを複数用意する（この時代のアーキテクチャはスレッド数をソケット数で稼ぐような考え方なので、現在のメニーコア構成だったり、STMを使ってスレッド数を稼ぐような構造になっていませんから、少し仕様が異なります。）事が可能だったので、仮想化はその時代からありますし、マルチブートの概念はブートローダーでHDDの先頭セクターを読めれば成立する物ですから、当然のようにDOSカーネルの時代から行える仕様になっているので前の世紀から行える状態になっていました。Linuxは今年で30周年なので1991年から存在していますが、日本国内でのインターネットの普及はもっと後の話（20世紀末の話。）ですから、UNIX互換OSも個人レベルで使えるようになっていたので、高専とか工科大に行かなくてもUNIXの勉強が出来る時代になり、サーバも個人で学習できる時代になっていましたが、スタンドアローンでしか動かないというのは、エンドユーザーの錯角や思い違いか虚偽の妄信レベルの間違いでしかなく、実際には、ブートローダーがあるので、読み込める環境を作れば、マルチブートが可能で20世紀末だと2ソケットモデルを用いた場合には、仮想化も行えていました。
スマホでは、Androidの選択肢がありますが、Androidはx86版も用意されているので、
■ Android-x86
Android-x86 - Porting Android to x86
と言うプロジェクトがあり、現在は、8.1-R6がダウンロードできるようになっていますから、仮想化環境で実行したり、セカンダリー以降のドライブにインストールしておいて、ブートローダーで呼び出して使うという事もできます。
Androidについては、
で触れていますが、WINDWOS 11でAmazonのアプリがそのまま動くような仕様になる（今後のアップデートで対応。）ようですが、Android x86をネイティブでx86環境で動かした場合、
の動画でも紹介されているように、結構すさまじいスコアが出ています。仮想化だとボトルネックが発生するのでパフォーマンスが落ちそうですが、現在は、x86でもこうした事が出来るようになっています。
x86環境でAndroidを動かすメリットとしては、
【 コードの実行をした時の挙動の確認 】
が考えあっれますが、AndroidStudioでも仮想化でAndroidエミュレーターを動かす仕様になっているので、Androidを実際に動かすような仕組みが用意されています。
その為、タッチパネルとかを用意する必要がありますが、クライアントの操作をAndroidで行ってみる事も可能ですし、作ったAPKをそのまま実行する為だけの端末として使う事もできるので、ローカルで何かしらのローカルのサーバを用意しておいて、Androidの端末でアクセスしてコンテンツを動かすなどのソリューションを考える時に、処理の軽いアプリを開発してシステムの動作確認をする場合に、RJ45の有線LAN環境で試せるという少し特殊な使い方もできます。
つまり、無駄にAndroid端末のセキュリティーレベルを下げなくても、ローカルで使用できる端末やアプリケーショの実行用の端末を用意できると言う利点があります。