microsoft has a thing called MFC, which is bunch of code that you use to write programs with windows (not the operating system, but the things, like pop-up boxes, and progress displays, and the like, as opposed to text-only stuff like dos programs).
it's a large collection of C++ classes (essentially, programming language constructs) that encapsulate the ideas behind all the procedural bullshit you have to go through to do anything useful, to protect the programmer from all of the internal bullshit windows makes you do without such an abstraction. don't even think about trying to make a useful program without MFC... but using MFC necessarily means your program is HUGE.
you'd think this was a good thing, but they've managed to make something frighteningly tedious into nightmarishly complex.
they claim MFC stands for Microsoft Foundation Classes, but i think it actually means MotherFucking Complicated.
to be fair, there's no such thing as an easy way to make windows appear. there are so many factors involved... if you want it really easy, you have to give up a large amount of control. but i don't think that excuses microsoft for some of their design decisions... every C programmer knows that a C program starts with main(). this is The Way It Goes. so what does microsoft do? they change that. console apps still use main(), but windows apps with a graphical user interface (the GUI (gooey!)) start with WinMain(). i can see why they use WinMain(), but i don't like it. i'd prefer to call WinMain() from main(), which is the way it's done on most other systems... of course, on most other systems, the GUI is not built into the core of the operating system, on the same level as the instructions that manage ram and task scheduling....
why am i bitching about this? i have a command-line app that really needs to stay command-line based... it's a scriptable control shell. what i want to do is add a dialog box with knobs and buttons to make changing the internal options a little less painful. well, dialog boxes and console apps don't mix very well in Windows. you can call some system dialogs like FileOpen and such (they're standard), but calling a dialog of your own design requires machinations of the sort i can't imagine, since i haven't been able to do it. you need things like "Instance Handles" which WinMain() will give you... but if I switch to the type of program that uses WinMain(), i have to scrap about 80% of what I've written, and essentially re-invent the wheel by implementing my own command interface window!@!!@!@!@!$%^ NO! i refuse to waste that much time! i WILL do it the way Windows doesn't want you to, because i am smarter than Windows will admit that i am....
...but, to try to bring up a dialog box in a program without WinMain() will require that i do it the Truly Hard Way, for the MFC won't work without it... *sigh*
Thu, 18 Feb 1999 15:21:22
it's worth noting that the very next day after writing the above diatribe, i had a working gui that i could call from within my Win32 console application. i did it in plain C and the straight Win32 API, without MFC. to my surprise, it's actually much clearer that way. their API is quite straightforward, but very dryi, mechanical, and downright unfriendly, forbidding, even. all the sample code i've seen for win32 looks as though the author didn't have a good time writing it, but rather felt like coding was a chore. i don't like that at all. i much prefer the more organic and friendly APIs of gtk+ and Qt, and the general unix API altogether -- these were developed by people who enjoy coding...
the app, on the other hand, is very cool --- no one at work believes that i did it, until they see it. i mean, it makes perfect sense to me... i can't help it if microsuck had to implement the WinMain thing because their operating system is brain dead...
Sat Mar 13 02:32:02 EST 1999