QEMU模擬器項目創始人Fabrice Bellard開發了在JavaScript中運行的模擬器，允許用戶在浏覽器上(支持Firefox 4和Google Chrome 11)啟動Linux。現在，另一位開發者修改了Fabrice Bellard的JS/Linux，允許模擬器啟動較新的內核版本linux kernel 3.0.4，同時支持永久儲存。
圖1 最新版本(內核版本為3.0.4)
開發者創建了一個虛擬塊設備，它能在HTML5本地儲存中儲存數據，塊設備可以分區和格式化。部分源碼(http://stud.hro.nl/0814604/jslinuxdemo/)地址，運行方法是點擊emulator.html(http://stud.hro.nl/0814604/jslinuxdemo/emulator.html)，登錄名為root。
圖2 最新版本(支持本地存儲，可以將文件系統鏡像保存到本地或上傳)
另一個版本的地址為http://bellard.org/jslinux/ 。
圖2 另一個版本(可通過clipboard設備在用戶和虛擬機中Linux傳遞信息)
這是一台完全通過JavaScript寫成的、使用QEMU模擬x86指令集的、運行在浏覽器（我的FireFox運行正常）上的虛擬機。這台機上面運行著一套2.6.20內核的Linux OS，這裡的“運行”和以前一些WebOS或者JavaScript模擬DOS的程序並不是一回事，這裡的OS就是完完全全運行在客戶端浏覽器上的，各種交互並不會傳送到服務端或者委派到cmd.exe這些程序上執行，說白了這就是一台這實實在在運行的Linux虛擬機，這台虛擬機的相關信息可以在作者公布的Tech頁面看到。也可以自己登錄到虛擬機上查一下。
發現文件系統是用BusyBox做的，可以使用大多數Linux的命令，還可以用tab來自動補全操作時的命令。
圖3 所有支持的命令
如何實現的：
作者 Fabrice Bellard 使用 JavaScript 編寫了一個簡單的 PC 模擬器，包含32位 x86 兼容 CPU、8259 可編程中斷控制器、8254 可編程中斷計時器
實現 16450 UART 串口設備
用 JavaScript 實現一個終端
編譯包含 FPU 模擬的 Linux 內核鏡像。
使用 Buildroot 創建文件系統並在啟動時載入 RAM。
添加基本工具集 BusyBox，微型 C 編譯器 TinyCC，以及迷你編輯器 QEmacs
jslinux 簡單分析
jslinux：用JavaScript寫出一個PC模擬器，上面運行Linux (The code is written in pure Javascript using Typed Arrays which are available in recent browsers.) 1、主頁面 (http://bellard.org/jslinux/) 很簡單，主要調用了 如下兩個 js 文件。 http://bellard.org/jslinux/term.js http://bellard.org/jslinux/cpux86.js 2、term.js 裡也沒有發現什麼特殊的地方； 3、cpux86.js 使用到一個 load_binary 的函數，查看了一下實現，是通過 XMLHttpRequest 來取如下三個 bin 文件(使用Typed Arrays 操作二進制文件)： http://bellard.org/jslinux/vmlinux26.bin http://bellard.org/jslinux/root.bin http://bellard.org/jslinux/linuxstart.bin
根據作者的描述，該模擬器的初衷是了解現在 JavaScript 引擎的工作，尤其是 Firefox 4 的 Jaeger Monkey 和 Chrome 的 V8，這個探索的結果，可以被用來：
通過 Linux 的啟動時間反應浏覽器的 JavaScript 性能。(作者說目前在 Firefox 4 下比 Chrome 11 要快 2倍，Chrome 12 有 Bug 無法運行)。
實驗在用 JavaScript 進行客戶端運算時載入 x86 運行庫的可能性。
進一步發展從而支持 DOS 游戲的運行。
圖4 微型 C 編譯器 TinyCC home目錄下有個一個hello.c文件，這是將它編譯後運行後的結果。有了C編譯器，以及QEmacs、vi等文本編譯器，我們可以在這個平台上編寫C程序。 
圖5 CPU信息
圖6 內存信息
下面是虛擬塊設備和本地存儲的一些介紹：
This project allows the virtual machine to access a persistent block device. This means a user can format and partition this device inside it's virtual machine. Because this disk is then stored in the HTML5 local storage(存儲在HTML5本地存儲中), a return to the emulator's web page allows a user to reopen the block device. All data stored on the disk can therefore be read again.
Schematically, the process works in the following way: A block device driver is added to the Linux kernel. This allows a user to operate with a 'device' written in JavaScript. This device is bound to the virtual machine using the same I/O ports as a floppy disk. The device driver itself uses a temporary testing major device node, id 250. Theoretically, it allows dynamic device node allocation, but I have not tested this. On the JavaScript side, a lot of caching occurs because the local storage interface is quite slow. I therefore decided to cache the total 'disk' in memory, because it's about 1M anyway. Writes are cached as well, and are 'flushed' once the driver has transferred a complete sector. For more details, see the source code.
===========================================================================
Javascript PC Emulator - News
Aug 20, 2011:
May 26, 2011:
May 20, 2011:
May 18, 2011:
May 17, 2011:
May 16, 2011:
Javascript PC Emulator - FAQ
Which browser should I use to try the PC emulator ?
What is the expected boot time of Linux with the emulator ?
How can I scroll back in the terminal ?
How can I copy data to the Virtual Machine ?
How can I copy data from the Virtual Machine ?
When will there be network support ?
Is it possible to emulate a VGA card and all the missing devices to launch say FreeDOS or Windows ?
Is there some source code available ?
Is my privacy respected ?
Javascript PC Emulator - Technical Notes技術內涵
This PC emulator is written in Javascript. The emulated hardware consists in the following devices:
CPU Emulation
Devices
Javascript terminal
Linux distribution
Javascript
What's the use ?
===========================================================================
Javascript PC Emulator - News
Aug 20, 2011:
faster emulation
added 16 bit & segmentation support
added scroll back in terminal
May 26, 2011:
display boot time
faster emulation
added some missing instructions (bcd support, XLAT, BOUND)
easier customization possible (see jslinux.js file).
May 20, 2011:
added support for more browsers including Opera 11.11 and Internet Explorer 9
reduced VM RAM size from 32 MB to 16 MB
Source code release of the Linux starter utility.
May 18, 2011:
added a clipboard to exchange data between the VM and the host
added FAQ and News pages
fixed monospace font for some browsers.
May 17, 2011:
fixed binary XHR for Firefox nightly builds
fixed terminal height for the less command
fixed ampersand output in the terminal.
May 16, 2011:
Initial realease.
Javascript PC Emulator - FAQ
更多精彩內容：http://www.bianceng.cn/OS/Linux/
The following browsers are officially supported:
Firefox >= 4
Chrome 11
Opera 11.11
Internet Explorer 9
For optimal performance, your browser should support the W3C Typed Arrays. Firefox 4.x and Chrome 11 have such support.
The current version of Chrome 12 beta is reported to have a bug preventing to run the emulator.
Here are some figures:
Use Ctrl-Up, Ctrl-Down, Ctrl-PageUp and Ctrl-PageDown.
Copy your file content to the OS clipboard using your favorite text editor.
Paste the data to the JS/Linux clipboard using the mouse (it is the text area on the right of the VM terminal).
In the VM Linux shell do:
cat < /dev/clipboard > /tmp/myfile
Your text file is now copied to /tmp/myfile.
To copy binary data, you can uuencode it on the PC using (assuming you use Linux):
uuencode myfile myfile > myfile.txt
Then you copy myfile.txt to the Linux VM and uudecode it by doing:
uudecode < /dev/clipboard
The procedure is the reverse of the previous one:
Copy your file to the clipboard:
cat myfile > /dev/clipboard
Select all the clipboard data and copy it to the host OS clipboard using the mouse over the text area on the right of the VM terminal.
Paste the data in your favorite text editor
For binary files, you can uuencode in the VM and uudecode on the host.
It is relatively easy to add a virtual network interface. The problem is to make it communicate with other hosts, so at this point it is not my priority. For example, due to security restrictions, it is only possible to communicate with the web site hosting the VM or with cooperating servers. Moreover, only specific types of network protocols can be handled because no raw TCP connection nor raw UDP packets can be sent due to API restrictions and security reasons.
Yes, it is possible but since the current VM is quite slow, only old OSes (such as Windows 3 or MSDOS) would be really usable.
In the technical notes, an archive is given which explains how to build the various binary images.
The readable source code of the JS PC emulator itself is not yet available. At this point, any mirroring or redistribution of the code needs my explicit permission.
Yes. What you type in the Virtual Machine stays in your browser. No data is sent back to the server.
Javascript PC Emulator - Technical Notes
By Fabrice Bellard - May 23, 2011
This PC emulator is written in Javascript. The emulated hardware consists in the following devices:
32 bit x86 compatible CPU
8259 Programmble Interrupt Controller
8254 Programmble Interrupt Timer
16450 UART
Real Time Clock.
The code is written in pure Javascript using the W3C Typed Arrays. A slightly slower fallback mode is implemented for browsers missing this support. For the exact list of supported browsers, see the FAQ. In any case, a fast Javascript engine is needed to have good performance.
Some of the code is inspired from my x86 dynamic translator present in QEMU, but there are important differences because here it is an interpreter. The CPU is close to a 486 compatible x86 without FPU. The lack of FPU is not a problem when running Linux as Operating System because it contains a FPU emulator. In order to be able to run Linux, a complete MMU is implemented. The exact restrictions of the emulated CPU are:
No FPU/MMX/SSE
No segment limit and right checks when accessing memory (Linux does not rely on them for memory protection, so it is not an issue. The x86 emulator of QEMU has the same restriction).
No single-stepping
I added some tricks which are not present in QEMU to be more precise when emulating unaligned load/stores at page boundaries. The condition code emulation is also more efficient than the one in QEMU.
Currently there is no synchronization between the PIT frequency and the real time, so there is a variable drift between the time returned by Linux (try the "date" command) and the real time.
The UART (serial port) does not support FIFO mode. Perhaps it could help to improve the display speed.
There is no network emulation at this point.
A clipboard device (seen as /dev/clipboard in the emulator) was added to allow exchange of data between the emulator and the outside world.
Although I could have reused the excellent termlib, I decided to write my own because I was curious to see how it could be done. The main problem is the key handling which is different among browsers and OSes, as described here.
I compiled a 2.6.20 Linux kernel (I guess any other version would work provided there is still an FPU emulator). The Linux kernel configuration, patch and the source code of the Linux starter (kind of BIOS) are available: linuxstart-20110820.tar.gz.
The disk image is just a ram disk image loaded at boot time. It contains a filesystem generated with Buildroot containing BusyBox. I added my toy C compiler TinyCCand my unfinished but usable emacs clone QEmacs. There is also a small MS-DOS .COM launcher I use to test the 16 bit emulation with a tiny .COM program to compute pi and a small self-assembling assembler for MS-DOS.
I happen to be interested by the implementation of Javascript engines these days - but I don't know yet if I will write my own any time soon ! Anyway, this emulator was a way to learn how to write optimized code for recent Javascript engines, in particular Jaeger Monkey (for Firefox 4) and V8 (for Chrome).
A troubling thing is that the PC emulator is slower using V8 than Jaeger Monkey (I used the 32 bit version for both). I have no precise explanation yet because I only looked at the Jeager Monkey code so far.
I did it for fun, just because newer Javascript Engines are fast enough to do complicated things. Real use could be:
Benchmarking of Javascript engines (how much time takes your Javascript engine to boot Linux ?). For this particular application, efficient handling of 32 bit signed and unsigned integers and of typed arrays is important.
Learning to use command line Unix tools without leaving the browser.
Client side processing using an x86 library, for example for cryptographic purposes. For such application, the x86 emulator can be modified to provide an API to load x86 dynamic libraries and to provide a js-ctypes like API to call the C/C++ functions from javascript.
A more advanced version would allow to use old DOS PC software such as games.
作者：csdn博客 ce123