Thus it was possible to write a program using the following steps:
1. Write out the Z80 assembly code
2. Convert to opcodes
3. Look up the opcodes in the character map and type the appropriate character on the screen starting at top left
Then you could execute the program by calling screen memory (which was possible from BASIC).
Happy days.
Similarly this made the inclusion of machine code in BASIC programs possible. I would optimize BASIC programs by including machine code subroutines stored as characters in REM statements. It wasn't hard to find those REM statements in memory (as the program was loaded in a fixed location) and call subroutines in the REM statements to speed things up.
IIRC correctly I used the same machine code in REM statement trick on the Research Machines 480Z (http://en.wikipedia.org/wiki/LINK_480Z) but this involved non-printing characters and thus it was not possible to LIST the entire program and so I typically stored all the machine code in lines numbers less than 100.
Which reminds me. On the 480Z there was an 800kbps network using coax. A friend and I disassembled the BIOS and reverse engineered the API (a software interrupt) used for sending and receiving data which enabled us to send arbitrary packets of code to any machine running our interrupt handler.
The receive buffer was only 128 bytes, so we would send the machine code in the packet and the receive handler would execute the packet inside the receive buffer. Amazing how much stuff you can do 128 bytes at a time. We wrote a network management package that used this functionality.
More recently, the JailbreakMe iPhone jailbreak used the screen to store the kernel shellcode, since the framebuffer was in a known memory location in both the kernel and userland.
So, I was bored after seeing this last week when I submitted it to HN, and so I whipped up a quick python script to shove code in to a BMP file. I bashed it out quick and didn't bother cleaning it up, but here it is:
Sadly there's still a bug, I think it has to do with alignment padding, which causes a null byte every 520 characters. When I get bored I'll fix it.
I think I'm going to write code though to try and make "pretty" images from source code, though in the end it won't be human readable when you open the file.
Yeah, I know that's the fix, I'm just too lazy to do it. When I belted it out I forgot to think about that and then I didn't notice the nulls until someone pointed them out. Oops.
If C++ supported the backwards comment "\\" meaning "everything before this is a comment" described by Stroustrup in http://www2.research.att.com/~bs/whitespace98.pdf, it could be compilable right out of Paint
That doesn't strike you as a really bad idea? Quite apart from the maintenance nightmare, consider what happens if you need to include a backslash in a string.
Read the paper... It also proposes limiting all identifiers to one character, using Wingdings as variables, and overloading whitespace as an operator. ;)
How is this a web standard? There really is no standard for video files and if there was, no one is taking gif seriously. There are proposals and half-assed implementations. Hell, not only do gifs look fucking terrible they're also a huge waste of bandwidth.
I'd rather just get served an mp4 file or even an embedded flash object instead of this. The only reason why there are so many gifs in the world is because its easy to find free hosting for them and email. Its still a piss poor format for video.
Not to mention, the gif people tried suing everyone once. Not exactly the paragon of open you think it is. Don't let Steve Jobs' rivalry with Adobe make you fall in love with sub-par formats. He's glad you uncritically parrot his thinking, but its really not doing anything for you.
A screencast is closer to a slideshow than a video. When only 1-5 frames per second are needed, Animated GIF doesn't use much bandwidth. It works in every browser and on very light CPUs.
"the gif people tried suing everyone once"
You mean Unisys, 'the LZW people'. CompuServe were 'the gif people', who didn't try to sue anyone. Anyways, the LZW patents expired in 2004, so that's no reason to avoid Animated GIFs now.
"Don't let Steve Jobs' rivalry with Adobe make you fall in love with sub-par formats. He's glad you uncritically parrot his thinking, but its really not doing anything for you."
Thanks for the ad hominem, but I didn't need Steve Jobs to tell me Flash has problems. As a smartphone user, I had already figured that out on my own. However, Adobe can easily win the argument. All they have to do is make Flash safe and stable, and create a fast and power efficient player for mobile devices. I'm just not going to hold my breath.
Having said that, the OP could've used far fewer frames, and instead of Animated GIF he could've used a series of JPEGs animated with JavaScript.
Bullshit, this is a HUGE file. Its 4 megabytes for whats essentially a few seconds of small extremely low quality video.
Again, mp4 or flash (even with the old flv based codecs) would be one tenth the size.
Again, gif is no web standard. Again, its owners were anything but open. Again, your hatred of flash and other alternatives is making you look foolish.
Actually I'm advocating mp4, but I'll take flash over gif. Heck, since Flash9, it can play mp4 files.
I'll even take wmv over gif. Gif is not an appropriate container for video. People use it for easy hosting not because its a "standard" or because its good at video. 4 megabytes of this? Please.
I call strawman. You are trying to make this about video, while I'm talking about slideshows. For video, Animated GIF is no good, we're in complete agreement there.
It isn't only the iPhone that doesn't have flash. Many people work on different architectures than x86 or x86_64. Some of us even want to watch these cool little bits. I realize that in your world there is only the PC, the Mac, and the iPhone, but out here in the real world there are many things in between. Standards are good and you're right, gif isn't one of them, but at least it works pretty much across the spectrum.
The maker of the picture wrote the code first in a text editor, and then for each triple of ASCII characters he found the corresponding RGB value, and set one pixel to it.
Since the bitmap is just a header (the mojibake you see at the start of the text file) and then a bunch of data bytes, the data bytes can be read as plain text again.
He is filling in the image from left-to-right, bottom-to-top. That's the scanline order of the data in BMP files, which means he is entering the code in the order it appears in the file.
Also, the image he is filling in is eight pixels wide. This is important because the row data in BMP files must be padded to a multiple of four bytes. Each pixel in a 24-bit image takes three bytes. If he had picked a width that wasn't a multiple of four, he would have had garbage padding bytes in the middle of his code.
Simple BMP files consist of a header followed by pixel data.
By selecting the colors for individual pixels that correspond to the ASCII characters in the source code, a BMP is created that contains the source code.
This seems completely useless, until you realize that early computers were programmed by flipping switches to enter the binary values the operator wanted to set...
Then you realize that this is entering human-readable high-level language code that would have to be compiled, and with a header that will fail to compile, so yes, this is completely useless. grin
It's pretty smart, but very simple. He just puts character ASCII codes into RGB fields in color picker. In 24 bit bmp format those values are saved directly to the file.
C code is too "random" to produce nice images. You can use the least significant bits to hold some data; Google "steganography" (this is just the most basic).
In a world where it is possible to compute a file that contains its own MD5, I wouldn't bet on this. Wish I could find the link, there was some feted programmer who had a friend that bet him such a thing was not possible. He proceeded to write an algorithm that found such a file by brute force.
I wouldn't count on the eventual C being pretty though.
Ultimately it's never going to be pretty if it's human readable as the range of bytes used will make a lot of greyish tones.
C/C++ wouldn't look a lot different I doubt, but if you want you can grab my python script (PIL required) and pack some source files and see for yourself:
In Java, source files can contain unicode escapes[1] of the form '\uXXXX' which are expanded prior to tokenization. In effect this gives you several options for what characters can exist in a given "pixel". I think that this, combined with careful application of whitespace and comments, should easily provide enough flexibility to make arbitrary code look roughly like a desired bitmap.
There's a hacker conference (I forget which, I think it's "the" demo scene con -- any remember Unreal from the early 90s?) where one of the events is creating a binary executable that is also a displayable image. Or maybe a playable sound file? Anyway, the same basic idea, and when I stumbled across the submissions, I thought it was a really neat concept.
What's nice about this is that the color palette he creates in the course of doing this looks as though it'd work well for a syntax-highlighting theme.
Thus it was possible to write a program using the following steps:
1. Write out the Z80 assembly code
2. Convert to opcodes
3. Look up the opcodes in the character map and type the appropriate character on the screen starting at top left
Then you could execute the program by calling screen memory (which was possible from BASIC).
Happy days.
Similarly this made the inclusion of machine code in BASIC programs possible. I would optimize BASIC programs by including machine code subroutines stored as characters in REM statements. It wasn't hard to find those REM statements in memory (as the program was loaded in a fixed location) and call subroutines in the REM statements to speed things up.
IIRC correctly I used the same machine code in REM statement trick on the Research Machines 480Z (http://en.wikipedia.org/wiki/LINK_480Z) but this involved non-printing characters and thus it was not possible to LIST the entire program and so I typically stored all the machine code in lines numbers less than 100.
Which reminds me. On the 480Z there was an 800kbps network using coax. A friend and I disassembled the BIOS and reverse engineered the API (a software interrupt) used for sending and receiving data which enabled us to send arbitrary packets of code to any machine running our interrupt handler.
The receive buffer was only 128 bytes, so we would send the machine code in the packet and the receive handler would execute the packet inside the receive buffer. Amazing how much stuff you can do 128 bytes at a time. We wrote a network management package that used this functionality.