Can somebody explain the concept of MFC to me. I know they are C++ classes but how are they used in the programs. Also isnt there any way to convert it to asm. Can somebody direct me to a beginners tut to mfc so that i can know more abt it. Also if any of u have seen, the MSDN site had been redesigned(so that now its even more difficult to navigate :D ). When i cliked on the link to mfc documentation it shows page not found! This message was edited by MovingFulcrum, on 6/23/2001 1:12:03 AM
Posted on 2001-06-23 01:05:00 by MovingFulcrum
The Microsoft Fundemental Classes are a set of tools to create GUI applictions with C++ (OOP). When you call a fuction in Win32 Asm (i.e. CreateWindowEx), you are essentually calling one of these classes.
Posted on 2001-06-23 01:23:00 by eet_1024
Hey maybe its an acronym to MovingFullCrum ;) Besides i belive if the Microsoft Foundation Clases a set of basic routine to nicely do allmost anything that VC++ does in a more bloatware but fancy style. they hide the "complexity" of the "low level" Win32API calls to the average C++ programmer and give his programs the "looks" of a PRO ;) i guess deep down it goes to the MSVC40RT.DLL or higher versions Borland also has something like this only they used to call it OWL... I dont think its legal to use it (MFC) without owning a VC copy ... but as long as MSVCXXRT.DLL comes with windows (yeah and then C++ programmers tell us about his "small" proggy) i gusess one can use functions inside that library...IF u know their prototypes... This message was edited by BogdanOntanu, on 6/23/2001 1:33:33 AM This message was edited by BogdanOntanu, on 6/23/2001 1:35:29 AM
Posted on 2001-06-23 01:31:00 by BogdanOntanu
Somewhere on this very forum I saw something about extracting prototypes out of dlls. This message was edited by eet_1024, on 6/23/2001 1:37:20 AM
Posted on 2001-06-23 01:36:00 by eet_1024
MFC == Microsoft Foundation Class It's a C++-specific thing, ie, you can use its full functionality via C++ only. It essentially envelopes windows elements into "objects", for example, a window object so that it follows the OOP paradigm. Many of its characteristics are pertinent to C++ only such as inheritance (it works at source code level), function/operator overloading. MFC40.dll or MFC42.dll is the dll you should look for. I personally don't recommend using MFC with asm: they are very different and you don't have much use for MFC anyway. If you want to, use COM instead.
Posted on 2001-06-23 06:25:00 by Iczelion
Well actually the thing is i got a source code with me which uses a LOT of MFC. How am i supposed to convert this to asm?
Posted on 2001-06-23 06:51:00 by MovingFulcrum
well, in reality those MFC classes are nothing more then wrappers for the API calls you use. So, you can examine the class itself and see which ones it uses (MFC is really ugly to look at) or you can just try to mimic its functionality yourself. yeah MSDN site sucks now, it's incredibily slow on my dual P3 800 :eek: with that annoying java side menu. I'm not buying a new PC just for MSDN online :(
Posted on 2001-06-23 06:59:00 by Hiroshimator
the source for MFC comes with vc++ so you can see how they made it (whatever it is u want to do, wndsplitter maybe?) then you can make your own set of functions in asm or whatever...
Posted on 2001-06-23 08:41:00 by superman911
Which would be wiser? To cancel all this hassle of converting from mfc to win32 and then code in asm and code in C++ only OR sit down and start converting! Why dont ppl like to use MFC? How is it slow? This message was edited by MovingFulcrum, on 6/24/2001 12:33:08 AM
Posted on 2001-06-24 00:31:00 by MovingFulcrum
yeah MSDN site sucks now, it's incredibily slow on my dual P3 800 with that annoying java side menu. I'm not buying a new PC just for MSDN online :(
LOL... hiro, you should try my PC... Single PIII 1000MHz, 512MB Ram, Win2k... I seem to have zero problems accessing MSDN online when necessary using DSL :D My thoughts on the matter: I have not every formally used MFC, OWL... I prefer working on the API level when possible. I have, however, used the source code to OWL and MFC (which I legally have access to) to attempt to learn from it. If you have a specific task that MFC accomplishes you can trace the objects down the hierarchy and try to mimic the functionality in ASM yourself. NaN and Ernie seem to have created many tutorials and some tools to help try to get the effect of C++ Classes in ASM. The task wouldn't be easy and I would rather prefer for such an instance, to use raw assembly and not OOP principles, as porting a framework could be very difficult. However, there is a book called Windows++ (that I own) and is still on many book shelves. It was written in Win 3.0 days and is highly relevant even today. It discusses creating your own framework and its windows and dialog, GDI and other such classes are handy. Otherwise, MFC is mainly for C++. _Shan
Posted on 2001-06-24 01:45:00 by _Shawn
I got this small heloo world program source in mfc. How the hell do i convert it to the api form. I have seen the sources of the mfc files but they confuse me even more. Where is the window created? Where is the wnd proc structure. I cant see any 'normal' CreateWindowEx in the mfc sources. By 'normal' i mena one without a class name. This program creates a winodw with a grey rectangle inside it with Hello World! written inside the rectangle. The source below can als be compiled to see how it actually looks like.



// Declare the application class
class CHelloApp : public CWinApp
  virtual BOOL InitInstance();

// Create an instance of the application class
CHelloApp HelloApp;

// Declare the main window class
class CHelloWindow : public CFrameWnd
  CStatic* cs;

// The InitInstance function is called each
// time the application first executes.
BOOL CHelloApp::InitInstance()
  m_pMainWnd = new CHelloWindow();		
  return TRUE;

// The constructor for the window class
  // Create the window itself		
    "Hello World!",				
  // Create a static label		
  cs = new CStatic();		
  cs->Create("hello world",				

Posted on 2001-06-29 07:53:00 by MovingFulcrum
MF, I use MFC at work, I'd advise you to stick to translating C programs, it's easier, MFC is almost a language in itself, and, if you don't know C++ then forget it..... Try looking at Programmers Heaven for examples of the same thing in C. Anyway, to answer your question, that program you list is just putting some text up on a window, you don't need MFC for that. The rectangle you describe is draw by the creation of a static window inside the main window. by default Text in a CStatic window is black and the background is light grey, so thats what you are seeing. If you want to use some of the exotic controls like listviews and calendar controls, MFC is alot easier, and quicker to write, but thats all it has going for it... Sadly Managers prefer speed of development to Speed of the final application, thus VB and MFC came into existence. If I had my way VB would have been banned by the Geneva(sp?) convention! umbongo
Posted on 2001-06-29 09:58:00 by umbongo
Mfc is, like people have said, a c++ framework which "wraps" the api functions... what this basically means is that when you use one of the classes... your code calls into a dll.. which then calls the api.. so the reason it is slow has a bit to do with the fact that there is a whole new level of calls going on between your actual program and the final code... as far as calling it from assembly.. im sure it would lose a bit of the speed advantage youre probably wanting if your working with assembly to begin with... i tend to agree with the ones who said make your own asm functions....
Posted on 2001-07-02 10:46:00 by passing_lurker
then i guess it's a waste to use MFC in asm... only people who use C/C++ has more advantage you mean? strange that dll calls api when in fact, we can call it ourself. :)
Posted on 2001-07-02 10:51:00 by disease_2000
then i guess it's a waste to use MFC in asm... only people who use C/C++ has more advantage you mean? strange that dll calls api when in fact, we can call it ourself.
The reason it's put into DLL's is simple, it gives the ability of dynamic linking at run-time, so if there was a bug in MFC 1.0 then when MFC1.5 came out they fixed it in the DLL, so all you code would not have to be re-linked, it just worked properly suddenly. It's the real reason for DLL's if you think about it. If you were a bit of a nutter, you could speed the whole of windows up by optimizing msvcrt.dll - it's all the C library function code, make that faster and you'll make alot of windows programs faster, as you will find 99% of them use it. umbongo
Posted on 2001-07-02 11:07:00 by umbongo
Here are some things you need to be aware of when converting MFC programs to ASM. The considerations listed below are common to all C++ to ASM conversions. 1) Implicit "this" pointer. Within a (class) member function, the code

    wnd = GetParent();
may actually mean

    wnd = this->GetParent();
2) The vtable. Unlike COM, which must be accessible from any programming language, the vtable ordering of MFC functions isn't published. How does the C++ compiler ensure the proper virtual function is being called? Answer: it doesn't...the C++ programmer forces the compiler to look at the same class definition (located in a .h file) that was used to compile the MFC support code. 3) Automatic "type" conversions. C++ allows you to define new type conversions. I'd have to check, but there might be a definition of a string-to-CString type conversion. In which case, the code

    x = cstr.Append("ABC");
might actually mean something similar to

    x = cstr.Append(string2CString("ABC"));
4) Mangling names of nonvirtual functions. Because one name can be used in many classes, and may have differing algorithms, name mangling is used to create unique names for the linker. Virtual functions are accessed via the vtable, by position. Nonvirtual functions are accessed directly by their (mangled) names. 5) Names of overloaded operators. An example, CString has a += operator for concatenation. What is its linking name?
Posted on 2001-07-02 23:45:00 by tank
hi all, care for some analogy? your program is a piece of art (sculpture). mfc is lego blocks, asm is clay. in mfc, almost everything has been done and pre-fab for you (only that it wasn't done good enough ;), and you just put the blocks together to come up with a "your" nice program. on another note, i've had this one "web-book" for almost a year now. i do mostly vc++ stuff and this book is really a nice one to have (it's what convinced me to abhor mfc!). for the past six months or so i've been spending most of my spare time learning win32asm and less c++. anyway, i was reading the book again last night for a refresher on OOP concepts (i'm doing a commercial website now with PHP. puts food on the table ;), when i saw something i didn't notice before. i'm sure many of you have this book and in case you missed this paragraph too, here it is: in the chapter "software project/about software/complexity/the living programmer" paragraph 27, quote: "A programmer is a human being. Failing to recognize it is a source of many misunderstandings. The fact that the programmer interacts a lot with a computer doesn't mean that he or she is any less human. Since it is the computer that is supposed to serve the humans and not the other way around, programming as an activity should be organized around the humans. It sounds like a truism, but you'd be surprised how often this simple rule is violated in real life. Forcing people to program in assembly (or C for that matter) is just one example. Structuring the design around low level data structures like hash tables, linked lists, etc., is another example." ;). btw, i still like (and learn) from the book. it's called C++ in Action by Bartosz Milewski, from and though he convinced me to stay away from mfc, he won't this time as far as asm is concerned. but then again, i think he's got a point. i have this asm programmer friend who's so insensitive and inhuman and... p.s. hiro, it's been 2 months since i was last here and i forgot my passw. how do i get it back? the name's pixelwise.
Posted on 2001-07-03 09:29:00 by pixelwiser