- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
idiots never heard of http://www.wxwidgets.org/
Admin
This seems very familliar, is this a former sidebar?
Admin
At least we got one line of code this time (technically)!
Admin
Admin
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.
Admin
Sigh. These millions could be far better spent by contributing to a project like the aforementioned wxWidgets, Qt, etc. :(
Admin
If the comments were written in poetic verse it would be:
A Rapper for the Wrapper.
Right?
Admin
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.
Admin
The more you keep thinking about it, the more its going to hurt.
Admin
Not if you use XML !!!
Edit: Darn, someone beat me to the XML thingy.
Admin
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.
Admin
300 developers and not one of them had the cahones to punch the C++/MFC zealot in the face?
Admin
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.
Admin
Someone ought to "wrap" the Lead Architect across the nogen a few times.
Admin
100 points to you for using the word "cahones."
:-j
Admin
Wouldn't it be a rapper for the wrapper's wrapper?
Admin
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.
Admin
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?
Admin
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!
Admin
We need to wrap the rapper in a wrapper to stop him from rapping.
Admin
A big mediocre WTF?
Admin
Admin
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.
Admin
Darn too, just when I was about to add that this need more XML as well.
Don't fear the reaper ;-)
Admin
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.....
Admin
Reading some of these posts ("..I once workedon a project..."), it sounds like one big WHINE.
{sorry, I had to}
Admin
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?
Admin
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.
Admin
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?
Admin
-200 points for misspelling "cojones"
Admin
and 200 to dasmb for using "garden of pure ideology".
Admin
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
Admin
How old school. This one should have been titled "Wrapper's Delight".
P.S. It's "cojones", people.
Admin
Or "Wrapshody"...
Admin
Depends on how late 90's it was. STLPort may have worked at the time.
Admin
In "Tex-Mex" or "Spanglish", "cohones" is also acceptable.
Admin
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.
Admin
Coooool! Actually, both are good, but "Wrapshody" is sublime.
Admin
No, it's called a money shot.
Admin
Argghh, it didn't quote. Let me try again.
"No, it's called a money shot."
Admin
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
Admin
> 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.
Admin
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...
Admin
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.
Admin
'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.
Admin
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.
Admin
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
Admin
And when the Mac API call you wanted wasn't emulated for QTW, what do you do?
Start an astroturf campaign to get some esoteric feature included in the next version, to /force/ Apple to implement the call!
Admin
ParkinT is a code poet.
Admin
Surely you meant:
Don't fear the rapper!
The rapper in the wrapper is going to need a wrap to rap about the wrapper's wrapper