Comment On Wrapping Fever

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

This seems very familliar, is this a former sidebar?

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

// This might be difficult to port to another platform

 

All they need is a wrapper for their wrapper. 

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.

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

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?

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.

 

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. 

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. 

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.
 

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

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.

Faced with the challenges of making my own toolkit, or using a tremulous one, I'd probably write my own.

Hopefully, I would have abstracted better.
 

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

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.

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

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

 

:-j

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?  

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.

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?

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!

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

 

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?

 

// This might be difficult to port to another platform

He can use Wine, maybe.

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.
 

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

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

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}

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?
 

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.

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? 

-200 points for misspelling "cojones"  

Anonymous:

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

 

:-j

 

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

 

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
 

 

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

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

Anonymous:

-200 points for misspelling "cojones"  

Dang, and I even consulted the Urban Dictionary ( http://www.urbandictionary.com/define.php?term=cahones ). Well, I'm in the negative on points now.
 

cconroy:

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

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

Or "Wrapshody"...
 

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.

Looking for definitions in Urban Dictionary is a WTF in and of itself.
There's too much of stuff like this for it to actually be useful (though, to be fair, that particular entry was created as a parody of all the others like it).

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. 

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. 

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. 

No, it's called a money shot.

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

// This might be difficult to port to another platform

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

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

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. 
 

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

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.

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