Winamp 官方放出 Legacy 版本的程式碼

看到「Winamp Legacy player source code (github.com/winampdesktop)」這個,官方放出 Winamp 程式碼:「Winamp」,主要算是歷史的記錄,用電腦聽音樂如果是有設備的人應該會挑 foobar2000 之類的軟體,如果只是隨意聽的話應該就是開各家 streaming 的應用程式?

話說 Nullsoft 做了不少有名的東西,除了 Winamp 以外還有 SHOUTcastNSIS 這兩個比較有名的軟體,不過都算是歷史了。

ARM 版的 Windows 宣稱要改善 x86 轉譯速度

在「Microsoft gives Windows new compiler, kernel, scheduler, and x86 translation layer on ARM」這邊看到的:

Microsoft also unveiled the name for its new x86 translation layer for Windows on ARM: Prism. Microsoft told Ars Technica that Prism is as fast as Apple’s Rosetta 2, which is interesting because Apple’s M series chips contain special silicon to speed up the translation process, making me wonder if Qualcomm has done the same, or is just brute-forcing it.

看起來之前 Windows 平板上跑 x86 應用程式很慢的痛點有機會改善?另外不知道技術相似度如何,有沒有機會看到細節分析...

在 virt-manager 裡面的 Windows 發出聲音

用了幾個月才發現沒聲音,花了點時間找方法測試才解決。

一般人用預設值應該是沒問題,不過我的環境比較特別,剛好不是預設值,我的 PulseAudio 輸出到 DA&T C-13 時是設定成 96kHz/24bit,而一般 Windows 預設輸出時是 44.1kHz/16bit,兩邊對不起來就沒聲音了。

找了一些文章,後來是在「Virtual machine audio setup – or how to get pulse audio working」這篇裡面講到用 virsh 直接改 XML 設定檔的方式讓 qemu 輸出到 PulseAudio 裡面轉,也就是文章裡面 Option 2 的部分。

這樣 guest OS 裡面還是跑 44.1/16,但外面輸出的時候就固定是 96/24 了。

比較奇怪的是如果 guest 裡面跑 96/16 的話聲音會破破的,不過我只是要有聲音 (不然也不會用了好幾個月才發現),品質的問題倒是還好...

Windows 98 安裝的三階段

看到「Why does part of the Windows 98 Setup program look older than the rest? (2020) (retrocomputing.stackexchange.com)」這個,原文是 2020 的討論:「Why does part of the Windows 98 Setup program look older than the rest?」。

問題是 Windows 98 的安裝過程中段可以看出來有 Windows 3.1 介面的感覺,像這樣:

而到了後段又是 Windows 98 的感覺,作者覺得 UI 介面風格不一致的問題...

回答的人則是解釋得很清楚,第一階段是 DOS 階段,會把 Windows 3.1 環境疊出來:

The first, which can run from the setup floppies and/or CD-ROM, uses a DOS program (DOSSETUP.BIN) to set up disk partitions, run various checks etc.:

This phases finishes by copying a minimal version of Windows 3.1 to the target installation drive, in a temporary directory (normally WININST0.400), containing DOSX.EXE, USER.EXE, GDI.EXE, KRNL386.EXE, LZEXPAND.DLL etc. (see MINI.CAB).

第二階段則是 Windows 3.1 環境,把 Windows 98 大多數的東西都複製到硬碟上:

The second uses this minimal Windows 3.1 to run a Windows 3 program, W98SETUP.BIN (specified as the “shell” in SYSTEM.INI):

This starts by copying more files to support all the information-gathering during setup, and various other niceties including the 3D look shown in your screenshot (the contents of the PRECOPY CABs); it ends by copying most of Windows 98, setting the system up so that it will boot Windows 98 from the target drive, and rebooting.

第三階段則是 Windows 98 環境,執行後續的設定程式:

The third runs after the first boot into Windows 98, from Windows 98:

而且也提到了當年可以升級作業系統的情況 (雖然我自己偏好重裝):

It is also possible to initiate the setup process from any of the above environments, which is how Windows 98 handles upgrades (from MS-DOS, or Windows 3, or Windows 95).

是個解釋遺跡的現場 XDDD

用 Samba 讓 virt-manager 內的 Windows 存取資料

續著「從 VirtualBox 換到 virt-manager」這篇,當時其他的問題都解的差不多了,但用 VirtualBox 時可以很方便的分享目錄,然後用 \\vboxsrv\directory 存取到 host 的資料,在 virt-manager 就沒辦法這樣弄了。

網路上比較多人提到的是 SPICE 提供的 WebDAV 方式存取,但怎麼弄都弄不起來,最後決定直接在 host 上面跑 Samba,這樣 guest OS 內也不用裝軟體了...

雖然中間有遇到新版 Windows 會在 client 端擋 guest access,用 gpedit 改一下就可以用了,這邊把摸索出來的 Samba 設定放在我自己的 wiki 上面:「Samba」。

這樣算是把 virt-manager 的最後一塊拼圖補上了...

從 VirtualBox 換到 virt-manager

為了可以使用 KVM,把桌機 Ubuntu (Xubuntu) 上的 VM 都從 VirtualBox 換到 virt-manager 了...

不得不說 VirtualBox 包的很好,很多事情就不用自己繞半天... 在 virt-manager 上面有蠻多東西得自己設定繞開,把 2024 年會遇到的問題整理下來。

首先是權限的部分,裝完 virt-manager 後馬上打開會遇到 virt-manager 說連不到 libvirtd 的問題:「virt-manager can't connect to libvirt」,而最簡單的解法就是重開機,原因是安裝過程中在 /etc/group 增加了 libvirt 的權限,現有的 session 因為權限不夠無法連上 libvirtd。

接下來就是操作介面上的順暢度問題了,預設「Automatically detect from the installation media / source」是勾起來的,但你丟 Windows 的 ISO 進去不一定會偵測到是 Windows 的 ISO,需要把勾勾拿掉,然後自己輸入 win 後才會出現可以選的選項,而不是直接選單選擇... 這邊的 UX 在第一次用的時候還蠻卡的。

另外裡面設定也是有問題的,選擇 Windows XP 會發現網路的設定居然還是用 e1000,導致 Windows XP 抓不到網路卡,需要另外再改成 rtl8139 (不過速度只有 100Mbps)。

最後在 Network selection 的部分,NAT 算是最常用的,不過如果要自己架設 lab 的話 (像是我弄了三台 Ubuntu VM 測各種服務),直覺會設定成 Bridge device,但這邊的 Bridge device 是需要先自己設定好 bridge interface 後再讓 virt-manager 設定掛進去。

所以比較「簡單」的方式 (當時以為比較簡單) 是選擇 Macvtap,然後選擇要用的介面,這樣設定後主機的確可以透過指定的介面連到 Internet 上,但就像設定 Macvtap 時出現的警告,guest 與 host 本機之間是無法溝通的:「In most configuration, macvtap does not work for host to guest network communication.」。

解決的方法還是自己搞 bridge interface,這邊由於 Ubuntu 現在網路都是透過 Netplan 在管理,我是透過「[Wishlist] Support macvlan/macvtap interfaces」這邊提供的 workaround 來解決。

以前是直接在 enps0f0 上面設定 IP address,現在是在 networkd 跑起來就先建立 macvlan0,然後在上面設定 IP address。然後 virt-manager 就可以用 macvtap 到 macvlan0 了,實際測試 guest 與 host 之間也通了...

折騰了一會算是搬過來了,這樣總算是可以在桌機上面跑 android emulator 了,先前硬關掉 KVM 跑了兩次,速度實在是受不了,就跑去 Mac 上開發了,現在這樣好多了...

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡,兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet,這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet,但我希望 VM 是走社區網路,所以用 bridge mode 設定到網卡上,用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到,前幾天用 Line 傳照片的時候很慢 (之前就有發生了,一直忘記去追問題),花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢,這點可以從 Speedtest 的測試結果看到:

先講最後的結論,在交叉測了很多組合後,我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled

回到當時抓問題的情況,當時先用筆電與 host 測試都沒看到問題,所以看起來應該是 VM 裡面的狀況,但不確定是什麼情況,畢竟不是斷掉...

由於下載速度正常,只有上傳速度卡住,一開始想到的是跟 MTU 相關的問題,所以找了指令降到 1400 後測試,還是一樣...

後來先把 VM 的網路改成 NAT,再測試上傳速度就正常了...

接著想要換個網路卡類型看看,結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了,但想說先去看看 Windows 10 網卡設定裡面的設定,結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗?)。

然後一關就正常了,交叉再開關兩次確認這個參數有影響,就肯定這個 workaround 應該是有效了...

另外在自己找完問題後,在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

Windows 95/NT 4.0/98/ME/2000/XP 的 Windows Update

看到「Project restores Windows Update for Windows 9x」這篇在介紹「Windows Update Restored: Fix Windows Update On Windows 95. 98, ME, 2000, and XP」這個幫這些古董 OS 裝 Windows Update 的專案。

看起來只是把官方的 security patch 整理起來而已,並不處理 EoL 後的安全性問題。

但對於要弄個老環境的人來說算是方便的工具,至少把有公開過的 security patch 都打進去。

Windows 3.1 下的 GPT client

前幾天在 Hacker News 上看到「Show HN: WinGPT – AI assistant for Windows 3.1 (dialup.net)」這篇,原始文章「WinGPT: AI Assistant for Windows 3.1」在介紹 Windows 3.1 下的 GPT client。

雖然反差很大 (一個 20 世紀的 GUI 環境配上最新科技),但從 Hacker News 的討論可以看到,最熱烈的是在 16-bit 環境下實作 TLS 1.3 連線,也就原文裡的這段,提到了他是原生支援 TLS 1.3:

WinGPT connects to the OpenAI API server natively with TLS 1.3, so it doesn't require a proxy on a modern machine to terminate TLS. To see how I did this and some of the challenges, take a look at Modern TLS on 16-bit Windows. (As you'll see on that page, this is not a secure implementation).

不過他不是從零開始解,而是基於 wolfSSL 的實作,因為 wolfSSL 有支援 16-bit compiler,就不需要從零開始:

WolfSSL stood out among the pack as it had explicit 16-bit compiler support while being fully-featured and well-supported.

這是讓人看到會「蛤?」的東西 XD

Windows 11 瘦身版本的 Tiny11

Tiny11NTDEV 弄出來的精簡版 Windows 11:「De-Bloated Windows 11 Build Runs on 2GB of RAM」。HN 上對應的討論在「De-Bloated Windows 11 Build Runs on 2GB of RAM (tomshardware.com)」。

It just uses around 8GB of space compared to the 20+GB that a standard installation does.

但有些限制,像是安全性更新需要自己來:

This OS install “is not serviceable,” notes NTDev. “.NET, drivers and security definition updates can still be installed from Windows Update,” so this isn’t an install which you can set and forget.

另外像是透過 WinSxS 安裝的功能 (包括語言) 會無法安裝:

Moreover, removing the Windows Component Store (WinSxS), which is responsible for a fair degree of Tiny11’s compactness, means that installing new features or languages isn’t possible.

但我記得拔掉 WinSxS 應該會影響蠻多東西的?這樣的系統應該是拿來跑跑 CI 或是固定用途還行,一般性的用途不知道會卡多少東西...

另外除了使用的磁碟空間變小以外,記憶體的使用量也大幅下降,畢竟也拔掉了一堆肥大的軟體:

In testing, NTDev said that Tiny11 could “run great” on a system with just 2GB of RAM.