My Windows API Idea...Any Thoughts?

Ok, I have been playing around with the Windows API for a while now. It's great, sure, but it's also hard and complicated to learn. I have to write 20 lines of code to get a file from the internet, not to mention all the types and everything that I have to get around. So, I had a thought today.

I don't know if any of you have heard of AutoIt. It's an interpreted language that in my mind is like a translation of C++ and the Windows API to something simpler and easier to use, great for someone that's just learning! Alas, it comes at a price. It's slower than hell. (Interpreted language). So, here's my idea. No promises, because it's quite a large undertaking.

Create a C++ library that contains functions to make the whole Windows.h experience easier, more enjoyable, and just as fast (well...like 95% as fast). Some functions in the library will be as simple as throwing and int cast in front of a function and returning it. Others...more complex. It will hide all the dirty details from the user, and if the complicated inner workings of Windows.h need to show its ugly head, the library's functions will at least convert the error codes to something a little more manageable, as in a plain text error ('out of memory' as oppose to 'error code 10045' or something). Using AutoIt as an example, I hope to eventually have something as useful, a million times faster, and at some point, more comprehensive. Consider this a long term goal. http://www.autoitscript.com/autoit3/docs/functions.htm

What do you guys think? Has it already been done? Think it's a stupid idea? Love it? Hate it? I would love any feedback at all, good or bad.

Thanks in advance!
Not trying to pour cold water on your idea but IT is always evolving. The current or at least in the next few years, mobile software development will be fiery hot. Won't it make more sense to go into mobile development instead ?

Your idea is good maybe apply to the *new" Windows Mobile instead of the desktop Windows. It surprises me M$ is so late into the mobile arena (although their previous WinCE was a flop IMO) but the newly rejuvenated Windows Mobile will be hot property next year :P

As always I stick to my Android. Until M$ show more promise in their Windows Mobile else I intend to monitor the situation and see how.
I suppose that's true, but at the moment Windows is the platform with the most market share. Perhaps in the next few years, yes, mobile devices will have the majority...so...I guess I have my deadline then. ;P
Its already been done caseymdk. Not once, but many times. Visual Basic is one example, .NET another. Yet another would be MFC. Still another would be OWL. Ad Infinitum. PowerBASIC has a wrapper implementation on the Windows Dialog Engine that produces fast, small GUI programs with just a few lines of code. Its called DDT (Dynamic Dialog Tools). Other languages similiarly.

If you think C++ is hard, or the Windows Api involved, you are right. That is something you should know up front before you even start. If you are looking for an easy ways out, you should choose a different language. I tend to think C++ is for those willing to bite the bullet and learn how things really work at a low level and with all the small details - nothing left out.

I hate Windows mobile and cell phones. Don't have any. Windows CE is great. Windows Mobile is a crippled version of it. I call it 'cripple ware'. All this IMNSHO, of course.
I don't think c++ is hard, I think the way the Windows API changes it is hard. :P While it is true that there are other library's, I would like to get it to a point where someone very early into the programming game won't get intimidated when he sees a 'class', or 'struct', but will still be able to use the full (well...mostly full) potential on the Windows API with an understanding of variables, ints, functions, and parameters, which will only be of type int or char.

I don't know, when I first started doing C++, I didn't like it because I was like "Well, ok, but how do you DO stuff besides print things to a screen? And printf, whats the diff from cout??? ok, i get the variable in the string, but why the hell is it sometimes a %u and sometimes a %d???!!!!"

I want to try to erase that confusion completely.
I'm sceptical.
Can you pick just one something from the API/windows.h and demonstrate to us??
Last edited on
Well, for example, http://msdn.microsoft.com/en-us/library/aa384257%28v=VS.85%29.aspx

The WinHttp functions.

Getting a file from an http server is something that the average Joe programmer might want to do. I would simply make some function like HttpGetFile(), and with it, streamline the process of calling...

WinHttpOpen()
WinHttpConnect()
WinHttpOpenRequest()
WinHttpSendRequest()
WinHttpReceiveResponse()
WinHttpReadData()
WinHttpQueryDataAvailable()

...and the loops and such needed, shown here. http://msdn.microsoft.com/en-us/library/aa384104%28v=VS.85%29.aspx

After that, the library will free the memory used by that function, and return something simple, like a pointer to a char pointer allocated with 'new' that would be managed by the library.

See the appeal? The user would be using a very simple interface that's fast, while still using C++. They don't need to learn structs, pointers, and classes, but still can if they want to.
In terms of the printf verses cout thing, I’ve been trying to figure that out for 12 years. What I mean is, I can’t understand for the life of me why iostream was ever created, why it continues to exist, and why anyone (everyone but me I guess) uses it. With GNU CodeBlocks optimizing for small size and with debug symbols removed, this…

1
2
3
4
5
6
7
8
#include <iostream>
using namespace std;

int main()
{
 cout << "Hello world!" << endl;
 return 0;
}


Produces a Hello, World! And compiles to 457K. This…

1
2
3
4
5
6
7
#include <stdio.h>

int main()
{
 printf("Hello world!\n");
 return 0;
}


Does the same thing and compiles to 6K. That’s 76 times bigger!

The format specifiers tell printf how to interpret the result, i.e., signed number, unsigned number, string, etc. Very useful. When moving on from console programming to GUI programming iostream isn’t much use, but the C Standard Library stdio functions are still much used and very useful.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdio.h>

int main()
{
 char szBuffer[]="Hello, World!";
 printf
 (
  "%s\t%u\n",            //Format Specifier
  szBuffer,              //Interpret szBuffer as a NULL terminated char string
  (unsigned)szBuffer);   //Interpret it as an address
 return 0;
}

//Output
//Hello, World!   2293554 


The Windows Api is a beautiful thing for those with an eye for it. I believe it’s a work of genius myself. A thing of unbelievable intellectual elegance and beauty. With the CreateWindow() call you can create a main program window, any standard or common control, a custom control, or an ActiveX control. All this from just varying the parameters of the call. I have never found any other GUI framework for any operating System this elegant. My personal feeling is that class frameworks mutilate it, so I don’t use them. But to each his own.

I agree as well as to why cout is useful. :P What I'm hoping to do is keep people from being put off C++ by using simpler functions to interact with Windows (although not necessarily a new printf, that would be over simplifying). When I wanted to learn C++, things like this were what made me wait until later to figure it out. I think the Windows API is great, but people just learning C++ might not think so...that's really who I'm aiming for.
Sorry old chap - but absolutely no way.

(well until we get Star Trek holograph suite technology )
IMO the guys behind the Windows API and TechNet deserve a Nobel Prize. I learned C++ on my own and it wasn't the three schools I attended afterwards that taught me why OOP is useful, nor was it the 12 books on C++ I've aquired over the years, it was MSDN and the Windows API.

My only complaint about the Windows API is that it could overload its functions more. One example: CreateProcess(...)
http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx
A basic function that takes information from the programmer and uses it to start a program then returns a Bool. It requires 10 arguments, only two of which would contain the name of the program that CreateProcess(...) is suppossed to start. Logically if I only pass it a string, WTF do you suppose that string is? The name of the program perhaps? You could say that argument 10 the ProcessInformation structure is important and I will agree with you, but that's TWO arguments down from TEN! C++ allows you to overload as many functions as you would like with as many versions as long as none overlap, but for some reason Microsoft stopped short of taking advantage of this wonderful feature.
Do you really think that people who are just learning C++ would object to this? I don't mean to sound rude, but, please share...I don't see the objection that people who just want it to work would have. Yes, after the years of learning you are talking about, using the API by itself would make sense, but until then...what would be the objection? I'm not thinking veteran programmers would use this at all, I'm talking about people who just downloaded MSVC.
In that case then they're actually hurting them selfs. Whenever you learn to do something the easy way, it becomes that much more difficult to learn it the otherway. Take someone who has driven automatic their whole life and throw them in a stick shift see what happens. Both tasks involve the same basic hand eye coordination and the same traffic laws they are both done on the same streets with the same crowds of people and both tasks go for the same end result. Yet the person who must for one reason or another drive stick all of a sudden will struggle while they relearn something they've been doing for half their life or more. It goes double in the world of programming, so many of the tricks we use almost unconsiously are only possible because of the layer that everything we know is built on. If we were forced into doing something that C++ wasn't designed for anyone of us would have trouble wrapping our heads around it.

I think the best thing you can do is write a library for your self and don't try to force anyone else to rely on it.
Yes, I do see your point there...I learned on a stick because of that. :/ Well, thanks everyone for the input.
closed account (3pj6b7Xj)
Hey Casey, sorry to hear you are having trouble with the API, yes it is very time consuming. I had been programming in DOS for a some years and never really liked the windows API. I was always discouraged by the amount of code it took just to create a simple application window but I started again, didn't give up on it and started writing classes that would make the whole proccess easier.

We all have to work from the ground up, everything is time consuming when you have no code to help you out.

I personally don't think the windows api is hard anymore, it is just a matter of understanding how it works and what you can do to make tasks easier.

One of the first thing I sat down and did on the windows api was create a class that would construct windows applications for me in plain english, with out the bloat, I didn't wanted to be concerned with creating a class, registering a class, creating a window or this and that, isntead I wrote a class that filled in default values but still allowed me to change any of the window application paramters before displaying the window.

After I was done with that and I still work on it from time to time making improvements, my tasks become easier.

I say start from the ground up before you focus on your end result or you will be overwhelmed with it all.
Topic archived. No new replies allowed.