• valhala (unregistered)

    Just to mention that icons on most *nix system are acctualy C code (XBM anyone) ... so what is so strange about this code !? When dealing with specialized hardware even more so ...

  • ~ (unregistered)

    Um, so, where is the WTF? I mean, this is a perfectly reasonable approach to embedding binary files into programs.

  • Harold (unregistered)

    Not a tractor on a christmas tree. The bottom is a perspective drawing of train tracks. A tractor is crossing the tracks to the left.

    Or does this say more about me?

  • Pierre (unregistered)

    Maybe the original developer was dealing with a version control system that couldn't handle binary data?

    Or else he was learning about bitmaps and thought this was a good learning exercise.

  • gsl (unregistered) in reply to Harold
    Harold:
    Not a tractor on a christmas tree. The bottom is a perspective drawing of train tracks. A tractor is crossing the tracks to the left.

    Or does this say more about me?

    I'd say the "tree" / "tracks" are actually sound waves. Though I'm still not sure how it relates to the vehicle moving left. A warning icon / button, perhaps, indicating whether an alarm is active. Low-resolution icon design can be awfully tricky. Almost sure this is for some big graphic LCD readout, given the icon size (and the fact that it is black and white).

  • jonasdmentia (unregistered)

    This isn't even close to being a WTF....considering it's an embedded system. The practice of encoding images in source code is common of small embedded systems where there's no such thing as a file system and storage space is a rare resource (embedding the image so that it can be referenced with just a pointer uses less space than needing a file system on the storage, the associated code for talking to that file system and code for loading the image into memory). Typically there's a tool that generates the .c/.h files from an image file (which presumably exists but has simply been overlooked...or lost with the handoffs...)

  • the real wtf (unregistered) in reply to Code monkey
    Code monkey:
    If they're automatically generated from actual bitmaps, I don't see what the WTF is.

    You'd wish. They were probably painstakingly typed in one by one. Or the program that did the conversion had to be typed in directly, in raw hex. No source code. Source code is for pussies, as are BMP loaders.

    Captcha: caecus. Caecus was a fire breathing dragon in Greek mythology. But also means "blind" in Latin. Or the caecum in the intestine, where this shit came from.

    Not everyone is a codemonkey.

  • (cs) in reply to Techpaul
    Techpaul:
    Mason Wheeler:
    Everyone keeps saying "EMBEDDED DEVICE WITH NO FILESYSTEM AND NEXT TO NO RESOURCES!!!!!!1111one!!", but I have to wonder how relevant that notion actually is anymore. Heck, even my cellphone has 256 MB of RAM, and a filesystem to manage a few gigs' worth of storage on a tiny storage chip that an infant could close their hand around. And at CES they just demoed a Droid-powered microwave! Are these fabled "embedded devices" actually still being created anymore? If so, what are they used for?

    Ah the SMALL volume items, the larm systems, coffee machines, microwaves, distributed processing units in modern cars, let alone anything with a small graphic LCD or even SWITCHES that LCD displays that can change the caption on the switch.

    The VAST bulk of microprocessors/controllers shipped by VOLUME are 4 and 8 bit processors, with next to no memory (ROM and RAM).

    Exactly. On alot of these things, resources are so tight, that the standard library sometimes has multiple flavors for how much functionality you need. Like printf with only integer support. If you want floating point support, you have to link the standard library differently.

    On that note, in this type of environment, even the overhead of parsing a bmp file might be a bit high (like you would have to do with the "link a bmp" suggestions everybody has been saying). With this, the bmp file can be in FLASH or EEPROM and never even need to be loaded into the very precious RAM. Just try parsing a BMP file into RAM on something like this http://atmel.com/dyn/products/product_card.asp?part_id=4347 <- that's 64 bytes of RAM. On the other hand, it's not exactly slow - up to 20 MIPS.

    Where do they use such small things? As mentioned earlier lots of places. I might add garage door openers, remote controls (how many have a Logitech Harmony?), mice, keyboards, toys, peripheral devices inside a PC, the list goes on and on and on. See the projects at avrfreaks.net for more ideas. Ever heard of the Arduino platform? It is exactly this type of environment.

    And this idea isn't even as uncommon on "regular" computers as some might think. How about the inline image part of the HTML spec: http://en.wikipedia.org/wiki/Inline_image. Google Chrome also does something similar http://www.chromium.org/developers/design-documents/linuxresourcesandlocalizedstrings For that matter, windows resources are just a systematic way of doing the same thing: http://blogs.msdn.com/oldnewthing/archive/2009/12/11/9935462.aspx, minus the C code, but that's just a universal way of doing the same thing.

  • Rich (unregistered)

    There's a reason the GIMP has support for outputting arbitrary files to C files...

  • mango (unregistered) in reply to Benjamin
    Benjamin:
    Does it count if it is a C png? I have a bunch of png files that I link into my program by just dumping them into string literals (via a ruby script called by a scons file) because it seemed simpler than figuring out how to make a properly installable package.

    No, that doesn't count. If you're working with PNGs, building with Ruby and SCons and talking about "installable packages", you probably aren't working in a resource constrained environment. Stop being lazy and learn how to write a build system. A good rule of thumb: if building and installing your package means running code in more than one interpreted language - not counting shell script - you're probably doing it wrong.

    When looking for open-source libraries/frameworks to support a new project, I often dismiss anything with a custom build system. The learning curve for autotools may be steep, but speaking as someone who has put the effort in, I wouldn't look back.

    For anyone developing open-source code: UNIX is not Windows. Not everybody wants to - or necessarily can - run pre-compiled blobs. If your source is open, the source is just as important as the binaries, and that source is near useless if nobody but you can compile it. Make your project easy to build and install and distributions will package it for you - that's why they have people called package maintainers.

    /rant

  • gsl (unregistered) in reply to itFinallyWorks
    itFinallyWorks:
    On that note, in this type of environment, even the overhead of parsing a bmp file might be a bit high (like you would have to do with the "link a bmp" suggestions everybody has been saying). With this, the bmp file can be in FLASH or EEPROM and never even need to be loaded into the very precious RAM. Just try parsing a BMP file into RAM on something like this http://atmel.com/dyn/products/product_card.asp?part_id=4347 <- that's 64 bytes of RAM. On the other hand, it's not exactly slow - up to 20 MIPS.

    Where do they use such small things? As mentioned earlier lots of places. I might add garage door openers, remote controls (how many have a Logitech Harmony?), mice, keyboards, toys, peripheral devices inside a PC, the list goes on and on and on. See the projects at avrfreaks.net for more ideas. Ever heard of the Arduino platform? It is exactly this type of environment.

    How about almost no RAM and no read access to your LCD? That was the last project I did with a display. Well, we had read access, but each 1x8 slice read took several milliseconds to read, which was way too slow to do anything useful. We had more than 64 bytes of RAM -- I think there was 1k total -- but much of that was reserved by drivers for the PWM and ADCs, and more of it was consumed by the stack.

    (And ugh... please don't bring up the Harmony. I can't believe how buggy that firmware is. Love the remote, but I swear, if I could I'd write new firmware from scratch for the thing.)

  • (cs) in reply to Scott
    Scott:
    So this is for a levitating tractor controller?

    Looks like some seismic sounding machine, maybe?

  • (cs) in reply to mango
    mango:
    Benjamin:
    Does it count if it is a C png? I have a bunch of png files that I link into my program by just dumping them into string literals (via a ruby script called by a scons file) because it seemed simpler than figuring out how to make a properly installable package.

    No, that doesn't count. If you're working with PNGs, building with Ruby and SCons and talking about "installable packages", you probably aren't working in a resource constrained environment. Stop being lazy and learn how to write a build system. A good rule of thumb: if building and installing your package means running code in more than one interpreted language - not counting shell script - you're probably doing it wrong.

    When looking for open-source libraries/frameworks to support a new project, I often dismiss anything with a custom build system. The learning curve for autotools may be steep, but speaking as someone who has put the effort in, I wouldn't look back.

    For anyone developing open-source code: UNIX is not Windows. Not everybody wants to - or necessarily can - run pre-compiled blobs. If your source is open, the source is just as important as the binaries, and that source is near useless if nobody but you can compile it. Make your project easy to build and install and distributions will package it for you - that's why they have people called package maintainers.

    /rant

    In other unrelated news, Sarah Palin signs multi-year deal with Fox.

  • toth (unregistered)
    there were no makefiles and over 9000 warnings and errors

    FTFY

  • fanha (unregistered)

    The real WTF is the submitter's knowledge of embedded systems.

  • Brian Enigma (unregistered)

    That doesn't sound too far off from X Bitmaps (http://en.wikipedia.org/wiki/X_BitMap). Perhaps the code originated on a Unix system? It's a kind of crufty concept now, but XBM was fairly standard 15+ years ago.

  • (cs) in reply to gsl
    gsl:
    itFinallyWorks:
    On that note, in this type of environment, even the overhead of parsing a bmp file might be a bit high (like you would have to do with the "link a bmp" suggestions everybody has been saying). With this, the bmp file can be in FLASH or EEPROM and never even need to be loaded into the very precious RAM. Just try parsing a BMP file into RAM on something like this http://atmel.com/dyn/products/product_card.asp?part_id=4347 <- that's 64 bytes of RAM. On the other hand, it's not exactly slow - up to 20 MIPS.

    Where do they use such small things? As mentioned earlier lots of places. I might add garage door openers, remote controls (how many have a Logitech Harmony?), mice, keyboards, toys, peripheral devices inside a PC, the list goes on and on and on. See the projects at avrfreaks.net for more ideas. Ever heard of the Arduino platform? It is exactly this type of environment.

    How about almost no RAM and no read access to your LCD? That was the last project I did with a display. Well, we had read access, but each 1x8 slice read took several milliseconds to read, which was way too slow to do anything useful. We had more than 64 bytes of RAM -- I think there was 1k total -- but much of that was reserved by drivers for the PWM and ADCs, and more of it was consumed by the stack.

    (And ugh... please don't bring up the Harmony. I can't believe how buggy that firmware is. Love the remote, but I swear, if I could I'd write new firmware from scratch for the thing.)

    That was an example, ATMEL has larger ones, but I know exactly what you mean. Memory is at a premium and don't count on using peripherals to help with that. Doing almost any kind of picture decoding on an embedded microcontroller is near impossible - the memory limitations will stop you before you even begin. Even a file system is very questionable with these (the block size alone might be half or more of your available memory).

    I'm not particularly impressed with the Harmony either. Seems slow, and the PC software seems rather stupid (a desktop application that requires you to make an account?) Haven't seen many bugs yet, though. But the micro is probably either an 8 bit uC or a small ARM. My bet is 8 bit uC - much simpler. But this is a good example of an embedded device, poor implementation though it may be.

  • SP (unregistered) in reply to frits
    frits:
    mango:

    ...

    In other unrelated news, Sarah Palin signs multi-year deal with Fox.

    Today's true WTF!

  • laoreet (unregistered)

    That's actually fairly common... For example, the various X bitmap format like XPM are actually regular C header files. It's probably both more compact and faster to include it in the code, than it is to open a binary file, read in the data, etc. Especially on old devices the difference was measurable.

  • (cs) in reply to Anon
    Anon:
    SP:
    [image]

    for the curious... 26x24

    Okay, but what is it? A tractor sitting on top of a tree moving to the left?

    "Deploy geological survey unit with ground-penetrating radar".

    Addendum (2010-01-11 17:54):

    Anon:
    SP:
    [image]

    for the curious... 26x24

    Okay, but what is it? A tractor sitting on top of a tree moving to the left?

    "Deploy geological survey unit with ground-penetrating radar". (EDIT: My guess, btw.)

    Addendum (2010-01-11 17:56): (second edit: oh poo. that wasn't meant to happen.)

  • (cs) in reply to Wodin
    Wodin:
    Code monkey:
    What, none of you ever programmed with PEEKs and POKEs and endless lists of DATA statements that could be machine code, image data, sounds, or whatever? Fo' shame!

    Captcha: erat. Quod Erat Demonstrandum.

    Of course! With crappy printouts in magazines where you often could not tell the difference between a B and an 8 :(

    Made for painstaking typing followed by a swift and colourful crash on a ZX Spectrum.

    Also fun was trying to reverse engineer what kind of PETSCII graphic code it originally was that they were trying to print out on a converted IBM Selectric and therefore which quoted control key you were actually meant to press. A capital 'S' in an unexpected place in a print statement often actually meant an inverse-video heart, or in other words Shift+CLR/HOME (CLS).
  • Mike (unregistered) in reply to jspenguin
    jspenguin:
    me:
    "as there were no makefiles and over warnings and errors."

    This does not sense, there some missing?

    i accidentally the OVER 9000!

    ... sorry.

    You'll be hearing from M00T's lawyers...

  • (cs)

    The HUGE WTFs here are:

    1. No makefile, despite having over 274 source files (considering there were 274 images, and they were in separate files.)

    2. None of the embedded people understand that this is a WTF.

    I did a small stint dealing with embedded systems. When I first suggested the use of make (or some equivalent program if they wanted something different), I was told, "We can't just use a standard compile command, because it tacks on the standard libraries and stuff for the development platform, and the [target platform] doesn't have them."

    So I modified the Makefile, so that it compiled the various parts the same way that they did them by hand.

    While I was ostensibly primarily working for a different department, using make gave me such a development performance edge over the devs who were dedicated to that project, I was able to actually contribute more code while only spending 10% of my time on it than most of them were able to do spending "100%" of their time on it. (Of course, subtracting meetings and other overhead, that was really more like 60% of their time. No, overhead shouldn't take 40% of ones time, but that company was rather Dilbert-esque.)

    For what it's worth, no, they didn't spend time debugging my code. No, they didn't spend time optimizing my code. My code was generally as tight, fast, and error free as their best. And, as of around 2003 or so, 80% of the code that still in use from when I'd been there (around five years earlier) was my code - but I'd only written about 1% of the code in the product.

    Addendum (2010-01-11 19:24): I forgot to point out that, according to my source for the 2003 figures, the Makefile I'd made was deleted almost as soon as I'd left. He noticed its absence, because he'd been asked to give them 10% of his time, since they'd lost 10% of my time.

  • (cs)

    I understand there are actually tools that can take a binary file and spit out a C header that declares it as a byte array. Probably not the best way to embed resources nowadays, though.

    Only example tool I know of is that Wireshark can take a network dump and convert it into a C header.

    I can only assume one of the Wireshark devs needed that functionality at one point...?

  • mypalmike (unregistered)

    The real WTF is that embedded coders don't care that 100 previous embedded coders have already explained that this is an accepted practice. Each one needs their "I'm smart and you're not" to be heard.

  • someone (unregistered)

    WTF? At the article, not the code. This is a perfectly standard and legitimate technique. It can be easier than messing with a bunch of image loading code, especially on embedded platforms that don't even have files. http://en.wikipedia.org/wiki/X_PixMap

  • David (unregistered)

    This seems to me like the standard simple approach to embedding bitmaps into an executable. I don't get wtf would be?

  • (cs) in reply to David
    David:
    This seems to me like the standard simple approach to embedding bitmaps into an executable. I don't get wtf would be?
    Hey, thanks for that David. I can hardly believe you're the very first person to post that explanation. Aren't you AMAZING?
  • (cs) in reply to Code monkey
    Code monkey:
    If they're automatically generated from actual bitmaps, I don't see what the WTF is.

    You'd wish. They were probably painstakingly typed in one by one. Or the program that did the conversion had to be typed in directly, in raw hex. No source code. Source code is for pussies, as are BMP loaders.

    Captcha: caecus. Caecus was a fire breathing dragon in Greek mythology. But also means "blind" in Latin. Or the caecum in the intestine, where this shit came from.

    Let's have more examples and decide then.

    Chances are they're autogenerated and today's WTF story is a result of pig-ignorance on the part of the submitter, the writer, and any editorial process (like there would be some...). Oh, and the commenters. I can understand that most programmers would never have been inside an XBM, XPM, PPM, PGM, PBM, or PNM; but to be unaware of their nature beggars belief.

    Also, the caecum is for breaking down food to be reingested later so that more nutrients can be absorbed. Rabbits poot their caecal ("night") pellets out and eat them. Larger mammals like horses do it all internally. How apt that you didn't know that, either.

    And what does "there were no makefiles and over warnings and errors" mean anyway? Is that supposed to be "other"?

  • (cs) in reply to Zylon
    Zylon:
    David:
    This seems to me like the standard simple approach to embedding bitmaps into an executable. I don't get wtf would be?
    Hey, thanks for that David. I can hardly believe you're the very first person to post that explanation. Aren't you AMAZING?
    It's called an "outcry". Look at it as several hundred people removing a certain bookmark from their daily set. Look at it as several thousand dollars of advertising revenue vaporizing.

    A site that is not worth reading is a site that is not worth visiting.

    ...or am I somehow wrong?

  • Slicerwizard (unregistered) in reply to SP
    SP:
    [image]

    for the curious... 26x24

    You fail. Time for you to read up on the .bmp file format.

  • freddo (unregistered)

    The editors of this site should refrain from posting anything that's written in C as they don't understand the systems built in C nowadays. :(

    Stick to the SQL/Java/.NET posts. Those technological areas seem to attract a crowd more prone to "interesting" solutions anyway...

  • Jonathan (unregistered)

    While clever, Johnny could never quite figure out how the "c-bitmap" is a good idea.

    Then Johnny had never worked with the X-Windows library, which uses this as a standard technique, and which provided tools and an API to support it.

    I'm not supporting the concept, these days there are better approaches. But in the days before decent packaging tools, compiling commonly-used bitmaps into your application was a standard mechanism to (a) simplify delivery and (b) boost performance.

    Move along folks, no WTF to see here.

  • informatimago (unregistered)

    The constraints are different on different operating systems.

    In operating systems where the whole executable is loaded at once, or where it is customary to have different versions of the resources for different markets, it might seems like a bad idea to keep the bitmaps in the executable.

    On the other hand, in operating systems that load and unload the executable page by page, and where more over it is convenient to have a single file executable, it is a good idea to integrate the bitmaps into the executable, and an easy and portable way to do so is to define them in the sources.

    Tere are ever X bitmap editors that will save the bitmap directly as C sources!

  • SP (unregistered) in reply to Slicerwizard

    [image]

    my bad, here's the version that ISN'T upside down.

  • (cs) in reply to tgape
    tgape:
    The HUGE WTFs here are:

    1. No makefile, despite having over 274 source files (considering there were 274 images, and they were in separate files.)

    2. None of the embedded people understand that this is a WTF.

    I think most of us assumed the article was claiming that TRWTF was the part beginning "But as Johnny soon learned, that was just the tip of the iceberg", tips of icebergs generally being the minor part, and not TR iceberg. So that's why we responded to that bit.

    Besides, it was the only interesting part. There's nothing particularly exciting or specially WTF-y about an old project that someone hasn't kept track of all the bits and pieces and you have to reconstruct parts of it from whatever's left over.

    tgape:
    When I first suggested the use of make (or some equivalent program if they wanted something different), I was told, "We can't just use a standard compile command, because it tacks on the standard libraries and stuff for the development platform, and the [target platform] doesn't have them."
    That, OTOH, is definitely ARWTF!
  • (cs)

    This is a pretty common method of embedding resources directly into a program. While it's a bit odd to want to embed an entire bitmap image, header and all, it has advantages - no dependency on external files, filesystems, etc.

    "Like many global corporations, Johnny had the usual problems" Johnny himself was a corporation? An odd name for one, that's for sure.

    "In fact, he wasn't even sure how it passed any compiler, as there were no makefiles and over warnings and errors." I'm not sure how this would pass proofreading, as there are over grammatical errors. (In before "over 9000".)

    In any case the real WTF is that the site went down just after this article had finished loading. What are the odds? That of course meant I had to wait until I got back home to post my now-several-hours-late comment... oh well.

  • Slicerwizard (unregistered) in reply to SP
    SP:
    [image]

    my bad, here's the version that ISN'T upside down.

    Dang, you pass! :)

  • Just Another Programmer (unregistered)

    There was a WTF here:

    WTF is such a standard, useful technique doing as a post on this site, and why, after dozens of comments pointing out that this is not a WTF, has the original post not been updated to say it isn't one?

    The site's been getting less and less interesting over time, though I don't know if it's the site or me. But this was annoying enough that I think it's finally time to give up reading it.

    But hey, thanks for the good times!

  • foxyshadis (unregistered) in reply to itFinallyWorks
    itFinallyWorks:
    On that note, in this type of environment, even the overhead of parsing a bmp file might be a bit high (like you would have to do with the "link a bmp" suggestions everybody has been saying). With this, the bmp file can be in FLASH or EEPROM and never even need to be loaded into the very precious RAM. Just try parsing a BMP file into RAM on something like this http://atmel.com/dyn/products/product_card.asp?part_id=4347 <- that's 64 bytes of RAM. On the other hand, it's not exactly slow - up to 20 MIPS.
    What RAM? They aren't talking about dynamic loading. The process of linking a resource dumps it into your binary image and provides a symbol to access it globally. You might want to look into it, if your toolchain supports it, unless you're completely wedded to a C-file conversion make step. One advantage is that it's a raw binary in bytes - no wasted bytes from escaping/unescaping and no wasted compilation time. Just make sure your files are already massaged into the final binary format (which might just mean replacing one make step with another).
  • Quirkafleeg (unregistered) in reply to xtremezone
    xtremezone:
    const char my_bmp_data[] = {0x42, 0x4d, 0x36, 0x0c, 0x00, ...snip... 0xed, 0x4d, 0x47, 0xf1};
    […]
    const char * const my_bmp_data = "\x42\x4d\x36\x0c\x00...snip...\xed\x4d\x47\xf1";
    What's wrong with 
    const char my_bmp_data[] = "BM6\x0c\x00[…]\xedMG\xf1";
    ? (Yes, fair enough, automatic NUL termination…)
  • SP (unregistered) in reply to Just Another Programmer
    Just Another Programmer:
    There was a WTF here:

    WTF is such a standard, useful technique doing as a post on this site, and why, after dozens of comments pointing out that this is not a WTF, has the original post not been updated to say it isn't one?

    The site's been getting less and less interesting over time, though I don't know if it's the site or me. But this was annoying enough that I think it's finally time to give up reading it.

    But hey, thanks for the good times!

    So long, and thanks for all the fish! lol

  • (cs)

    I am simply flabbergasted that I am able to get to Page 3 of the comments, and there are STILL people mentioning that this is not a WTF, outlining the same reasons that the first poster on the first page did. Yes I know some are doing it to take the wizz, but most aren't.

    Yes, I have heard of XPM. I've heard of it at least 5 times now. All within the last 10 minutes.

    Christ. I don't expect anyone to read every word of every comment, but is it really that hard to just gloss over the first couple of responses to see if anyone's already said what you're saying?

  • Quirkafleeg (unregistered) in reply to squidbot
    squidbot:
    If there is a WTF, perhaps it's on the head of "Johnny D".
    Agreed. And, it appears, that is reason enough to post the article: sometimes it's not the code, it's the submitter.

    And the lack of a makefile is fine if you can just (fairly quickly) do something like

    cc *.c -o foo
    Of course, if it takes a while or requires a lot of typing, then, well…

  • Quirkafleeg (unregistered) in reply to tgape
    tgape:
    […] I forgot to point out that, according to my source for the 2003 figures, the Makefile I'd made was deleted almost as soon as I'd left. He noticed its absence, because he'd been asked to give them 10% of his time, since they'd lost 10% of my time.
    I don't know about you, but there seems to me to be just a hint of ‘job security’ about that.
  • --- (unregistered)

    Once more, the real WTF is the complete ignorance of the poster. This site is becoming a little more pathetic every day.

  • Daniel (unregistered) in reply to SP

    I can see it!

    It's a wifi controlled tractor that shoots rockets! Possibly to defend the agricultural sector for the upcoming zombie invasion?

  • (cs) in reply to Helix
    Helix:
    thedailywft logo as a C file:
    • Source file: logo
    • Dimensions: 488 * 70
    • NumColors: 16

    */

    #include <stdlib.h>

    #include "GUI.h"

    #ifndef GUI_CONST_STORAGE #define GUI_CONST_STORAGE const #endif

    [image]
  • (cs)

    Kudos to those who posted the bitmaps. I'm both impressed and disappointed. Impressed because that's quite the feat you pulled off. Disappointed because I was sure the bmp would be a rickroll of some sorts.

  • (cs)

    For those who keep saying "embedded system"... Here's how the boot logo is included in the Linux kernel: http://nerdvar.com/ting/linux-2.6.30/drivers/video/logo/

    Granted, those .c files are automatically generated from the .ppm files in the same directory, but they're still essentially the same format as given here...

Leave a comment on “The c-bitmap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article