• Procedural (unregistered)

    Before Windows 3.0 adding resources to an executable was a majestic PITA, so this was a common trick. Same for MZ and NE executables. It's not that the code is wrong. It's that the OP hasn't been in the business long enough to remember resourceless executable formats (the alternative solution was to make your own exe file "suffix" and tagging your resources there one after the other, but you were doing so as a custom solution without benefit of any kind of specific OS support).

  • oheso (unregistered) in reply to sirlewk
    sirlewk:
    No definetly not. You are the first, thank you for your insight. It is a good thing you didn't bother to read the comments, that would have just slowed you down in posting this helpful perspective.

    Whoosh!

  • DOUG GOD DAMNIT (unregistered)

    I'm certain this has been pointed out but jeeezuz that's perfectly normal when dealing with it or atmel shit and gimp actually will export an image as c code.

    wtf what a waste of a good wtf.

  • embedlor (unregistered)

    It's common to embed resources in the source code in embedded projects, especially if the OS has no resource system. Sometimes there is no OS nor any filesystem, and it's the only way to do things.

    The programmer that set that up at least defined the bitmap in a standard format so people coming along later could open it in paint and edit it even if the original source file got lost, that's pretty damn decent. I would have expected a device-specific format with no header.

  • Lee K-T (unregistered) in reply to DaveK
    DaveK:
    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).

    Spectrum, those were the days! I remember drawing my 8X8 boxes on a piece of paper to calculate the boolean number corresponding to each line of the image... lol

  • YourName (unregistered)

    That code seems to come from an file used for an 8051 uC which was compiled by KEIL C51 Compiler. This is why he couldn't find any makefile. And if I'm right and the code was for an 8051, storing bitmaps as const c-arrays was the only way to handle bitmap data as nobody wanted to implement a filesystem to handle those bitmaps....

    So I personaly can't find the WTF... except that the author wasn't able to find out which compiler was used...

  • gaaack (unregistered)

    Well, just do a

    strings which xboard.real

    It's a better solution than depending on 9000 image files which are conveniently located in /usr/share/beatmewithaclub .. no wait, in /usr/local/fsckmeharder.. no wait.. ARGHHH..! And on a freaking image library and on correctly handling all these stupid error conditions.

    "Opening Files" must die.

  • Alan (unregistered) in reply to Slicerwizard

    "Telepathic gecko this way"?

    CAPTCHA: amet, as in "amet Bill Gates and he told me to go away"

  • Jimmy Jones (unregistered)

    Is this bad? I do it all the time...

  • Kilrah (unregistered)

    As some already said, this might look like a WTF to the IT guys on here, but for small embedded devices without an OS or filesystem it's actually the standard way to do it. And there's a whole lot of those out there.

  • Jimmy Jones (unregistered)

    Imagine if the original developer had used some linker/loader functions to do this...

    After the code had been "passed around" a bit he'd be totally up a certain creek without a rowing implement.

    This is the easiest, most reliable, compiler-independent way to do it.

    The WTF is when you don't do this and instead write a program with 22000 files to be loaded at runtime (eg. Photoshop). How do you test that build to make sure there's none missing?

    With the c-bitmap you know there's a missing file because the compiler will tell you all about it (usually in upper case letters).

  • Jimmy Jones (unregistered) in reply to gsl
    gsl:
    It's really a totally different world when you're working under such limiting circumstances -- much more like application programming was during the days of the Apple //e and Commodore 64 than any sort of PC programming today.

    I think c-bitmaps make sense even in the world of quad-core multi-gigabyte Windows coding..

  • (cs)

    Nice. This reminds me of embedded C projects. There was literally no file system in this board we were working on, so we basically had to have the files, indeed, as c-bitmaps.

    Ahh, the good ole days.

  • no need (unregistered) in reply to Jimmy Jones
    Jimmy Jones:
    Imagine if the original developer had used some linker/loader functions to do this...

    After the code had been "passed around" a bit he'd be totally up a certain creek without a rowing implement.

    This is the easiest, most reliable, compiler-independent way to do it.

    The WTF is when you don't do this and instead write a program with 22000 files to be loaded at runtime (eg. Photoshop). How do you test that build to make sure there's none missing?

    With the c-bitmap you know there's a missing file because the compiler will tell you all about it (usually in upper case letters).

    Yes, plus I(!) know how those files have been created by whom and what they're fore. Those files are autogenerated by a tool. Plus the guy handing this in is pretty clueless about his work.

    And a sidenote: the name he had chosen to submit this under is pretty obvious what clients code he had posted (so if wanted it could be tracked back to the supplier unable to proper handle code and knowledge about compiling it). A real smartass...

  • A. (unregistered)

    I'm pretty sure I've seen this somwhere before, no idea where, tho.

    It looks to me like wanting to add bitmap resources to the executable when no other way of doing this is available.

  • Marc (unregistered)

    C bitmaps have been around for ages. Typically they have the extension xcf. They are a (bit old-fashioned) way to include bitmap resources in compiled C. Moreover, unlike other ways to include resources, they will work in a cross-platform context. There are graphics editors that will convert a bitmap to C and vice versa, so nothing WTF about that either.

    The only possible WTF is if this guy hand-coded his bitmaps and/or uses a non-xcf format.

  • Sam Morris (unregistered) in reply to gcc can embed objects directly

    Would you care to point us at the documentation for that feature? For a while I embedded data with (IIRC) objcopy and linked the resulting .o files into my executable, but that would not guarantee the correct alignment, so sometimes the string would appear as garbage when accessed. In the end I used a script 'bin2s' that converted a binary file into assembly statements for the alignment and data; but if GCC now has a way to do that directly I'd like to know how it's done.

  • intelligent brian (unregistered)

    This is not really a WTF. The developer is probably working on an embedded system, perhaps one that does not even have a file system. On such a system, this is a sensible, safe and portable way of putting resources in to your code.

  • Burpy (unregistered)

    The real WTF is having four pages of comments all saying that it's not a WTF because of embeded blah while most humans would understand the point after 1-2 comments.

  • Boing (unregistered)

    Hmm, some time ago XBM and XPM files made perfect sense ... packaging bitmap data in source code form therefore does not scream out at me as being totally weird. Oh well, maybe I'm just too old for this shit ...

  • -L (unregistered)

    Maybe this was an embedded system, with no operating system and hence no file system.

    The question would then be how this method is worse than some other methods the original developer could have used to include the bitmaps in the executable? And how is the used method any worse?

    After all the files only need to be re-compiled when the bitmap is updated.

  • rob (unregistered) in reply to gatechman
    gatechman:
    I'm still calling this WTF as the original developer could have linked a binary file instead leaving it as a C file. This is by far the better solution as changing the bitmap would only require replacing the file instead of re-writing a C file. In addition you can specify in your linker script where you want the bitmap to be loaded in memory. Finally, manually editing file headers? Well I guess if your in windoze and your dealing with Mr. Gates idea of a bitmap..

    The original file should exist in source control. As part of the build process those C files are generated automatically from the original bitmap files, and the code is then compiled. No one with a shred of common sense would think of editing those files manually. The only WTF here is that either:

    a) They don't use source control since they appear to have 'lost' the original makefiles. b) The person submitting this was a moron.

    Oh, and for the record, it's not a windows trick. Windows has resource dll's for that purpose. The code is most likely to have come from linux or an embedded environment.

  • Sid (unregistered)

    I don't understand - someone posted a WTF, but it turns out that the WTF is, on closer inspection, not in fact a WTF? In effect, what we're saying here is that the original poster didn't understand the code? That he is mocking someone for being stupid, but has actually demonstrated that it is he who is the incompetent fuckwit?

    Why, that NEVER happens on The Daily WTF! Maybe only 95% of WTFs posted here follow that pattern!

    Maybe this site's name should be changed to Daily Passive-Aggressive Geek With an Inferiority Complex and a Massive Chip on His Shoulder? DailyPAGWaICaMCoHS for short.

  • Dave (unregistered)

    perhaps he was developing for an embedded system where it maybe didn't have a filesystem. not a wtf.

  • (cs) in reply to Dave
    Dave:
    perhaps he was developing for an embedded system where it maybe didn't have a filesystem. not a wtf.

    Thank God you got through!

  • Anonymous (unregistered)

    You're all so busy complaining that you're missing a great meta-WTF here.

  • chane325 (unregistered)

    No wtfs here. This is development on an embedded platform where there might not be (probably isn't) a file system to allow the program to load up graphics. So this is a standard way to put the graphics in to the executable.

  • (cs) in reply to El_Heffe
    El_Heffe:
    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]

    Well i did have to hand copy it and type it in manual from a hex editor

  • Foo (unregistered)

    it's called an embedded resource you hapless programming newbie

    what the hell do you think a .xpm is?

  • Wouter Verhelst (unregistered)

    This is actually quite useful if you don't have a file system. A controller being a rather embedded thing, probably does not have a file system. Also, if you embed the bitmap in the binary in this way, you don't need to fopen() and load the bitmap, you can just pass a pointer to the correct region in memory.

    Of course you want to autogenerate that code then, rather than manually write this file (as seems to have been done here, cfr the comments), but that's a different matter entirely.

  • Joshua (unregistered)

    When I worked for the U.S. Air Force Reserve, there was a COTS product formerly called DEPCON (I have no idea what it's called now) that was essentially a document distribution clearinghouse. At any rate, it handled bitmaps the same way. The files had a .bmp extension but inside, they were C header files. Many of them had interesting variable names like const int FNORD[] = { }; and const int PINKY[] = { }; and so forth. I found it quite amusing.

  • Brad (unregistered)

    This seems like the naive way to get bitmaps loaded onto a device without a proper filesystem. Is there a better way to do this?

  • Anonymous coward (unregistered)

    All the people who made fun of this ("the goggles!") have just betrayed themselves as fakers who know nothing about programming but just repeat the same stuff every fucking time. Thanks in advance for chastising them.

  • Jim (unregistered) in reply to Anonymous coward

    Maybe someone programmed some kind of embedded system to post comments talking about how normal it is to embed images in source.

  • It's Me (unregistered) in reply to Code monkey

    Nah. It's latin. Kinda like frist -- only a bit late...

  • borat (unregistered)

    Why is storing bitmaps as C-files in an embedded project a WTF? I'll give you a reason why it's not: C is roughly standardized, the file systems and resource managers one would use are usually not.

  • Peter Tramonson (unregistered)

    About the image : people controlled by brain-washing Mickey helmets should go to the left.

  • Design Pattern (unregistered)

    No it is not a WTF to embed binary resources in your program executable.

    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).

    From the description of GNU objcopy:

    --binary-architecture=BFDARCH: Useful when transforming a raw binary input file into an object file. This option will be ignored if the input file has a known BFDARCH. You can access this binary data inside a program by referencing the special symbols that are created by the conversion process. These symbols are called _binary_OBJFILE_start, _binary_OBJFILE_end and _binary_OBJFILE_size. e.g. you can transform a picture file into an object file and then access it in your code using these symbols.

    And about the complaint it turned out misaligned sometimes:

    `--pad-to ADDRESS' Pad the output file up to the load address ADDRESS. This is done by increasing the size of the last section. The extra space is filled in with the value specified by `--gap-fill' (default zero).

    This is a classic WTF, almost as big as a WTF can get. Which turns out to be using XML. For anything (than text markup).

    CAPTCHA: consequat Why not consequently run a spell-checker on the CAPTCHAs?

  • Joe (unregistered)

    Not sure why you'd see this as a WTF. You need to store the bmp somewhere. In a modern world it might be a resource or external file, but if space is limited, the obvious place to store it is within the executable. So writing a utility to convert small bitmaps to C source code could be reasonable.

  • Design Pattern (unregistered) in reply to Joe
    Joe:
    Not sure why you'd see this as a WTF. You need to store the bmp somewhere. In a modern world it might be a resource or external file, but if space is limited, the obvious place to store it is within the executable. So writing a utility to convert small bitmaps to C source code could be reasonable.
    Is this a reply on my post? If yes then you are a troll.
  • squidbot (unregistered) in reply to embedlor

    "The programmer that set that up at least defined the bitmap in a standard format so people coming along later could open it in paint and edit it even if the original source file got lost, that's pretty damn decent. I would have expected a device-specific format with no header."

    You're right, this is almost an ANTI-WTF. A bitmap header with useful things like dimensions. It could have just been presented as a giant bitfield with no comments.

  • just finished reading all the comments (unregistered)
    Design Pattern:
    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).

    Chances are high that you have very limited real world experience with embedded programming, where replacing your tools isn't trivial. Maybe there is another tool that supports this; it might cost too much, and it might be worse in other ways.

    Coding a simple binary-to-C encoder is a trade-off that the original coders might have decided was worthwhile. You have no idea what their constraints were, and calling them on their knowledge of the compiler and their tools betrays your own inexperience.

    Besides, it's a pretty simple and straightforward task, and writing a well tested tool to do this would take most programmers about half the time it would take them to read all these comments.

    How unprofessional it would be to shell out for a new tool, or building binutils or similar for the platform (and incurring the testing burden that entails.)

  • Wouter van Kleunen (unregistered)

    You don't have to read from disk and you don't have to distribute all kinds of bitmap files, just one executable. It's not that uncommon to do this.

  • Reinier (unregistered)

    See

    http://en.wikipedia.org/wiki/X_BitMap

  • (cs) in reply to frits
    frits:
    Dave:
    perhaps he was developing for an embedded system where it maybe didn't have a filesystem. not a wtf.

    Thank God you got through!

    That was in fact the first post, but he's been constantly getting those server error messages for the past three days and retrying!

    (Irony: I hit submit to post this and guess what happens? 2nd try... 3rd...)

  • (cs) in reply to Sam Morris
    Sam Morris:
    Would you care to point us at the documentation for that feature? For a while I embedded data with (IIRC) objcopy and linked the resulting .o files into my executable, but that would not guarantee the correct alignment, so sometimes the string would appear as garbage when accessed. In the end I used a script 'bin2s' that converted a binary file into assembly statements for the alignment and data; but if GCC now has a way to do that directly I'd like to know how it's done.
    For objcopy syntax, see this other comment, which was probably intended as a reply to your post. The only thing to add is that there are two ways by which you can skip objcopy altogether:

    • you can pass the binary file directly to 'ld' by prefixing it on the command line with "-b binary".

    • you can include it directly into an assembly file using the ".incbin" directive.

  • Entropy (unregistered)

    It's not the worst idea ever in concept. It's a portable way to include image data into a binary, which is useful in embedded environment where you might not have a separate filesystem to hold these things.

    TRWTF is that he rolled his own. XPM is a standard file format supported by a number of image editing and conversion tools that is valid C code and can be just #included into a project. Although I think that XPM is a pretty limited format and might not support all the features that .BMP does (e.g. 24-bit color).

  • Alex Reicher (unregistered)

    Actually this is not necessarily a WTF...

    Converting BMP files into C files could be useful if you're required to bake the BMPs into your executable image while perhaps supporting multiple endianesses, processor architectures, executable formats, compilers and linkers -- i.e. you can't use some single well defined method of resource packaging.

    Of course it's better to create these C files as part of the build process and not keep them in a VCS.

  • Slicerwizard (unregistered) in reply to SP
    SP:
    my bad, here's the version that ISN'T upside down.
    Yeah, but your upside down image is a featured comment...

    Alex, you are the weakest link.

  • just finished reading all the comments (unregistered)

    Why does the original article put "bitmap" in quotes?

    there were a total of 274 such "bitmaps" in the project.

    Ask your dad what a bitmap is.

Leave a comment on “The c-bitmap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article