Creating a Windows API interface

[paprica]

I think about creating a Win32 namespace/class (haven't decided how stuff will go yet) but I want to hear an opinion about this first.
Basically I do this because I'm tired of all these annoying Win32 functions that always require MSDN to be opened in the background.
I want to create my own interface that will include simple functions like WinCreate(name,width,height,x,y,style) etc.

Is this going to be a total fail?

[VictorN]

I guess you should look at the MFC framework.

[paprica]

I don't like it. It's too big and too Microsoftish.
Yeah, Microsoftish.

[VictorN]

1. Define "too big".
2. You are posting to

C++ and WinAPI Discuss Windows API related issues using C++

what means that all discussed problems are "Microsoftish"...
So what is the problem?

[Paul McKenzie]

I think about creating a Win32 namespace/class (haven't decided how stuff will go yet) but I want to hear an opinion about this first.
Basically I do this because I'm tired of all these annoying Win32 functions that always require MSDN to be opened in the background.

To write a C++ wrapper, you must know the Windows API and how to use it properly.

I want to create my own interface that will include simple functions like WinCreate(name,width,height,x,y,style) etc.

And what function will "WinCreate" call to create a window? The "annoying" Windows API function, of course.

Is this going to be a total fail?

Please read this thread:

http://www.codeguru.com/forum/showthread.php?t=514257

And this post:
http://www.codeguru.com/forum/showpo...1&postcount=13

Regards,

Paul McKenzie

[paprica]

Please don't enhance controversial words that I say, like "annoying".
What I really meant was that these functions really require nonstop MSDN pages navigations.

Anyway, I get you. "Wrapping" this library isn't for me. I guess I'll just stick to MFC.

Victor, here's "too big" and "too Microsoftish" for you.
http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

No straight to the point classes/functions names. Many stuff I'm not looking for. Only thing I get for searching "Create" in my browser is "CCreateContext Structure" which isn't what I'm looking for.

I might sound like a complete novice but isn't the whole point for wrapping such a library is to make easier and more convenient to use?
Could be something like

INT WinMain(...)
{
  CWindow mywindow(par1, par2, par3);
  mywindow.Show();
}

I don't know. I google "MFC Tutorial" and I get all these examples without even an entry point for the application.

[Igor Vartanov]

Victor, here's "too big" and "too Microsoftish" for you.
http://msdn.microsoft.com/en-us/library/bk77x1wx(v=vs.71).aspx

Very bad example. The number of classes is stipulated by internal diversity of various windows. Windows API is as much complex as Windows itself is.

I might sound like a complete novice but isn't the whole point for wrapping such a library is to make easier and more convenient to use?
Could be something like

INT WinMain(...)
{
  CWindow mywindow(par1, par2, par3);
  mywindow.Show();
}

I don't know. I google "MFC Tutorial" and I get all these examples without even an entry point for the application.

You know, you really do.

This is your WinMain how MFC does it:

class CMyApp: public CWinApp
{
    BOOL InitInstance()
    {
        CMyDlg dlg;
        dlg.DoModal();
        return FALSE;
    }
}
CMyApp theApp;

Don't you find it looking good enough for you?

[Igor Vartanov]

I google "MFC Tutorial" and I get all these examples without even an entry point for the application.

MFC hides WinMain implementation from user. The very first framework entry available for custom implementation is CWinApp::InitInstance. You really need to start from some good book on MFC rather than messing with on-line tutorials. Or try WTL if you feel MFC is not for you.

[Arjay]

Or try WTL if you feel MFC is not for you.

+1 for WTL.

If you already know MFC, then you'll immediately see the beauty and compactness of WTL.

If not, then you've got some of that dreaded Msdn reading to do.

Or you can go the other route than some folks find appealing, called reinventing the wheel.

Folks that do this sort of thing enjoy it, only to be despised by other folks that need to maintain their code.

[JohnCz]

paprica,

In addition to what has already been said.
I would like to ask two questions:
How many programs/application have you written and what OS were they for? How much simpler was it in comparison to programming for Windows?

To write a good application you have to have fairly good knowledge about the OS system MS or not.
To write a good application you have to be a good knowledge about programming language and set of functions that you use to write a program, no matter what you choose: some kind of framework (MFC, WTL) or raw Windows API.
All of the above is called experience.
You can consider C#, or VB. But still you have to understand how to use the language and functionality it provides.
Anyway, I am not sure why is it customary and fashionable to complain about Microsoft but still trying to write Windows applications.
If Microsoft-ish and Windows turn you off, switch to Unix-like OS for example and see how window creation is handled in this paradigm.

[Bssldr]

I'd rather use WinAPI than MFC. MFC is just bad - I find it hard to even call it object-oriented. The only promising thing in the future seems to be WinRT.

[JohnCz]

I'd rather use WinAPI than MFC.

Could you please share with us how long have you been using WinAPI vs. MFC vs. other framework?

MFC is just bad - I find it hard to even call it object-oriented.

Could you please elaborate? What is disqualifying MFC as object oriented?

.The only promising thing in the future seems to be WinRT.

Well, correct me if I am wrong: WinRT is a toolkit used by some to develop drivers. It has nothing to do with programming Windows applications. How promising could that be for applications developers?

[VictorN]

I'd rather use WinAPI than MFC. MFC is just bad - I find it hard to even call it object-oriented.

What is so "bad" in MFC that makes you rather use WinAPI than MFC?

[Bssldr]

Could you please share with us how long have you been using WinAPI vs. MFC vs. other framework?
Could you please elaborate? What is disqualifying MFC as object oriented?
Well, correct me if I am wrong: WinRT is a toolkit used by some to develop drivers. It has nothing to do with programming Windows applications. How promising could that be for applications developers?

What is so "bad" in MFC that makes you rather use WinAPI than MFC?

WinRT - http://arstechnica.com/microsoft/new...m-reborn.ars/2

Now about MFC. Modern - returning BOOL when there's bool, hungarian notation? Object oriented - global functions, class methods that are nothing more than WinAPI functions throwed into meaningful classes? Honestly, come on. I'll just use Qt for GUI and since I program for Windows only I'll use WinAPI for the rest - the way MFC mixes C and C++ makes me want to throw up.

[Arjay]

Complaining about BOOL and hungarian notation? Really?

BOOL existed before there was a boolean data type in C++. Should the MFC folks switch BOOL (an int) to bool and chance breaking existing code?

Nothing wrong with Hungarian notation. Remember, it was handy before IDE's could tell you datatypes with intellisense or by hovering over variables. Do you think it would be a good idea to rename MFC variables as well?

In fact, it isn't surprising that MFC is a bit dated, as it was first designed in the Win 3.1 timeframe for 16-bit Windows. Back then, there was a big push to get folks to start writing apps for 32-bit Windows, so it wouldn't have been a good idea to drastically change the classes.

That's kind of the problem with a framework that achieves the success that MFC has - you can't really alter it much without the risk of breaking your users.

As an alternative to MFC, you might want to check out ATL (um, WTL). Since it uses templates, it's a bit more modern than MFC.