• Kazan (cs)

    idiots never heard of http://www.wxwidgets.org/ 

  • Anonymous (unregistered)

    This seems very familliar, is this a former sidebar?

  • Pap (cs)

    At least we got one line of code this time (technically)!

  • R.Flowers (cs)
    // This might be difficult to port to another platform
     
    All they need is a wrapper for their wrapper. 
  • diaphanein (unregistered)

    Well, its better than the build system at my company.  Instead of porting our build system to multiple platforms, we require you port the platform to the build system.

    So on Windows, "build c:/project" is valid, while you cannot specify "build c:\project" - "Cannot find c:\project.  Does not exist".  Friggin' awesome.

  • Asztal (unregistered)

    Sigh. These millions could be far better spent by contributing to a project like the aforementioned wxWidgets, Qt, etc. :(

  • ParkinT (cs) in reply to R.Flowers
    R.Flowers:
    // This might be difficult to port to another platform
     
    All they need is a wrapper for their wrapper. 

    If the comments were written in poetic verse it would be:

    A Rapper for the Wrapper.

    Right?

  • emurphy (cs)

    I was just about to write that a competent programmer (not that the Core Group had any of those) could have faked the registry on another OS with something like a front end to an XML file.

     

    Then I realized:  Oh crap, their programs aren't just stashing their own settings in the registry, they're probably also expecting to read all sorts of Windows-centric settings like "location of user's home directory".

     

    Then I realized:  Oh crap, their incompetent programmers probably wasted a metric buttload of time trying to wrap every Windows-centric setting they could think of, using a ginormous if/then/else monstrosity.

     

  • Runtime Error (unregistered) in reply to emurphy
    emurphy:

    I was just about to write that a competent programmer (not that the Core Group had any of those) could have faked the registry on another OS with something like a front end to an XML file.

     

    Then I realized:  Oh crap, their programs aren't just stashing their own settings in the registry, they're probably also expecting to read all sorts of Windows-centric settings like "location of user's home directory".

     

    Then I realized:  Oh crap, their incompetent programmers probably wasted a metric buttload of time trying to wrap every Windows-centric setting they could think of, using a ginormous if/then/else monstrosity.

     

     

    The more you keep thinking about it, the more its going to hurt. 

  • kuroshin (cs)
    Alex Papadimoulis:

    Though only a single line, it spoke a lot for the entire system ...

    // This might be difficult to port to another platform

    Not if you use XML !!! 

     

    Edit: Darn, someone beat me to the XML thingy. 

  • exussum (unregistered)

    Kinda a good and a poor wtf.  One typically writes an abstraction layer away from a system you do not have direct access to change.   Examples?  Abstraction from databases, other data sources, graphical interfaces. 

    31 parameter constructors may mirror something in the MFC.  I can't say.  Or it may mirror a composite object.  I can't say w/o seeing the code.

    Some bad code, ie the 6 char string, could be artifact to design and someone forgot to take it out.  That happens.  Not frequently, but it does.

    Writing something that IS tied, considering there was a wrapper written is the big wtf.

     A mediocre one.
     

  • dasmb (unregistered) in reply to Kazan
    Comment held for moderation.
  • Steve-o (unregistered)

    300 developers and not one of them had the cahones to punch the C++/MFC zealot in the face?

  • Anymoose Jr (unregistered) in reply to dasmb
    Anonymous:

    Looking at the history of wxWidgets, it seems like the project was in quite a bit of flux and transition in the late 90's when this project would have been in its design stages.  Open Source hadn't yet become the garden of pure ideology it is today, and a lot of people (even ones without NIH syndrome) were wary of strange, "free" projects developed by academics and hung out to rot.

     

    That still leaves you with Qt and Swing and AWT and SWT and Flash and wed-frontends ... or using a simple "Builder" design pattern. Really, there is no excuse for this beast.

  • Red5 (cs)

    Someone ought to "wrap" the Lead Architect across the nogen a few times.

  • IceJetser (unregistered) in reply to Steve-o

    100 points to you for using the word "cahones."

     

    :-j

  • themagni (cs) in reply to ParkinT
    ParkinT:
    R.Flowers:
    // This might be difficult to port to another platform
     
    All they need is a wrapper for their wrapper. 

    If the comments were written in poetic verse it would be:

    A Rapper for the Wrapper.

    Right?

    Wouldn't it be a rapper for the wrapper's wrapper?  

  • dasmb (unregistered) in reply to Anymoose Jr

    That still leaves you with Qt and Swing and AWT and SWT and Flash and wed-frontends

    Remember: we are talking about a system that was designed in the late 1990s.  Please do not berate developers for not coding to future interfaces, it is difficult enough for us already.

  • Steve-o (unregistered) in reply to IceJetser

    I hope I didn't offend beanbag girl with that comment... wait, it's the viking vixens now gracing these pages. Is that a malted milk beverage?

  • Ghost Ware Wizard (cs)

    LOL on the "Wrapper" what a doofus!

     I had a project once where the "lead developer/manager/architect/know-it-all/@$$hole" was creating their own (wtf #1) "language" to do what they wanted with IVR.  problem was they used C/C++ to write the interpreter and thus shot themselves in the foot as they had output an encrypted (wtf #2 ) file with an XOR 1 method and then emailed this file around to various servers to process the "call flow."

     wtf: idiots are everywhere!

  • Anon E Moose (unregistered) in reply to themagni

    We need to wrap the rapper in a wrapper to stop him from rapping.

     

  • Say What? (unregistered) in reply to exussum
    Anonymous:

    Kinda a good and a poor wtf.  One typically writes an abstraction layer away from a system you do not have direct access to change.   Examples?  Abstraction from databases, other data sources, graphical interfaces. 

    31 parameter constructors may mirror something in the MFC.  I can't say.  Or it may mirror a composite object.  I can't say w/o seeing the code.

    Some bad code, ie the 6 char string, could be artifact to design and someone forgot to take it out.  That happens.  Not frequently, but it does.

    Writing something that IS tied, considering there was a wrapper written is the big wtf.

     A mediocre one.
     

    A big mediocre WTF?

     

  • anonymous (unregistered) in reply to ParkinT
    // This might be difficult to port to another platform
    He can use Wine, maybe.

  • coyo (cs)

    Ah yes, code that is so wrapped it is just a layer after another. Eventually you find that it is 99% layers and 1% code that actually does something.

     Coding something that might be usefull later is a waste the overwhelming majority of the time. Even if it turns out to be usefull sometime in the future, it's probably not been tested, debugged very much because its case has not yet come up.

     
    Coders who overuse layers ought to be shellacked.
     

  • WIldpeaks (cs) in reply to kuroshin
    kuroshin:

    Not if you use XML !!! 

    Edit: Darn, someone beat me to the XML thingy. 

     Darn too, just when I was about to add that this need more XML as well.

      

    We need to wrap the rapper in a wrapper to stop him from rapping.

    Don't fear the reaper ;-)

  • Moridin8 (cs)

    I woulda considered this to be a foo WTF if it weren't for the fact I have seen this occur way to often in my everyday line of work...

    My current employer suffers from this heavily, and many many (failed) attempts have been made to create 'wrappers' to business as usual systems that don't even support something as obvious as XML of all things! (despite being 'modern' systems and the like)

    After some persuasion I have been able to create a facade web-service based layer that disguises all the background poo (while also ignoring the often platform specific or plain wrong legacy 'wrappers') from the application I am working on in the small possibility that someone will take some time out and learn XML!  Passing data around a system in CSV format via FTP in todays modern age on what is meant to be a real-time CDC is little irritating to say the least!

    To give you an idea of some of the incompetance I am experiencing (if the above isn't enough), I have some the head muppet from security implying that my middle-tier web services (with absolutely NO perimiter availability) are open to SQL Injection!?  WTF!?

    Some people should just quit while they are ahead in IT, the problem is that many of them just don't know how to bow out gracefully...  This WTF's Core Group seems to be full of many of these people... I wonder how many of them now work for my employer these days....? Hmm.....

  • ParkinT (cs) in reply to anonymous
    Anonymous:
    // This might be difficult to port to another platform
    He can use Wine, maybe.


    Reading some of these posts ("..I once workedon a project..."), it sounds like one big WHINE.

    {sorry, I had to}

  • merreborn (cs) in reply to exussum
    Anonymous:

    Kinda a good and a poor wtf.  One typically writes an abstraction layer away from a system you do not have direct access to change.   Examples?  Abstraction from databases, other data sources, graphical interfaces. 

    31 parameter constructors may mirror something in the MFC.  I can't say.  Or it may mirror a composite object.  I can't say w/o seeing the code.

    Some bad code, ie the 6 char string, could be artifact to design and someone forgot to take it out.  That happens.  Not frequently, but it does.

    Writing something that IS tied, considering there was a wrapper written is the big wtf.

     A mediocre one.
     

     

    You're right, it's absolutely commonplace to write wrappers for cross platform applications.  It'd be insane not to.  But they're wrapping at the wrong level!  MFC is a *windows system library*.  In an appropriate design, their application would call wrapper functions; those wrapper functions would then call platform specific functions, like those in the MFC.  You're supposed to wrap the application, not the application *and* the platform-specific library!

    Replicating the MFC libraries in a non-windows environment is basically what the WINE project is all about -- note that they've been working on that for THIRTEEN YEARS.  It's very very hard work!

     

    How can any WTF that requires in millions of dollars of budget overages and years of deadline overruns be considered moderate?
     

  • R (unregistered) in reply to dasmb

    That still leaves you with Qt and Swing and AWT and SWT and Flash and wed-frontends

    Remember: we are talking about a system that was designed in the late 1990s. Please do not berate developers for not coding to future interfaces, it is difficult enough for us already.

    Qt so was around in the 1990s, but I don't remember when it was available on Windows, but it was so not on MacOS at the time. AWT came with the first releases of Java (1995), Swing was at least announced in 1997, but I have no idea about SWT. Point is, there were cross-platform libraries at the time.

  • Solo (unregistered) in reply to exussum
    Anonymous:

    Kinda a good and a poor wtf.  One typically writes an abstraction layer away from a system you do not have direct access to change.   Examples?  Abstraction from databases, other data sources, graphical interfaces. 

    31 parameter constructors may mirror something in the MFC.  I can't say.  Or it may mirror a composite object.  I can't say w/o seeing the code.

    Some bad code, ie the 6 char string, could be artifact to design and someone forgot to take it out.  That happens.  Not frequently, but it does.

    Writing something that IS tied, considering there was a wrapper written is the big wtf.

     A mediocre one.
     

    Please read the post again, let me highlight the keywords for you: Platform Independant, MFC, Wrapper (around mfc)
     

    Passionately wrapping the whole MFC library is akin to reinventing the wheel, several times. Not to say that at the time good cross platform solutions existed, but wrapping MFC (and re-inventing all MFC functionnality on all other non microsoft platform) is a bit of a WTF. Wait, that is the WTF. 

    Captcha: quality. Of course! Why didn't I think of that? 

  • Avanai (unregistered) in reply to IceJetser

    -200 points for misspelling "cojones"  

  • emurphy (cs) in reply to IceJetser
    Anonymous:

    100 points to you for using the word "cahones."

     

    :-j

     

    and 200 to dasmb for using "garden of pure ideology".

     

  • Jan (unregistered)

    Oh, this looks so familiar :) I had the pleasure to work on a quite large project where the decision was made to wrap everything - even STL and the scene graphs used. The idea was that somebody may decide to swap these for something else in the future and also to ensure portability. Except that when I needed to get this supposedly portable system to run on Linux, it was discovered:

    a) Nobody ever tried to compile it on anything else but Windows with MSVC 6.0 (at the time), thus the "portable" code wasn't even half-way implemented for anything else but Windows.
    b) The STL wrappers were so complex and convoluted that the code was unmaintainable and had to be thrown out in the end (try converting between std::string and custom string all the time ...)
    c) The STL wrappers used non-standard constructs to get it work with broken STL in MSVC 6.0, thus breaking compilation everywhere else.
    d) The code used such constructs which weren't even syntactically valid C/C++ - however MSVC 6.0 compiled that just fine.
    e) Did I mention custom RTTI mechanism for the wrappers which was not using dynamic_cast<> but compared the mangled class names as strings instead? Guess how did that work when compiled with gcc (hint - it didn't since the names are compiler-dependent ...)

     Those were the times ...

     Jan
     

     

  • cconroy (cs)

    How old school.  This one should have been titled "Wrapper's Delight".

    P.S. It's "cojones", people.

  • Steve-o (unregistered) in reply to Avanai
    Comment held for moderation.
  • themagni (cs) in reply to cconroy
    cconroy:

    How old school.  This one should have been titled "Wrapper's Delight".

    P.S. It's "cojones", people.

    Or "Wrapshody"...
     

  • mkb (cs) in reply to Solo
    Anonymous:

    Not to say that at the time good cross platform solutions existed, but wrapping MFC (and re-inventing all MFC functionnality on all other non microsoft platform) is a bit of a WTF. Wait, that is the WTF.

     
     Depends on how late 90's it was. STLPort may have worked at the time.

  • Quietust (unregistered) in reply to Steve-o
    Comment held for moderation.
  • Anonymous (unregistered) in reply to cconroy
    cconroy:

    How old school.  This one should have been titled "Wrapper's Delight".

    P.S. It's "cojones", people.

    In "Tex-Mex" or "Spanglish", "cohones" is also acceptable. 

  • HitScan (cs) in reply to merreborn
    merreborn:

    You're right, it's absolutely commonplace to write wrappers for cross platform applications.  It'd be insane not to.  But they're wrapping at the wrong level!  MFC is a *windows system library*.  In an appropriate design, their application would call wrapper functions; those wrapper functions would then call platform specific functions, like those in the MFC.  You're supposed to wrap the application, not the application *and* the platform-specific library!

    Replicating the MFC libraries in a non-windows environment is basically what the WINE project is all about -- note that they've been working on that for THIRTEEN YEARS.  It's very very hard work!

     

    How can any WTF that requires in millions of dollars of budget overages and years of deadline overruns be considered moderate?
     

     

    A couple problems: 1. MFC, most thankfully, is not a system library or API. It's an object-oriented* wrapper around the system API, which is called Win32. 2. Wine's purpose isn't to make MFC work on Unix, it's to make Win32 work on Unix. They do happen to have some MFC work going on, but I don't know if MFC was even around when Wine started. (If so, it wasn't old)

     That, of course, brings us to another WTF: namely, that they were writing a wrapper for a wrapper that's such a low level wrapper that from a portability perspective it's indistinguishable from the native API. That's A-Grade stupidity right there.

     

     

    *For certain, ambiguous, yet painful, definitions of object-oriented. 

  • R.Flowers (cs) in reply to themagni
    themagni:
    cconroy:

    How old school.  This one should have been titled "Wrapper's Delight".

    Or "Wrapshody"...
     

    Coooool! Actually, both are good, but "Wrapshody" is sublime. 

  • Rick (unregistered) in reply to Steve-o

    No, it's called a money shot.

  • Rick (unregistered) in reply to Steve-o

    Anonymous:
    ...wait, it's the viking vixens now gracing these pages. Is that a malted milk beverage?

     Argghh, it didn't quote.  Let me try again.

     "No, it's called a money shot."
     

  • CodeWhisperer (cs)
     
    // This might be difficult to port to another platform

    In 1998 or so I worked for a company that made home networking products based on the CEBus standard.  Since they were located in a small southwestern desert town, they didn't have access to a wide pool of developers, and somebody decided it would be a good idea to bring in some outsourced developers from India.  

    This happened before I arrived, but based on what I saw of their code, they had never used C/C++ before (they rewrote standard C functions like strcat) and had a truly twisted understanding of Windows development.

    First, they decided that storing data in document files just wasn't the way to go.  Instead they wrote the data into the registry.   Think about that for a moment.  Mb sized files being broken down into a tree structure and stored in the registry (and a lot of it wasn't really 'tree shaped', just wedged in where they could). 

    Apparently somebody figured out that this just wasn't an appropriate solution and the outsourced guys made a second pass at it... they created a series of functions that matched the calls to the registry functions and wrote it to a file instead, then just did a global search and replace on the codebase.  The files were grotesque to work with and their code was buggy and had a tendency to wipe out their carefully crafted tree structure, and each request opened and closed the file each time.  (And, of course, at a quick glance the code still looked like it was accessing the registry since they just put an underscore in front of the name or something equally clever).

    So, apparently it wasn't that hard to port...badly, at least.

    I tried to get them to replace the document handling entirely, but after having paid several tens of thousands of dollars to the offshoring company, they decided that they'd stick with what they had already paid for.

    This wasn't the end of the WTFs at this company, however...other choice ones include:

    1) The CEO who changed his mind on the color of light switch plates (Eggshell?  Or Off white?  No, Eggshell...no, off white...no...) so often that our suppliers started to refused to deal with us.
    2) Spending a huge chunk of our $X million investment in an oak-paneled office and conference room with custom made art displayed inside a custom made table.   (We started laying people off not long after...)
    3) The entire company was based on the CEBus protocol -- and not a single developer knew it.   Somebody wrote some code years in the past and they just kept reusing it with the assumption that it must be perfect (if perfect means 'issues 10x as many control messages as necessary').  When I left, I was still the only one who knew it.

    -cw

  • Darin (unregistered) in reply to coyo

    > Coding something that might be usefull later is a waste the overwhelming majority of the time.

     I ran into that problem at an previous job.  Had to integrate with programmers at a foreign site who were porting to new hardware, and this team did not have a strong software lead.  This was a large company and most of the teams did actually move around to different projects a lot, and code sharing was common.  So they had a laudable goal of creating platform and project independent modules.  The drawback though was that this portability goal was this team's number one goal, and "getting the product to work" came in a distant second (this was not true of the company in general).  The division was shut down before the product was finished.

  • lomaxx (cs)

    the thing I always wonder when I read these posts about millions of dollars that are smoked into oblivion is whether
    a) these companies are seriously making that much money that they can stay afloat after pumping hundreds of millions of dollars down the tube
    b) do they ever get a return on these garbage products

    None of the companies that I've worked at would be able to just absorb the cost of a couple of mill, let alone hundreds of millions...

  • tster (cs) in reply to Darin

    creating a language for a project is not a WTF.

     

    coding something that will be useful later can be very good.

     
    If you are working on a specific functionality and you have the following options:

    spend 4 days making it work.

    spend 4 days writing an object that abstracts the functionality and then a day coding on top of that, you may very well save many days down the road. 
     

  • Chris (unregistered) in reply to coyo

    've heard this type of code -- the kind thats an unmaintianiable mess because of the huge amount of layers and encapsulation called Ravioli Code.  It's Spaghetti Code's object oriented brother.

  • Ulric (unregistered)

    Many companies have made ports of MFC to other plateforms, including Mac.  I know at least of three!

    In fact Corel made Draw for the Mac using their own port of the Win32 C api itself, which is much less a good idea than porting at the MFC level which is more controlled.  It's not totally insane.  You got the source of MFC, and as long as the programmer call the methods (and not Win32 directly) you can remap that to another OS.  It simply makes the app run better on Windows, and the programmers can use the VC++ online help as the doc for the 'toolkit'. You can easily use windows-specific enhancements for the Windows version, which don't use on the secondary plateform.

    Making an app with QT in the late 90s would have meant a terrible Windows version, with emulated controls and all.

    WxWindows would have been an option, though.  I know it was around in the 90s I checked it out (we ended up using XVT)  If I'm not mistaken it was made by people who loved MFC and it was very much like MFC back then, used native plateform controls, and was open source with no license restriction.

    Google and other company use WineLib, others use MainWin, and yet many more people than you think use in-house Win32/MFC wrappers, this is not really from the left field.  It depends what is your priority.

  • Ulric (unregistered) in reply to Ulric

    Ho there are also several companies using Windows port of CodeWarrior' PowerPlant, the equivalent VC++'s MFC.

    If you really want a WTF, some companies actually used QuickTime to port their Mac apps to Windows, because QuickTime for Windows had to have some Mac API emulation on windows to work.  That *that* was stupid, because it was unsupported and not recommended by Apple

Leave a comment on “Wrapping Fever”

Log In or post as a guest

Replying to comment #:

« Return to Article