Is there any way to escape the horrible wrath of object-oriented programming in Windows?

Question

I'm learning to program for Windows and trying to find a way to program without dealing with OOP. I am not liking the Windows API one bit. Even with assembly language, many of the functions I call deal with classes and objects and all of that object-oriented BS. Creating a window deals with device contexts, window classes, device classes, and objects. Everything seems to need a class, a context, and a handle. Can I actually make Windows applications without dealing with all of this?

Answer 1

In Windows API programming, the classes, device contexts and objects (e.g. file system and GUI objects) have nothing to do with OOP; The term, "object" is just used to refer to something.



Also:

A window class is NOT something related to OOP. They just use the 'class' word because a window class defines the properties of a window. Once a class is defined (e.g. with RegisterClassEx), you can use that class (i.e. window properties) to create other windows with those same properties, without having to specify them again.



Windows API programming isn't as bad as you think. I mean, you REALLY wouldn't want to try using stupid crap like the Borland VCL framework or Microsoft MFC framework libraries. The closest you get to OOP is when you need to acess those idiotic COM objects for DirectX and some other things. Despite the name, COM objects are not exactly like an OOP object. Rather, COM objects are just a method of distributing code. In fact, you won't find a more brain-dead method of providing code functions anywhere else. (To illustrate how stupid those Adobe programmers are, those idiots based their Director code libraries on COM objects.)



By the way, did you get Petzold's book? Seriously, unless you want to waste a lot of time, you're better off learning from his book rather than just looking at the Windows API documentation. The only caveat is that his books were written for Win9x, so some functions may have changed for Win2000 and later. Win2000 is a combined version of business-oriented Windows NT and the regular consumer version of Windows (Win9x). So, you have additional functions from NT, plus the extra security.

Answer 2

Yes, you can, but you probably won't like them. The console API does a pretty good job of hiding the GUI plumbing necessary to keep a terminal-type window alive.



The basic Windows API was written in C for C applications, and C is not an object-oriented language. Even so, you'll find objects in the basic API. The FILE struct is the best example. The innards aren't disclosed (encapsulation), they are created sole by the fopen() function (constructor, or factory method...take your pick), implementations of different types of files share a common infrastructure--the FILE* struct itself (inheritance), and provide a common API for different file types to the client program (polymorphism, in a limited way.)



Nobody would call Brian Kernighan's "Hello World!" program an OOP example. If you go looking for objects, though, stdout is lurking in the background.



GUIs are different from console programs. Not only does the program itself have context, but all of the pieces managed by the system do too. Buttons, labels, frames, icons, etc.; they all have individual state information (Visible? If so, where, relative to what? Can be a target in a drag-drop? etc.) That's what window handles handle for you. Do you really want keep track of all that on your own without some sort of object mechanism?



Device context allows you use the same code on any display type. For a while, everybody had at least XVGA with 24-bit color depth, but that wasn't true when Windows was designed. Small mobile devices have changed that. Even so, there are a number of different printer devices. GDI and Windows drivers handle those differences for you. I remember writing code in the MS-DOS days. Developers wrote their own device drivers (or bought a library) for every application that used display features beyond those implemented by IBM hardware (MGA, CGA, VGA, MCGA), or for any sort of printer graphics at all.



Want text that isn't in both the video card ROM and the printer's built-in fonts? Write code to do it at the pixel level. It wasn't a fun time for CRUD application coders.



Speaking of those days, you can get a flavor for graphics in the MS-DOS days by finding and installing WinBGIM on a compatible C platform. (I think Visual C++ and MinGW are both supported.) That's a clone of the old Turbo/Borland C BGI ("Borland Graphics Interface"). Try writing a windowed application in that. (Borland didn't. They had a windowed platform based entirely on text graphics in later versions of Turbo Pascal with Objects and Turbo C++. It was, predictably, object-oriented too.)

Answer 3

"device contexts, window classes, device classes, and objects"

none of those things have anything to do with object-oriented programming



a windows class is not a "class" in the OO sense



"Everything seems to need a class, a context, and a handle"

once again, none of those things have anything to do with object-oriented programming



a handle is basically a pointer



yes, the windows API is difficult to learn because of all the new words, but it is no different from any other API

Answer 4

Are you really asking this? Abstraction is the best thing to ever happen to Computer Science. It makes your world multitudes easier.



Taking that away is like saying "I'm tired of accidentally hitting myself with the hammer anytime I want to hammer a nail. Is there any way to build this house without using a hammer?" You say "Even with assembly language". Are you kidding me? Assembly IS NOT OOP. If you find both OOP languages and Assembly difficult, then the problem is not OOP.



If you don't want to deal with OOP, then by all means my friend, go make a Windows Application in SQL.

Answer 5

possible but not best practice