Windows Programming. Bah
I know that this has been asked a million times. But I was wondering. To write efficient window programs, is it best to learn win32 or MFC...or something else (visual basic)? I would prefer to use c/C++, but I''m just wondering. And would a book be the best way to learn...any suggestions?
We shall be free; th'' Almighty hath not build here for his ervy, will not drive us hence: Here we may reign secure and in my choyce To reign is worth ambition though in Hell: Better to reign in Hell, than serve in Heav''n.
i learned the SDK, and then MFC. I like MFC now for the object oriented style and the small file sizes it produces.
June 02, 2000 01:44 PM
quote:
I like MFC now for the object oriented style and the small file sizes it produces.
small file sizes???
quote: small file sizes???
Hell ya! I made a whole map editor in MFC that fit into a little 56K file.
=======================================
A man with no head is still a man.
A head with no man is plain freaky.
Depends. I personnaly prefer the SDK as it is much simpler, and is written in C which I also use. Basically, learning *another* MS Api is just too much to ask from programmers when the average lifespan of a human is only about 80 years.
-----------------------------
A wise man once said "A person with half a clue is more dangerous than a person with or without one."
-----------------------------
A wise man once said "A person with half a clue is more dangerous than a person with or without one."
-----------------------------A wise man once said "A person with half a clue is more dangerous than a person with or without one."The Micro$haft BSOD T-Shirt
MFC file sizes are smaller than SDK b/c MFC apps use libraries that are a part of the Windows OS.
I use MFC, Visual Basic, and the SDK. It really depends on what your goal is and what kind of factors you have to take into consideration:
1. If you want to write fast gui/frontends that interface to Access, MS SQL or some other ODBC or OLE DB type of database Visual Basic is really efficent and timely in that manner.
2. If you want to write tight code and have total control than Visual C++ is the way to go. If you are object oriented than MFC is a good library. I won''t knock it. If you are the kind of person who wants super tight control and wants to know everything that is going on in your code than the C - Windows SDK is for you, this has been likened to writing in Assembly code, in the mere fact, that the C SDK library is the lowest level of writing to Windows Applications.
It is a matter of personal preference as well as what you want to do.
acw83: Is MFC really smaller executable? I always thought it added more than what you needed to your EXE?!?!
btw, Most game programmers and lots of tutorials build Window apps using a skeleton structure derived from the Windows ''C'' SDK. They state because of the smaller executable it generates. If MFC is small why don''t more game programmers use it, or even tutorials?
00000001 - My 2 bits
1. If you want to write fast gui/frontends that interface to Access, MS SQL or some other ODBC or OLE DB type of database Visual Basic is really efficent and timely in that manner.
2. If you want to write tight code and have total control than Visual C++ is the way to go. If you are object oriented than MFC is a good library. I won''t knock it. If you are the kind of person who wants super tight control and wants to know everything that is going on in your code than the C - Windows SDK is for you, this has been likened to writing in Assembly code, in the mere fact, that the C SDK library is the lowest level of writing to Windows Applications.
It is a matter of personal preference as well as what you want to do.
acw83: Is MFC really smaller executable? I always thought it added more than what you needed to your EXE?!?!
btw, Most game programmers and lots of tutorials build Window apps using a skeleton structure derived from the Windows ''C'' SDK. They state because of the smaller executable it generates. If MFC is small why don''t more game programmers use it, or even tutorials?
00000001 - My 2 bits
-----------------------------00000010 - My 2 bits"Smile life gets worse, and then you die!" - Optimist
The filesize of MFC programs are big if you use static linking, and are small if you use dynamic linking ??
Or am I confused....?
-------------Ban KalvinB !
As far as I know, an MFC program is gonna be bigger than a straight Win32 one, although maybe not by much. If you dynamically link the MFC libraries, the program won''t be all that big, but probably still bigger than a straight Win32 program. The MFC DLLs are NOT part of the Windows OS (as acw said), although most people do have them, and they might come with windows. However, the Win32 libraries are definitely part of the OS.
The file size won''t be too big provided your program isn''t huge and you dynamically link the libs.
The file size won''t be too big provided your program isn''t huge and you dynamically link the libs.
That''s about right - some info on MFC file sizes:
Dynamically linked is (obviously) smaller than statically linked. This is because the MFC42.DLL is used, instead of it being linked straight into the code. Note however, that this is not necessarily a bonus when distributing the software, because you usually have to put in the MFC42.DLL as well, since not all people will have the latest version.
Statically linked is bigger, but as I hinted at before, you don''t need to redistribute the MFC42.dll so it may save you some space after all.
Another thing to be careful of: MFC debug builds are HUGE! ( 10* bigger than release builds I''d say, though I''m probably exaggerating. ) If you have a really big MFC exe, you''re probably not building in Release mode. Try that, and I think you''ll be pleasantly surprised.
The last MFC program I released was about 500k in a zipped file, Dynamically linked, with the MFC42.DLL in the archive.
That''s not too bad I think;
#pragma DWIM // Do What I Mean!
~ Mad Keith ~
Dynamically linked is (obviously) smaller than statically linked. This is because the MFC42.DLL is used, instead of it being linked straight into the code. Note however, that this is not necessarily a bonus when distributing the software, because you usually have to put in the MFC42.DLL as well, since not all people will have the latest version.
Statically linked is bigger, but as I hinted at before, you don''t need to redistribute the MFC42.dll so it may save you some space after all.
Another thing to be careful of: MFC debug builds are HUGE! ( 10* bigger than release builds I''d say, though I''m probably exaggerating. ) If you have a really big MFC exe, you''re probably not building in Release mode. Try that, and I think you''ll be pleasantly surprised.
The last MFC program I released was about 500k in a zipped file, Dynamically linked, with the MFC42.DLL in the archive.
That''s not too bad I think;
#pragma DWIM // Do What I Mean!
~ Mad Keith ~
It's only funny 'till someone gets hurt.And then it's just hilarious.Unless it's you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement