• Doug (unregistered) in reply to Design Pattern
    Design Pattern:
    But using a translator to generate C-Code from the binary data only to let the compiler write the original data in the object file certainly is.

    If your tools do not allow you to reliably embed binary resources in your executables and you need to use such carco-cult-techniques then your tools are broken and the real WTF is not to replace them with tools that support that directly; especially if your target environment requires to do this often.

    (Chances are high that this is not the case and you do this only because you do not know your tools; you know only the C-Compiler and use it as a hammer to pound in screws - learn what the screwdriver is for).

    Considering that the binary will come out of the compiler in pretty much the same way, the c method saves a lot of time and headaches for the sorry son of a bitch that just figured out that he's not programming an x86. Especially if all the makefiles somehow get lost (or are never created). While not incorrect and possibly useful I don't see a wtf in doing it this way. It's hardly "cargo cult" and embedded programming is pretty much black magic anyways.

    Maybe I'm just a lazy sack of shit though.

  • (cs)

    I think TRWTF is the lack of a document explaining how to build the code.

  • just finished reading all the comments (unregistered) in reply to dmitriy

    ...that the submitter knew of.

    But then the submitter somehow thinks it's better to send something they don't understand to TDWTF rather than asking a colleague or sending their noob question to stackoverflow.com

    I would blame Java schools, but naievity has been around a lot longer than Java (or else Java wouldn't exist...)

  • John Haugeland from http://fullof.bs/ (unregistered)

    Erm. It's so that the binaries can be pre-built into translation units, which among other things massively reduces linking time and allows for link time modularity and resource replacement.

    This is a very common thing in high-end C and C++ development. There's nothing WTF about this at all.

  • INTERNETS (unregistered)

    Another embedded system programmer here agreeing that it is not a WTF, indeed it is more like industry standard procedure. I actually work on agricultural machinery, and I am assuming that the TRS is a Tractor Radar System?

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

    for the curious... 26x24

    Drive tractor, fart loudly?

  • salud (unregistered) in reply to Helix
    Helix:
    thedailywft logo as a C file:
    Let's not.
    Helix:
    /* *** End of file *** */

    Ever heard of RLE?

  • Stefan P (unregistered)

    Is that so weird ? It used to be common. The old XBM and XPM image file formats were in fact... C

    Maybe the WTF is that those formats were not used ?

  • Mavrik (unregistered) in reply to Stefan P

    True WTF is this whole topic, showing the current state of programming world: loads of developers saying ("reimplementing") the same thing in slightly different redundant ways instead of actually checking what other people have written.

  • Anders (unregistered) in reply to SP

    I guess this can be considered proof that there is intelligent life on earth.

  • Ben (unregistered)

    I don't quite see the problem - I admit it is not too easy to exchange images, sure. But gimp can easily save images as C files (the output looks kind of similar). I used this too when I was to lazy to add a image file parser in college.

    (damn windows static heap sice was often too small though when porting the stuff)

  • jim (unregistered)

    Guys, this isn't really bad. If they were working in an embedded environment, one where a filesystem might not be available, then this is perfectly reasonable. I just wanted to make that clear before the discussion got too heated.

  • Helix (unregistered) in reply to salud
    salud:
    Helix:
    thedailywft logo as a C file:
    Let's not.
    Helix:
    /* *** End of file *** */

    Ever heard of RLE?

    Yes.

    Tell me what it has to to with the standard output of a bmp2c converter exe?

  • Design Pattern (unregistered) in reply to Doug

    [quote user="Doug"] Considering that the binary will come out of the compiler in pretty much the same way, the c method saves a lot of time and headaches for the sorry son of a bitch that just figured out that he's not programming an x86. [/code] Are you implying x86 is the only target supported by GCC / GNU binutils?

    [quote user="Doug"] Especially if all the makefiles somehow get lost (or are never created). [/code] Are you still arguing "not a WTF"?

    How about: [quote] Especially if the C-Compiler somehow get lost (or never existed). [/code] (seems to me on the same level of absurdness).

    [quote user="Doug"] It's hardly "cargo cult" and embedded programming is pretty much black magic anyways. [/quote] Accepting such cargo cult voodoo as "industrial practice" instead of using tools that directly support what is needed is exactly what makes embedded programming black magic.

    Why pay a commercial manufacturer of embedded system processors a shitload of money for a dev kit whose linker is unable to simply include a binary file in an executable?

    Instead of chosing a different one or telling the manufacturer that this feature is required, those developers wasted their time in implementing a binary to C-converter only to complicate and slowdown the build process!

  • (cs) in reply to Design Pattern

    [quote user="Design Pattern]...telling the manufacturer that this feature is required...[/quote]

    HaHaHaHaHA!

  • Doug (unregistered) in reply to Design Pattern

    1: Hardly, I've written a GEM myself. Also, are you implying GCC is the only c compiler in use?

    2/3: It isn't really comparable. There are ISAs that, while rare, don't even have c compilers! Sometimes people do silly things (even your coworkers!), but the "c-bitmap" surely didn't hurt anything.

    4: I wouldn't exactly consider this example to be "black magic" either, considering a new programmer could probably put two and two together without too much trouble. I'm sure you know some things will get a bit trickier.

    If I'm not mistaken, MPLAB is actually free. I'm certain you could probably do it your way with Microchips tools too.

    MCU's are often specialized, or already in the design. You can't always just get a different one. The above programmer didn't create that bitmap to c converter, it already exists. And it seems to me that it actually makes the build process simpler, and probably not too much slower. The compiler would even align it for you!

  • Sergey (unregistered)

    It's actually a standard format for bitmaps. The author of the letter should read more.

  • J (unregistered)

    The WTF is that you post this as a WTF. It is perfectly normal to do that.

  • just finished reading all the comments (unregistered) in reply to Design Pattern
    Design Pattern:
    Are you implying x86 is the only target supported by GCC / GNU binutils? [...] How about:
    Especially if the C-Compiler somehow get lost (or never existed).
    (seems to me on the same level of absurdness). [...] Why pay a commercial manufacturer of embedded system processors a shitload of money for a dev kit whose linker is unable to simply include a binary file in an executable?

    Instead of chosing a different one or telling the manufacturer that this feature is required, those developers wasted their time in implementing a binary to C-converter only to complicate and slowdown the build process!

    Did you submit this WTF? Because you seem to have some idea of embedded programming, but obviously not a lot of real world experience with it.

    "Look boss, I know it would take me twenty minutes to write a well tested binary converter, but I refuse to. YOU need to get on the phone and tell Motorola that we demand they build it themselves! And they won't get any more of our money until they do! In the mean time I'll be spending the next two hours building binutils, after three days of getting gcc to produce code for our target, and then probably the rest of the project finding code gen bugs. Where's my paycheck?"

  • Tyr (unregistered)

    This is actually used when compiling stuff to be run on NDSs or GBAs. There is even a utility, grit, (http://www.coranac.com/projects/) to convert things to them. It is necessary because all the files need to be linked into one binary.
    Similar cases might show up in other low level devices without a OS or filesystem.

  • Delos (unregistered)

    This is the preferred way of storing images when writing GBA carts, and the same probably holds true for older nintendo cartridge systems.

  • just finished reading all the comments (unregistered) in reply to Design Pattern
    Design Pattern:
    Instead of chosing a different one or telling the manufacturer that this feature is required, those developers wasted their time in implementing a binary to C-converter only to complicate and slowdown the build process!

    Why do you assume the devs wasted their time implementing a converter? Maybe they

    1. used a free one
    2. got one as part of their toolchain
    3. had a work experience student write it

    The submitter already got it wrong that the code is a WTF, I doubt he has any clue about how it was generated. Again, he seemed happier to rush it to TDWTF than to ask his colleagues or stackoverflow and learn something about his profession.

  • just finished reading all the comments (unregistered) in reply to Design Pattern
    Design Pattern:
    Instead of chosing a different one or telling the manufacturer that this feature is required, those developers wasted their time in implementing a binary to C-converter only to complicate and slowdown the build process!

    Why do you assume the devs wasted their time implementing a converter? Maybe they

    1. used a free one
    2. got one as part of their toolchain
    3. had a work experience student write it

    The submitter already got it wrong that the code is a WTF, I doubt he has any clue about how it was generated. Again, he seemed happier to rush it to TDWTF than to ask his colleagues or stackoverflow and learn something about his profession.

  • Sika (unregistered)

    It was all the rage in the ancient days... http://en.wikipedia.org/wiki/X_PixMap http://en.wikipedia.org/wiki/X_BitMap

    Apparently, it was WWW standard :)

  • John (unregistered)

    Meh. I'm an embedded developper myself, so I can sympathise with the original developer. Lots of embedded systems don't have a file-system. No fopen(), fread(), whatever. Thus you have to include your static data directly into your binary. I like to use objdump to convert arbitrary data to object files I can easily include in an executable. (see also: windows resource files)

  • salud (unregistered) in reply to Helix
    Helix:
    salud:
    Helix:
    thedailywft logo as a C file:
    Let's not.
    Helix:
    /* *** End of file *** */

    Ever heard of RLE?

    Yes.

    Tell me what it has to to with the standard output of a bmp2c converter exe?

    I won't. But you should know what it has to do with the annoyingly large amount of uselessly repetitive data you posted.

  • (cs)

    Hey Design Pattern stop using terms (cargo cult) that you don't understand.

    I've been writing C and C++ code for 16 years for everything from painful pure win32 API apps to painless cross platform wxWidgets applications (Did i mention XPM's are GREAT for cross platform GUI coding? It is the simplest solution to giving you a consistent way of addressing them.) to game programming, to working on major financial systems.

    You sound like someone who read the book on Design Patterns and then the one that discusses anti patterns and DIDN'T ACTUALLY UNDERSTAND THEM.

    You're surrounded by gods of programming (embedded programmers) and you're demonstrating your ignorance.

    Let me give you some advice, son: SHUT YOUR IGNORANT PIE HOLE.

    /PS: when you get out of the kiddie pool (aka Java and C#.NET) come back and try talking to the guys in this thread who are working in microsubs in the Marianas Trench (embedded programmers)

  • TJ (unregistered)

    As a former embedded systems engineer (8051 derivative microcontrollers FTW,) has anyone mentioned that this isn't a WTF at all, but a fairly common practice?

    They have?

    Oh.

    Well, has anyone mentioned that the real WTF is that they employed this idiot?

  • Srh (unregistered)

    This may not be WTF, because the most-portable-of-all game library Allegro works like this. It have a tool which you can use to convert a bitmap image to C code. Bitmap is usually loaded from a database, or file, and converted to a format usable by Allegro. Converting it to C file, all this operations are redundant, and everything runs much faster. And game file grows larger, but this is acceptable, if your issue is speed.

  • Anonymous (unregistered)

    All I can see is the best solution for including an image in an embedded device. WTWTF?

  • eye (unregistered)

    The real WTF is the redundant comment noise that this post has generated. Also, whoever let this go on the frontpage is a n00b who never dealth with a microcontroller.

  • Ginjiro (unregistered)

    This actually isn't that uncommon. It could be to make avoid using fancy resource tools that might not be portable across compilers, or it could be to have the code in version management, who knows.. but I've seen it numerous times on numerous platforms in multiple languages.

  • Chris 'Xenon' Hanson (unregistered)

    Actually, that's a relatively common technique in environments where you don't have something like a Resource Compiler to incorporate binary resources (often images) into your final executable and you don't want to rely on loading them from files at runtime.

  • Hans Peter (unregistered)

    What's new? X pixmaps have been C arrays for decades. http://en.wikipedia.org/wiki/X_PixMap

  • mara (unregistered) in reply to SP

    @SP: Thanks! I think it's some kind of levitating car :)

  • Andrej (unregistered)

    For the ancient cross compilers, this makes perfect sense.

    Normally, you'd store bitmaps into disk files or resources, but embedded systems of old had none of that. ROM, RAM, and that was it, no file system. Converting bitmaps and similar data to C initializers was the only way, I've done that more than once.

  • Repetitive (unregistered)

    The real WTF is 5 pages of replies of people all saying the same thing!

  • Anonymous (unregistered)

    As an embedded developer you very often find that there isn't actually a filesystem to read external resources from. Where this is the case, it makes perfect sense to define your resources as arrays of image data; indeed, there may be no other option. I don't know if anyone has pointed this out yet.

  • (cs) in reply to Repetitive

    That has also been pointed out, repetitively.

  • Repetitive (unregistered) in reply to frits
    frits:
    That has also been pointed out, repetitively.
    You've been trolled. Epic fail. Then again maybe I was trolled as well. D'oh!
  • Jeremy (unregistered)

    This all seems pretty reasonable. Where else are you going to put bitmaps in a small device with no filesystem? The implementation is a bit clunky (3 separate structs with the same name is awkward), but the basic idea is sound.

    Of course, I'd hope the build system generates these .c/.h files from the original bitmaps as part of the build process...

  • some random dude (unregistered) in reply to Mike D.

    Wtf indeed! You are crazy. Crazy enough to join doctor steels army, do not mark as spam please, join now for a utopian playland

  • some random dude (unregistered) in reply to Mike D.

    Wtf indeed! You are crazy. Crazy enough to join doctor steels army, do not mark as spam please, join now for a utopian playland

  • The Real WTF (unregistered)

    The real WTF is that they used the BMP format which is almost as retarded as a raw bitmap format can be. The only way to beat that WTF would have been using ZX spectrum screen images. int .height int .width char[] .data

  • Anonymous coward (unregistered)

    The person who reported this as a wtf should had been fired on the spot for gross incompetence, that is the only wtf i see here.

  • Jules (unregistered) in reply to Patrick
    What's wrong with embedding the file as just a byte array and passing it through a stream? That doesn't need a file system, just the standard bmp library

    That would need twice as much memory: the memory space for the original file, and some space to copy it into while you're using it. Also, the device it's targetted at may not actually have enough RAM to hold a copy of the bitmap, it may only fit in the ROM that the code is stored in. So why not just hard code it in the in-memory format your bitmap display code will use, as this seems to have done? Skip the loading stage, save RAM, make the display faster, and just take a little bit extra development time to write the .bmp-to-.c converter.

  • Spudd86 (unregistered) in reply to nose
    Embedding bitmaps as C code is perfectly reasonable, especially if you live in a constraint environment where there's really no filesystem to load images from.

    You just need a tool to convert your images to .c/.h files, which is a 10 minute job to make for .bmp files.

    err, bmp files are nasty if you actually want to handle them properly...

  • Spudd86 (unregistered) 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 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.

    Yes no makefile is a WTF, but the c-bitmap is not

  • s. (unregistered)

    shrug let me say, I had to do something very similar, at least with the header part. n-th byte adjustments, compiler balking at or ignoring #pragma PACK and the likes, I finally gave up all structured approaches and did the straightforward thing.

  • WilliamF (unregistered)

    try getting an 8 pin micro-controller (its a PIC with a watered down bootloader done by rev-ed AKA PICAXE) with 4 outputs, decode 32 ASCII characters and drive 8 seven segment displays with decimal points, I have got one of these to decode the 10 ASCII numbers, colons, 20 different letters and the bell character, it'll receive 8 bytes for the display (via 4800 baud serial and displays 8 characters out of the 32 "palette" max) has decimal point selection code, beep's when it receives a bell, and a display control routine, in 256 bytes of program space and using a micro-controller'ed version of BASIC the "font rom" is shared with the program memory in a way it has an embedded "font" for the 7 segments. for me its quite an achievement. controlling 64 LEDs and decoding the ASCII to drive said LEDs isnt exactly a small feat for a 8 pin micro-controller

    captcha validus: your argumentus is in-validus

Leave a comment on “The c-bitmap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article