uaa@framboise:~/z/open-watcom-v2/build/binbuild$ ls *.core
errdoc.core msgencod.core optencod.core vicomp.core
uaa@framboise:~/z/open-watcom-v2/build/binbuild$

bdiff 未対応のため何もしない
fe_misc 要対応
gui 未対応のため何もしない
setupgui 保留
wdis 未対応のため何もしない？
wgml 未対応のため何もしない？
wprof 未対応のため何もしない
wv 未対応のため何もしない

…で、いいのかな。後で再度
egrep -e "clibint.h" -e "clibext.h" -e _cmdname -e "_argv =" -e "_argc =" bld/*/c/*|less
で見直そう。

ぶっちゃけた話、_argv, _argcを未設定ってことか…

vi/c/init.c: _argv = __argv;
wasm/c/main.c: _argv = argv;
wcl/c/owcc.c: _argv = argv;
wcl/c/wcl.c: _argv = argv;
whpcvt/c/whpcvt.c: _argv = argv;
wl/c/ideentry.c: _argv = argv;
wl/c/maindrv.c: _argv = argv;
wmake/c/main.c: _argv = argv;
wsample/c/sample.c: _argv = argv;
wstrip/c/strip.c: _argv = argv;

int main( int argc, char **argv )
/*******************************/
{
#if !defined( __WATCOMC__ )
_argc = argc;
_argv = argv;
#else
/* unused parameters */ (void)argc;
#endif

#else

…？

(gdb) run
Starting program: /home/uaa/z/open-watcom-v2/bld/wasm/binbuild/bwasm.exe
Watchpoint 1: _argc
Watchpoint 2: _argv
Watchpoint 1: _argc
Watchpoint 2: _argv
Watchpoint 1: _argc
Watchpoint 2: _argv
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Watchpoint 1: _argc

Old value = 0
New value = 1
main (argc=1, argv=0x77f8932cfaf8) at ../c/main.c:1157
1157 _argv = argv;

普通はこうだよねえ…

(gdb) watch _argc
Watchpoint 1: _argc
(gdb) watch _argv
Watchpoint 2: _argv
(gdb) run
Starting program: /home/uaa/z/open-watcom-v2/bld/wtouch/bsdx64/wtouch.exe
Watchpoint 1: _argc
Watchpoint 2: _argv
Error evaluating expression for watchpoint 1
Cannot access memory at address 0x380f8
Watchpoint 1 deleted.
Error evaluating expression for watchpoint 2
Cannot access memory at address 0x380f0
Watchpoint 2 deleted.
0x0000070b9a325327 in __start ()
(gdb)

はいいい？

_argv=NULLの場合、パスの通っていない状況で./wtouchみたいなことをしてもちゃんと動かないという制約が生じるんだけど…まあ、しょうがないよねえ。

Pentium G4600上が55分だけど、i7-7700なLinux上の仮想マシンだとこんな感じ。
================= 18:17:52 /home/uaa/open-watcom-v2/bld/posix =================
==================== 18:17:52 /home/uaa/open-watcom-v2/bld ====================
50m48.52s real 29m45.53s user 15m25.77s system
openbsd-current-vm$

キャッシュの効果かちょい速いけど…その5分のためにお金を出せるかと聞かれると、どうなんかなあ…

wtouchが動かない理由、_argvが何故かNULLになる（この理由は調べないといけないけど）ことで、_cmdname()が落ちるという理由なんだけど…とりあえず_argvがNULLになっても死なないようにする処置を突っ込んでみた。
あと、PATH=/usr/bin:みたいに最後に:が来た場合、PATH=/usr/bin:.とみなすように直してる。PATH=:/usr/binをPATH=.:/usr/binとするようにはしてたんだけどね…

https://github.com/open-watcom/open-watcom-v2/pull/1394/commits/164ef943ce46f92445d281401975bd2cd0a6c22a

uaa@framboise:~/z/open-watcom-v2$ ./bld/wtouch/bsdx64/wtouch.exe
wtmsg: name size 1025
_argv NULL!
Abort trap (コアダンプ)
uaa@framboise:~/z/open-watcom-v2$

あ、あんですってー？！

異論はあるだろうけど個人的にはstyle(9)に近いものでお願いしたいです… https://man.openbsd.org/style

xlxdのコーディングスタイルもなかなか強烈ですが、OpenWatcomもなかなかやりにくいスタイルです。if ( ( hoge == fuga || foo == bar ) )なスタイルで本当に良いのか（実はif ( (hoge == fuga || foo == bar) )だったりしないか）とか、考えれば考えるほど頭痛が痛いです。

とりあえずこれでOpenBSD上でもbuild.sh relまではイケる。wtouchが動いてないみたいなのでこれから見るけど…

_cmdname()の実装、色々思うことはあるんだけど__BSD_VISIBLE禁止されてる状況なのと、OpenWatcomのコーディングスタイルやら諸々（可能性は低いだろうけどOpenWatcomによるセルフビルド可能にするとか）を考えた末こういうコードになりました。

素直にsnprintf()とかstrlcpy()使えば？って気がしなくもないんですが、strlen()で文字数得てるならそれを活かした方が速いのかなーって。本当はmalloc()じゃなくalloca()使いたかったんですけどね…

https://github.com/open-watcom/open-watcom-v2/pull/1394/files

あー、多分旧ライフボートの所管だろうからソースコード消失の可能性も考えないといかんかー。

https://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%83%95%E3%83%9C%E3%83%BC%E3%83%88

最悪、ライブラリのバイナリをフリーに扱っても良い権利とか逆アセンブルしても文句言わんといてとかそういう話に持ってくしかない？

これでPR投げて、問題なく受け付けられたら一段落かなあ。\39800出して買ったWatcom C/C++ 11.0Jが色々あってオープンソース化されてだいぶ経ったけど、まさかこんな形でプロジェクトに関われるとは。

PC-98x1用のグラフィックライブラリのソースコードを出してください、ってライフボートに掛け合ってみたらどうなるんだろう？そんなもんはもう残っちゃいないとか、個人なんか相手にしてられるかｳﾞｧｰｶと門前払い食らうのか（ソースが出てるならもう出てるって気がしなくもない）。

=================== 13:40:42 /home/uaa/z/open-watcom-v2/bld ===================

real 55m0.081s
user 35m48.250s
sys 13m46.840s
uaa@framboise:~/z/open-watcom-v2$

うーん、OpenWatcom/OpenBSD、他環境より２倍はいかないけどそれくらいのビルド時間かかってる…

元ドライバ屋さんとしては、高級なアセンブラとして使えれば良い…マイコン内蔵ペリフェラルの叩きやすさ、という観点かなあ。マルチプロセッサだのキャッシュだのライトバッファ（メモリバリア）だの、イマドキのCPUは高速化のためのギミックが多々ある以上その辺をうまーく言語系がサポートしてくれるっていうならそれはそれでありがたいけど。

なので、今のところCかC++辺りで良くね？に落ち着いちゃう。

Zigの方が馴染みやすそうに見えるけど、Rustの方がより枯れてる印象があるけどどうなんだろうな。ZigもZigでビルドシステム持ってるから結局Rust/Zig使うにはそれぞれの「文化」を知るところから始めることになる訳なんだが…

OpenWatcomのビルド、OpenBSD版が未だに終わらぬ…何が遅くさせてるんだろ（これで問題なければ修正内容を目視確認してPR投げるぉ）

COBOLをオワコンとやって血祭りにあげた後はC言語をターゲットにしてやいのやいのするんですよね、日経の某木村さん？違うとは言わせない…

既にMake他色々システムがあるのに、Cargoとか別システムであれこれやるってのが気に食わないっていうのがあるんじゃないのかなあ…

（確かにCのお作法が身に付いている身には、いちいち別の開発作法をCのプロジェクトに取り込むんかい…？という気分にはなる。せいぜい、cc→別言語のコンパイラ、というコマンド名の挿げ替え程度で対応できるなら使おうかーというところなんじゃないかなあ）

==================== 13:25:07 /home/uaa/open-watcom-v2/bld ====================
2460.70 real 1643.37 user 831.69 sys
netbsd-vm$

==================== 13:15:05 /home/uaa/open-watcom-v2/bld ====================

real 30m54.252s
user 27m2.194s
sys 4m22.314s
uaa@emeraude:~/open-watcom-v2$

================== 13:13:17 /usr/home/uaa/open-watcom-v2/bld ==================
1766.06 real 1511.06 user 250.78 sys
uaa@freebsd-vm:~/open-watcom-v2 $

==================== 13:21:13 /home/uaa/open-watcom-v2/bld ====================
1624.826u 623.436s 37:15.12 100.5% 3397+871k 114546+148io 5284pf+0w
uaa@dragonfly-vm:~/open-watcom-v2 %

あーこれかー、あるセキュアな言語が某OSのメンテナから癌扱いされてるって話…（あとで見ようっと

まあそうだよなあ、rdtsc命令が特権命令じゃないから別にこれ使ってタイミング取るのはおかしなことじゃない

DOSBox/DOSBox-x、OpenBSD（NetBSDも？）[cpu]のcycles=auto, maxがちゃんと機能してない気がするんだけど気のせいかなあ。cycles=10000000とか決め打ちの方がちゃんと動く気がする。

うーん、この辺がPentium G4600の限界なのかなあ。Turbo使わなければクロックはi7-7700と変わらないけど、キャッシュサイズの違いが効いてる気がする。

まさかDOSBoxの設定を確認するのに古の86Duino開発環境を引っ張り出す羽目になるとは… https://github.com/roboard/86Duino/blob/Coding-106/build/linux/work/DOSBox-0.74/dosbox-86duino.conf#L29

だーーーーーーーーーーー💢💢💢💢💢💢💢💢

ここでこんな決め打ちされてたらビルド用の.mifにOS毎の処理突っ込んでもどうにもならないじゃないですかああああああああああああああああああああああああああああああああああああああああああああ

https://github.com/open-watcom/open-watcom-v2/blob/master/bld/wipfc/configure.ac#L5