Alice wrote:That might work, though it sounds like it wouldn't work without me having to modify rom files before they can be used.
No... I was thinking more like this (as a solution to the case where the files are stored on the user's computer, rather than on the server):
1. The first time the user runs a program, they choose a file using a file dialog
2. The program then puts a copy of the program into localStorage
3. When the user runs the program again, it gets the copy from localStorage rather than having to use a file dialog.
The original file doesn't have to be changed, and the copy in memory that it runs from doesn't have to be changed, but the copy in localStorage has to be a string. So step 2 has to somehow convert the file into a string, and step 3 has to convert it back into binary. What I suggested was one way of doing that, though there are others (e.g., store the program as a hexadecimal string).
Of course, this isn't necessary if the file is on the server, where the program can access it.
If you're curious, here's where the differences come from:
• There's a bug in toHex: if a byte has one hexadecimal digit (i.e., it's less than 0x10), then it'll only output one digit, whereas it should output 2 digits for each byte. (You can fix this with an if statement that adds "0" in the right place.)
• Somewhere along the line (which could be when copying the string into the program), null bytes (00) got changed into spaces (20). This doesn't have anything to do with UTF-16; many programs that handle text, regardless of encoding, don't like dealing with null characters. Firefox seems to allow null characters in strings if you write them as \0, but I wouldn't count on every browser dealing with them correctly.
• Somewhere along the line, characters were converted from Windows-1252 encoding to Unicode (character values are the same for the two encodings except for 0x80-0x9f (the actual representation in bytes is different, but that's not important here)), so 0x80 (€ in Windows-1252) was changed to 0x20ac (€ in Unicode).