• eager beaver (unregistered)

    "Seth loaded up their issue tracker and eagerly navigated to #88743."

    There's your wtf right there.

  • Aaron (unregistered) in reply to eager beaver

    Apparently you have never worked with a large codebase.

  • CadCad (unregistered)

    Was working for a PCB designer in 2001 who'd set up everything to work quite well with DesignCAD 4.
    A DOS program. Designed to run on a 386 (although putting it on a (still primitive) 200MHz P1 made it run quite sweetly).

    The onscreen menues didn't work with any other DesignCad revision. The active dimensioning features didn't work. The graphics tablet layout didn't work.

    And it depended strictly on a set of hardcoded graphics cards, as the concept of a re-usable driver apparently hadn't been implemented by then. A 16-bit ISA card. With 1MB of graphics memory.

    I still have piles of files from there (most are at least partially readable with the free viewer on a modern system), but finally quit using it when my last sample of 'functional' graphics cards expired.

    Upgrading was basically impossible. Now I just print off what the old drawing looked like, and draw them all over again (not much fun for a complex circuit board just to fix one bad trace somewhere, or update it for a no-longer-available component...

    sigh

  • (cs) in reply to 5|i(3_x
    5|i(3_x:
    It doesn't have to be intentionally malicious to be harmful: http://en.wikipedia.org/wiki/Hanlon's_razor .

    Unfortunately, Hanlon's Razor cuts both ways. Malice is well aware of Hanlon's Razor and uses it as cover all too frequently.

  • (cs)

    So to use your application I need to buy another application so I can configure it... that makes SO much sense!

  • monies (unregistered) in reply to tamm
    tamm:
    So to use your application I need to buy another application so I can configure it... that makes SO much sense!

    shrug

    it would if they sold both of the applications.

  • El Dorko (unregistered) in reply to JD

    Holy moses - I recognized Multiplan in a split-second! I haven't used it in, oh, maybe 20 - 25 years or so, but man oh man was it a great tool.

    They don't make them anymore like they used to...

  • St Mary's Hospital for the Frantically Coding (unregistered)

    I don't understand you all.

    The real WTF® is using any software written in LOLCODE.

  • (cs) in reply to Bizzle
    Bizzle:
    I was just thinking about how great it would be if TopCod3r came back. And what do you know, he did!
    And what a disappointment it was.
  • Abraham (unregistered)

    So they use excel and macros to export config files, and omg ... it did not work with apostrophe ! Come on, what's the big deal ? And what comes next ? An exciting story about a guy who used Javascript to validate fields on webform ... and somebody entered dd.mm.yy where the script expected mm/dd/yy ?

  • Médinoc (unregistered) in reply to JD
    JD:
    The .NET framework includes a multitude of possibilities for storing and retrieving configuration settings. Problem is, the .NET framework has only been around for a few years and is not yet mature enough to be trusted for mission-critical functionality. This is why I prefer to use Multiplan for DOS. With 26 years of service under its belt, you just can't get a better time-tested solution. (snip)
    Multiplan for DOS? Hah! For years, my father has used Multiplan for CP/M plus on an Amstrad CPC 6128. NOW we're talking proven technology!
  • blunder (unregistered) in reply to Abraham

    They probably did ten times the amount of work writing those scripts, when they could have just put the configuration page into the program and serialize the data.

    The validation code would have been much easier, since they wouldn't have been fighting against a program that automatically changes the formatting of the data based on its values (for example, anticipating having to add the leading zeroes on a ZIP). For multiple-choice or yes/no values, they could use input methods designed specifically for those, like checkboxes. With defaults set. In that case, you don't even need code to validate the entries.

    They might not have even had to use COM at all directly, if that was the only place they used it.

    They got nothing of value for all that extra work and actually complicated things on their clients' end. And what's more, all of the programmers knew it, even the new kid...just not the one guy.

    Perhaps this isn't the sort of thing that makes you laugh or raises the hair on your arms, but I can tell you that it definitely works on me, and I'm one of those readers that really only cares about the CodeSODs.

  • Herby (unregistered)

    What?? Nobody has proposed using Spectactulator (made by Radio Shack, and available on a ColorComputer in a plug-in module. Worked pretty well in a limited memory machine (32k bytes, yes 32768 bytes!)

  • /dev/null (unregistered)

    Almost as brillant as using excel to do issue tracking. I tell the bosses the spreadsheet is not compatible with Quattro Pro 4 :-P

  • (cs) in reply to 5|i(3_x
    5|i(3_x:
    mjk340:
    I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    I'm not so forgiving. Input is evil and should be treated with prejudice. It doesn't have to be intentionally malicious to be harmful: http://en.wikipedia.org/wiki/Hanlon's_razor .

    What if the customer's ZIP code changes to something like ";drop database;" ??

  • (cs) in reply to ParkinT
    ParkinT:
    only (128) ASCII characters to worry about!
    Actually roughly 30 of those (all unprintable characters) aren't normally used in a text document, only text terminal communications. There are 3 other "unprintable" characters that do exist in ASCII text, "tab", "cartridge return"* and "line feed"**. There are also "vertical tab" and "form feed" (page break) codes, which are rarely used due to keys for them not being on most keyboards. * Windows and Linux files ** Windows and Mac Files

    So when handling ASCII text, you only really need to worry about under 100 characters.

  • El Dorko (unregistered) in reply to Médinoc

    "For years, my father has used Multiplan for CP/M plus on an Amstrad CPC 6128. NOW we're talking proven technology"

    Luke - I am your father! I had a damn CPC 6128, and CP/M! Damn your mother, she never told me I had a son...

  • tragomaskhalos (unregistered) in reply to ParkinT
    ParkinT:
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    Amen to that - .ini files were brilliant; human-grokkable, and perfectly adequate for the vast majority of config tasks. And IIRC there were some nice API calls to pluck data out of them without having to parse the file yourself. XML shmeXML indeed.

  • Bosshog (unregistered) in reply to tragomaskhalos
    tragomaskhalos:
    ParkinT:
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    Amen to that - .ini files were brilliant; human-grokkable, and perfectly adequate for the vast majority of config tasks. And IIRC there were some nice API calls to pluck data out of them without having to parse the file yourself. XML shmeXML indeed.

    No no no NO NOO! You have to take the list of key-value pairs, type them into Word (you can colour the text if you like). Print it out. Put it on a wooden table. Take a picture with your digital camera. Send that to a friend. Have them read from the screen into a WAV recording. Have them send you the WAV. Open it in a hex editor. Convert each hex digit to an ASCII code (in decimal), and use these to build your XML config file out of <ascii> tags. It will be much harder for unauthorised users to make config changes.

  • Kozz (unregistered) in reply to Peter

    MS Word as a code editor? Wow. I guess that for some people, when all you've got is a hammer, everything looks like a ... watermelon?

  • Kozz (unregistered) in reply to Smash King

    No, no... that won't work. Everybody knows that the DB user account is granted only the permissions it needs.

  • Edward Royce (unregistered)

    Hmmm.

    shrug could be worse.

    I once worked on a custom application, years ago, where the configuration information was stored in a -image file-. I think it was a JPG but it's hard to remember some of the details as I definitely wanted to forget them soon after.

    The whole point behind this was that the application would only run if the image file existed and was in the right place -and- had the correct information. The image file also had dates encoded in it so the application would not only not run properly if the system date was outside the bounds set in the image file but the application would delete the image file.

    This system was set up so that customers would have to pay their bill and couldn't simply edit a text file or something else to get around it.

    shrug I guess it's better than a dongle. But not by much IMO.

  • DYMongoose (unregistered) in reply to Anonymouse
    Anonymouse:
    Your father's Microsoft Word. This is the weapon of a true programmer. Not as clumsy or random as Excel. An elegant solution, for a more civilized age.

    Hokey programing techniques and ancient word processors are no match for a good spreadsheet by your side...

  • Anonymous (unregistered) in reply to Edward Royce
    Edward Royce:
    Hmmm.

    shrug could be worse.

    I once worked on a custom application, years ago, where the configuration information was stored in a -image file-. I think it was a JPG but it's hard to remember some of the details as I definitely wanted to forget them soon after.

    The whole point behind this was that the application would only run if the image file existed and was in the right place -and- had the correct information. The image file also had dates encoded in it so the application would not only not run properly if the system date was outside the bounds set in the image file but the application would delete the image file.

    This system was set up so that customers would have to pay their bill and couldn't simply edit a text file or something else to get around it.

    shrug I guess it's better than a dongle. But not by much IMO.

    OK, so I'm confused. Was this some futile effort at security by obscurity? I really can't think of a single good reason why you would encode config settings into an image file. But, of course, security by obscurity is a massive WTF in itself so I could kind of imagine some idiot development manager seeing this as "a really elegant way to securely store our config settings!". Was that where this idea came from, or am I way off?

  • Anonymous (unregistered) in reply to Anonymous
    Anonymous:
    Edward Royce:
    <snip>
    <snip>
    Guess I haven't drank enough coffee today. Just re-read your post and saw the bit about customers not being able to edit the image file. So I guess that this is an example of security by obscurity. When the hell are people going to learn that security by obscurity is about as useful as security by chipmunk?
  • (cs) in reply to Bosshog
    Bosshog:
    tragomaskhalos:
    ParkinT:
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    Amen to that - .ini files were brilliant; human-grokkable, and perfectly adequate for the vast majority of config tasks. And IIRC there were some nice API calls to pluck data out of them without having to parse the file yourself. XML shmeXML indeed.

    No no no NO NOO! You have to take the list of key-value pairs, type them into Word (you can colour the text if you like). Print it out. Put it on a wooden table. Take a picture with your digital camera. Send that to a friend. Have them read from the screen into a WAV recording. Have them send you the WAV. Open it in a hex editor. Convert each hex digit to an ASCII code (in decimal), and use these to build your XML config file out of <ascii> tags. It will be much harder for unauthorised users to make config changes.

    That's true but a more productive way would be to just hard code the settings into the exe, then have the customers call a premium rate phone line to request a build with their new settings (only one setting can be changed per call of course, if you want to change your address and phone number, that's 2 seperate calls thank you very much). :)

  • Anonymous (unregistered) in reply to tragomaskhalos
    tragomaskhalos:
    ParkinT:
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    Amen to that - .ini files were brilliant; human-grokkable, and perfectly adequate for the vast majority of config tasks. And IIRC there were some nice API calls to pluck data out of them without having to parse the file yourself. XML shmeXML indeed.
    I must admit, I also have something of a soft spot for INI files. As noted above, they're easy to use, easy to understand, human editable and there are even API commands available so you don't have to parse them manually (not that it's difficult or anything, given their rigid structure). Shame that MS has been trying to kill them off since about 1995.

  • tragomaskhalos (unregistered) in reply to Anonymous
    Anonymous:
    Edward Royce:
    Hmmm.

    shrug could be worse.

    I once worked on a custom application, years ago, where the configuration information was stored in a -image file-. I think it was a JPG but it's hard to remember some of the details as I definitely wanted to forget them soon after.

    The whole point behind this was that the application would only run if the image file existed and was in the right place -and- had the correct information. The image file also had dates encoded in it so the application would not only not run properly if the system date was outside the bounds set in the image file but the application would delete the image file.

    This system was set up so that customers would have to pay their bill and couldn't simply edit a text file or something else to get around it.

    shrug I guess it's better than a dongle. But not by much IMO.

    OK, so I'm confused. Was this some futile effort at security by obscurity? I really can't think of a single good reason why you would encode config settings into an image file. But, of course, security by obscurity is a massive WTF in itself so I could kind of imagine some idiot development manager seeing this as "a really elegant way to securely store our config settings!". Was that where this idea came from, or am I way off?
    Well the mechanism is reasonably standard in computer steganography AFAIK, but as to why you'd want to use it for config information, who knows?

  • Dave (unregistered) in reply to JD

    Hahaha.... for a minute I thought you were serious.

    WOOSH!

  • Robert S. Robbins (unregistered) in reply to tragomaskhalos

    [quote user="tragomaskhalos"][quote user="Anonymous"][quote user="Edward Royce"] Well the mechanism is reasonably standard in computer steganography AFAIK, but as to why you'd want to use it for config information, who knows? [/quote]

    You could use XMP (Extensible Metadata Platform) to embed information in images without affecting the image quality. The ExifTool or Adobe Bridge can be used for reading, writing and editing meta information.

    I was thinking of using that to store user information in user profile images for a web application. Naturally I would not document it. I'll just leave the data source as a mystery for future developers to figure out.

  • ckelloug (unregistered)

    Exif is cool. A pity it's not used more. I once wrote a perl cgi web catalog application (over Christmas Break in college) that stored the prices and item information as EXIF data. This allowed the non-computer savy user to add this information to images ensuring that when the system built the catalog pages it had the right metadata for each image. The front end for it was the Pegasus Image Editor: From pegasus, makers of that horrid pop3 mail program. This was all great technology for a small business when I developed it 12 years ago but it was long in the tooth by about 8 years ago. I finally got out of supporting it when the owner of the store died about 6 years ago.

  • eager beaver (unregistered) in reply to Aaron
    Aaron:
    Apparently you have never worked with a large codebase.

    My point was in reference to the eagerness, not the issue number. Keep up the overtime on your supersized penile substitute codebase.

  • troels (unregistered) in reply to Peter
    Peter:
    I would never have believed it if I had not seen it myself.

    Neither would I.

  • Will (unregistered)

    Wow, reminds me of my boss. Apparently from his perspective, everything from asset management systems to CRM systems and email marketing can be effectively replaced with Excel-- everyone else is just too dumb to realize it.

    Of course when I suggest that he replace his accounting software with Excel it's another story...

  • cal (unregistered) in reply to revenant
    revenant:
    Even better, there is be a nonzero probability that when another excel expert types extra apostrophe in the hex editor, she would accidentally add new useful features to the program.

    Actually, since there is an infinite number of possible changes but (I assume) only a finite number of potentially useful features, almost surely she doesn't add a useful feature. (I mean "almost surely" in the context of probability theory, i.e. the probability is zero)

Leave a comment on “Waiting to Excel ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article