Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!wam!bchin From: bchin@wam.umd.edu (Weiyuan W. Chin) Newsgroups: comp.windows.ms Subject: Re: Windows programming in C Keywords: Windows 3.0, Windows SDK, C programming Message-ID: <1990Jun29.231845.20456@wam.umd.edu> Date: 29 Jun 90 23:18:45 GMT Sender: usenet@wam.umd.edu (USENET Posting) Reply-To: bchin@wam.umd.edu (Weiyuan W. Chin) Distribution: na Organization: University of Maryland at College Park Lines: 110 in response to the message from: nelson_p@apollo.HP.COM (Peter Nelson) Hewlett-Packard Apollo Division - Chelmsford, MA >I posted questions about it a couple of months ago and >received, on the net and via email, lots of horror stories >about it. About how most standard C library functions like >printf can't be used in the SDK, about the number of lines it >takes to do even simple things, about how long it takes to >get up to speed on it (*two* different people quoted me the >figure of SIX MONTHS before I would be able to productively >write code with the SDK), and about the difficulties in writing >code for different hardware configurations. I think it learning curve is about 3 to 4 months initially, then about a month per major concept (ie. MDI, DDE, DLL ) if one is trying to learn this *alone*, with just the manuals and a couple of books. Having a guru around, using BBS's, Usenet, or Online support will drastically cut down the time required. Yes, several standard C functions will not work... but do you really *want* to use them? And forsake the ability to swap out unused portions of code, move memory around to get larger contiguous blocks, etc....? The only one that seems a pain at first is printf(), which is easily replaced with textout or MessageBoxes, and the rich set of new Windows functions more than make up for the loss (however, that also contributes to the learning curve). The real pain is learning the message processing method Windows (_and_ other GUI's) operate, and learning to be cooperative instead of assuming total control of the system. The concept of Device Contexts (DC's) and handles help in writing multi-configuration programs. Where else are you going to find a program that can let you print to hundreds of different printers and dozens of displays through one routine? Are you going to limit yourself to CGA, EGA, and VGA? As long as you have a driver (most companies write their windows driver right after their autocad driver) you can use it. And I can design my program w/o too much difficulty to look great using VGA, VESA, 8514/A, or other custom screens. >Just for fun I recently wrote a little GUI library in (Zortech) C. >Nothing fancy; just buttons and sliders (3D, of course) and dialogue >boxes and ways of associating screen-events like button pushes with C >functions, etc. I used it to implement a 3D graphics viewer, but >it's general purpose and now I'm porting my other apps to it. >It's very simple, maybe a couple of dozen functions, and requires >very little change to existing apps, except that it assumes you're in graphics mode. > >Now I'm *not* trying to compare this to Windows except to say that >that's all the functionality I NEED. Memory-management issues and >multi-tasking and resizing the window, and so forth are not things >the APPLICATION should have to worry about. They should be invisible >to the application, as much as possible. ( I realize that DOS apps If you don't worry about memory or how the window looks when resized, who will? You don't have to worry about *how* windows moves memory or where or when it moves it... you've got the handle and so when you need it just lock the block down. And remember to unlock it. (for most apps) >have to worry about things like or pointers and such, >but that's true even if you're not in Windows. Heck, Windows >can already multitask lots of DOS apps as it is. If the apps were >written with a compiler and run-time libraries designed to ensure >well-behaved programs for a Windows environment it could probably >multitask any such app. >So I guess what I don't understand is why it's necessary for the >API to be so complicated. It doesn't take a lot of complication >just to support bottons and menus. And most of the other things >I've seen people mention here would appear to be better addressed >by the compiler, the libraries, or the run-time package. True, it can multitask DOS apps... but that's not the primary reason one would use Windows. If that's all you want, use Desqview. I think the attraction are all the *goodies*: clipboard, Dynamic Data Exchange, memory management ( I love to be able to do this: hGlobalMem = GlobalAlloc( GMEM_MOVEABLE, 2048000 ); <--- two meg ), Multiple Document Interface, Device Independent Bitmaps, multi-tasking ( I agree this area is a bit weak, though), hardware device independence (both displays and printers), etc... And the Mac only has a few of the above. As a Windows developer, you've got a lot more toys (oops, tools) to play with and you can present a better, more cooperative, and flexible (we're in the Bush era) app. >>One excuse for complication people often mention is *performance tuning*. Fine. Make such features available but don't force me to use >them. CPU's are a LOT more powerful than they were a couple of years >ago and for many people even hideously innefficient might run just fine. If you're interested in only performance, Windows won't work for you. Hell... multitasking a DOS machine won't help you either. I recommend a 20mhz 386 w/ dual monitors (in order to run Codeview Windows), 4mb of physical RAM and a fast HD for development work, but if you're just going to run Windows apps, a 12mhz 286 with two-four megs would do. Multitasking screen intensive DOS apps aren't efficient either... and multitasking (in a window) graphics apps almost impossible under Windows 3.0. And of course, the real solution is OS/2. >Remeber,I'm saying this without having seen the SDK so if I have some >major misconceptions feel free to flame me. > ---Peter Disclaimer: My opinions are my own, not my employer's or anyone elses. -- Bill Chin University of Maryland College Park internet: bchin@cville.umd.edu