ラベル WSL の投稿を表示しています。 すべての投稿を表示
ラベル WSL の投稿を表示しています。 すべての投稿を表示

2026-08-30

amd64移植におけるテーブル構造

東大版Palo Alto Tiny BASICをWSL2のUbuntu環境に移植しようと作業を進めています。BASICというのは、プログラム編集機能とインタプリタ機能が統合されています。オリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していますから、プログラム編集機能といっても簡単なものです。amd64移植にあたり、機能的な拡張は全くおこなわない方針です。今日の水準から見れば貧弱そのものですが、移植する過程を学ぶのが主目的なので、本格的な機能は求めないことにします。

 

ひとまず編集機能はできあがりましたので、次はインタプリタ機能です。ここで問題となるのが、入力された文字列を認識して、対応する機能に分岐するロジックです。オリジナル版は、i8080というものに強く依存しているので、そのままamd64に対応させるのはよくないと考えています。基本的な構造は「CASEマクロ」にあります。

CASE   .macro STR,ADRS
       DB    &STR
       DB    (&ADRS SHR 8)+80H
       DB    &ADRS AND 0FFH
       .endm

このマクロを使って次のようなテーブルが作られます。例えば「LIST」という文字列だったら、LISTルーチンに飛ぶことになります。

CMDKW: CASE  'LIST',LIST
       CASE  'RUN',RUN
       CASE  'NEW',NEW
STMKW: CASE  'NEXT',NEXT

ここで注目すべきは、文字列の終端を認識するために、ルーチンのアドレスのMSBをONにしている点です。しかもi8080はリトルエンディアンなのに、ビッグエンディアンのように逆転させて配置しています。これはi8080の事だけを考えて組み立てるのであれば、秀逸なアイディアと言えます。しかしamd64に移植しようとするなら、あまりよろしくありません。しかも、amd64への移植が済んだら、他の環境にも移植したいと考えているので、なおさらです。

 

どうしたらよいか、これから検討します。Geminiに相談してみようと思います。 

 

2026-08-18

東大版Palo Alto Tiny BASICのGETIルーチンをamd64に移植するとLEA命令を使う

SDK-80のシリアルポートにASR-33が接続された環境を想定している東大版Palo Alto Tiny BASICをWSL2Ubuntu環境に移植しています。Geminiと相談しながら作業しています。BASICというものは、編集環境と実行環境が統合されているところに真髄があるのですが、まず編集環境の方から移植を進めています。数字文字列を2進数に変換するために「GETI」というルーチンがあります。これをamd64にしてみます。

 

オリジナルは次のようになっています。

GINT:  LXI   H,0000H        ;GET INTEGER
       MOV   B,H
       CALL  SKPBL
GETI1: CPI   '0'
       RC                    ;RETURN INTEGER IN HL
       CPI   '9'+1
       RNC
       MVI   A,0F0H
       ANA   H                ;IF INTEGER>#0FFF ERHOW
       JNZ   ERHOW
       INR   B
       PUSH  B
       MOV   B,H            ;HL HL+10
       MOV   C,L
       DAD   H
       DAD   H
       DAD   B
       DAD   H
       LDAX  D                ;HL HL+(DE)&#0F
       INX   D
       ANI   0FH
       ADD   L
       MOV   L,A
       MVI   A,00H
       ADC   H
       MOV   H,A
       POP   B
       LDAX  D
       JM    ERHOW
       JMP   GETI1

 

Geminiの指導を受けながらamd64に移植したら、次のようになりました。

.equ    GINT_DIGIT_MAX,        (NINE-ZERO)
.equ    GINT_MAX_BEFORE_X10,    0x0FFF
gint:    xor    eax,eax
    xor    ecx,ecx
    call    skpbl
geti1:    movzx    edx,byte ptr [rdi]
    sub    edx,ZERO
    cmp    edx,GINT_DIGIT_MAX
    ja    geti9
    cmp    ax,GINT_MAX_BEFORE_X10
    ja    erhow
    inc    cx
    # amd64の真骨頂: LEA命令による AX = (AX * 10) + DX
    lea    eax,[rax + rax*4]
    lea    eax,[rdx + rax*2]
    inc    rdi
    test    ax,ax
    js    erhow
    jmp    geti1
geti9:    ret

amd64と比べるのは卑怯かもしれませんが、i8080は命令が貧弱です。レジスタの内容を10倍するのも、簡単にはできません。一方amd64は、IMUL命令で簡単に10倍できるはずですが、Geminiが提示してきたのはLEA命令を使う方法でした。なぜIMUL命令を使わないでLEA命令なのかとGeminiに問うと、内部処理の都合上この方が速いのだそうです。ここがボトルネックという訳ではないので、微妙に速くなっても全体としては速さを意識できないと思います。しかし、いかにもamd64チューニングされているという感じにはなりました。 

2026-08-12

東大版Palo Alto Tiny BASICをamd64環境に移植するための入力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみるため、出力ルーチンが出来たので、引き続き入力ルーチンも書いてみました。WSL2のUbuntuを使っていますが、端末をRAWモードに設定する必要があります。プログラムを動かす前にsttyで設定を変えておくことにして、プログラム内部ではロジックを組みません。

 

オリジナルの入力ルーチンは次のようになっています。

GET:   IN    IFLG
       NOP
       ANI   IMSK
       RZ
       IN    ITTY
       ANI   7FH
       CPI   0FH
       JNZ   TTYI2
       LDA   OMASK
       CMA
       STA   OMASK
       JMP   GET
TTYI2: CPI   03H
       JZ    START
       RET

Geminiに教えてもらいながら、入力ルーチンを書いてみました。動作確認には、既にできている出力ルーチンを使いました。

# as get.s -o get.o
# ld get.o -o get
# stty raw -echo ; ./get ; stty sane
.intel_syntax noprefix
.global _start

.equ    CTRL_C,        0x03
.equ    CTRL_O,        0x0F
.equ    CR,        0x0D
.equ    LF,        0x0A
.equ    SYS_READ,    0
.equ    SYS_WRITE,    1
.equ    SYS_IOCTL,    16
.equ    STDIN,        0
.equ    STDOUT,        1

.equ    TC_MAGIC,    'T'
.equ    FIONREAD_CMD,    27
.equ    FIONREAD,    (TC_MAGIC << 8) | FIONREAD_CMD

.equ    OMASK_TOGGLE,    0x01

_start:    call    get
    call    put
    jmp    _start
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret

get:    push    rbp
    mov    rbp,rsp
    sub    rsp,16

    mov    rax,SYS_IOCTL
    mov    rdi,STDIN
    mov    rsi,FIONREAD
    lea    rdx,[rbp-4]
    syscall
    test    eax,eax
    js    ttyi8
    cmp    dword ptr [rbp-4],0
    jz    ttyi8

ttyi1:    mov    rax,SYS_READ
    mov    rdi,STDIN
    lea    rsi,[rbp-5]
    mov    rdx,1
    syscall
    cmp    rax,1
    jl    ttyi8

    movzx    eax,byte ptr [rbp-5]
    cmp    al,CTRL_O
    jne    ttyi2

    xor    byte ptr [rip+omask],OMASK_TOGGLE
    mov    rsp,rbp
    pop    rbp
    jmp    get

ttyi2:    cmp    al,CTRL_C
    je    done
    jmp    ttyi9
ttyi8:    xor    eax,eax
ttyi9:    mov    rsp,rbp
    pop    rbp
    ret

.data
omask:    .byte 1        # 出力フラグ(0: 出力抑制 / 0以外: 出力許可)


東大版Palo Alto Tiny BASICをamd64環境に移植するための出力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみようと思います。基本方針としては、オリジナル版の仕様を再現することに主眼をおき、C言語で書き直すとか、整数16ビットを拡張するなどはおこなわないつもりです。プログラムのデータ構造やサブルーチン構成も変更しないつもりですが、i8080とamd64の違いでやむを得ない場合は、変更します。

 

またオリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していると思われます。amd64環境としては、WSL2のUbuntuとかFreeBSD/amd64などを考えていて、少なくともOSの管理下で動作するようにします。まずは入出力ルーチンを移植してみようと思います。

 

オリジナル版の出力ルーチンは、次のようになっています。

PUT:   PUSH  PSW                ;PUT CHARACTER IN A REG
       LDA   OMASK
       ORA   A
       JNZ   TTYO0
       POP   PSW
       RET
TTYO0: IN    OFLG
       ANI   OMSK
       JZ    TTYO0
       POP   PSW
       OUT   OTTY
       CPI   0DH
       RNZ
       MVI   A,0AH
       CALL  PUT
       MVI   A,0DH
       RET

 Geminiの助けを借りながら、オリジナルと同じ動きになるような出力ルーチンを書いてみました。動作確認のため「Hello World」を出力させてみましたが、うまくいっているようです。

# as put.s -o put.o
# ld put.o -o put
# ./put
.intel_syntax noprefix
.global _start

CR        =    0x0D
LF        =    0x0A
SYS_WRITE    =    1
STDOUT        =    1

_start: lea    rbx,[rip+msg]
loop:    mov    al,[rbx]
    cmp    al,0
    je    done
    call    put
    inc    rbx
    jmp    loop
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret
    
.data
omask:    .byte 1        # 出力フラグ(0: 出力抑制 / 0以外: 出力許可)

.section .rodata
msg:    .asciz    "Hello World\r"

2026-08-09

東大版Palo Alto Tiny BASICをamd64環境に移植できるだろうか

simhのAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作し、Tiny Trekも動きました。ひとまず区切りがつきましたが、これを他の環境に移植してみても面白いのではないかという気がします。他の環境というのは、具体的にはつぎのようなものを思い描いています。

  • amd64環境として、WSL2のUbuntuかFreeBSD/amd64
  • PDP-11/40のUNIX v6
  • OpenVMS vax
  • OpenVMS alpha 

 

いずれの環境であっても、アセンブラで書いてみようと思います。オリジナルはOSを意識しておらず、シリアルポートの先にASR-33が接続されているのを想定しています。しかし入出力はOSのが提供する機能を利用しようと思います。それでも、行編集のような便利な機能はつかわず、ASR-33並みの原始的な行入力にしておこうと思います。

 

またオリジナルの8080版では、整数16ビットを想定しています。amd64なら整数32ビットにすることもできるかもしれませんが、そういうTiny BASICの仕様を拡張するようなことはしない方針です。できるだけオリジナルと同じ仕様にしておきつつ、動作環境が8080ではないという方向で考えています。

 

データ構造やサブルーチンなども、オリジナルの東大版Palo Alto Tiny BASICと同じようにしようと考えています。発表当時の時代背景を踏まえて、BASICソースは、メモリ上に単純に置かれています。ソフトウェア工学的には、メモリ上の持ち方を変えればスマートかもしれませんが、そういうこともしないつもりです。所詮はTiny BASICなので、大規模と言ってもTiny Trekのような高々200行弱のプログラムで十分です。何千行もあるようなプログラムになることは考えず、最適化されたアルゴリズムを採用しません。

 

いろいろな環境を考えているとはいっても、いきなり全てはできません。まずはamd64環境から始めようと思います。 

2026-02-26

FDI形式ファイルの構造を出力するスクリプトを作成

Windows11上のT98-NEXTでWizardryをプレイするとNFD形式でフロッピーディスクイメージが作られます。これをNetBSD/i386上のxnp2で利用するにはFDI形式に変換しなくてはなりません。変換スクリプトを作成する前に、FDI形式について学ぶため、ファイル内の構造を出力するスクリプトを作ってみました。
 
以前なら、GoogleなどでWebを検索して、参考となるサイトを探していました。今でも同様なのですが、最近はGeminiと対話しながら、作成するようになりました。世間一般では、生成されたスクリプトを何も考えずに使うだけなのか、それとも生成されたものを参考にしながら自前で作るのか、どうしているのかはわかりません。私の場合には、Geminiが生成したスクリプトを参考にして、自分で作り上げるようにしています。 

その結果、以下のようなスクリプトが出来上がりました。これを使ってWizardryで使用しているファイルを参照してみると、いろいろと勉強になります。 

 #!/usr/bin/python3
import sys
import ctypes

# 基本的な型のエイリアス
DWORD = ctypes.c_uint32

# ヘッダ
class FDI_FILE_HEAD(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("Reserve1",   DWORD),
        ("dwMedia",    DWORD),
        ("dwHeadSize", DWORD),
        ("dwDataSize", DWORD),
        ("dwSectSize", DWORD),
        ("dwSecter",   DWORD),
        ("dwHead",     DWORD),
        ("dwCylinder", DWORD),
        ("Reserve2",   ctypes.c_char * (4096 - 4 * 8)),
    ]

if __name__ == "__main__":
    try:
        f = open(sys.argv[1], "br")
    except:
        print("usage: FDIdump <filename>")
        exit(1)

    header = FDI_FILE_HEAD()
    f.readinto(header)

    print(f"dwMedia:0x{header.dwMedia:08x} ({header.dwMedia})")
    print(f"dwHeadSize:0x{header.dwHeadSize:08x} ({header.dwHeadSize})")
    print(f"dwDataSize:0x{header.dwDataSize:08x} ({header.dwDataSize})")
    print(f"dwSectSize:0x{header.dwSectSize:08x} ({header.dwDataSize})")
    print(f"dwSecter:0x{header.dwSecter:08x} ({header.dwSecter})")
    print(f"dwHead:0x{header.dwHead:08x} ({header.dwHead})")
    print(f"dwCylinder:0x{header.dwCylinder:08x} ({header.dwCylinder})")

    print("header size:", ctypes.sizeof(FDI_FILE_HEAD))

#[EOF]

NFD形式ファイルの構造を出力するスクリプトを作成

Windows11上のT98-NEXTでWizardryをプレイするとNFD形式でフロッピーディスクイメージが作られます。これをNetBSD/i386上のxnp2で利用するにはFDI形式に変換しなくてはなりません。変換スクリプトを作成する前に、NFD形式について学ぶため、ファイル内の構造を出力するスクリプトを作ってみました。

 

以前なら、GoogleなどでWebを検索して、参考となるサイトを探していました。今でも同様なのですが、最近はGeminiと対話しながら、作成するようになりました。世間一般では、生成されたスクリプトを何も考えずに使うだけなのか、それとも生成されたものを参考にしながら自前で作るのか、どうしているのかはわかりません。私の場合には、Geminiが生成したスクリプトを参考にして、自分で作り上げるようにしています。

 

その結果、以下のようなスクリプトが出来上がりました。これを使ってWizardryで使用しているファイルを参照してみると、いろいろと勉強になります。 

 

#!/usr/bin/python3
import sys
import ctypes

# 基本的な型のエイリアス
BYTE  = ctypes.c_uint8
WORD  = ctypes.c_uint16
DWORD = ctypes.c_uint32

# セクタ情報
class NFD_SECT_ID(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("C",        BYTE),
        ("H",        BYTE),
        ("R",        BYTE),
        ("N",        BYTE),
        ("flMFM",    BYTE),
        ("flDDAM",   BYTE),
        ("byStatus", BYTE),
        ("byST0",    BYTE),
        ("byST1",    BYTE),
        ("byST2",    BYTE),
        ("byPDA",    BYTE),
        ("Reserve1", ctypes.c_char * 5),
    ]

# ヘッダ
class NFD_FILE_HEAD(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("szFileID",    ctypes.c_char * 15),
        ("Reserve1",    ctypes.c_char * 1),
        ("szComment",   ctypes.c_char * 0x100),
        ("dwHeadSize",  DWORD),
        ("flProtect",   BYTE),
        ("byHead",      BYTE),
        ("Reserve2",    ctypes.c_char * 10),
        ("si",          NFD_SECT_ID * (163 * 26)),
        ("Reserve3",    ctypes.c_char * 0x10),
    ]

if __name__ == "__main__":
    try:
        f = open(sys.argv[1], "br")
    except:
        print("usage: NFDdump <filename>")
        exit(1)

    header = NFD_FILE_HEAD()
    f.readinto(header)

    print(f"szFileID:{header.szFileID}")
    print(f"szComment:{header.szComment}")
    print(f"dwHeadSize:{header.dwHeadSize} (0x{header.dwHeadSize:X})")
    print(f"flProtect:{header.flProtect}")
    print(f"byHead:{header.byHead}")

    for i in range(len(header.si)):
        print(f"{i:4}:  ", end="")
        print(f"C:{header.si[i].C:02x} ", end="")
        print(f"H:{header.si[i].H:02x} ", end="")
        print(f"R:{header.si[i].R:02x} ", end="")
        print(f"N:{header.si[i].N:02x} ", end="")
        print(f"MFM:{header.si[i].flMFM} ", end="")
        print(f"DDAM:{header.si[i].flDDAM} ", end="")
        print(f"Status:{header.si[i].byStatus:02x} ", end="")
        print(f"ST0:{header.si[i].byST0:02x} ", end="")
        print(f"ST1:{header.si[i].byST1:02x} ", end="")
        print(f"ST2:{header.si[i].byST2:02x} ", end="")
        print(f"PDA:{header.si[i].byPDA:02x} ", end="")
        print(f"addr:{(header.dwHeadSize + i * 256):08x}")
#[EOF]
 

2025-10-26

WSLのインストールが簡単になった

Windows11を使うため、新しいPCを購入しましたので、Windows10だった旧PCで使っていたソフトをインストールし、同様の環境を作ろうとしています。その一環として「WSL」をインストールしました。

 

10年ほど前にWSLが登場したころは、まだ開発途上だったからでもありますが、インストール手順が面倒だった記憶があります。それなのに、今回Windows11においてWSLをインストールする手順は、とても簡単でした。Windows PowerShellのコマンドラインを開き、「wsl --install」と入力するだけです。あまりに簡単すぎて拍子抜けでした。

2025-04-21

pathTranslationStyle

WSLを利用する際にはWindowsターミナルを使っています。昔々のWindowsターミナルでは、エクスプローラからフォルダなどをドロップすると、Unix形式のパスに変換してくれて便利だったのですが、いつの間にかWindows形式のパスのままになっていました。形式変換には「wslpath」というコマンドがあるので、何とかなるのですが、ドロップした時に自動的に変換して欲しいと思っていました。

 

ところが、ふとしたことで、求めていた自動変換が実現していることを知りました。「pathTranslationStyle」という設定パラメータで制御できるようです。2025年2月5日付の記事「Windows Terminal Preview 1.23 Release」には、次のような記述があります。

WSL and Ubuntu lovers will love this next one! We now have a Path Translation setting that allows users to control how file paths are translated during drag-and-drop operations. This setting will also be backported to Windows Terminal 1.22!

 

 つい最近になって入った機能のようです。待ってました!という気持ちです。

WSL2とVirtualBoxが共存できた

先週後半にVirtualBoxを更新したら、WSL2が動かなくなり、復旧しようとして試行錯誤したらVirtualBoxも動かなくなってしまいました。ひとまずVirualBoxはアンインストールし、WSL2だけは動くようにしておきました。頭を冷やして、VirtualBoxとWSLを入れなおしたら、なんとか共存できているようです。

 

大雑把な手順は次の通りです。

  1. まず前提として、VirtualBoxは既にアンインストールしてあります。
  2. 「Windowsの機能の有効かまたは無効化」から「Linux用Windowsサブシステム」を無効にします。ここでWindows10を再起動します。
  3. まずVirtualBox 7.1.8をインストールしました。念のためにWindows10を再起動しておきます。
  4. ここでVirtualBox上の仮想環境を動かしたら、エラーになりませんでした。
  5. 次に「Windowsの機能の有効かまたは無効化」から「Linux用Windowsサブシステム」を再び有効にします。やはりWindows10の再起動が必要です。
  6. 心配なので、VirtualBox上で仮想環境を動かしてみましたが、エラーになりませんでした。
  7. WSL2でUbuntuを実行してみたら、エラーにならずに動きました。

 

これで、ひとまずはWSL2もVirtualBoxもエラーにならずに動いてくれるようになりました。しかし、WSL側か、VirutalBox側で何かが更新されたら、また動かなくなるかもしれません。将来も安心というわけにはいかないかもしれません。

 

どんな環境でも絶対大丈夫とは言えませんが、動作した事例があるということは言えます。ちなみにWSLのバージョンは次の通りです。

WSL バージョン: 2.4.13.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.19045.5737

 

またVirtualBoxのバージョンは次の通りです。 

VirtualBox グラフィカルユーザーインターフェース
バージョン 7.1.8 r168469 (Qt6.5.3)

2025-04-17

VirtualBoxの最新版を入れたら仮想環境が起動しなくなり、しかもWSL環境も動かなくなった

VirtualBox 7.1.8が出たので更新したら、仮想環境が起動しなくなってしまいました。これがVirtualBoxの不具合なのか、僕のマシン(Windows10)の問題なのか分かりませんが、原因が何であったにせよ、ともかく仮想環境が起動しません。さらに不幸なことに、WSL2環境も動かなくなりました。WSL2環境は、更新作業の直前には動作するのを確認しています。VirtualBoxの仮想環境も、最近使用して、問題ありませんでした。

 

もしかすると、再起動したら問題なく動作するのかもしれません。微かな望みをかけつつ再起動しましたが、WSL2環境もVirtualBoxの仮想環境も起動しませんでした。

 

とにかく復旧させなければならないので、VirualBoxをアンインストールしました。念のために再起動したのですが、WSL2環境は相変わらず起動しません。

 

 次に「Windowsの機能の有効化または無効化」から「Linux用Windowsサブシステム」を一旦無効にして、改めて有効にしてみました。この間、何度か再起動しています。それでもWSL2環境は起動してくれません。

 

最後にWSL2としてインストールしてある「Ubuntu」を削除し、改めてインストールし直したところ、ようやくWSL2環境でUbuntuが動作してくれました。しかし一度削除しているので、壊れる前のファイルは全て無くなってしまいましたが、WSL2環境が復活したので、これで良しとします。

 

VirtualBoxの最新版に何か不具合があったのかもしれませんが、その確証はありません。もしかすると僕の使っている環境がWindows10なのが良くないのかもしれません。今年秋にはWindows10のサポートが切れるので、それまでにはWindows11に移行しようと思っています。でも薄々感じるのですが、Windows11になっても、今回のような突発的なトラブルからは逃れられない気がします。

2025-01-22

エクスプローラからWindows Terminal上のWSLにパス名をドロップした際の挙動

VirtualBox 7.1.6をインストールしたらWSL上のUbuntuが動かなくなったので、なんとか復旧しました。すると、Windows Terminal上の挙動が変わったことに気づきました。


従来は、エクスプローラからフォルダをWSL上にドロップすると、WSL形式のパス名に自動的に変換されていました。ところが、何故かWindows形式のパス名のままなので、そのままではUbuntu上ではパス名として有効ではありません。wslpathというコマンドが用意されているようなので、それを使えば変換できますが、ひと手間増えるので、以前の挙動の方が楽でした。

 

調べてみると「Windows Terminal のおすすめ設定2022年4月版」という記事に、以下の記述がありました。

ターミナルへのファイルのドラッグ&ドロップでWSLのパスに変換してくれるのはプレビュー版の機能なので、プレビュー版(バージョン: 1.13.10734.0)を使う。


今使っているのは「Windows ターミナル 1.21.3231.0」です。これは、インストールしなおした訳ではないのですが、何故か挙動が違います。それはともかく、プレビュー版の機能として実現するのではなく、最新版でも機能すればありがたいと思います。もし何か不具合が生じる可能性があるならば、設定画面でON/OFFを切り替えられるようになっていてほしいところです。

VirtualBox 7.1.6をインストールしたら、WSL2上のUbuntuが起動しなくなった

VertualBox 7.1.6がリリースされたようなのでインストールしました。これが直接の原因なのかわかりませんが、他の変更を加えていないので疑わしいことは間違いありませんが、WSL2が起動しなくなりました。Webを検索し、復旧方法を探ったところ、WSL2の入れ直しになってしまうようです。


  1. WSLのコンポーネントをWindows10から外して、再起動する。
  2. WSLのコンポーネントをWindows10に入れて、再起動する。
  3. WSL上のUbuntuをインストールする。 

 

このような手順で、ひとまずWSL2は動くようになりました。しかし新規インストール扱いになるので、これまでWSL上のUbuntuに加えてきたパッケージなどは、綺麗さっぱり無くなってしまいました。

2024-02-10

vscodeとPythonと『Python計算機科学新教本』

オライリーから『Python計算機科学新教本』という書籍が出版されています。大雑把に言ってしまうとアルゴリズムについて書かれた本ですが、Pythonを使って説明しているのが今風です。同じ著者から他の言語で説明している書籍がO'Reillyから出ていますが、和訳は無いようです。

 

この本の「3章 制約充足問題」や「4章 グラフ問題」を勉強してみようと思っています。書籍の中でソースコードも提示されていますし、ダウンロードサービスもあるようですから、Pythonが動く環境さえあれば、勉強するための最低限の環境は整います。それでも構わないのですが、最近はやりのVisual Studio Codeを使ってみようかと思います。


vscodeとWSLを連携させることが出来るようですし、Pythonを扱うための機能も揃っているようです。Web上には多くの記事がありますが、「Visual Studio Codeで快適Pythonライフ」を参考にしてみました。Pythonをコーディングするだけなら、WSL上でviを使うのが手っ取り早いのですが、vscodeならデバッガを利用できるようなので、そこに魅力を感じています。

2023-01-09

WSLgで日本語が出るように設定

昨日WSLをストア版に更新することで、Windows10でもWSLgを利用することができるようになりました。GUI版のemacsが使えるので感動したのですが、日本語フォントがないので、日本語を表示できません。


Webを検索すると「Win11のWSL2 (WSLg)を日本語化 & Mozcで日本語入力」という情報を見つけました。日本語を表示するだけではなく、日本語入力も行えるようにするようですが、僕の場合は日本語表示だけで良いので、その一部だけを設定しました。


Ubuntu内で「fc-list」すると見つかるフォントは20個だけで、もちろん日本語フォントはありません。そこで/etc/fonts/local.confを作成してみると、572個ものフォントが見つかるようになり、GUI版emacsでも日本語が出るようになりました。


/etc/fonts/local.confは、上述した記事にあるのと同様で、以下の内容です。

<?xml version="1.0"?>

<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<fontconfig>

        <dir>/mnt/c/Windows/Fonts</dir>

</fontconfig>

Docker Desktop for Windowsをインストールしたら、既存のWSL2が影響を受けた

機能はWSL2をストア版に更新したので、次に前々から気になっていたDockerを入れてみました。Dockerの概念的なことは理解できます。しかし一歩踏み込んだところがピンとこないので、使ってみて理解していこうと思っています。

 

まずはDocker Desktop for Windowsをインストールしました。インストール後に再起動し、Windowsが起動しましたが、何をしたら良いのか、まだわかりません。PowerShellのコマンドラインから「docker run hello-world」してみましたが、問題なく動いているようです。

 

 Dockerについて今後おいおい勉強していくことにして、ここでちょっとWSLgで試したいことがあったので、WSL2のUbuntuを起動しました。ところが何だか様子が変です。昨日インストールしたはずのXクライアントが見つからなくなっています。しかもアカウントが「wslg」になっており、こんなアカウントは作った覚えがありません。いったい何が起きたのか全く分からず、PowerShellのコマンドプロンプトで「wsl -l -v」としたら、次のような結果になりました。

PS C:\Users\FURUSAWA> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Running         2
  docker-desktop-data    Running         2
  docker-desktop         Running         2


Docker関係が増えています。何か悪さをしているのかもしれません。よくわからないので、PowerShellのコマンドプロンプトで「wsl --shutdown」してみました。docker-desktopは停止状態になりませんでした。それから改めてUbuntuを起動したところ、Dockerインストール前の状態が復活しました。


何故このような現象が起きたのか理由は分かりませんが、元の状態に戻ったので、良しとします。

2023-01-08

Windows10のWSLをストア版に更新し、WSLgを試してみた

Microsoft Windowsで利用できるWSLがストア版に一本化されるようなので、更新作業をおこないました。更新はとても簡単で、10分もかからず完了しました。あわせて、これまでWindows11のWSLでしか利用できなかったWSLgが、Windows10のWSLでも利用できるので、試してみました。xeyesを動かしてみましたが、問題ありません。

更新作業は、コマンドプロンプトでおこないました。当初DOSコマンドラインを使おうとしたのですが、動作が思わしくないので、PowerShellコマンドラインで作業しました。

作業前のWSLは、こんな感じでした。

PS C:\Users\FURUSAWA> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Stopped         2
PS C:\Users\FURUSAWA> wsl --version
コマンド ライン オプションが無効です: --version
Copyright (c) Microsoft Corporation. All rights reserved.
(以下略)
PS C:\Users\FURUSAWA> wsl --status
既定の配布: Ubuntu
既定のバージョン: 2

Linux 用 Windows サブシステムの最終更新日: 2022/03/26
WSL の自動更新が有効になっています。

カーネル バージョン: 5.10.102.1

 

更新作業は、こんな感じです。数分で終わりました。

PS C:\Users\FURUSAWA> wsl --update
インストール中: Linux 用 Windows サブシステム
Linux 用 Windows サブシステム  はインストールされました。

 

更新後のWSLは、こんな感じになりました。

PS C:\Users\FURUSAWA> wsl -l -v
NAME      STATE           VERSION
* Ubuntu    Stopped         2
PS C:\Users\FURUSAWA> wsl --version
WSL バージョン: 1.0.3.0
カーネル バージョン: 5.15.79.1
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.19045.2364
PS C:\Users\FURUSAWA> wsl --status
既定のディストリビューション: Ubuntu
既定のバージョン: 2


WSLgを試してみるには、Xクライアントをインストールしておく必要があります。

 

$ sudo apt install x11-apps


これでXクライアントがインストールされるので、xeyesやicoを試してみたところ、問題なく動作しました。

2022-11-24

WSLg

Microsoftは数年前にWindows Subsystem for Linuxを発表し、当初のWSLとは別にWSL2も登場しました。その後Windows11ではWSLgというGUIも可能となる拡張がおこなわれました。しかしWSLgはWindows10では動作しないので、残念に感じていたところです。


ところが「Windows 10でもWSLを使ってLinux GUIアプリが実行可能に」によると、Microsoft StoreからリリースされるWSLでは、Windows10でもWSLgが有効になるとのことでした。これは朗報です。


現在はWindows10同梱のWSL2を利用していますが、WSLgが使えるなら、Microsoft Store版WSLに移行しようと思います。正式なリリースは2022年12月半ばらしいので、リリースされ次第、移行するつもりです。

2021-09-08

WSL2を有効にしてVirtualBox上でCentOS7が動作した

昨年からWindows10上でWSL2を利用しています。もともとWSLを使っていましたが、1年ほど前にWSL2に移行しました。それ以前より、WSLと共に、VirtualBoxやVMware Playerも利用していました。


ところがWSL2を有効にしたら、VirualBox上でCentOS7が動かなくなりました。VirtualBox上で動作するOSもあり、VMware Playerを使えばCentOS7が動作するのですが、何が悪いのか分かりませんが、動作する組み合わせがあるようです。


先日Webをみていたら、WSL2を有効にしていてもVirtualBox上で動くようになったという記事「WSL2とHyper-Vの関係」を見つけたので、あらためてVirutalBox上でCentOS7.4を動かしてみたところ、一部に不審なメッセージが出るものの、動作することを確認しました。


動作を確認した環境は、こんな感じです。

  • 【CPU】Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz
  • 【Windows10】バージョン 20H2 (OSビルド 19042.1165)
  • 【VirtualBox】バージョン 6.1.26 r145957 (Qt5.6.2)
  • 【CentOS7.4】Linux foobar 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

2021-05-14

WSLのUbuntuでdo-release-upgradeに失敗

WSL上でUbuntuを利用しています。 

No LSB modules are available.

Distributor ID: Ubuntu

Description:    Ubuntu 18.04.5 LTS

Release:        18.04

Codename:       bionic


何かのために本格的に利用している訳ではないのですが、Web上の記事「Ubuntu 18.04(LTS)→20.04(LTS)アップグレード方法」を参考にして、バージョンを上げようとしました。ところがエラーで中断してしまいます。

状態情報を読み取っています... 完了      

=== Command detached from window (Fri May 14 17:37:50 2021) ===

=== Command terminated with exit status 1 (Fri May 14 17:38:00 2021) ===


何かのコマンドが異常終了したようですが、それが何なのか分かりません。どこかに情報が出ているのでしょうか。


エラーの原因を突き止めて、問題を解決すれば綺麗だとは思いますが、手っ取り早くUbuntuを再インストールするのも一つの方法かと思います。