数値計算ソフト作成の経緯

プログラム電卓ぐらいのプログラムで、数値計算やグラフが描けるソフトを作ることにしました。
速度は遅くなるのですが、テキスト文を解読しながら処理する方式にしました。( VisualBasic(VB)で作成 )
演算部分は、アセンブリ言語によるプログラムでも処理できるようにしました。
方程式の解析は、Mathematica (Wolfram Research 社製) がいいかもしれません。
1997年4月頃、あるパソコンショップ(秋葉原)で英語版の Mathematica が18万円でした。
当時、お金がなく買えませんでした。
この頃から、自分のための数値計算ソフト，テキストエディターとして、Windows95用に作り始めました。
VBで作成したのは、C言語が自分にとって、難解で，扱いにくく，記号の使い方が性に合わなかったためです。
一部(CLC.DLL)は VisualC(VC)のインラインアセンブラを使ったのですが、
ほとんどC言語を使わなくて済む仕様なので助かりました。
RS-232C通信を追加し、多数桁計算(加減剰余)もできるようにしました。 (10000桁まで)
かなり時間がかかりますが、 π やｅ の計算はできます。
整数関連の計算は、UBASIC86(MS-DOS 2700桁以内)がいいかもしれません。
その後、データベース処理を追加しました。





その他

マイクロソフトは、Oracle に追いつけ追い越せの頃、ADO を無料配布していた。

使用した開発言語のVB4(低価版)に、バイナリ通信のできない通信ソフト(Ver1.0 1995年)が付属していた。
( InputMode がない、たぶん宣伝用。)
1996年のヘルプファイルの配布許諾一覧では、Standard Edition で MSCOMM32.OCX(Ver1.0) が許可されている。
1997年のサポート技術情報では、MSCOMM32.OCX が、Standard Edition の一覧にない。担当者の勘違い？。
( VB5,VB6の高価版に付属の通信ソフト(Ver5.0, 6.0))は、バイナリ通信ができた。)

マイクロソフトがライセンスを得ていた通信ソフトに対し訴訟があり、ライセンスがあいまいになった。
初期のモデムが28800bpsまでの頃に、マイクロソフトは 38400〜256000bps を予約済み値としていた。
56Kモデムが普及しても、MSCOMM32.OCX(Ver1.0) は更新されず、低価版に付属しなくなった。(VB4→VB6)
パソコンのシリアル(RS-232C)端子は、レガシーデバイスとなった。

WindowsXP付属のハイパーターミナルは、115200[bps] で RS-232C間通信ができたが、
Windowsは、自動でインターネット通信をする仕組みなので、
ハイパーターミナルの安全性は、ＵＳＢと同じかも知れない。


インターネットに接続するだけで、ウィルスが侵入することがあった。
ホルダやファイルにセキュリティをかけても、ウィルスはアクセスできることもあり、
パソコンの使用者が、ホルダやファイルにアクセスできないこともある。
セキュリティに守られた怪しいホルダや、使用中の怪しいファイルを削除できないこともあった。
ホルダやファイルにセキュリティをかけるより、ＰＣの入出力を監視すべき。



VB7とならず、VBNetとなってしまった。VB7にNetアプリーションとアセンブラーの付属であれば買ったかも知れない。
新しい開発言語には、新しいＯＳの環境が必要となり、アプリケーションの古いＯＳへの対応が難しくなる。

Ｃプログラマーによって作られたＶＢは、保身？のためか制限が多かった。
あれもできない、これもできない、VB4に比べ、VB6は、できる範囲が広くなった。
SDKがなくても、APIリファレンスのVB本でかなり解決できた。
ターボＣも買ったが、Ｃ言語でアプリケーションを作る気にはならなかった。
低価版のＶＢは、DLLを作れなかったし、アセンブラーが付属していなかった。
低価版の Visual C 4.0 は、DLLを作れたし、アセンブラーが付属していた。



Windows3.1は、DOS から起動できて便利だったが、Windows95を、DOS 上のＯＳと揶揄され、
古いDOSからでも、Windows を起動できるようにくふうされなかった。

いくら CPU が高速化しても、巨大化したＯＳがその分を遅くしてしまうので、
いつまでたってもパソコンは速くならない。

数値計算は、CPU の周波数の数値が多いほど速いが、
パソコンの操作感は、[CPU100MHzのWindows3.1]より、[CPU3GHzのWindows7]の方が遅い。
ＯＳ以外にも原因があっても、CPU から見れば、ＯＳが30倍遅くなったように見える。

ＯＳの常駐プログラムが多すぎるし、
ＯＳの中にアプリケーションのINIファイルデータを入れるべきではなかったし、
ＶＢを直ちに拡張し、ＯＳの開発言語をＣからＶＢに早期に変更すべきだった。
使い勝手が悪く、規則正しくなく、余分なプログラムが付随するＣ言語が、
ＯＳを複雑化し、ＯＳを巨大化させた、原因と言える。

開発コストを配慮し、
アプリーションの作成を早期にＣ言語から Visual Basic に変えたアメリカ企業もある。



Windows10に無料バージョンアップしたが、画面が不安定になったので、Windows8.1に戻した。
製品版を購入したが、ビデオドライバーは画面を鮮明に表示しなくなった。
Windows10の販売後、10以外のWindowsも、画面が不鮮明になったり、赤いにじみが出るようになった。
赤いにじみは、最上部のメニュー文字から始まり、徐々に下方の文字に広がっていく。
一度でもインターネットに接続すると、ハードディスクをクリーンにし、再インストールしても直らなかった。
( メインボードのビデオ関係，BIOS，CPU，モニターが影響を受けたようだ。)
無料,有料アンチウィルスソフトでも検出できない。
ハードにむりを強いたり、古いものを軽視したのが原因のようだ。

GIGABYTEは、メインボードという名称でかなりねばったが、ついにマザーボードにしてしまった。



ノートパソコンと据え置き型パソコンの両方に許可している有料ソフトもある。
Windowsは認証を重視し過ぎで、そのために大変な苦労を強いられている。
Windowsの再インストールのとき、
アプリケーションを再インストールしなくて済む仕組みに変更できないのだろうか？。
ＯＳの基幹部とその他を完全に分離し、その他をアプリケーションとすべきで、
ＯＳが不調になったとき、基幹部だけを復元し、文字サイズやカラーなどの個人設定は、不変にすべきでしょう。


古いソフトや古いハードの軽視，複雑で肥大化したＯＳが、パソコン離れの原因になると言える。
ＰＣのWindowsアプリケーションが動作するスマートホーンは期待できる。

Windows11からは、裕福(個人,企業等)向けになるようだ。
安価に構築するのなら、Linux がいいかも知れない。

ATCLC95F＋ATCLCLF で、ATCLC が Puppy(fossapup64-9.5.iso)＋wine-3.0 でほぼ使える。 WineLinux
アイコン化は不可、RS-232C は可、データーベースは可。(*.MDBだけ)

PC版 Android x86_64-9.0-r2.iso ＋ [ Wine-3.0-x86.apk ]　WineAndroid
アイコン化は可、RS-232C は不可、データーベースは可。(*.MDBだけ)

arm スマホ版 Winlator3.0 [Wine8.0.1]　DeviceOSEmltr
アイコン化は可、RS-232C は不可、データーベースは不可。

[ 2022年, 2024年 ]





[ 2007年2月，2008年，2009年，2022年, 2024年 ]


ＡＴＨＰトップページ