Visual C++: the need for MFC

Discussion in 'C++' started by Man-wai Chang ToDie (33.6k), Jun 14, 2008.

  1. Is it possible to build a Visual C++ GUI program without using MFC,
    using VC++ 2008 Express Edition?

    Forget about the time and speed issue.

    --
    @~@ Might, Courage, Vision, SINCERITY.
    / v \ Simplicity is Beauty! May the Force and Farce be with you!
    /( _ )\ (Xubuntu 8.04) Linux 2.6.25.6
    ^ ^ 20:42:01 up 2 days 10:36 2 users load average: 1.08 1.14 1.06
    ? ? (CSSA):
    http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/
     
    Man-wai Chang ToDie (33.6k), Jun 14, 2008
    #1
    1. Advertising

  2. On Jun 14, 1:44 pm, "Man-wai Chang ToDie (33.6k)"
    <> wrote:

    > Is it possible to build a Visual C++ GUI program without using MFC,
    > using VC++ 2008 Express Edition?
    >
    > Forget about the time and speed issue.


    yes. For details ask in a microsoft ng.
    eg. comp.os.ms-windows.programmer.win32


    -- Nick Keighley
     
    Nick Keighley, Jun 14, 2008
    #2
    1. Advertising

  3. Man-wai Chang ToDie (33.6k)

    Linonut Guest

    * Man-wai Chang ToDie (33.6k) peremptorily fired off this memo:

    > Is it possible to build a Visual C++ GUI program without using MFC,
    > using VC++ 2008 Express Edition?


    Pick a cross-platform framework such as FLTK, wxWidgets, Qt, gtk++, or
    others, and use that for developing a GUI.

    You might see if there some open-source projects already out there that
    work on Windows, to get a good code example.

    --
    When we have the information highway, I'll put it [information about
    himself] out there. Everybody who wants to pay, I don't know, one cent, can
    see what movies I'm watching and what books I'm reading and certain other
    information. If I'm still interesting, I'll rack up dollars as people
    access that part of the highway.
    -- Bill Gates, Interview in Playboy magazine (1994)
     
    Linonut, Jun 14, 2008
    #3
  4. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Man-wai Chang ToDie (33.6k) wrote:
    >
    > Is it possible to build a Visual C++ GUI program without using MFC,
    > using VC++ 2008 Express Edition?
    >
    > Forget about the time and speed issue.
    >


    Well, the "wizard" of the lcc-win compiler generates
    a skeleton for a GUI application complete with menu/main loop
    window class registering/opening, etc with just a few clicks.

    The output language is just C (NOT C++) so there is surely
    no MFC involved.

    You can download the lcc-win C compiler at no charge from
    the address below.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 14, 2008
    #4
  5. Man-wai Chang ToDie (33.6k) wrote:
    >
    > Is it possible to build a Visual C++ GUI program without using MFC,
    > using VC++ 2008 Express Edition?


    You can avoid using MFC by using the Win32 API directly, but you
    *really* don't want to do that, believe me. Even creating the simplest
    of dialogs using the Win32 API is a nightmare.

    If you don't mind using alternative libraries, consider WTL or some of
    the portable ones (such as wxwidgets).
     
    Juha Nieminen, Jun 15, 2008
    #5
  6. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Juha Nieminen wrote:
    > Man-wai Chang ToDie (33.6k) wrote:
    >> Is it possible to build a Visual C++ GUI program without using MFC,
    >> using VC++ 2008 Express Edition?

    >
    > You can avoid using MFC by using the Win32 API directly, but you
    > *really* don't want to do that, believe me. Even creating the simplest
    > of dialogs using the Win32 API is a nightmare.
    >


    No, it is fairly easy, and you get used to it fairly quickly.

    This horror story has been repeated at will by people that want to
    promote this or that library.

    I always use C for my dialogs. Suppose a dialog that asks for a number,
    with two OK Cancel buttons.

    The minimal code to handle that dialog is:
    INT_PTR CALLBACK AskALine(HWND hDlg,MSGTYPE message,WPARAM wParam,LPARAM
    lParam)
    {
    int i, c, line;
    HWND hCB;
    char tmpbuf[10];
    switch (message) {
    case WM_COMMAND:
    switch (GETIDFROMWPARAM(wParam)) {
    case IDOK:
    GetDlgItemText(hDlg,IDGOTOLINENR, tmpbuf, 9);
    if (!ValidateInteger(tmpbuf, &line))
    return 1;
    if (l <= 0)
    break;
    EndDialog(hDlg,line);
    return 1;
    }
    }
    return (HandleDefaultMessages(hDlg, message, wParam, lParam));
    }

    That is all. True, the "HandleDefaultMessages" procedure will
    be a more complex one, but essentially that is ALL the code
    you will want to write. And guess what?

    That code was written for windows 3.1. And that code performs
    perfectly under windows Vista 64 bits. It was "ported" from
    16 bits to 32, and from 32 to 64. And it does NOT need anything
    more than EXACTLY what you need.

    But obviously I am wrong. Keeping it simple is no longer a
    good strategy nowadays.

    > If you don't mind using alternative libraries, consider WTL or some of
    > the portable ones (such as wxwidgets).



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 15, 2008
    #6
  7. jacob navia wrote:
    > I always use C for my dialogs. Suppose a dialog that asks for a number,
    > with two OK Cancel buttons.
    >
    > The minimal code to handle that dialog is:
    > INT_PTR CALLBACK AskALine(HWND hDlg,MSGTYPE message,WPARAM wParam,LPARAM
    > lParam)
    > {
    > int i, c, line;
    > HWND hCB;
    > char tmpbuf[10];
    > switch (message) {
    > case WM_COMMAND:
    > switch (GETIDFROMWPARAM(wParam)) {
    > case IDOK:
    > GetDlgItemText(hDlg,IDGOTOLINENR, tmpbuf, 9);
    > if (!ValidateInteger(tmpbuf, &line))
    > return 1;
    > if (l <= 0)
    > break;
    > EndDialog(hDlg,line);
    > return 1;
    > }
    > }
    > return (HandleDefaultMessages(hDlg, message, wParam, lParam));
    > }


    I fail to see where is it that you define the actual contents of the
    dialog: Title bar text, dialog text and its location, a textfield (or
    similar, to ask for the number) and its geometry, the amount and
    contents of the buttons...

    The only thing I see there is a callback function which handles
    signals received by something.

    Note that we are talking about Visual Studio Express here: AFAIK it
    doesn't have fancy graphical window design editors. If you want to
    create a new window type using the Win32 API, you'll have to write it
    completely by hand. And, AFAIK, this is a real nightmare.
     
    Juha Nieminen, Jun 15, 2008
    #7
  8. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Juha Nieminen wrote:
    > jacob navia wrote:
    >> I always use C for my dialogs. Suppose a dialog that asks for a number,
    >> with two OK Cancel buttons.
    >>
    >> The minimal code to handle that dialog is:
    >> INT_PTR CALLBACK AskALine(HWND hDlg,MSGTYPE message,WPARAM wParam,LPARAM
    >> lParam)
    >> {
    >> int i, c, line;
    >> HWND hCB;
    >> char tmpbuf[10];
    >> switch (message) {
    >> case WM_COMMAND:
    >> switch (GETIDFROMWPARAM(wParam)) {
    >> case IDOK:
    >> GetDlgItemText(hDlg,IDGOTOLINENR, tmpbuf, 9);
    >> if (!ValidateInteger(tmpbuf, &line))
    >> return 1;
    >> if (l <= 0)
    >> break;
    >> EndDialog(hDlg,line);
    >> return 1;
    >> }
    >> }
    >> return (HandleDefaultMessages(hDlg, message, wParam, lParam));
    >> }

    >
    > I fail to see where is it that you define the actual contents of the
    > dialog: Title bar text, dialog text and its location, a textfield (or
    > similar, to ask for the number) and its geometry, the amount and
    > contents of the buttons...
    >
    > The only thing I see there is a callback function which handles
    > signals received by something.
    >
    > Note that we are talking about Visual Studio Express here: AFAIK it
    > doesn't have fancy graphical window design editors. If you want to
    > create a new window type using the Win32 API, you'll have to write it
    > completely by hand. And, AFAIK, this is a real nightmare.



    Obviously you need a resource editor that generates the dialog template
    for you.

    Such an editor is present in the compiler system

    lcc-win

    or in many other compilers.

    To do a simple dialog like the one I described you need
    around 10 clicks of the mouse and it is all done.

    You can download lcc-win at the URL below


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 15, 2008
    #8
  9. OT: Visual C++: the need for MFC

    On 15 Jun, 13:23, jacob navia <> wrote:
    > Juha Nieminen wrote:
    > > Man-wai Chang ToDie (33.6k) wrote:


    > >> Is it possible to build a Visual C++ GUI program without using MFC,
    > >> using VC++ 2008 Express Edition?

    >
    > >   You can avoid using MFC by using the Win32 API directly, but you
    > > *really* don't want to do that, believe me. Even creating the simplest
    > > of dialogs using the Win32 API is a nightmare.

    >
    > No, it is fairly easy, and you get used to it fairly quickly.
    >
    > This horror story has been repeated at will by people that want to
    > promote this or that library.


    Jocob is correct. Writing applications using in32 is not particularly
    difficult.


    --
    Nick Keighley
     
    Nick Keighley, Jun 16, 2008
    #9
  10. Man-wai Chang ToDie (33.6k)

    Jerry Coffin Guest

    Re: OT: Visual C++: the need for MFC

    In article <d6ac9a2d-fce0-4d88-bd8f-21fbae48d780
    @m3g2000hsc.googlegroups.com>, says...

    [ ... ]

    > Jocob is correct. Writing applications using in32 is not particularly
    > difficult.


    It isn't _particularly_ difficult, that's true.

    OTOH, using the raw API, you have about 50 lines of code to register a
    window class, create a window and make it visible. You have another 30-
    40 lines for even an extremely minimal message processor. You have
    another 25 lines for a message loop plus calling the above. If you want
    an MDI application, roughly double all of those (i.e. you have to
    register an extra window class, create not just two but three windows,
    be ready to respond to messages to do things like cascade and tile the
    child windows, etc.)

    For beginners, this is rather intimidating: they have to write a couple
    of hundred lines of code (or so) just to get to the point of a bare
    minimum program that doesn't really even DO anything yet -- it just
    creates an empty window that you can resize, minimize, maximize, etc.

    For experienced programmers, it's no longer intimidating, but it is
    repetitive and boring. Nearly the only reasonable alternative is to use
    a library of one sort or another -- if you don't use a conventional
    library of object code, then you use a "library" of source code from
    which to cut and paste chunks of code to avoid retyping the same junk
    over and over and over again.

    The bottom line is that for most people's programs most of the time,
    writing to the raw Win32 API is a pointless waste of time.

    We now return you to your regularly scheduled (but topical) flaming...

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jun 16, 2008
    #10
  11. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Re: OT: Visual C++: the need for MFC

    Jerry Coffin wrote:
    > In article <d6ac9a2d-fce0-4d88-bd8f-21fbae48d780
    > @m3g2000hsc.googlegroups.com>, says...
    >
    > [ ... ]
    >
    >> Jocob is correct. Writing applications using in32 is not particularly
    >> difficult.

    >
    > It isn't _particularly_ difficult, that's true.
    >
    > OTOH, using the raw API, you have about 50 lines of code to register a
    > window class, create a window and make it visible. You have another 30-
    > 40 lines for even an extremely minimal message processor. You have
    > another 25 lines for a message loop plus calling the above. If you want
    > an MDI application, roughly double all of those (i.e. you have to
    > register an extra window class, create not just two but three windows,
    > be ready to respond to messages to do things like cascade and tile the
    > child windows, etc.)
    >
    > For beginners, this is rather intimidating: they have to write a couple
    > of hundred lines of code (or so) just to get to the point of a bare
    > minimum program that doesn't really even DO anything yet -- it just
    > creates an empty window that you can resize, minimize, maximize, etc.
    >
    > For experienced programmers, it's no longer intimidating, but it is
    > repetitive and boring. Nearly the only reasonable alternative is to use
    > a library of one sort or another -- if you don't use a conventional
    > library of object code, then you use a "library" of source code from
    > which to cut and paste chunks of code to avoid retyping the same junk
    > over and over and over again.
    >


    If you use lcc-win you just start the "wizard", check a few
    checkboxes and all that is generated for you.

    MDI applications are also generated. You have nothing to do but
    fill the blanks.

    The generated code is just straight C/Win API. It will compile
    in all windows compilers. You are NOT forced to use lcc-win
    afterwards!

    > The bottom line is that for most people's programs most of the time,
    > writing to the raw Win32 API is a pointless waste of time.
    >


    You gain all that time with the extra features that NO OTHER LIBRARY
    can ever offer:

    1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
    stable, and will not disappear any time soon. You can even run your
    programs uder linux or solaris using the windows emulator "wine".


    2: Speed. There isn't any time consuming layer of code between you
    and the API.

    3: Simplicity. If the library forgot to give you the feature "xxx" you
    are dead. Using the windows API you get ALL features you have
    available.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 16, 2008
    #11
  12. Re: OT: Visual C++: the need for MFC

    jacob navia wrote:
    > 3: Simplicity.


    This one made me ROTFL.
     
    Juha Nieminen, Jun 16, 2008
    #12
  13. Man-wai Chang ToDie (33.6k)

    Jerry Coffin Guest

    Re: OT: Visual C++: the need for MFC

    In article <g35unk$mdf$>, says...

    [ ... ]

    > If you use lcc-win you just start the "wizard", check a few
    > checkboxes and all that is generated for you.


    Of course -- but if you're using Wizard-generated code, you might as
    well also save recompiling those bits along with the code you care
    about, and pull those pieces from a library instead.

    > MDI applications are also generated. You have nothing to do but
    > fill the blanks.


    Yippie.

    > The generated code is just straight C/Win API. It will compile
    > in all windows compilers. You are NOT forced to use lcc-win
    > afterwards!


    Oooh! I can certainly see how "it does the same thing as everybody else,
    but 15 years later" qualifies for an exclamation point.

    > > The bottom line is that for most people's programs most of the time,
    > > writing to the raw Win32 API is a pointless waste of time.
    > >

    >
    > You gain all that time with the extra features that NO OTHER LIBRARY
    > can ever offer:


    What a bunch of BS.

    > 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
    > stable, and will not disappear any time soon. You can even run your
    > programs uder linux or solaris using the windows emulator "wine".


    MFC (for one obvious example) has been sufficiently stable that I have
    code originally written for 16-bit Windows that works, unmodified,
    beautifully under both 32-bit and 64-bit Windows.

    Of course, if WINE meets its goals, it should allow essentially all
    Windows programs to run under any system that can host WINE -- whether
    it uses other libraries or not.

    > 2: Speed. There isn't any time consuming layer of code between you
    > and the API.


    What makes you think that code generated by your Wizard will be any
    faster than the same code if it was in a library instead?

    > 3: Simplicity. If the library forgot to give you the feature "xxx" you
    > are dead. Using the windows API you get ALL features you have
    > available.


    Complete nonsense from beginning to end. Using a library does not
    restrict you from using the API directly when/if you want to do
    something the library doesn't support directly.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jun 16, 2008
    #13
  14. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Re: OT: Visual C++: the need for MFC

    Jerry Coffin wrote:
    > In article <g35unk$mdf$>, says...
    >
    > [ ... ]
    >
    >> If you use lcc-win you just start the "wizard", check a few
    >> checkboxes and all that is generated for you.

    >
    > Of course -- but if you're using Wizard-generated code, you might as
    > well also save recompiling those bits along with the code you care
    > about, and pull those pieces from a library instead.
    >
    >> MDI applications are also generated. You have nothing to do but
    >> fill the blanks.

    >
    > Yippie.
    >
    >> The generated code is just straight C/Win API. It will compile
    >> in all windows compilers. You are NOT forced to use lcc-win
    >> afterwards!

    >
    > Oooh! I can certainly see how "it does the same thing as everybody else,
    > but 15 years later" qualifies for an exclamation point.
    >


    Yes, this is nothing new. Obviously when something works, and
    works well, the fact that has worked well for 15 years is a flaw.
    It must be thrown away and replaced with the latest fad immediately.

    >>> The bottom line is that for most people's programs most of the time,
    >>> writing to the raw Win32 API is a pointless waste of time.
    >>>

    >> You gain all that time with the extra features that NO OTHER LIBRARY
    >> can ever offer:

    >
    > What a bunch of BS.


    That means actually:

    "I disagree with the views of jacob". Apparently you are unable
    to discuss in a less emotional way. Well, who cares.

    >
    >> 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
    >> stable, and will not disappear any time soon. You can even run your
    >> programs uder linux or solaris using the windows emulator "wine".

    >
    > MFC (for one obvious example) has been sufficiently stable that I have
    > code originally written for 16-bit Windows that works, unmodified,
    > beautifully under both 32-bit and 64-bit Windows.
    >


    MFC is obsolete and hasn't been updated for several YEARS now.
    Obviously, the code written using MFC will still work, but you can't use
    all the features that have been added to the API using MFC now.

    Microsoft decided to go the C# way, and all the MOUNTAINS of code
    written using MFC are all obsolete. The MFC which they depend on
    is no longer being developed.

    That shows the problem with using third party libraries very well!

    Either you port the MFC code to using the API (a huge task) or
    you rewrite the applications form scratch, or you use the API for the
    new features, and leave the old code as is...

    Nice alternatives.


    > Of course, if WINE meets its goals, it should allow essentially all
    > Windows programs to run under any system that can host WINE -- whether
    > it uses other libraries or not.
    >
    >> 2: Speed. There isn't any time consuming layer of code between you
    >> and the API.

    >
    > What makes you think that code generated by your Wizard will be any
    > faster than the same code if it was in a library instead?
    >


    Because there is one layer of indirection less than when you call
    the API directly. The library needs to translate the calls you
    do into library code that calls the API anyway.

    Note that we are talking about using the API directly in your
    application. The "wizard" code just gets you started with a
    common boilerplate, it doesn't write the application for you.

    >> 3: Simplicity. If the library forgot to give you the feature "xxx" you
    >> are dead. Using the windows API you get ALL features you have
    >> available.

    >
    > Complete nonsense from beginning to end. Using a library does not
    > restrict you from using the API directly when/if you want to do
    > something the library doesn't support directly.
    >


    Yes, you are right. You have just to learn the library, then
    learn the API anyway. Fine. Go on using MFC then. It is no longer
    developed but who cares?

    Or switch to the Borland library (forgot the name).
    It is no longer being developed.

    Or switch bto one of the COUNTLESS libraries done during the last
    15 years of windows. Most of them are no longer running, forgotten,
    whatever.

    Only those people that used the windows API are now able to develop
    their applications without any problems now!




    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 16, 2008
    #14
  15. Man-wai Chang ToDie (33.6k)

    Jerry Coffin Guest

    Re: OT: Visual C++: the need for MFC

    In article <g36nmh$kfc$>, says...

    [ ... ]

    > > Oooh! I can certainly see how "it does the same thing as everybody else,
    > > but 15 years later" qualifies for an exclamation point.
    > >

    >
    > Yes, this is nothing new. Obviously when something works, and
    > works well, the fact that has worked well for 15 years is a flaw.
    > It must be thrown away and replaced with the latest fad immediately.


    Please read what I said -- I only commented on the exclamation point,
    and specifically its use to emphasize something that's been well known
    and in widespread use for well over a decade.

    > >>> The bottom line is that for most people's programs most of the time,
    > >>> writing to the raw Win32 API is a pointless waste of time.
    > >>>
    > >> You gain all that time with the extra features that NO OTHER LIBRARY
    > >> can ever offer:

    > >
    > > What a bunch of BS.

    >
    > That means actually:
    >
    > "I disagree with the views of jacob". Apparently you are unable
    > to discuss in a less emotional way. Well, who cares.


    Not so -- below I pointed out exactly HOW each point is BS. Worse, your
    reply is based almost entirely on more BS -- specifically, the false
    claim that MFC is no longer in active development.

    > >> 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
    > >> stable, and will not disappear any time soon. You can even run your
    > >> programs uder linux or solaris using the windows emulator "wine".

    > >
    > > MFC (for one obvious example) has been sufficiently stable that I have
    > > code originally written for 16-bit Windows that works, unmodified,
    > > beautifully under both 32-bit and 64-bit Windows.
    > >

    > MFC is obsolete and hasn't been updated for several YEARS now.


    False! It was updated (significantly) for Visual Studio 2008 -- which is
    to say within the last few months (note how I've used the exclamation
    point to emphasize something that clearly is NOT known to many
    developers).

    > Obviously, the code written using MFC will still work, but you can't use
    > all the features that have been added to the API using MFC now.


    I'm not sure about _all_, but then again, I'm pretty sure you can't use
    _all_ the new features from the raw API either -- a fair amount is now
    available only via .NET.

    > Microsoft decided to go the C# way, and all the MOUNTAINS of code
    > written using MFC are all obsolete. The MFC which they depend on
    > is no longer being developed.


    A communist leader once (rather famously) claimed that repeating a
    falsehood (or maybe "lie") often enough could make it true. His theory
    should have died with him, but apparently some aren't willing to let
    even the worst of ideas go.

    > That shows the problem with using third party libraries very well!
    >
    > Either you port the MFC code to using the API (a huge task) or
    > you rewrite the applications form scratch, or you use the API for the
    > new features, and leave the old code as is...
    >
    > Nice alternatives.


    You left out the obvious alternative: continue to use MFC which is still
    undergoing active development, directly contrary to your false claims.

    [ ... ]

    > >> 2: Speed. There isn't any time consuming layer of code between you
    > >> and the API.

    > >
    > > What makes you think that code generated by your Wizard will be any
    > > faster than the same code if it was in a library instead?
    > >

    > Because there is one layer of indirection less than when you call
    > the API directly. The library needs to translate the calls you
    > do into library code that calls the API anyway.


    I suppose if you insist on using an amazingly primitive compiler that
    can't generate calls inline, this could be true. A decent compiler will
    remove this handicap, and make quite a bit of the other code faster as
    well.

    The reality is that the code should be put into functions for the sake
    of organization, and the compiler should take care of trivia like
    whether to actually call it or generate it inline. Yes, if you've really
    verified that the compiler is doing the wrong thing with code that's
    really critical, it can be worthwhile to do some work to get what you
    want -- but it's _incredibly_ unlikely to be the case here --
    registering a window class (for example) isn't usually something you do
    in a tight or deeply nested loop. Quite the contrary, it's something you
    rarely do more than a handful of times even in a reasonably large
    program, and it's slow enough that the difference between calling or
    inlining the function that does it is likely to make a difference in the
    range of parts per million, not something you'd even reasonably measure
    in fractions of a percent.

    > Note that we are talking about using the API directly in your
    > application. The "wizard" code just gets you started with a
    > common boilerplate, it doesn't write the application for you.


    Gee really. Next you're going to tell me that despite the name, it
    really doesn't do any magic or read the user's mind?

    > >> 3: Simplicity. If the library forgot to give you the feature "xxx" you
    > >> are dead. Using the windows API you get ALL features you have
    > >> available.

    > >
    > > Complete nonsense from beginning to end. Using a library does not
    > > restrict you from using the API directly when/if you want to do
    > > something the library doesn't support directly.
    > >

    >
    > Yes, you are right. You have just to learn the library, then
    > learn the API anyway. Fine. Go on using MFC then. It is no longer
    > developed but who cares?


    Repeating the falsehood yet again still hasn't made it true. In any
    case, if you know the API well enough to use it directly, using MFC (for
    one example) is truly trivial. Trying to act like it adds a great deal
    of extra work is so misleading that it borders on (yet another)
    falsehood.

    > Or switch to the Borland library (forgot the name).


    Presumably you mean OWL.

    > It is no longer being developed.
    >
    > Or switch bto one of the COUNTLESS libraries done during the last
    > 15 years of windows. Most of them are no longer running, forgotten,
    > whatever.


    Most that I've seen still run as well as they ever did. Just for
    example, changing the name from wxWindows to wxWidgets doesn't seem to
    have caused any major problem with keeping the code working.

    > Only those people that used the windows API are now able to develop
    > their applications without any problems now!


    Rather the contrary -- they've had problems all along, and they continue
    to do so. In reality, rewriting most of the applications two or three
    times over using one library after another would STILL have been less
    work than doing it just once using the raw API.

    Also keep in mind that when Win32 was introduced, there were substantial
    changes in how messages were packed, so anybody using the raw API
    previously had to do substantial rewriting just to get their code to
    work under Win32.

    Porting from 32- to 64-bit Windows _can_ be reasonably painless as long
    as you use the types that were designed specifically to support the
    port. Unfortunately, most Win32 code doesn't, and most Win32
    documentation doesn't even make clear what types are needed when. As
    such, unless all your code was written very carefully within the last
    couple of years or so, you're going to be rewriting a lot of it again if
    it uses the raw API. By contrast, if it uses almost any halfway decent
    library, all of that is handled in the library, and you deal only with
    far more abstract types that haven't changed a bit.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jun 17, 2008
    #15
  16. Re: OT: Visual C++: the need for MFC

    jacob navia wrote:

    > Only those people that used the windows API are now able to develop
    > their applications without any problems now!


    And they'll run only on Windows (Wine is a half-working hack, not a
    robust platform.) Applications today are best developped in a
    cross-platform way, this not only makes them easier ported to other
    existing systems, it also makes them more portable towards future
    developments just in the same way that writing in a higher-level
    language compared to assembler will make your software more portable if
    the industry moves on from processor type X to processor type Y.
     
    Matthias Buelow, Jun 17, 2008
    #16
  17. Man-wai Chang ToDie (33.6k)

    jacob navia Guest

    Re: OT: Visual C++: the need for MFC

    Jerry Coffin wrote:
    >> MFC is obsolete and hasn't been updated for several YEARS now.

    >
    > False! It was updated (significantly) for Visual Studio 2008 -- which is
    > to say within the last few months (note how I've used the exclamation
    > point to emphasize something that clearly is NOT known to many
    > developers).



    MFC's last update was in 1998. Ten years passed and nothing was updated,
    until now. I did not know about this new release. So, obviously a
    library that is updated in a 10 YEAR basis is considered OK.

    There is no point in discussing this further.

    Use MFC. I will go on using the API.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jun 17, 2008
    #17
  18. Man-wai Chang ToDie (33.6k)

    Dilip Guest

    Re: OT: Visual C++: the need for MFC

    On Jun 17, 12:49 am, Jerry Coffin <> wrote:
    > False! It was updated (significantly) for Visual Studio 2008 -- which is
    > to say within the last few months (note how I've used the exclamation
    > point to emphasize something that clearly is NOT known to many
    > developers).


    Jerry needs no support from me but just to bolster his point, please
    read the Visual C++ team blog's latest entry:
    http://blogs.msdn.com/vcblog/archive/2008/06/30/teched-2008-meeting-customers-at-the-booth.aspx

    The recent updates to MFC apparently was the talk of TechEd 2008.

    Also, I don't know if Jerry knows about this but John Torjo's template
    based C++-GUI library is also shaping up to be a fine competitor:
    http://msdn.microsoft.com/en-us/magazine/cc534994.aspx
     
    Dilip, Jul 1, 2008
    #18
  19. Man-wai Chang ToDie (33.6k)

    feedscrn Guest

    Re: OT: Visual C++: the need for MFC

    I suppose it depends on what you are after...

    If you are developing your own applications, please see above posts.

    Otherwise, if you are looking for a job in C/C++, then the above is
    probably a moot point. It would then be prudent to learn MS or
    whatever compiler would impress a potential employer these days.

    Feedscrn
     
    feedscrn, Jul 4, 2008
    #19
  20. Man-wai Chang ToDie (33.6k)

    Jerry Coffin Guest

    Re: OT: Visual C++: the need for MFC

    In article <22a707fe-d775-4a99-b3af-dd8ed82d5159
    @r66g2000hsg.googlegroups.com>, says...
    > On Jun 17, 12:49 am, Jerry Coffin <> wrote:
    > > False! It was updated (significantly) for Visual Studio 2008 -- which is
    > > to say within the last few months (note how I've used the exclamation
    > > point to emphasize something that clearly is NOT known to many
    > > developers).

    >
    > Jerry needs no support from me but just to bolster his point, please
    > read the Visual C++ team blog's latest entry:
    > http://blogs.msdn.com/vcblog/archive/2008/06/30/teched-2008-meeting-customers-at-the-booth.aspx
    >
    > The recent updates to MFC apparently was the talk of TechEd 2008.


    Right -- I should also mention that although it's clearly the _largest_
    update to MFC in quite a while, this really is NOT the first in ten
    years as was stated elsethread. Documentation of them has been minimal
    (to put it nicely) but I believe every release of the compiler has
    included at least a few minor updates to MFC.

    > Also, I don't know if Jerry knows about this but John Torjo's template
    > based C++-GUI library is also shaping up to be a fine competitor:
    > http://msdn.microsoft.com/en-us/magazine/cc534994.aspx


    Yup -- while this clearly has a lot less support, it also looks like
    quite a decent library.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jul 7, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott McPhillips
    Replies:
    0
    Views:
    380
    Scott McPhillips
    Jul 5, 2003
  2. Jimmie
    Replies:
    1
    Views:
    557
    Greg P.
    Aug 26, 2003
  3. ringos75
    Replies:
    0
    Views:
    966
    ringos75
    Apr 14, 2005
  4. yopwojtek

    Derive from MFC DLL to MFC APP

    yopwojtek, Aug 6, 2005, in forum: C++
    Replies:
    1
    Views:
    388
    Alf P. Steinbach
    Aug 6, 2005
  5. Test
    Replies:
    2
    Views:
    339
    Peter_Julian
    Mar 17, 2006
Loading...

Share This Page