• (cs)

    There was a company called Bristol in those days which had a pretty good MFC implementation for Unix et al. They still have it..

     http://www.bristol.com/windu/ 

    Sometimes our technology choices are limited by the amount of R&D we do. And in those old ages google wasn't there to answer all the questions of life.

     

  • ben (unregistered)

    My porting wtf story goes the other way around: In the early-mid 90s I worked for a very small company (3 programmers) that wrote a vertical market niche application, which ran on a  combination of OS/2, and DOS boxes in the OS/2 environment. I was slowly porting/rewriting the application from DOS->OS/2. I knew from the start that it was likely sometime in future we'd have to port to windows, so I tried as much as possible to structure my code into a OS/2 dependent layer (~300kB of code) and Application code (~2.5 meg of code), which ran on top of it. The OS/2 dependent code was all written to the OS/2 PM API which was roughly equivilent to the Win32 API. Apart from the use of some OS/2 specific controls, I figured the port to windows would be fairly straight forward. The application code was structured in a naive form of MFC-alike C++ code. I was learning as I went and made the usual newb C++ mistakes.

    Eventually the small company ran out of money and got purchased by another small company from the US, who shipped us all over to Texas. Sometime later it was decided the  port needed to happen, as OS/2 was dying and had no future. So they hired a "hot shot, twin PhDs in Maths and Physics, windows programmer" to do it, because I didn't know Windows programming and was completely overloaded with the application code I was writing. The hotshot windows programmer took one look at my 300kB of os/2 layer code, and said there no way it was possible to rewite it in Win32, and the only possiblity for the port to happen would be if he wrote a windows layer under my os/2 layer. I argued this wasn't so, that the os/2 layer should be replaced with a win32 equivilent, but because I was the foreign kid, with no formal qualifications, management listened to the hotshot win programmer over me.

    After about 6 months of porting with no recognizable progress it emerged he was attempting to write his windows layer using MFC. So the code would be structured as OS/2 C++ code ontop of OS/2 PM wrapper ontop of Win32-alike functions ontop of MFC. When I discovered that, I knew there was no hope and left shortly after. He never produced anything that ever got out of the dev lab, and the company supposedly burnt thru $20 million trying to make a windows product.

    Almost 10 years later I'm still in contact with couple of the customers of the product. They're still using it as nothing in the market comes close. They're rolling out new installations at new sites all the time and are struggling with getting OS/2 running on modern hardware, and looking at moving to eComstation, and asking me to help them. *sigh*
     

  • (cs) in reply to ben
    Anonymous:

    Almost 10 years later I'm still in contact with couple of the customers of the product. They're still using it as nothing in the market comes close. They're rolling out new installations at new sites all the time and are struggling with getting OS/2 running on modern hardware, and looking at moving to eComstation, and asking me to help them. *sigh*
     

     

    How well does OS/2 run in a VM?

     

  • Kirit (unregistered) in reply to exussum
    Anonymous:

    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.

    I think there were 31 constructors for the object, not a constructor that takes 31 parameters. 

     
     Why in the effing world would any architect (i dont  care how incompitent they are)  choose to build a platform independent application in anything besides Java (im sure java was around then, version 1.2 actually). Moreover, MFC???.... This is a brilliant WTF, and truly personifies the sentiment of WTF. If Alex submitted just a one sentence article saying :

    Roman worked for a company trying to make a platform independent product using C++/MFC.
     

    It would take nothing away from the WTFing-ness of the story
  • csrster (unregistered) in reply to Steve-o

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

     

    ... or the face to punch him in the cojones? 

  • ben (unregistered) in reply to emurphy

    emurphy:
    How well does OS/2 run in a VM?

    They've been trying this, I'm not totally sure of the results. I think they might have hit a wall trying to get OS/2's virtualization of DOS sessions working in a VM.

  • Roman (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.

     

    Nah, they werent in any way sophisticated, not even the bad one, they would just access typical Windows settings vie the wrapped registry access, hence the comment "it will be difficult..." :-)

    -Roman

  • maht (unregistered) in reply to Kirit

    Yeah, use java like Apache, Postgresql, mysql, firefox & opera all do

     

  • Fowl (unregistered) in reply to maht

    None of those are java...

  • (cs)

    For my final year project at uni I had to write a cross platform app which absolutely had to work on Linux and Windows.  I looked into a few cross platform api's including wxWidgets but in the end decided to use Kylix from Borland.  It was an interesting idea to say the least.  You have one Kylix IDE for Windows and then another for Linux.  Your projects are instantly portable between the two, I just had a shared drive and worked on it there.  I think Kylix would be bottom of my list if I had to redo that project now, talk about a nightmare project....

    its sooo true what someone else wrote about how the millions wasted on Romans project would of been better spent on one of the more established projects like wxWidgets and Qt.

  • Zlodo (unregistered) in reply to exussum

    MFC is awful to use even on its intended platform. It somehow manages to suck everything good out of C++ (example: not actually initializing stuff in constructors).

    Trying to turn it into a cross platform API is a completly retarded idea.

    This is really definitely a WTF.
     

  • (cs) in reply to Steve-o
    Anonymous:
    300 developers and not one of them had the cahones to punch the C++/MFC zealot in the face?

    Ahh. You don't know the formula for the intellegence of a group of people greater than 1, have you?

    It is (Brightest person) ^ -1/(total amount of people).

    ^ = base exponential index

    Most people would go, i've got a well paying job, i like the doughnuts, and there are 299 other people. Surely one of them will stand up and ... ?

  • coz (unregistered)

     Super solution :

    - on Windows (native platform) : use application

     - on Linux/Mac/Unix/...:

              1. install VmWare

              2. install windows in VMware

              3. use application on windows image...

    Simple, no? 

     

  • Zlodo (unregistered) in reply to Steve-o

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

    C++ enthusiast with a functional brain, MFC enthusiast: you can only be one of these things. Both is a physical impossibility.

    Don't drag down C++ with that MFC crap. 

    MFC is not C++. MFC is a grotesque parody of C++ programming. The whole design of that thing yells "I didn't get how the language works, but I'm going to create a toolkit with it nonetheless, because I'm Microsoft and I Know Better than everyone else".

    Im maintaining a MFC app at work. Every day. So I hope no one won't try a "I used MFC once a long time ago and I don't remember that it sucked" rebuttal on me.

  • (cs) in reply to R
    Anonymous:

    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

    Yes and no, Qt's first public release (Qt 0.90) was released in May 1995.

    Anonymous:

    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.

    Wikipedia sez Qt 3.0, in 2001.

    Anonymous:
    None of those are java...

    I'm pretty sure that kind-of was his point...

    Anonymous:

    MFC is not C++. MFC is a grotesque parody of C++ programming.

    Wouldn't that yield that MFC is a parody of a parody of programming?

  • (cs) in reply to Kirit
    Anonymous:

    Why in the effing world would any architect (i dont  care how incompitent they are)  choose to build a platform independent application in anything besides Java (im sure java was around then, version 1.2 actually).

    Because it needed to be fast.  Or they wanted a native look and feel to the application.  I think only recently have Java UI's stopped being very obviously different from anything else running on a machine.

  • 4tehwin!!! (unregistered)

    that's a dirty system.....

     *drumroll*

     better double-wrap it

    *rimshot*

  • Onion (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.

     

     I will not be that quick to suggest an XML file can be a good replacement of Registry. Registry is a single writer multiple readers data source of high robustness & high availability.

     I know of one project attempting this without a singleton server and failed badly.

     

  • Zlodo (unregistered) in reply to masklinn
    masklinn:

    Wouldn't that yield that MFC is a parody of a parody of programming?

    I see what you did there, but I'm not going to get drawn into a C++ versus Java flamewar today, sorry :p

  • Zlodo (unregistered) in reply to Onion
    Anonymous:
    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.

     

     I will not be that quick to suggest an XML file can be a good replacement of Registry. Registry is a single writer multiple readers data source of high robustness & high availability.

     I know of one project attempting this without a singleton server and failed badly.

     

    And most importantly, the registry is a system that needs to access data randomly among a large data set. This is something for which XML is totally inadequate.

    Of course, the WTF here is that they built, just for the registry, a specific single writer, multiple reader data source of high availability with random access capabilities, instead of using the fucking filesystem, which already does all that.

    Of course, back in windows 95, their filesystem sucked and wasn't able to store small files directly in directory tables, but maybe they should have focused some of this awesomeness they always claim to have when it comes to development on making a proper file system instead of the registry thing.

  • Duff (unregistered) in reply to tster
    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.

    No, those *aren't* the only options.

    Write the functionality in a way that makes sense for your environment and the software you're trying to integrate with. If you need it again somewhere else, refactor.

    "A way that makes sense for your environment" will very frequently be a reusable object -- but if it isn't, reusability can and *should* take a back seat to fitting in well with the program the functionality is being developed for. Moreover, an API developed with one specific program in mind frequently won't work well elsewhere --- which is all the more reason to expect an eventual refactor up-front.

  • anonymous (unregistered) in reply to Zlodo
    Anonymous:
    Anonymous:
    I will not be that quick to suggest an XML file can be a good replacement of Registry. Registry is a single writer multiple readers data source of high robustness & high availability.

     I know of one project attempting this without a singleton server and failed badly

    And most importantly, the registry is a system that needs to access data randomly among a large data set. This is something for which XML is totally inadequate.

    Of course, the WTF here is that they built, just for the registry, a specific single writer, multiple reader data source of high availability with random access capabilities, instead of using the fucking filesystem, which already does all that.

    Of course, back in windows 95, their filesystem sucked and wasn't able to store small files directly in directory tables, but maybe they should have focused some of this awesomeness they always claim to have when it comes to development on making a proper file system instead of the registry thing.

     
    *cough*/.gconf/desktop/gnome/file_views/%gconf.xml*cough*

     

  • (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. 
     
    And a $1000 boom-box might help...
     
    <ducking> 
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to IceJetser
            
            
    
                
     Anonymous:
    100 points to you for using the word "cahones."
     
    :-j
     
    Too bad. He would have gotten 250 if he'd used the proper ethnic spelling of "cajones" 
    
            
    
        
    • 
        
  • 
 Zlodo   (unregistered)                                         in reply to anonymous
            
            
    
                
     Anonymous:
    *cough*/.gconf/desktop/gnome/file_views/%gconf.xml*cough*
    The discussion strayed toward "replacing the whole registry" somehow, for which a pure xml solution wouldn't make sense. In your example, the heavy lift when it comes to locating the configuration for file_views among all the exitising configuration files is done by the filesystem, not xml. xml then only has a small amount of data to process in that file, for which it's not inadequate, just mediocre (yes, I'm trolling. Yay)
    
            
    
        
    • 
        
  • 
 Say What?   (unregistered)                                         in reply to anonymous
            
            
    
                
    In 1995-6, we needed to build an application and have it run on PC's and Solaris, but only wanted one codebase. We were using C++ and a cross platform GUI library written in C++: Galaxy. You basically used a Galaxy_xxx widget for every conceivable GUI object, and then just compiled and linked on the target platform using the platform-specific version of the Galaxy GUI library. It was a good idea, but it never really worked right. Then Java came along with 'platform portability' and killed it (Galaxy).
    
            
    
        
    • 
        
  • 
 Aussie Pete   (unregistered)                                         in reply to Kirit
            
            
    
                
     Anonymous:
    Why in the effing world would any architect (i dont  care how incompitent they are)  choose to build a platform independent application in anything besides Java (im sure java was around then, version 1.2 actually).
    

    Because Tcl/Tk is faster, mostly cross-platform, can be deployed in a 'starpack' executible without relying on an external runtime environment, can store its libraries in an internal VFS to the binary application, and the Tile library gives Tcl/Tk access to attractive, native platform widgets?
    (Well, you did ask... Java's not the only cross-platform language around, you know.)
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
     Alex Papadimoulis:
    ...one of the main design goals was to make the product platform independent. They also decided to use C++/MFC.
    That's like the worst library to pick to make a platform independent library. MFC is known to be a very thin layer over Win32 and it only purpose is to make Win32 object oriented and C++ friendly. Anything using MFC will be Win32 dependent. I wonder if MFC was really the library being wrapped or if that is just Alex anonymizing the story.
    
            
    
        
    • 
        
  • 
 Zlodo   (unregistered)                                         in reply to Aussie Pete
            
            
    
                
     Anonymous:
     Anonymous:
    Why in the effing world would any architect (i dont  care how incompitent they are)  choose to build a platform independent application in anything besides Java (im sure java was around then, version 1.2 actually).
    

    Because Tcl/Tk is faster, mostly cross-platform, can be deployed in a 'starpack' executible without relying on an external runtime environment, can store its libraries in an internal VFS to the binary application, and the Tile library gives Tcl/Tk access to attractive, native platform widgets?
    (Well, you did ask... Java's not the only cross-platform language around, you know.)
     
    C++ is cross platform, too. There aren't really many situations where it is useful to have portability at runtime. Portability at compilation time is also perfectly fine, provided that you don't choose retarded middlewares like MFC and go for something that is actually good like Qt. 
    
            
    
        
    • 
        
  • 
 The Captain Answers   (unregistered)                                         in reply to Anon E Moose
            
            
    
                
     Anonymous:
     
    We need to wrap the rapper in a wrapper to stop him from rapping.
     
    I agree.  Then he would no longer be able to publicly expose his interface.
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    Wrappers.  Pffft.  Now if they'd have used Adaptors everything would have been fine.


    
            
    
        
    • 
        
  • 
 The Captain Answers   (unregistered)                                         in reply to MitchW
            
            
    
                
     Anonymous:
     
    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 
     
    Ouch.
    
            
    
        
    • 
        
  • 
 eric   (unregistered)                                         in reply to Fowl
            
            
    
                
     Anonymous:

    Why in the effing world would any architect choose to build a platform independent application in anything besides Java


    that is an absurd thing to say.

     Anonymous:

    Yeah, use java like Apache, Postgresql, mysql, firefox & opera all do


    thank you.

     Anonymous:

    None of those are java...


    no shit.

    captcha: sphinctastic
            
    
        
    • 
        
  • 
 kbiel   (unregistered)                                         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. 
     
    No, no, no.  It's obvious!  They need to write a registry system for all non-windows platforms.  That would be brillant.
     
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to kbiel
            
            
    
                
     Anonymous:
     R.Flowers:
    // This might be difficult to port to another platform
     
    All they need is a wrapper for their wrapper. 
     
    No, no, no.  It's obvious!  They need to write a registry system for all non-windows platforms.  That would be brillant.
     
     
    Coder, please. All they gots to do is get some star power up in the hizzie and crank on the code with the Jolt all night long. They be droppin' Registries like it's they birthday.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to WIldpeaks
            
            
    
                
     WIldpeaks:
     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 ;-)
    More cowbell!
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to JustThat
            
            
    
                
     JustThat:
     Anonymous:
     
    100 points to you for using the word "cahones."
     
    :-j
     
    Too bad. He would have gotten 250 if he'd used the proper ethnic spelling of "cajones" 
    It's "cojones".  "cajones" means "wooden box drums" or "[furniture] drawers", according to Wikipedia.
    
            
    
        
    • 
        
  • 
 _dandy_   (unregistered)                                     
            
    
                
    Not much of a WTF in an of itself, if planned carefully.  Back in the 90's, I wrote a Win16 app (just a simple dialog box to collect information from a user in a user-friendly fashion).  Initially it targetted only Win16, so I wrote the app in MFC (the reasoning being that it's way easier to create a Windows UI in C++ with MFC than the straight C API).
    Couple of years later it was decided that this app should be ported to Win32 and OS/2 (OS/2 was still relevant enough at that point that TPTB decided it was worth the investment).
    The UI's "top-layer" (control manipulation, etc) simply interacted with the high-level MFC components--porting to Win32 wasn't much of a problem, and on the OS/2 side, I wrote a smallish MFC wrapper around the native OS/2 controls--I could instantiate CButtons, CWnds, CListBox, CEdit, etc.  The top layer code didn't have to change at all; I just had to drop in the pseudo-MFC library to act as an intermediary between the program and the native controls.
    Someone then had the bright idea to backport the app to DOS (text mode) as well.  Obviously that took longer.  Again, the UI's top layer didn't have to change, other than to dynamically build the layout since there's no such thing as a resource editor (or an edit control or anything else like that for that matter) on DOS.  But I did have a text mode CButton, CListBox, etc that I could manipulate with the same member functions.
    But yeah, a text-mode DOS UI was pushing it.  :-)  OTOH I thought my implementation looked better than Borland's at the time.
    
            
    
        
    • 
        
  • 
 Homer   (unregistered)                                         in reply to IceJetser
            
            
    
                
    Imagine being the poor bastard who had to maintain that shit?  Imagine tracking down the lead and whacking him in the balls with a baseball bat...
    
            
    
        
    • 
        
  • 
 mjk   (unregistered)                                         in reply to Kazan
            
            
    
                
    What's funny is that wxWidgets does in fact wrap the registry: http://www.wxwidgets.org/manuals/2.6.3/wx_wxconfigbase.html#wxconfigbase
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to mjk
            
            
    
                
    You would think, back in the 90s (and really, still today), someone designing a speech processing application would be satisfied if he could just make something that worked.  Who cares about cross platform whatever?  
    
            
    
        
    • 
        
  • 
 kibbled_bits   (unregistered)                                     
            
    
                
    You idiot, MFC stands for Microsoft Foundation Classes.  This project was never intended to be platform independent.  Why not put the blame on M$ instead of platform independence.
    :-) 
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to kibbled_bits
            
            
    
                
    The wrapper around MFC was existed specifically to make it platform independent. 
    Whether it was intended to actually work or not, that was it's reason for being.
    Dumbass.
    
            
    
        
    • 
        
  • 
 Steamer25   (unregistered)                                         in reply to Anonymous
            
            
    
                
     Anonymous:
    This seems very familliar, is this a former sidebar?
     
    Sounds a lot like this story: http://thedailywtf.com/forums/thread/85510.aspx
    CAPTCHA: whiskey -- big pimpin'
    
            
    
        
    • 
        
  • 
 Kim   (unregistered)                                         in reply to dasmb
            
            
    
                
     Anonymous:
     
    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.
    Since Trolltech (the company behind QT) was founded in 1994 and they sold their first license in 1996, they had at least one alternative.
    
            
    
        
    • 
        
  • 
 Zigmar   (unregistered)                                         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. 


    "Every software problem can be solved by adding additional abstraction layer, besides the problem of having too many abstraction layers"
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to emurphy
            
            
    
                
    Is a metric buttload larger than an Imperial short buttload, and smaller than an Imperial long buttload, as is the case with other measurements?
     
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to IceJetser
            
            
    
                
    You think he might have meant cajones?
    
            
    
        
    • 
        
  • 
 cbciv   (unregistered)                                         in reply to IceJetser
            
            
    
                
    100 points to you for using the word "cahones."
    

    -100 points for both of you for misspelling "cojones". 
    
            
    
        
    • 
        
  • 
 john   (unregistered)                                     
            
    
                
    There were a lot of crossplatform solutions back in the late 90s.  They didn't give you MFC, but they did cover the rudimentary GUI stuff.  Most of them, however, were just Mac/Windows or Unix/Windows or some other permutation of Motif, Mac, Windows, etc.
    
            
    
        
    • 
    


            


            
  • 



            


                

                
Leave a comment on “Wrapping Fever”


                
Log In or post as a guest


                
                
Replying to comment #:


                

                    
                    Log Out
                


                

                    
                


                





                

                    
                


            


            
« Return to Article